linux.git/fs/locks.c, branch v2.6.18

[PATCH] fcntl(F_SETSIG) fix

2006-08-14T20:10:59+00:00

fcntl(F_SETSIG) no longer works on leases because
lease_release_private_callback() gets called as the lease is copied in
order to initialise it.

The problem is that lease_alloc() performs an unnecessary initialisation,
which sets the lease_manager_ops.  Avoid the problem by allocating the
target lease structure using locks_alloc_lock().

Signed-off-by: Trond Myklebust 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

VFS: Add support for the FL_ACCESS flag to flock_lock_file()

2006-07-05T17:13:18+00:00

Signed-off-by: Trond Myklebust

VFS: Allow caller to determine if BSD or posix locks were actually freed

2006-07-05T17:13:17+00:00

Change posix_lock_file_conf(), and flock_lock_file() so that if called
with an F_UNLCK argument, and the FL_EXISTS flag they will indicate
whether or not any locks were actually freed by returning 0 or -ENOENT.

Signed-off-by: Trond Myklebust

[PATCH] fs/locks.c: make posix_locks_deadlock() static

2006-06-23T14:43:03+00:00

We can now make posix_locks_deadlock() static.

Signed-off-by: Adrian Bunk 
Cc: Trond Myklebust 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] vfs: add lock owner argument to flush operation

2006-06-23T14:43:02+00:00

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: Miklos Szeredi 
Cc: Trond Myklebust 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] locks: clean up locks_remove_posix()

2006-06-23T14:43:02+00:00

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: Miklos Szeredi 
Cc: Trond Myklebust 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] locks: don't do unnecessary allocations

2006-06-23T14:43:02+00:00

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: Miklos Szeredi 
Cc: Trond Myklebust 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] locks: don't unnecessarily fail posix lock operations

2006-06-23T14:43:02+00:00

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: Miklos Szeredi 
Cc: Trond Myklebust 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] remove steal_locks()

2006-06-22T22:05:57+00:00

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: Miklos Szeredi 
Cc: Trond Myklebust 
Cc: Matthew Wilcox 
Cc: Chris Wright 
Cc: Christoph Hellwig 
Cc: Steven French 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Return error in case flock_lock_file failure

2006-06-14T15:59:44+00:00

If flock_lock_file() failed to allocate flock with locks_alloc_lock()
then "error = 0" is returned. Need to return some non-zero.

Signed-off-by: Pavel Emelianov 
Signed-off-by: Kirill Korotaev 
Signed-off-by: Linus Torvalds