1. 07 5月, 2007 2 次提交
  2. 17 4月, 2007 2 次提交
  3. 09 12月, 2006 1 次提交
  4. 08 12月, 2006 2 次提交
  5. 02 10月, 2006 1 次提交
  6. 01 10月, 2006 1 次提交
  7. 15 8月, 2006 1 次提交
  8. 06 7月, 2006 2 次提交
  9. 23 6月, 2006 6 次提交
    • A
      [PATCH] fs/locks.c: make posix_locks_deadlock() static · b0904e14
      Adrian Bunk 提交于
      We can now make posix_locks_deadlock() static.
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b0904e14
    • M
      [PATCH] vfs: add lock owner argument to flush operation · 75e1fcc0
      Miklos Szeredi 提交于
      Pass the POSIX lock owner ID to the flush operation.
      
      This is useful for filesystems which don't want to store any locking state
      in inode->i_flock but want to handle locking/unlocking POSIX locks
      internally.  FUSE is one such filesystem but I think it possible that some
      network filesystems would need this also.
      
      Also add a flag to indicate that a POSIX locking request was generated by
      close(), so filesystems using the above feature won't send an extra locking
      request in this case.
      Signed-off-by: NMiklos Szeredi <miklos@szeredi.hu>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      75e1fcc0
    • M
      [PATCH] locks: clean up locks_remove_posix() · ff7b86b8
      Miklos Szeredi 提交于
      locks_remove_posix() can use posix_lock_file() instead of doing the lock
      removal by hand.  posix_lock_file() now does exacly the same.
      
      The comment about pids no longer applies, posix_lock_file() takes only the
      owner into account.
      Signed-off-by: NMiklos Szeredi <miklos@szeredi.hu>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ff7b86b8
    • M
      [PATCH] locks: don't do unnecessary allocations · 39005d02
      Miklos Szeredi 提交于
      posix_lock_file() always allocates new locks in advance, even if it's easy to
      determine that no allocations will be needed.
      
      Optimize these cases:
      
       - FL_ACCESS flag is set
      
       - Unlocking the whole range
      Signed-off-by: NMiklos Szeredi <miklos@szeredi.hu>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      39005d02
    • M
      [PATCH] locks: don't unnecessarily fail posix lock operations · 0d9a490a
      Miklos Szeredi 提交于
      posix_lock_file() was too cautious, failing operations on OOM, even if they
      didn't actually require an allocation.
      
      This has the disadvantage, that a failing unlock on process exit could lead to
      a memory leak.  There are two possibilites for this:
      
      - filesystem implements .lock() and calls back to posix_lock_file().  On
      cleanup of files_struct locks_remove_posix() is called which should remove all
      locks belonging to files_struct.  However if filesystem calls
      posix_lock_file() which fails, then those locks will never be freed.
      
      - if a file is closed while a lock is blocked, then after acquiring
      fcntl_setlk() will undo the lock.  But this unlock itself might fail on OOM,
      again possibly leaking the lock.
      
      The solution is to move the checking of the allocations until after it is sure
      that they will be needed.  This will solve the above problem since unlock will
      always succeed unless it splits an existing region.
      Signed-off-by: NMiklos Szeredi <miklos@szeredi.hu>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0d9a490a
    • M
      [PATCH] remove steal_locks() · c89681ed
      Miklos Szeredi 提交于
      This patch removes the steal_locks() function.
      
      steal_locks() doesn't work correctly with any filesystem that does it's own
      lock management, including NFS, CIFS, etc.
      
      In addition it has weird semantics on local filesystems in case tasks
      sharing file-descriptor tables are doing POSIX locking operations in
      parallel to execve().
      
      The steal_locks() function has an effect on applications doing:
      
      clone(CLONE_FILES)
        /* in child */
        lock
        execve
        lock
      
      POSIX locks acquired before execve (by "child", "parent" or any further
      task sharing files_struct) will after the execve be owned exclusively by
      "child".
      
      According to Chris Wright some LSB/LTP kind of suite triggers without the
      stealing behavior, but there's no known real-world application that would
      also fail.
      
      Apps using NPTL are not affected, since all other threads are killed before
      execve.
      
      Apps using LinuxThreads are only affected if they
      
        - have multiple threads during exec (LinuxThreads doesn't kill other
          threads, the app may do it with pthread_kill_other_threads_np())
        - rely on POSIX locks being inherited across exec
      
      Both conditions are documented, but not their interaction.
      
      Apps using clone() natively are affected if they
      
        - use clone(CLONE_FILES)
        - rely on POSIX locks being inherited across exec
      
      The above scenarios are unlikely, but possible.
      
      If the patch is vetoed, there's a plan B, that involves mostly keeping the
      weird stealing semantics, but changing the way lock ownership is handled so
      that network and local filesystems work consistently.
      
      That would add more complexity though, so this solution seems to be
      preferred by most people.
      Signed-off-by: NMiklos Szeredi <miklos@szeredi.hu>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Steven French <sfrench@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c89681ed
  10. 14 6月, 2006 1 次提交
  11. 08 5月, 2006 1 次提交
  12. 20 4月, 2006 1 次提交
  13. 01 4月, 2006 2 次提交
  14. 27 3月, 2006 3 次提交
  15. 21 3月, 2006 5 次提交
  16. 09 1月, 2006 1 次提交
    • M
      [PATCH] tiny: Uninline some fslocks.c functions · 33443c42
      Matt Mackall 提交于
      uninline some file locking functions
      
      add/remove: 3/0 grow/shrink: 0/15 up/down: 256/-1525 (-1269)
      function                                     old     new   delta
      locks_free_lock                                -     134    +134
      posix_same_owner                               -      69     +69
      __locks_delete_block                           -      53     +53
      posix_locks_conflict                         126     108     -18
      locks_remove_posix                           266     237     -29
      locks_wake_up_blocks                         121      87     -34
      locks_block_on_timeout                        83      47     -36
      locks_insert_block                           157     120     -37
      locks_delete_block                            62      23     -39
      posix_unblock_lock                           104      59     -45
      posix_locks_deadlock                         162     100     -62
      locks_delete_lock                            228     119    -109
      sys_flock                                    338     217    -121
      __break_lease                                600     474    -126
      lease_init                                   252     122    -130
      fcntl_setlk64                                793     649    -144
      fcntl_setlk                                  793     649    -144
      __posix_lock_file                           1477    1026    -451
      Signed-off-by: NMatt Mackall <mpm@selenic.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      33443c42
  17. 07 1月, 2006 2 次提交
    • J
      NLM: Further cancel fixes · 64a318ee
      J. Bruce Fields 提交于
       If the server receives an NLM cancel call and finds no waiting lock to
       cancel, then chances are the lock has already been applied, and the client
       just hadn't yet processed the NLM granted callback before it sent the
       cancel.
      
       The Open Group text, for example, perimts a server to return either success
       (LCK_GRANTED) or failure (LCK_DENIED) in this case.  But returning an error
       seems more helpful; the client may be able to use it to recognize that a
       race has occurred and to recover from the race.
      
       So, modify the relevant functions to return an error in this case.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      64a318ee
    • J
      NLM: don't unlock on cancel requests · 5996a298
      J. Bruce Fields 提交于
       Currently when lockd gets an NLM_CANCEL request, it also does an unlock for
       the same range.  This is incorrect.
      
       The Open Group documentation says that "This procedure cancels an
       *outstanding* blocked lock request."  (Emphasis mine.)
      
       Also, consider a client that holds a lock on the first byte of a file, and
       requests a lock on the entire file.  If the client cancels that request
       (perhaps because the requesting process is signalled), the server shouldn't
       apply perform an unlock on the entire file, since that will also remove the
       previous lock that the client was already granted.
      
       Or consider a lock request that actually *downgraded* an exclusive lock to
       a shared lock.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      5996a298
  18. 14 11月, 2005 2 次提交
  19. 19 10月, 2005 1 次提交
  20. 24 9月, 2005 1 次提交
  21. 18 9月, 2005 1 次提交
  22. 10 9月, 2005 1 次提交