[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1190044850.6700.81.camel@heimdal.trondhjem.org>
Date: Mon, 17 Sep 2007 12:00:50 -0400
From: Trond Myklebust <trond.myklebust@....uio.no>
To: Pavel Emelyanov <xemul@...nvz.org>
Cc: Andrew Morton <akpm@...l.org>,
"J. Bruce Fields" <bfields@...ldses.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
devel@...nvz.org
Subject: Re: [PATCH] Wake up mandatory locks waiter on chmod (v2)
On Mon, 2007-09-17 at 18:16 +0400, Pavel Emelyanov wrote:
> Trond Myklebust wrote:
> > On Mon, 2007-09-17 at 12:13 +0400, Pavel Emelyanov wrote:
> >> When the process is blocked on mandatory lock and someone changes
> >> the inode's permissions, so that the lock is no longer mandatory,
> >> nobody wakes up the blocked process, but probably should.
> >
> > Please explain in more detail why we need this patch.
>
> From "this fixes an OOPs/deadlock/leak" POV we do not. This is
> just an attempt to make the locking code be more consistent and
> clean.
Why do you think we get a deadlock or leak? AFAICS if the user turns off
mandatory locks on the file, then the existing locks default back into
advisory locks which use the same notification mechanism as the
mandatory locks.
IOW: the process that is waiting in locks_mandatory_area() will be
released as soon as the advisory lock is dropped. If that theory is
broken in practice, then that is the bug that we need to fix. We neither
want to add a load of locking crap to notify_change(), nor should we
need to.
Cheers
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists