Re: [PATCH 0/2] locks: allow mandatory locking to work with file-private locks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 10, 2014 at 03:31:29PM -0400, Jeffrey Layton wrote:
> On Mon, 10 Mar 2014 15:21:46 -0400
> "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:
> 
> > On Mon, Mar 10, 2014 at 09:36:45AM -0400, Jeff Layton wrote:
> > > 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.
> > 
> > As another alternative, could we declare file-private locks to never
> > be mandatory?
> > 
> > The mandatory bit has only ever applied to traditional posix locks,
> > so I don't think there's necessarily a presumption they'd apply to
> > this new lock type as well.
> > 
> > That doesn't necessarily simplify the locks_mandatory_area case as it
> > then needs __posix_lock_file to be able to ignore traditional posix
> > locks.
> > 
> 
> Erm...I think you mean "ignore file-private locks"...

Yep, sorry.  (well, "optionally ignore file-private locks", with the
option taken in locks_mandatory_area).

> We certainly could do that, but I'm not sure I really like it any
> better and it'd be harder to code that up. What would be the benefit of
> doing that instead?

I'd just rather limit the scope of mandatory locking where possible.

It's not a big deal I guess.

--b.

> I'm not a real fan of mandatory locking but my aim all along has been
> to allow fp locks to work as much like classic locks as possible. Is
> there a compelling reason to make them different here?
> 
> -- 
> Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux