1. 15 5月, 2012 2 次提交
    • K
      printk() - isolate KERN_CONT users from ordinary complete lines · c313af14
      Kay Sievers 提交于
      Arrange the continuation printk() buffering to be fully separated from the
      ordinary full line users.
      
      Limit the exposure to races and wrong printk() line merges to users of
      continuation only. Ordinary full line users racing against continuation
      users will no longer affect each other.
      
      Multiple continuation users from different threads, racing against each
      other will not wrongly be merged into a single line, but printed as
      separate lines.
      
      Test output of a kernel module which starts two separate threads which
      race against each other, one of them printing a single full terminated
      line:
        printk("(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)\n");
      
      The other one printing the line, every character separate in a
      continuation loop:
        printk("(C");
        for (i = 0; i < 58; i++)
                printk(KERN_CONT "C");
        printk(KERN_CONT "C)\n");
      
      Behavior of single and non-thread-aware printk() buffer:
        # modprobe printk-race
        printk test init
        (CC(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        CC(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        CC(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        CC(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        C(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC)
        (CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC)
      
      New behavior with separate and thread-aware continuation buffer:
        # modprobe printk-race
        printk test init
        (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        (CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC)
        (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
        (CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC)
        (CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC)
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: Ted Ts'o <tytso@mit.edu>
      Cc: Ingo Molnar  <mingo@kernel.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Sasha Levin <levinsasha928@gmail.com>
      Signed-off-by: NKay Sievers <kay@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c313af14
    • A
      sysfs: get rid of some lockdep false positives · 356c05d5
      Alan Stern 提交于
      This patch (as1554) fixes a lockdep false-positive report.  The
      problem arises because lockdep is unable to deal with the
      tree-structured locks created by the device core and sysfs.
      
      This particular problem involves a sysfs attribute method that
      unregisters itself, not from the device it was called for, but from a
      descendant device.  Lockdep doesn't understand the distinction and
      reports a possible deadlock, even though the operation is safe.
      
      This is the sort of thing that would normally be handled by using a
      nested lock annotation; unfortunately it's not feasible to do that
      here.  There's no sensible way to tell sysfs when attribute removal
      occurs in the context of a parent attribute method.
      
      As a workaround, the patch adds a new flag to struct attribute
      telling sysfs not to inform lockdep when it acquires a readlock on a
      sysfs_dirent instance for the attribute.  The readlock is still
      acquired, but lockdep doesn't know about it and hence does not
      complain about impossible deadlock scenarios.
      
      Also added are macros for static initialization of attribute
      structures with the ignore_lockdep flag set.  The three offending
      attributes in the USB subsystem are converted to use the new macros.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NTejun Heo <tj@kernel.org>
      CC: Eric W. Biederman <ebiederm@xmission.com>
      CC: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      356c05d5
  2. 14 5月, 2012 6 次提交
  3. 12 5月, 2012 5 次提交
  4. 11 5月, 2012 3 次提交
  5. 10 5月, 2012 5 次提交
  6. 09 5月, 2012 1 次提交
  7. 08 5月, 2012 11 次提交
  8. 05 5月, 2012 7 次提交