svn commit: r273549 - head/sys/kern

[Edward Tomasz Napierała]

Dnia 23 paź 2014 o godz. 20:38 John Baldwin <jhb at freebsd.org> napisał(a):

>> On Thursday, October 23, 2014 11:35:47 am Mateusz Guzik wrote:
>> Author: mjg
>> Date: Thu Oct 23 15:35:47 2014
>> New Revision: 273549
>> URL: https://svnweb.freebsd.org/changeset/base/273549
>> 
>> Log:
>>  Avoid taking the lock in selfdfree when not needed.
>> 
>> Modified:
>>  head/sys/kern/sys_generic.c
>> 
>> Modified: head/sys/kern/sys_generic.c
> ==============================================================================
>> --- head/sys/kern/sys_generic.c    Thu Oct 23 15:16:40 2014    (r273548)
>> +++ head/sys/kern/sys_generic.c    Thu Oct 23 15:35:47 2014    (r273549)
>> @@ -1600,10 +1600,11 @@ static void
>> selfdfree(struct seltd *stp, struct selfd *sfp)
>> {
>>    STAILQ_REMOVE(&stp->st_selq, sfp, selfd, sf_link);
>> -    mtx_lock(sfp->sf_mtx);
>> -    if (sfp->sf_si)
>> +    if (sfp->sf_si != NULL) {
>> +        mtx_lock(sfp->sf_mtx);
>>        TAILQ_REMOVE(&sfp->sf_si->si_tdlist, sfp, sf_threads);
>> -    mtx_unlock(sfp->sf_mtx);
>> +        mtx_unlock(sfp->sf_mtx);
>> +    }
>>    uma_zfree(selfd_zone, sfp);
> 
> How do you ensure that the value you read for sf_si here is up to date?  In 
> particular, if a thread is selecting on multiple fds and one awakens it,
> another fd can invoke selwakeup() while the thread is in seltdclear().
> In that case, you might see a stale value of sf_si and not realize it is 
> cleared by the selwakeup() after you get the lock and you will invoke
> TAILQ_REMOVE an extra time.

FWIW, I've just hit a panic in selfdfree().