If the request has FL_CLOSE set, then we know we're releasing locks in
response to a fd being closed. When iterating over locks, skip any
locks that have FL_FILP_PRIVATE set and that don't have the same fl_file
pointer.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/locks.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/fs/locks.c b/fs/locks.c
index 086c3b4..7186b9a 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -135,6 +135,7 @@
#define IS_POSIX(fl) (fl->fl_flags & FL_POSIX)
#define IS_FLOCK(fl) (fl->fl_flags & FL_FLOCK)
#define IS_LEASE(fl) (fl->fl_flags & FL_LEASE)
+#define IS_PRIVATE(fl) (fl->fl_flags & FL_FILP_PRIVATE)
static bool lease_breaking(struct file_lock *fl)
{
@@ -1009,6 +1010,14 @@ static int __posix_lock_file(struct inode *inode, struct
file_lock *request, str
/* Process locks with this owner. */
while ((fl = *before) && posix_same_owner(request, fl)) {
+ /*
+ * For fd-private locks, only release locks that are associated
+ * with this filp.
+ */
+ if ((request->fl_flags & FL_CLOSE) && IS_PRIVATE(fl) &&
+ request->fl_file != fl->fl_file)
+ goto next_lock;
+
/* Detect adjacent or overlapping regions (if same lock type)
*/
if (request->fl_type == fl->fl_type) {
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
