Skip to content

cloud-kernel
cloud-kernel

bug2833 / cloud-kernel
与 Fork 源项目一致

Fork自 openanolis / cloud-kernel

通知 1
Star 0
Fork 0
cloud-kernel
cloud-kernel

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

切换分支/标签
  1. 21 3月, 2006 2 次提交
  3. 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
  5. 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
  7. 14 11月, 2005 2 次提交
  9. 19 10月, 2005 1 次提交
  11. 24 9月, 2005 1 次提交
  13. 18 9月, 2005 1 次提交
  15. 10 9月, 2005 1 次提交
  17. 28 7月, 2005 1 次提交
    • P
      [PATCH] stale POSIX lock handling · c293621b
      由 Peter Staubach 提交于 
      I believe that there is a problem with the handling of POSIX locks, which
the attached patch should address.

The problem appears to be a race between fcntl(2) and close(2).  A
multithreaded application could close a file descriptor at the same time as
it is trying to acquire a lock using the same file descriptor.  I would
suggest that that multithreaded application is not providing the proper
synchronization for itself, but the OS should still behave correctly.

SUS3 (Single UNIX Specification Version 3, read: POSIX) indicates that when
a file descriptor is closed, that all POSIX locks on the file, owned by the
process which closed the file descriptor, should be released.

The trick here is when those locks are released.  The current code releases
all locks which exist when close is processing, but any locks in progress
are handled when the last reference to the open file is released.

There are three cases to consider.

One is the simple case, a multithreaded (mt) process has a file open and
races to close it and acquire a lock on it.  In this case, the close will
release one reference to the open file and when the fcntl is done, it will
release the other reference.  For this situation, no locks should exist on
the file when both the close and fcntl operations are done.  The current
system will handle this case because the last reference to the open file is
being released.

The second case is when the mt process has dup(2)'d the file descriptor.
The close will release one reference to the file and the fcntl, when done,
will release another, but there will still be at least one more reference
to the open file.  One could argue that the existence of a lock on the file
after the close has completed is okay, because it was acquired after the
close operation and there is still a way for the application to release the
lock on the file, using an existing file descriptor.

The third case is when the mt process has forked, after opening the file
and either before or after becoming an mt process.  In this case, each
process would hold a reference to the open file.  For each process, this
degenerates to first case above.  However, the lock continues to exist
until both processes have released their references to the open file.  This
lock could block other lock requests.

The changes to release the lock when the last reference to the open file
aren't quite right because they would allow the lock to exist as long as
there was a reference to the open file.  This is too long.

The new proposed solution is to add support in the fcntl code path to
detect a race with close and then to release the lock which was just
acquired when such as race is detected.  This causes locks to be released
in a timely fashion and for the system to conform to the POSIX semantic
specification.

This was tested by instrumenting a kernel to detect the handling locks and
then running a program which generates case #3 above.  A dangling lock
could be reliably generated.  When the changes to detect the close/fcntl
race were added, a dangling lock could no longer be generated.

Cc: Matthew Wilcox <willy@debian.org>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c293621b
  19. 08 7月, 2005 1 次提交
  21. 23 6月, 2005 1 次提交
  23. 06 5月, 2005 1 次提交
  25. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4