linux-toradex.git/fs/locks.c, branch v3.16.3

locks: set fl_owner for leases back to current->files

2014-06-10T16:29:05+00:00

This fixes a regression due to commit 130d1f956ab3 (locks: ensure that
fl_owner is always initialized properly in flock and lease codepaths). I
had mistakenly thought that the fl_owner wasn't used in the lease code,
but I missed the place in __break_lease that does use it.

The i_have_this_lease check in generic_add_lease uses it. While I'm not
sure that check is terribly helpful [1], reset it back to using
current->files in order to ensure that there's no behavior change here.

[1]: leases are owned by the file description. It's possible that this
     is a threaded program, and the lease breaker and the task that
     would handle the signal are different, even if they have the same
     file table. So, there is the potential for false positives with
     this check.

Fixes: 130d1f956ab3 (locks: ensure that fl_owner is always initialized properly in flock and lease codepaths)
Signed-off-by: Jeff Layton

locks: add some tracepoints in the lease handling code

2014-06-02T12:09:30+00:00

v2: add a __break_lease tracepoint for non-blocking case

Recently, I needed these to help track down a softlockup when recalling a
delegation, but they might be helpful in other situations as well.

Cc: "J. Bruce Fields" 
Signed-off-by: Jeff Layton

fs/locks.c: replace seq_printf by seq_puts

2014-06-02T12:09:29+00:00

Replace seq_printf where possible

Cc: Jeff Layton 
Cc: Alexander Viro 
Cc: Andrew Morton 
Signed-off-by: Fabian Frederick 
Signed-off-by: Jeff Layton

locks: ensure that fl_owner is always initialized properly in flock and lease codepaths

2014-06-02T12:09:29+00:00

Currently, the fl_owner isn't set for flock locks. Some filesystems use
byte-range locks to simulate flock locks and there is a common idiom in
those that does:

    fl->fl_owner = (fl_owner_t)filp;
    fl->fl_start = 0;
    fl->fl_end = OFFSET_MAX;

Since flock locks are generally "owned" by the open file description,
move this into the common flock lock setup code. The fl_start and fl_end
fields are already set appropriately, so remove the unneeded setting of
that in flock ops in those filesystems as well.

Finally, the lease code also sets the fl_owner as if they were owned by
the process and not the open file description. This is incorrect as
leases have the same ownership semantics as flock locks. Set them the
same way. The lease code doesn't actually use the fl_owner value for
anything, so this is more for consistency's sake than a bugfix.

Reported-by: Trond Myklebust 
Signed-off-by: Jeff Layton 
Acked-by: Greg Kroah-Hartman  (Staging portion)
Acked-by: J. Bruce Fields

locks: only validate the lock vs. f_mode in F_SETLK codepaths

2014-05-09T15:41:54+00:00

v2: replace missing break in switch statement (as pointed out by Dave
    Jones)

commit bce7560d4946 (locks: consolidate checks for compatible
filp->f_mode values in setlk handlers) introduced a regression in the
F_GETLK handler.

flock64_to_posix_lock is a shared codepath between F_GETLK and F_SETLK,
but the f_mode checks should only be applicable to the F_SETLK codepaths
according to POSIX.

Instead of just reverting the patch, add a new function to do this
checking and have the F_SETLK handlers call it.

Cc: Dave Jones 
Reported-and-Tested-by: Reuben Farrelly 
Signed-off-by: Jeff Layton

locks: rename FL_FILE_PVT and IS_FILE_PVT to use "*_OFDLCK" instead

2014-04-23T20:17:03+00:00

File-private locks have been re-christened as "open file description"
locks.  Finish the symbol name cleanup in the internal implementation.

Signed-off-by: Jeff Layton

locks: rename file-private locks to "open file description locks"

2014-04-22T12:23:58+00:00

File-private locks have been merged into Linux for v3.15, and *now*
people are commenting that the name and macro definitions for the new
file-private locks suck.

...and I can't even disagree. The names and command macros do suck.

We're going to have to live with these for a long time, so it's
important that we be happy with the names before we're stuck with them.
The consensus on the lists so far is that they should be rechristened as
"open file description locks".

The name isn't a big deal for the kernel, but the command macros are not
visually distinct enough from the traditional POSIX lock macros. The
glibc and documentation folks are recommending that we change them to
look like F_OFD_{GETLK|SETLK|SETLKW}. That lessens the chance that a
programmer will typo one of the commands wrong, and also makes it easier
to spot this difference when reading code.

This patch makes the following changes that I think are necessary before
v3.15 ships:

1) rename the command macros to their new names. These end up in the uapi
   headers and so are part of the external-facing API. It turns out that
   glibc doesn't actually use the fcntl.h uapi header, but it's hard to
   be sure that something else won't. Changing it now is safest.

2) make the the /proc/locks output display these as type "OFDLCK"

Cc: Michael Kerrisk 
Cc: Christoph Hellwig 
Cc: Carlos O'Donell 
Cc: Stefan Metzmacher 
Cc: Andy Lutomirski 
Cc: Frank Filz 
Cc: Theodore Ts'o 
Signed-off-by: Jeff Layton

locks: allow __break_lease to sleep even when break_time is 0

2014-04-15T10:17:49+00:00

A fl->fl_break_time of 0 has a special meaning to the lease break code
that basically means "never break the lease". knfsd uses this to ensure
that leases don't disappear out from under it.

Unfortunately, the code in __break_lease can end up passing this value
to wait_event_interruptible as a timeout, which prevents it from going
to sleep at all. This makes __break_lease to spin in a tight loop and
causes soft lockups.

Fix this by ensuring that we pass a minimum value of 1 as a timeout
instead.

Cc: 
Cc: J. Bruce Fields 
Reported-by: Terry Barnaby 
Signed-off-by: Jeff Layton

locks: make locks_mandatory_area check for file-private locks

2014-03-31T12:24:43+00:00

Allow locks_mandatory_area() to handle file-private locks correctly.
If there is a file-private lock set on an open file and we're doing I/O
via the same, then that should not cause anything to block.

Handle this by first doing a non-blocking FL_ACCESS check for a
file-private lock, and then fall back to checking for a classic POSIX
lock (and possibly blocking).

Note that this approach is subject to the same races that have always
plagued mandatory locking on Linux.

Reported-by: Trond Myklebust 
Signed-off-by: Jeff Layton

locks: fix locks_mandatory_locked to respect file-private locks

2014-03-31T12:24:43+00:00

As Trond pointed out, you can currently deadlock yourself by setting a
file-private lock on a file that requires mandatory locking and then
trying to do I/O on it.

Avoid this problem by plumbing some knowledge of file-private locks into
the mandatory locking code. In order to do this, we must pass down
information about the struct file that's being used to
locks_verify_locked.

Reported-by: Trond Myklebust 
Signed-off-by: Jeff Layton 
Acked-by: J. Bruce Fields