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"... 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'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
