From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: [PATCH 0/2] locks: allow mandatory locking to work with file-private locks Date: Mon, 10 Mar 2014 09:36:45 -0400 Message-ID: <1394458607-23579-1-git-send-email-jlayton@redhat.com> Cc: bfields@fieldses.org, trond.myklebust@primarydata.com, Andy Lutomirski To: linux-fsdevel@vger.kernel.org Return-path: Received: from mail-qa0-f43.google.com ([209.85.216.43]:48185 "EHLO mail-qa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753436AbaCJNg4 (ORCPT ); Mon, 10 Mar 2014 09:36:56 -0400 Received: by mail-qa0-f43.google.com with SMTP id j15so6849717qaq.16 for ; Mon, 10 Mar 2014 06:36:55 -0700 (PDT) Sender: linux-fsdevel-owner@vger.kernel.org List-ID: This patchset fixes the problems that Trond pointed out last week, namely that you can end up deadlocking yourself if you set a file-private lock on a file and then do some I/O on the same. With this set, mandatory locking should work more or less as you'd expect with file-private locks. If you set a lock on an open file and then do some I/O on it, it won't block. If you try to lock and do I/O on different open files, then the I/O may end up blocked. Note that this approach is just as racy as the existing mandatory lock implementation, but I don't think it makes anything worse there. Jeff Layton (2): locks: fix locks_mandatory_locked to respect file-private locks locks: make locks_mandatory_area check for file-private locks fs/locks.c | 22 +++++++++++++++++----- fs/namei.c | 2 +- include/linux/fs.h | 20 ++++++++++---------- mm/mmap.c | 2 +- mm/nommu.c | 2 +- 5 files changed, 30 insertions(+), 18 deletions(-) -- 1.8.5.3