fcntl spinlock in Linux?

J. Bruce Fields bfields at fieldses.org
Thu Feb 21 09:50:33 MST 2013


On Mon, Feb 18, 2013 at 04:08:36PM +1030, Rusty Russell wrote:
> "J. Bruce Fields" <bfields at fieldses.org> writes:
> 
> > On Thu, Feb 14, 2013 at 08:12:59PM +1030, Rusty Russell wrote:
> >> Volker Lendecke <Volker.Lendecke at SerNet.DE> writes:
> >> > Also, I am pretty certain that the fact that this happens in
> >> > an otherwise overloaded system adds to that effect, during
> >> > my tests here the systems were otherwise idle.
> >> 
> >> Oops, I dropped the list from my CC's somehow.
> >> 
> >> OK, I'll assume that improving this benchmark with 10000 or 20000 mean
> >> we have a real improvement.
> >> 
> >> I haven't tested, but one thing I noticed looking at the code: we're
> >> often deleted from the block list when we're woken, so we don't need
> >> to re-grab the lock in that case:
> >
> > Hm.  But  __locks_delete_block does more than make &waiter->fl_block
> > empty.  Isn't there a possibility that I could call locks_delete_block
> > while someone else was partway through __locks_delete_block?  So
> > something like:
> >
> > 				__locks_delete_block:
> > 				list_del_init(&waiter->fl_block);
> >
> > 	locks_delete_block sees
> > 	fl_block empty, returns,
> > 	caller frees the block
> > 				list_del_init(&waiter->fl_link);
> > 				waiter->fl_next = NULL;
> >
> > and then someone's writing into memory that belonged to the now-freed
> > block?
> 
> Sorry, it was more a though experiement (and benchmarking question) than
> patch candidate.

Fair enough, definitely looks worth a try.

> In practice, we should probably do:
> 
> void locks_delete_block(struct file_lock *waiter)
> {
> 	/* We could already be deleted by the time this runs. */
> 	if (!waiter->fl_next)
> 		return;
> 	lock_flocks();
> 	__locks_delete_block(waiter);
> 	unlock_flocks();
> }
> 
> and in __locks_delete_block:
> 
> {
> 	list_del_init(&waiter->fl_block);
> 	list_del_init(&waiter->fl_link);
>         smp_wmb();
> 	waiter->fl_next = NULL;
> }
> 
> (I'm assuming waiter->fl_next is never NULL, but that might be
> v. wrong).

That looks right.

--b.


More information about the samba-technical mailing list