svn commit: r259407 - head/sys/kern

Julian Elischer julian at elischer.org
Thu Dec 19 15:41:17 UTC 2013


On 12/17/13, 8:34 PM, John Baldwin wrote:
> On Tuesday, December 17, 2013 1:17:45 pm Mateusz Guzik wrote:
>> On Tue, Dec 17, 2013 at 11:41:49AM -0500, John Baldwin wrote:
>>> On Saturday, December 14, 2013 11:11:43 pm Mateusz Guzik wrote:
>>>> Author: mjg
>>>> Date: Sun Dec 15 04:11:43 2013
>>>> New Revision: 259407
>>>> URL: http://svnweb.freebsd.org/changeset/base/259407
>>>>
>>>> Log:
>>>>    proc exit: don't take PROC_LOCK while freeing rlimits
>>>>    
>>>>    Code wishing to check rlimits of some process should check whether it
>>>>    is exiting first, which current consumers do.
>>> Does this measurably reduce contention?
>>>
>> No, this is just a cosmetic change I did while doing some other work
>> with rlimits.
>>
>> It would use some more cosmetic work (e.g. no reason not to
>> lim_free(p->plimit); p->p_limit = NULL) and maybe I'll get to that
>> later unless this kind of stuff is unwanted.
> I find it useful to leave the locking in place so it is clear that p_limit is
> always written to with the lock held.  If we ever got a static analyzer that
> understood locking rules then leaving this locking in would reduce false
> positives.  When I first did locking for fields in struct proc I did it by
> hand based on grepping the source tree for all uses of a field and ensuring
> they were locked.  I think it might be more confusing later on for another
> reader to see unlocked access and then have to think about why that is safe.
>
leave the locks there but commented out with an explanatory comment.



More information about the svn-src-head mailing list