summaryrefslogtreecommitdiffstats
path: root/fs/locks.c
Commit message (Collapse)AuthorAgeFilesLines
* wrappers for ->i_mutex accessAl Viro2016-01-221-3/+3
| | | | | | | | | | | parallel to mutex_{lock,unlock,trylock,is_locked,lock_nested}, inode_foo(inode) being mutex_foo(&inode->i_mutex). Please, use those for access to ->i_mutex; over the coming cycle ->i_mutex will become rwsem, with ->lookup() done with it held only shared. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* Merge branch 'work.copy_file_range' of ↵Linus Torvalds2016-01-121-13/+9
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull vfs copy_file_range updates from Al Viro: "Several series around copy_file_range/CLONE" * 'work.copy_file_range' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: btrfs: use new dedupe data function pointer vfs: hoist the btrfs deduplication ioctl to the vfs vfs: wire up compat ioctl for CLONE/CLONE_RANGE cifs: avoid unused variable and label nfsd: implement the NFSv4.2 CLONE operation nfsd: Pass filehandle to nfs4_preprocess_stateid_op() vfs: pull btrfs clone API to vfs layer locks: new locks_mandatory_area calling convention vfs: Add vfs_copy_file_range() support for pagecache copies btrfs: add .copy_file_range file operation x86: add sys_copy_file_range to syscall tables vfs: add copy_file_range syscall and vfs helper
| * locks: new locks_mandatory_area calling conventionChristoph Hellwig2015-12-071-13/+9
| | | | | | | | | | | | | | | | | | | | Pass a loff_t end for the last byte instead of the 32-bit count parameter to allow full file clones even on 32-bit architectures. While we're at it also simplify the read/write selection. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* | locks: rename __posix_lock_file to posix_lock_inodeJeff Layton2016-01-081-5/+6
| | | | | | | | | | | | | | ...a more descriptive name and we can drop the double underscore prefix. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Acked-by: "J. Bruce Fields" <bfields@fieldses.org>
* | locks: prink more detail when there are leaked locksJeff Layton2016-01-081-4/+29
| | | | | | | | | | | | | | | | | | Right now, we just get WARN_ON_ONCE, which is not particularly helpful. Have it dump some info about the locks and the inode to make it easier to track down leaked locks in the future. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Acked-by: "J. Bruce Fields" <bfields@fieldses.org>
* | locks: pass inode pointer to locks_free_lock_contextJeff Layton2016-01-081-1/+3
| | | | | | | | | | | | | | ...so we can print information about it if there are leaked locks. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Acked-by: "J. Bruce Fields" <bfields@fieldses.org>
* | locks: sprinkle some tracepoints around the file locking codeJeff Layton2016-01-081-3/+9
| | | | | | | | | | | | | | | | | | Add some tracepoints around the POSIX locking code. These were useful when tracking down problems when handling the race between setlk and close. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Acked-by: "J. Bruce Fields" <bfields@fieldses.org>
* | locks: don't check for race with close when setting OFD lockJeff Layton2016-01-081-6/+10
| | | | | | | | | | | | | | | | | | We don't clean out OFD locks on close(), so there's no need to check for a race with them here. They'll get cleaned out at the same time that flock locks are. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Acked-by: "J. Bruce Fields" <bfields@fieldses.org>
* | locks: fix unlock when fcntl_setlk races with a closeJeff Layton2016-01-071-21/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dmitry reported that he was able to reproduce the WARN_ON_ONCE that fires in locks_free_lock_context when the flc_posix list isn't empty. The problem turns out to be that we're basically rebuilding the file_lock from scratch in fcntl_setlk when we discover that the setlk has raced with a close. If the l_whence field is SEEK_CUR or SEEK_END, then we may end up with fl_start and fl_end values that differ from when the lock was initially set, if the file position or length of the file has changed in the interim. Fix this by just reusing the same lock request structure, and simply override fl_type value with F_UNLCK as appropriate. That ensures that we really are unlocking the lock that was initially set. While we're there, make sure that we do pop a WARN_ON_ONCE if the removal ever fails. Also return -EBADF in this event, since that's what we would have returned if the close had happened earlier. Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: <stable@vger.kernel.org> Fixes: c293621bbf67 (stale POSIX lock handling) Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Acked-by: "J. Bruce Fields" <bfields@fieldses.org>
* | fs: make locks.c explicitly non-modularPaul Gortmaker2015-12-181-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Kconfig currently controlling compilation of this code is: config FILE_LOCKING bool "Enable POSIX file locking API" if EXPERT ...meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering gets bumped to one level earlier when we use the more appropriate fs_initcall here. However we've made similar changes before without any fallout and none is expected here either. Cc: Jeff Layton <jlayton@poochiereds.net> Acked-by: Jeff Layton <jlayton@poochiereds.net> Cc: "J. Bruce Fields" <bfields@fieldses.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* | locks: use list_first_entry_or_null()Geliang Tang2015-11-181-6/+4
| | | | | | | | | | | | | | Simplify the code with list_first_entry_or_null(). Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* | locks: Allow disabling mandatory locking at compile timeJeff Layton2015-11-161-0/+2
|/ | | | | | | | | | | | | | | | | Mandatory locking appears to be almost unused and buggy and there appears no real interest in doing anything with it. Since effectively no one uses the code and since the code is buggy let's allow it to be disabled at compile time. I would just suggest removing the code but undoubtedly that will break some piece of userspace code somewhere. For the distributions that don't care about this piece of code this gives a nice starting point to make mandatory locking go away. Cc: Benjamin Coddington <bcodding@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jeff Layton <jeff.layton@primarydata.com> Cc: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: cleanup posix_lock_inode_wait and flock_lock_inode_waitBenjamin Coddington2015-10-221-6/+3
| | | | | | | All callers use locks_lock_inode_wait() instead. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* Move locks API users to locks_lock_inode_wait()Benjamin Coddington2015-10-221-1/+1
| | | | | | | | | Instead of having users check for FL_POSIX or FL_FLOCK to call the correct locks API function, use the check within locks_lock_inode_wait(). This allows for some later cleanup. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: introduce locks_lock_inode_wait()Benjamin Coddington2015-10-221-0/+24
| | | | | | | | | | Users of the locks API commonly call either posix_lock_file_wait() or flock_lock_file_wait() depending upon the lock type. Add a new function locks_lock_inode_wait() which will check and call the correct function for the type of lock passed in. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: Use more file_inode and fix a commentBenjamin Coddington2015-10-151-5/+3
| | | | | Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* fs: fix data races on inode->i_flctxDmitry Vyukov2015-09-211-27/+36
| | | | | | | | | | | | | | | | | | | | | | locks_get_lock_context() uses cmpxchg() to install i_flctx. cmpxchg() is a release operation which is correct. But it uses a plain load to load i_flctx. This is incorrect. Subsequent loads from i_flctx can hoist above the load of i_flctx pointer itself and observe uninitialized garbage there. This in turn can lead to corruption of ctx->flc_lock and other members. Documentation/memory-barriers.txt explicitly requires to use a barrier in such context: "A load-load control dependency requires a full read memory barrier". Use smp_load_acquire() in locks_get_lock_context() and in bunch of other functions that can proceed concurrently with locks_get_lock_context(). The data race was found with KernelThreadSanitizer (KTSAN). Signed-off-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* fs: fix fs/locks.c kernel-doc warningRandy Dunlap2015-08-311-0/+1
| | | | | | | | | Fix kernel-doc warnings in fs/locks.c: Warning(..//fs/locks.c:1577): No description found for parameter 'flags' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: inline posix_lock_file_wait and flock_lock_file_waitJeff Layton2015-07-131-28/+0
| | | | | | | They just call file_inode and then the corresponding *_inode_file_wait function. Just make them static inlines instead. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: new helpers - flock_lock_inode_wait and posix_lock_inode_waitJeff Layton2015-07-131-12/+38
| | | | | | | | Allow callers to pass in an inode instead of a filp. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Reviewed-by: "J. Bruce Fields" <bfields@fieldses.org> Tested-by: "J. Bruce Fields" <bfields@fieldses.org>
* locks: have flock_lock_file take an inode pointer instead of a filpJeff Layton2015-07-131-6/+6
| | | | | | | | | | | | | | | | | | ...and rename it to better describe how it works. In order to fix a use-after-free in NFS, we need to be able to remove locks from an inode after the filp associated with them may have already been freed. flock_lock_file already only dereferences the filp to get to the inode, so just change it so the callers do that. All of the callers already pass in a lock request that has the fl_file set properly, so we don't need to pass it in individually. With that change it now only dereferences the filp to get to the inode, so just push that out to the callers. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Reviewed-by: "J. Bruce Fields" <bfields@fieldses.org> Tested-by: "J. Bruce Fields" <bfields@fieldses.org>
* proc: show locks in /proc/pid/fdinfo/XAndrey Vagin2015-04-171-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's show locks which are associated with a file descriptor in its fdinfo file. Currently we don't have a reliable way to determine who holds a lock. We can find some information in /proc/locks, but PID which is reported there can be wrong. For example, a process takes a lock, then forks a child and dies. In this case /proc/locks contains the parent pid, which can be reused by another process. $ cat /proc/locks ... 6: FLOCK ADVISORY WRITE 324 00:13:13431 0 EOF ... $ ps -C rpcbind PID TTY TIME CMD 332 ? 00:00:00 rpcbind $ cat /proc/332/fdinfo/4 pos: 0 flags: 0100000 mnt_id: 22 lock: 1: FLOCK ADVISORY WRITE 324 00:13:13431 0 EOF $ ls -l /proc/332/fd/4 lr-x------ 1 root root 64 Mar 5 14:43 /proc/332/fd/4 -> /run/rpcbind.lock $ ls -l /proc/324/fd/ total 0 lrwx------ 1 root root 64 Feb 27 14:50 0 -> /dev/pts/0 lrwx------ 1 root root 64 Feb 27 14:50 1 -> /dev/pts/0 lrwx------ 1 root root 64 Feb 27 14:49 2 -> /dev/pts/0 You can see that the process with the 324 pid doesn't hold the lock. This information is required for proper dumping and restoring file locks. Signed-off-by: Andrey Vagin <avagin@openvz.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Acked-by: Jeff Layton <jlayton@poochiereds.net> Acked-by: "J. Bruce Fields" <bfields@fieldses.org> Acked-by: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Joe Perches <joe@perches.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* locks: use cmpxchg to assign i_flctx pointerJeff Layton2015-04-031-8/+1
| | | | | | | | | | | | | | | | | | | | | | | During the v3.20/v4.0 cycle, I had originally had the code manage the inode->i_flctx pointer using a compare-and-swap operation instead of the i_lock. Sasha Levin though hit a problem while testing with trinity that made me believe that that wasn't safe. At the time, changing the code to protect the i_flctx pointer seemed to fix the issue, but I now think that was just coincidence. The issue was likely the same race that Kirill Shutemov hit while testing the pre-rc1 v4.0 kernel and that Linus spotted. Due to the way that the spinlock was dropped in the middle of flock_lock_file, you could end up with multiple flock locks for the same struct file on the inode. Reinstate the use of a CAS operation to assign this pointer since it's likely to be more efficient and gets the i_lock completely out of the file locking business. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: get rid of WE_CAN_BREAK_LSLK_NOW dead codeJeff Layton2015-04-031-6/+1
| | | | | | | | | | | | | As Bruce points out, there's no compelling reason to change /proc/locks output at this point. If we did want to do this, then we'd almost certainly want to introduce a new file to display this info (maybe via debugfs?). Let's remove the dead WE_CAN_BREAK_LSLK_NOW ifdef here and just plan to stay with the legacy format. Reported-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: change lm_get_owner and lm_put_owner prototypesJeff Layton2015-04-031-3/+5
| | | | | | | | | | | | The current prototypes for these operations are somewhat awkward as they deal with fl_owners but take struct file_lock arguments. In the future, we'll want to be able to take references without necessarily dealing with a struct file_lock. Change them to take fl_owner_t arguments instead and have the callers deal with assigning the values to the file_lock structs. Signed-off-by: Jeff Layton <jlayton@primarydata.com>
* locks: don't allocate a lock context for an F_UNLCK requestJeff Layton2015-04-031-8/+12
| | | | | | | | | | | | In the event that we get an F_UNLCK request on an inode that has no lock context, there is no reason to allocate one. Change locks_get_lock_context to take a "type" pointer and avoid allocating a new context if it's F_UNLCK. Then, fix the callers to return appropriately if that function returns NULL. Signed-off-by: Jeff Layton <jlayton@primarydata.com>
* locks: Add lockdep assertion for blocked_lock_lockDaniel Wagner2015-04-031-0/+6
| | | | | | | | Annonate insert, remove and iterate function that we need blocked_lock_lock held. Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: remove extraneous IS_POSIX and IS_FLOCK testsJeff Layton2015-04-031-2/+2
| | | | | | | We know that the locks being passed into this function are of the correct type, now that they live on their own lists. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: Remove unnecessary IS_POSIX testDaniel Wagner2015-04-031-2/+0
| | | | | | | | | | | | | | | | | | | Since following change commit bd61e0a9c852de2d705b6f1bb2cc54c5774db570 Author: Jeff Layton <jlayton@primarydata.com> Date: Fri Jan 16 15:05:55 2015 -0500 locks: convert posix locks to file_lock_context all Posix locks are kept on their a separate list, so the test is redudant. Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Cc: Jeff Layton <jlayton@primarydata.com> Cc: "J. Bruce Fields" <bfields@fieldses.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: fix file_lock deletion inside loopYan, Zheng2015-03-271-3/+2
| | | | | | | | | locks_delete_lock_ctx() is called inside the loop, so we should use list_for_each_entry_safe. Fixes: 8634b51f6ca2 (locks: convert lease handling to file_lock_context) Signed-off-by: "Yan, Zheng" <zyan@redhat.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: fix generic_delete_lease tracepoint to use victim pointerJeff Layton2015-03-141-1/+1
| | | | | | | It's possible that "fl" won't point at a valid lock at this point, so use "victim" instead which is either a valid lock or NULL. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: fix fasync_struct memory leak in lease upgrade/downgrade handlingJeff Layton2015-03-041-1/+2
| | | | | | | | | | | | | | | | | | | Commit 8634b51f6ca2 (locks: convert lease handling to file_lock_context) introduced a regression in the handling of lease upgrade/downgrades. In the event that we already have a lease on a file and are going to either upgrade or downgrade it, we skip doing any list insertion or deletion and simply re-call lm_setup on the existing lease. As of commit 8634b51f6ca2 however, we end up calling lm_setup on the lease that was passed in, instead of on the existing lease. This causes us to leak the fasync_struct that was allocated in the event that there was not already an existing one (as it always appeared that there wasn't one). Fixes: 8634b51f6ca2 (locks: convert lease handling to file_lock_context) Reported-and-Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: fix list insertion when lock is split in twoJeff Layton2015-02-171-0/+1
| | | | | | | | | | | | | In the case where we're splitting a lock in two, the current code the new "left" lock in the incorrect spot. It's inserted just before "right" when it should instead be inserted just before the new lock. When we add a new lock, set "fl" to that value so that we can add "left" before it. Reported-by: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: remove conditional lock release in middle of flock_lock_fileJeff Layton2015-02-171-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As Linus pointed out: Say we have an existing flock, and now do a new one that conflicts. I see what looks like three separate bugs. - We go through the first loop, find a lock of another type, and delete it in preparation for replacing it - we *drop* the lock context spinlock. - BUG #1? So now there is no lock at all, and somebody can come in and see that unlocked state. Is that really valid? - another thread comes in while the first thread dropped the lock context lock, and wants to add its own lock. It doesn't see the deleted or pending locks, so it just adds it - the first thread gets the context spinlock again, and adds the lock that replaced the original - BUG #2? So now there are *two* locks on the thing, and the next time you do an unlock (or when you close the file), it will only remove/replace the first one. ...remove the "drop the spinlock" code in the middle of this function as it has always been suspicious. This should eliminate the potential race that can leave two locks for the same struct file on the list. He also pointed out another thing as a bug -- namely that you flock_lock_file removes the lock from the list unconditionally when doing a lock upgrade, without knowing whether it'll be able to set the new lock. Bruce pointed out that this is expected behavior and may help prevent certain deadlock situations. We may want to revisit that at some point, but it's probably best that we do so in the context of a different patchset. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* locks: only remove leases associated with the file being closedJeff Layton2015-02-171-1/+2
| | | | | | We don't want to remove all leases just because one filp was closed. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* Revert "locks: keep a count of locks on the flctx lists"Jeff Layton2015-02-161-29/+16
| | | | | | | | | | | This reverts commit 9bd0f45b7037fcfa8b575c7e27d0431d6e6dc3bb. Linus rightly pointed out that I failed to initialize the counters when adding them, so they don't work as expected. Just revert this patch for now. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
* fs: add FL_LAYOUT lease typeChristoph Hellwig2015-02-021-4/+10
| | | | | | | | | | | | | | | | This (ab-)uses the file locking code to allow filesystems to recall outstanding pNFS layouts on a file. This new lease type is similar but not quite the same as FL_DELEG. A FL_LAYOUT lease can always be granted, an a per-filesystem lock (XFS iolock for the initial implementation) ensures not FL_LAYOUT leases granted when we would need to recall them. Also included are changes that allow multiple outstanding read leases of different types on the same file as long as they have a differnt owner. This wasn't a problem until now as nfsd never set FL_LEASE leases, and no one else used FL_DELEG leases, but given that nfsd will also issues FL_LAYOUT leases we will have to handle it now. Signed-off-by: Christoph Hellwig <hch@lst.de>
* fs: track fl_owner for leasesChristoph Hellwig2015-02-021-5/+7
| | | | | | | | Just like for other lock types we should allow different owners to have a read lease on a file. Currently this can't happen, but with the addition of pNFS layout leases we'll need this feature. Signed-off-by: Christoph Hellwig <hch@lst.de>
* locks: update comments that refer to inode->i_flockJeff Layton2015-01-211-1/+1
| | | | Signed-off-by: Jeff Layton <jlayton@primarydata.com>
* locks: consolidate NULL i_flctx checks in locks_remove_fileJeff Layton2015-01-161-2/+7
| | | | | | | | We have each of the locks_remove_* variants doing this individually. Have the caller do it instead, and have locks_remove_flock and locks_remove_lease just assume that it's a valid pointer. Signed-off-by: Jeff Layton <jlayton@primarydata.com>
* locks: keep a count of locks on the flctx listsJeff Layton2015-01-161-16/+29
| | | | | | | | This makes things a bit more efficient in the cifs and ceph lock pushing code. Signed-off-by: Jeff Layton <jlayton@primarydata.com> Acked-by: Christoph Hellwig <hch@lst.de>
* locks: clean up the lm_change prototypeJeff Layton2015-01-161-7/+6
| | | | | | | | | Now that we use standard list_heads for tracking leases, we can have lm_change take a pointer to the lease to be modified instead of a double pointer. Signed-off-by: Jeff Layton <jlayton@primarydata.com> Acked-by: Christoph Hellwig <hch@lst.de>
* locks: add a dedicated spinlock to protect i_flctx listsJeff Layton2015-01-161-43/+44
| | | | | | | | We can now add a dedicated spinlock without expanding struct inode. Change to using that to protect the various i_flctx lists. Signed-off-by: Jeff Layton <jlayton@primarydata.com> Acked-by: Christoph Hellwig <hch@lst.de>
* locks: convert lease handling to file_lock_contextJeff Layton2015-01-161-153/+99
| | | | | Signed-off-by: Jeff Layton <jlayton@primarydata.com> Acked-by: Christoph Hellwig <hch@lst.de>
* locks: convert posix locks to file_lock_contextJeff Layton2015-01-161-51/+57
| | | | | Signed-off-by: Jeff Layton <jlayton@primarydata.com> Acked-by: Christoph Hellwig <hch@lst.de>
* locks: move flock locks to file_lock_contextJeff Layton2015-01-161-19/+35
| | | | | Signed-off-by: Jeff Layton <jlayton@primarydata.com> Acked-by: Christoph Hellwig <hch@lst.de>
* locks: add a new struct file_locking_context pointer to struct inodeJeff Layton2015-01-161-0/+44
| | | | | | | | | | | | | | | | | | | | | | The current scheme of using the i_flock list is really difficult to manage. There is also a legitimate desire for a per-inode spinlock to manage these lists that isn't the i_lock. Start conversion to a new scheme to eventually replace the old i_flock list with a new "file_lock_context" object. We start by adding a new i_flctx to struct inode. For now, it lives in parallel with i_flock list, but will eventually replace it. The idea is to allocate a structure to sit in that pointer and act as a locus for all things file locking. We allocate a file_lock_context for an inode when the first lock is added to it, and it's only freed when the inode is freed. We use the i_lock to protect the assignment, but afterward it should mostly be accessed locklessly. Signed-off-by: Jeff Layton <jlayton@primarydata.com> Acked-by: Christoph Hellwig <hch@lst.de>
* locks: have locks_release_file use flock_lock_file to release generic flock ↵Jeff Layton2015-01-161-18/+31
| | | | | | | | | locks ...instead of open-coding it and removing flock locks directly. This helps consolidate the flock lock removal logic into a single spot. Signed-off-by: Jeff Layton <jlayton@primarydata.com>
* locks: add new struct list_head to struct file_lockJeff Layton2015-01-161-3/+5
| | | | | | | | | ...that we can use to queue file_locks to per-ctx list_heads. Go ahead and convert locks_delete_lock and locks_dispose_list to use it instead of the fl_block list. Signed-off-by: Jeff Layton <jlayton@primarydata.com> Acked-by: Christoph Hellwig <hch@lst.de>
* locks: fix NULL-deref in generic_delete_leaseNeilBrown2015-01-131-1/+1
| | | | | | | | | | | | | | | | | | commit 0efaa7e82f02fe69c05ad28e905f31fc86e6f08e locks: generic_delete_lease doesn't need a file_lock at all moves the call to fl->fl_lmops->lm_change() to a place in the code where fl might be a non-lease lock. When that happens, fl_lmops is NULL and an Oops ensures. So add an extra test to restore correct functioning. Reported-by: Linda Walsh <suse@tlinx.org> Link: https://bugzilla.suse.com/show_bug.cgi?id=912569 Cc: stable@vger.kernel.org (v3.18) Fixes: 0efaa7e82f02fe69c05ad28e905f31fc86e6f08e Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Jeff Layton <jlayton@primarydata.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-21 23:26:22 +0000