1. 19 7月, 2012 1 次提交
    • L
      Make wait_for_device_probe() also do scsi_complete_async_scans() · eea03c20
      Linus Torvalds 提交于
      Commit a7a20d10 ("sd: limit the scope of the async probe domain")
      make the SCSI device probing run device discovery in it's own async
      domain.
      
      However, as a result, the partition detection was no longer synchronized
      by async_synchronize_full() (which, despite the name, only synchronizes
      the global async space, not all of them).  Which in turn meant that
      "wait_for_device_probe()" would not wait for the SCSI partitions to be
      parsed.
      
      And "wait_for_device_probe()" was what the boot time init code relied on
      for mounting the root filesystem.
      
      Now, most people never noticed this, because not only is it
      timing-dependent, but modern distributions all use initrd.  So the root
      filesystem isn't actually on a disk at all.  And then before they
      actually mount the final disk filesystem, they will have loaded the
      scsi-wait-scan module, which not only does the expected
      wait_for_device_probe(), but also does scsi_complete_async_scans().
      
      [ Side note: scsi_complete_async_scans() had also been partially broken,
        but that was fixed in commit 43a8d39d ("fix async probe
        regression"), so that same commit a7a20d10 had actually broken
        setups even if you used scsi-wait-scan explicitly ]
      
      Solve this problem by just moving the scsi_complete_async_scans() call
      into wait_for_device_probe().  Everybody who wants to wait for device
      probing to finish really wants the SCSI probing to complete, so there's
      no reason not to do this.
      
      So now "wait_for_device_probe()" really does what the name implies, and
      properly waits for device probing to finish.  This also removes the now
      unnecessary extra calls to scsi_complete_async_scans().
      Reported-and-tested-by: NArtem S. Tashkinov <t.artem@mailcity.com>
      Cc: Dan Williams <dan.j.williams@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: James Bottomley <jbottomley@parallels.com>
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: linux-scsi <linux-scsi@vger.kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eea03c20
  2. 17 7月, 2012 1 次提交
  3. 15 7月, 2012 1 次提交
  4. 12 7月, 2012 7 次提交
  5. 10 7月, 2012 2 次提交
  6. 08 7月, 2012 2 次提交
    • T
      cgroup: fix cgroup hierarchy umount race · 5db9a4d9
      Tejun Heo 提交于
      48ddbe19 "cgroup: make css->refcnt clearing on cgroup removal
      optional" allowed a css to linger after the associated cgroup is
      removed.  As a css holds a reference on the cgroup's dentry, it means
      that cgroup dentries may linger for a while.
      
      Destroying a superblock which has dentries with positive refcnts is a
      critical bug and triggers BUG() in vfs code.  As each cgroup dentry
      holds an s_active reference, any lingering cgroup has both its dentry
      and the superblock pinned and thus preventing premature release of
      superblock.
      
      Unfortunately, after 48ddbe19, there's a small window while
      releasing a cgroup which is directly under the root of the hierarchy.
      When a cgroup directory is released, vfs layer first deletes the
      corresponding dentry and then invokes dput() on the parent, which may
      recurse further, so when a cgroup directly below root cgroup is
      released, the cgroup is first destroyed - which releases the s_active
      it was holding - and then the dentry for the root cgroup is dput().
      
      This creates a window where the root dentry's refcnt isn't zero but
      superblock's s_active is.  If umount happens before or during this
      window, vfs will see the root dentry with non-zero refcnt and trigger
      BUG().
      
      Before 48ddbe19, this problem didn't exist because the last dentry
      reference was guaranteed to be put synchronously from rmdir(2)
      invocation which holds s_active around the whole process.
      
      Fix it by holding an extra superblock->s_active reference across
      dput() from css release, which is the dput() path added by 48ddbe19
      and the only one which doesn't hold an extra s_active ref across the
      final cgroup dput().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      LKML-Reference: <4FEEA5CB.8070809@huawei.com>
      Reported-by: Nshyju pv <shyju.pv@huawei.com>
      Tested-by: Nshyju pv <shyju.pv@huawei.com>
      Cc: Sasha Levin <levinsasha928@gmail.com>
      Acked-by: NLi Zefan <lizefan@huawei.com>
      5db9a4d9
    • T
      Revert "cgroup: superblock can't be released with active dentries" · 7db5b3ca
      Tejun Heo 提交于
      This reverts commit fa980ca8.  The
      commit was an attempt to fix a race condition where a cgroup hierarchy
      may be unmounted with positive dentry reference on root cgroup.  While
      the commit made the race condition slightly more difficult to trigger,
      the race was still there and could be reliably triggered using a
      different test case.
      
      Revert the incorrect fix.  The next commit will describe the race and
      fix it correctly.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      LKML-Reference: <4FEEA5CB.8070809@huawei.com>
      Reported-by: Nshyju pv <shyju.pv@huawei.com>
      Cc: Sasha Levin <levinsasha928@gmail.com>
      Acked-by: NLi Zefan <lizefan@huawei.com>
      7db5b3ca
  7. 07 7月, 2012 5 次提交
  8. 06 7月, 2012 2 次提交
  9. 03 7月, 2012 1 次提交
  10. 01 7月, 2012 1 次提交
  11. 30 6月, 2012 3 次提交
  12. 29 6月, 2012 1 次提交
    • K
      printk: flush continuation lines immediately to console · 084681d1
      Kay Sievers 提交于
      Continuation lines are buffered internally, intended to merge the
      chunked printk()s into a single record, and to isolate potentially
      racy continuation users from usual terminated line users.
      
      This though, has the effect that partial lines are not printed to
      the console in the moment they are emitted. In case the kernel
      crashes in the meantime, the potentially interesting printed
      information would never reach the consoles.
      
      Here we share the continuation buffer with the console copy logic,
      and partial lines are always immediately flushed to the available
      consoles. They are still buffered internally to improve the
      readability and integrity of the messages and minimize the amount
      of needed record headers to store.
      Signed-off-by: NKay Sievers <kay@vrfy.org>
      Tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      084681d1
  13. 27 6月, 2012 2 次提交
  14. 26 6月, 2012 2 次提交
  15. 21 6月, 2012 4 次提交
  16. 19 6月, 2012 1 次提交
  17. 18 6月, 2012 1 次提交
    • S
      perf: Use css_tryget() to avoid propping up css refcount · 9c5da09d
      Salman Qazi 提交于
      An rmdir pushes css's ref count to zero.  However, if the associated
      directory is open at the time, the dentry ref count is non-zero.  If
      the fd for this directory is then passed into perf_event_open, it
      does a css_get().  This bounces the ref count back up from zero.  This
      is a problem by itself.  But what makes it turn into a crash is the
      fact that we end up doing an extra dput, since we perform a dput
      when css_put sees the ref count go down to zero.
      
      css_tryget() does not fall into that trap. So, we use that instead.
      
      Reproduction test-case for the bug:
      
       #include <unistd.h>
       #include <sys/types.h>
       #include <sys/stat.h>
       #include <fcntl.h>
       #include <linux/unistd.h>
       #include <linux/perf_event.h>
       #include <string.h>
       #include <errno.h>
       #include <stdio.h>
      
       #define PERF_FLAG_PID_CGROUP    (1U << 2)
      
       int perf_event_open(struct perf_event_attr *hw_event_uptr,
                           pid_t pid, int cpu, int group_fd, unsigned long flags) {
               return syscall(__NR_perf_event_open,hw_event_uptr, pid, cpu,
                       group_fd, flags);
       }
      
       /*
        * Directly poke at the perf_event bug, since it's proving hard to repro
        * depending on where in the kernel tree.  what moved?
        */
       int main(int argc, char **argv)
       {
              int fd;
              struct perf_event_attr attr;
              memset(&attr, 0, sizeof(attr));
              attr.exclude_kernel = 1;
              attr.size = sizeof(attr);
              mkdir("/dev/cgroup/perf_event/blah", 0777);
              fd = open("/dev/cgroup/perf_event/blah", O_RDONLY);
              perror("open");
              rmdir("/dev/cgroup/perf_event/blah");
              sleep(2);
              perf_event_open(&attr, fd, 0, -1,  PERF_FLAG_PID_CGROUP);
              perror("perf_event_open");
              close(fd);
              return 0;
       }
      Signed-off-by: NSalman Qazi <sqazi@google.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NTejun Heo <tj@kernel.org>
      Link: http://lkml.kernel.org/r/20120614223108.1025.2503.stgit@dungbeetle.mtv.corp.google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9c5da09d
  18. 16 6月, 2012 3 次提交