svn commit: r269055 - stable/10/sys/kern

[Konstantin Belousov]

On Fri, Jul 25, 2014 at 12:45:52AM +0400, Andrey Chernov wrote:
> On 24.07.2014 23:48, Konstantin Belousov wrote:
> > On Thu, Jul 24, 2014 at 11:31:32PM +0400, Andrey Chernov wrote:
> >> On 24.07.2014 14:43, Konstantin Belousov wrote:
> >>> Author: kib
> >>> Date: Thu Jul 24 10:43:15 2014
> >>> New Revision: 269055
> >>> URL: http://svnweb.freebsd.org/changeset/base/269055
> >>>
> >>> Log:
> >>>   MFC r268384:
> >>>   When the lock was stolen from us, retry the whole lock sequence in kernel,
> >>>   instead of returning EINTR.
> >>
> >> Does it make dead loop possible?
> > 
> > What is dead loop ?
> 
> I mean infinite retries with returning EDOOFUS each time and goto
> retry_setlock; again.
The fcntl(F_SETLKW) behaviour requires blocking until the lock can be
obtained.

I think (I remember this, but I did not re-readed the code now to confirm
my memory) is that if the race does not happen then the advisory locks
are fair, i.e. the lock requests are granted in the order of apperance.
The race causes the lock requestor to re-enter the queue from the start.

On the other hand, the race which causes the problems there is rare and
probably impossible to utilize in reliable manner.  That said, I would
be interested in seeing proof-of-concept lifelock code, but I very much
doubt that it can be written.

Also, I think (same disclaimer) that the race can only happen with mt
process among its own threads.

> 
> > Do you see a problem on your machine ?
> 
> No, just by looking at the commit message.
> 
> -- 
> http://ache.vniz.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-stable/attachments/20140725/382b6862/attachment.sig>