Skip to content

L
linux

Linux-御风守护者 / linux
与 Fork 源项目一致

从无法访问的项目Fork

通知 1
Star 0
Fork 0
L
linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 10 10月, 2007 10 次提交
    • P
      locks: Fix potential OOPS in generic_setlease() · 85c59580
      由 Pavel Emelyanov 提交于 
      This code is run under lock_kernel(), which is dropped during
sleeping operations, so the following race is possible:

CPU1:                                CPU2:
  vfs_setlease();                    vfs_setlease();
  lock_kernel();
                                     lock_kernel(); /* spin */
  generic_setlease():
    ...
    for (before = ...)
    /* here we found some lease after
     * which we will insert the new one
     */
    fl = locks_alloc_lock();
    /* go to sleep in this allocation and
     * drop the BKL
     */
                                     generic_setlease():
                                       ...
                                       for (before = ...)
                                       /* here we find the "before" pointing
                                        * at the one we found on CPU1
                                        */
                                      ->fl_change(my_before, arg);
                                              lease_modify();
                                                     locks_free_lock();
                                                     /* and we freed it */
                                     ...
                                     unlock_kernel();
   locks_insert_lock(before, fl);
   /* OOPS! We have just tried to add the lease
    * at the tail of already removed one
    */

The similar races are already handled in other code - all the
allocations are performed before any checks/updates.

Thanks to Kamalesh Babulal for testing and for a bug report on an
earlier version.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Cc: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
      85c59580
    • P
      Use list_first_entry in locks_wake_up_blocks · f0c1cd0e
      由 Pavel Emelyanov 提交于 
      This routine deletes all the elements from the list
with the "while (!list_empty())" loop, and we already
have a list_first_entry() macro to help it look nicer :)
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      f0c1cd0e
    • J
      locks: fix flock_lock_file() comment · 02888f41
      由 J. Bruce Fields 提交于 
      This comment wasn't updated when lease support was added, and it makes
essentially the same mistake that the code made before a recent bugfix.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      02888f41
    • P
      Memory shortage can result in inconsistent flocks state · 84d535ad
      由 Pavel Emelyanov 提交于 
      When the flock_lock_file() is called to change the flock
from F_RDLCK to F_WRLCK or vice versa the existing flock
can be removed without appropriate warning.

Look:
        for_each_lock(inode, before) {
                struct file_lock *fl = *before;
                if (IS_POSIX(fl))
                        break;
                if (IS_LEASE(fl))
                        continue;
                if (filp != fl->fl_file)
                        continue;
                if (request->fl_type == fl->fl_type)
                        goto out;
                found = 1;
                locks_delete_lock(before); <<<<<< !
                break;
        }

if after this point the subsequent locks_alloc_lock() will
fail the return code will be -ENOMEM, but the existing lock
is already removed.

This is a known feature that such "re-locking" is not atomic,
but in the racy case the file should stay locked (although by
some other process), but in this case the file will be unlocked.

The proposal is to prepare the lock in advance keeping no chance
to fail in the future code.

Found during making the flocks pid-namespaces aware.

(Note: Thanks to Reuben Farrelly for finding a bug in an earlier version
of this patch.)
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Cc: Reuben Farrelly <reuben-linuxkernel@reub.net>
      84d535ad
    • J
      locks: kill redundant local variable · 526985b9
      由 J. Bruce Fields 提交于 
      There's no need for another variable local to this loop; we can use the
variable (of the same name!) already declared at the top of the function,
and not used till later (at which point it's initialized, so this is safe).
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      526985b9
    • J
      locks: reverse order of posix_locks_conflict() arguments · b842e240
      由 J. Bruce Fields 提交于 
      The first argument to posix_locks_conflict() is meant to be a lock request,
and the second a lock from an inode's lock request.  It doesn't really
make a difference which order you call them in, since the only
asymmetric test in posix_lock_conflict() is the check whether the second
argument is a posix lock--and every caller already does that check for
some reason.

But may as well fix posix_test_lock() to call posix_locks_conflict()
with the arguments in the same order as everywhere else.
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
      b842e240
    • L
      Linux 2.6.23 · bbf25010
      由 Linus Torvalds 提交于
      bbf25010
    • L
      Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus · 5df3e0d9
      由 Linus Torvalds 提交于 
      * 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  [MIPS] Au1000: set the PCI controller IO base
  [MIPS] Alchemy: Fix USB initialization.
  [MIPS] IP32: Fix fatal typo in address computation.
      5df3e0d9
    • T
      NLM: Fix a memory leak in nlmsvc_testlock · a6d85430
      由 Trond Myklebust 提交于 
      The recent fix for a circular lock dependency unfortunately introduced a
potential memory leak in the event where the call to nlmsvc_lookup_host
fails for some reason.

Thanks to Roel Kluin for spotting this.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a6d85430
    • J
      sata_mv: correct S/G table limits · baf14aa1
      由 Jeff Garzik 提交于 
      The recent mv_fill_sg() rewrite, to fix a data corruption problem
related to IOMMU virtual merging, forgot to account for the
potentially-increased size of the scatter/gather table after its run.

Additionally, the DMA boundary is reduced from 0xffffffff to 0xffff
to more closely match the needs of mv_fill_sg().
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      baf14aa1
  3. 09 10月, 2007 10 次提交
  5. 08 10月, 2007 15 次提交
  7. 07 10月, 2007 5 次提交