Skip to content

L
linux
Switch branch/tag
  1. 31 Mar, 2014 16 commits
    • Jeff Layton's avatar
      locks: fix locks_mandatory_locked to respect file-private locks · d7a06983
      Jeff Layton authored 
      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: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Acked-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      d7a06983
    • Jeff Layton's avatar
      locks: require that flock->l_pid be set to 0 for file-private locks · 90478939
      Jeff Layton authored 
      Neil Brown suggested potentially overloading the l_pid value as a "lock
context" field for file-private locks. While I don't think we will
probably want to do that here, it's probably a good idea to ensure that
in the future we could extend this API without breaking existing
callers.

Typically the l_pid value is ignored for incoming struct flock
arguments, serving mainly as a place to return the pid of the owner if
there is a conflicting lock. For file-private locks, require that it
currently be set to 0 and return EINVAL if it isn't. If we eventually
want to make a non-zero l_pid mean something, then this will help ensure
that we don't break legacy programs that are using file-private locks.

Cc: Neil Brown <neilb@suse.de>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      90478939
    • Jeff Layton's avatar
      locks: add new fcntl cmd values for handling file private locks · 5d50ffd7
      Jeff Layton authored 
      Due to some unfortunate history, POSIX locks have very strange and
unhelpful semantics. The thing that usually catches people by surprise
is that they are dropped whenever the process closes any file descriptor
associated with the inode.

This is extremely problematic for people developing file servers that
need to implement byte-range locks. Developers often need a "lock
management" facility to ensure that file descriptors are not closed
until all of the locks associated with the inode are finished.

Additionally, "classic" POSIX locks are owned by the process. Locks
taken between threads within the same process won't conflict with one
another, which renders them useless for synchronization between threads.

This patchset adds a new type of lock that attempts to address these
issues. These locks conflict with classic POSIX read/write locks, but
have semantics that are more like BSD locks with respect to inheritance
and behavior on close.

This is implemented primarily by changing how fl_owner field is set for
these locks. Instead of having them owned by the files_struct of the
process, they are instead owned by the filp on which they were acquired.
Thus, they are inherited across fork() and are only released when the
last reference to a filp is put.

These new semantics prevent them from being merged with classic POSIX
locks, even if they are acquired by the same process. These locks will
also conflict with classic POSIX locks even if they are acquired by
the same process or on the same file descriptor.

The new locks are managed using a new set of cmd values to the fcntl()
syscall. The initial implementation of this converts these values to
"classic" cmd values at a fairly high level, and the details are not
exposed to the underlying filesystem. We may eventually want to push
this handing out to the lower filesystem code but for now I don't
see any need for it.

Also, note that with this implementation the new cmd values are only
available via fcntl64() on 32-bit arches. There's little need to
add support for legacy apps on a new interface like this.
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      5d50ffd7
    • Jeff Layton's avatar
      locks: skip deadlock detection on FL_FILE_PVT locks · 57b65325
      Jeff Layton authored 
      It's not really feasible to do deadlock detection with FL_FILE_PVT
locks since they aren't owned by a single task, per-se. Deadlock
detection also tends to be rather expensive so just skip it for
these sorts of locks.

Also, add a FIXME comment about adding more limited deadlock detection
that just applies to ro -> rw upgrades, per Andy's request.

Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      57b65325
    • Jeff Layton's avatar
      locks: pass the cmd value to fcntl_getlk/getlk64 · c1e62b8f
      Jeff Layton authored 
      Once we introduce file private locks, we'll need to know what cmd value
was used, as that affects the ownership and whether a conflict would
arise.
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      c1e62b8f
    • Jeff Layton's avatar
      locks: report l_pid as -1 for FL_FILE_PVT locks · 3fd80cdd
      Jeff Layton authored 
      FL_FILE_PVT locks are no longer tied to a particular pid, and are
instead inheritable by child processes. Report a l_pid of '-1' for
these sorts of locks since the pid is somewhat meaningless for them.

This precedent comes from FreeBSD. There, POSIX and flock() locks can
conflict with one another. If fcntl(F_GETLK, ...) returns a lock set
with flock() then the l_pid member cannot be a process ID because the
lock is not held by a process as such.
Acked-by: default avatarJ. Bruce Fields <bfields@fieldses.org>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      3fd80cdd
    • Jeff Layton's avatar
      locks: make /proc/locks show IS_FILE_PVT locks as type "FLPVT" · c918d42a
      Jeff Layton authored 
      In a later patch, we'll be adding a new type of lock that's owned by
the struct file instead of the files_struct. Those sorts of locks
will be flagged with a new FL_FILE_PVT flag.

Report these types of locks as "FLPVT" in /proc/locks to distinguish
them from "classic" POSIX locks.
Acked-by: default avatarJ. Bruce Fields <bfields@fieldses.org>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      c918d42a
    • Jeff Layton's avatar
      locks: rename locks_remove_flock to locks_remove_file · 78ed8a13
      Jeff Layton authored 
      This function currently removes leases in addition to flock locks and in
a later patch we'll have it deal with file-private locks too. Rename it
to locks_remove_file to indicate that it removes locks that are
associated with a particular struct file, and not just flock locks.
Acked-by: default avatarJ. Bruce Fields <bfields@fieldses.org>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      78ed8a13
    • Jeff Layton's avatar
      locks: consolidate checks for compatible filp->f_mode values in setlk handlers · bce7560d
      Jeff Layton authored 
      Move this check into flock64_to_posix_lock instead of duplicating it in
two places. This also fixes a minor wart in the code where we continue
referring to the struct flock after converting it to struct file_lock.
Acked-by: default avatarJ. Bruce Fields <bfields@fieldses.org>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      bce7560d
    • J. Bruce Fields's avatar
      locks: fix posix lock range overflow handling · ef12e72a
      J. Bruce Fields authored 
      In the 32-bit case fcntl assigns the 64-bit f_pos and i_size to a 32-bit
off_t.

The existing range checks also seem to depend on signed arithmetic
wrapping when it overflows.  In practice maybe that works, but we can be
more careful.  That also allows us to make a more reliable distinction
between -EINVAL and -EOVERFLOW.

Note that in the 32-bit case SEEK_CUR or SEEK_END might allow the caller
to set a lock with starting point no longer representable as a 32-bit
value.  We could return -EOVERFLOW in such cases, but the locks code is
capable of handling such ranges, so we choose to be lenient here.  The
only problem is that subsequent GETLK calls on such a lock will fail
with EOVERFLOW.

While we're here, do some cleanup including consolidating code for the
flock and flock64 cases.
Signed-off-by: default avatarJ. Bruce Fields <bfields@fieldses.org>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      ef12e72a
    • Jeff Layton's avatar
      locks: eliminate BUG() call when there's an unexpected lock on file close · 8c3cac5e
      Jeff Layton authored 
      A leftover lock on the list is surely a sign of a problem of some sort,
but it's not necessarily a reason to panic the box. Instead, just log a
warning with some info about the lock, and then delete it like we would
any other lock.

In the event that the filesystem declares a ->lock f_op, we may end up
leaking something, but that's generally preferable to an immediate
panic.
Acked-by: default avatarJ. Bruce Fields <bfields@fieldses.org>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      8c3cac5e
    • Jeff Layton's avatar
      locks: add __acquires and __releases annotations to locks_start and locks_stop · b03dfdec
      Jeff Layton authored 
      ...to make sparse happy.
Acked-by: default avatarJ. Bruce Fields <bfields@fieldses.org>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      b03dfdec
    • Jeff Layton's avatar
      locks: remove "inline" qualifier from fl_link manipulation functions · 6ca10ed8
      Jeff Layton authored 
      It's best to let the compiler decide that.
Acked-by: default avatarJ. Bruce Fields <bfields@fieldses.org>
Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      6ca10ed8
    • Jeff Layton's avatar
      locks: clean up comment typo · 46dad760
      Jeff Layton authored 
      Acked-by: default avatarJ. Bruce Fields <bfields@fieldses.org>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      46dad760
    • Jeff Layton's avatar
      locks: close potential race between setlease and open · 24cbe784
      Jeff Layton authored 
      As Al Viro points out, there is an unlikely, but possible race between
opening a file and setting a lease on it. generic_add_lease is done with
the i_lock held, but the inode->i_flock check in break_lease is
lockless. It's possible for another task doing an open to do the entire
pathwalk and call break_lease between the point where generic_add_lease
checks for a conflicting open and adds the lease to the list. If this
occurs, we can end up with a lease set on the file with a conflicting
open.

To guard against that, check again for a conflicting open after adding
the lease to the i_flock list. If the above race occurs, then we can
simply unwind the lease setting and return -EAGAIN.

Because we take dentry references and acquire write access on the file
before calling break_lease, we know that if the i_flock list is empty
when the open caller goes to check it then the necessary refcounts have
already been incremented. Thus the additional check for a conflicting
open will see that there is one and the setlease call will fail.

Cc: Bruce Fields <bfields@fieldses.org>
Cc: David Howells <dhowells@redhat.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Signed-off-by: default avatarJ. Bruce Fields <bfields@fieldses.org>
      24cbe784
    • Jeff Layton's avatar
      MAINTAINERS: update entry for fs/locks.c · 18156e7e
      Jeff Layton authored 
      Both Bruce and I have done a fair bit of work in these files recently,
and would like to be notified if anyone is proposing changes to it.

Also, Matthew is no longer interested in maintaining this code, so
remove him.

Cc: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Acked-by: default avatar"J. Bruce Fields" <bfields@fieldses.org>
      18156e7e
  3. 03 Feb, 2014 4 commits
    • Linus Torvalds's avatar
      Linus 3.14-rc1 · 38dbfb59
      Linus Torvalds authored
      38dbfb59
    • Linus Torvalds's avatar
      Merge branch 'parisc-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 69048e01
      Linus Torvalds authored 
      Pull parisc updates from Helge Deller:
 "The three major changes in this patchset is a implementation for
  flexible userspace memory maps, cache-flushing fixes (again), and a
  long-discussed ABI change to make EWOULDBLOCK the same value as
  EAGAIN.

  parisc has been the only platform where we had EWOULDBLOCK != EAGAIN
  to keep HP-UX compatibility.  Since we will probably never implement
  full HP-UX support, we prefer to drop this compatibility to make it
  easier for us with Linux userspace programs which mostly never checked
  for both values.  We don't expect major fall-outs because of this
  change, and if we face some, we will simply rebuild the necessary
  applications in the debian archives"

* 'parisc-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: add flexible mmap memory layout support
  parisc: Make EWOULDBLOCK be equal to EAGAIN on parisc
  parisc: convert uapi/asm/stat.h to use native types only
  parisc: wire up sched_setattr and sched_getattr
  parisc: fix cache-flushing
  parisc/sti_console: prefer Linux fonts over built-in ROM fonts
      69048e01
    • Mikulas Patocka's avatar
      hpfs: optimize quad buffer loading · 1c0b8a7a
      Mikulas Patocka authored 
      HPFS needs to load 4 consecutive 512-byte sectors when accessing the
directory nodes or bitmaps.  We can't switch to 2048-byte block size
because files are allocated in the units of 512-byte sectors.

Previously, the driver would allocate a 2048-byte area using kmalloc,
copy the data from four buffers to this area and eventually copy them
back if they were modified.

In the current implementation of the buffer cache, buffers are allocated
in the pagecache.  That means that 4 consecutive 512-byte buffers are
stored in consecutive areas in the kernel address space.  So, we don't
need to allocate extra memory and copy the content of the buffers there.

This patch optimizes the code to avoid copying the buffers.  It checks
if the four buffers are stored in contiguous memory - if they are not,
it falls back to allocating a 2048-byte area and copying data there.
Signed-off-by: default avatarMikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1c0b8a7a
    • Mikulas Patocka's avatar
      hpfs: remember free space · 2cbe5c76
      Mikulas Patocka authored 
      Previously, hpfs scanned all bitmaps each time the user asked for free
space using statfs.  This patch changes it so that hpfs scans the
bitmaps only once, remembes the free space and on next invocation of
statfs it returns the value instantly.

New versions of wine are hammering on the statfs syscall very heavily,
making some games unplayable when they're stored on hpfs, with load
times in minutes.

This should be backported to the stable kernels because it fixes
user-visible problem (excessive level load times in wine).
Signed-off-by: default avatarMikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2cbe5c76
  5. 02 Feb, 2014 12 commits
  7. 01 Feb, 2014 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7