svn commit: r314667 - in stable/10/sys: amd64/amd64 cddl/contrib/opensolaris/uts/common/dtrace cddl/contrib/opensolaris/uts/common/fs/zfs cddl/dev/profile compat/ndis contrib/ipfilter/netinet dev/a...

Julian Elischer julian at freebsd.org
Sat Mar 4 16:11:15 UTC 2017


On 5/3/17 12:02 am, Andriy Gapon wrote:
> On 04/03/2017 17:30, Julian Elischer wrote:
>> On 4/3/17 9:03 pm, Andriy Gapon wrote:
>>> Author: avg
>>> Date: Sat Mar  4 13:03:31 2017
>>> New Revision: 314667
>>> URL: https://svnweb.freebsd.org/changeset/base/314667
>>>
>>> Log:
>>>     MFC r283291: don't use CALLOUT_MPSAFE with callout_init()
>>>        The main purpose of this MFC is to reduce conflicts for other merges.
>>>     Parts of the original change have already "trickled down" via individual MFCs.
>> is there a better name than ''1" when you replace " CALLOUT_MPSAFE"?
> Maybe 'true'.  The argument has type int and it is documented this way:
>
>       If the mpsafe argument is zero, the callout structure
>       is not considered to be “multi-processor safe”; and the Giant lock will
>       be acquired before calling the callout function and released when the
>       callout function returns.
then I disagree with the change. I think CALLOUT_MPSAFE is a better 
value than '1'.
or CALLOUT_IS_MPSAFE.
I'm sort of confused by why 283291 made that change. It seems a 
regression to me.
MFC-ing it is a different question and 'diff reduction' is a valid 
reason but the original change in head seems suspect.


>>> -    callout_init(&watchdog_callout, CALLOUT_MPSAFE);
>>> +    callout_init(&watchdog_callout, 1);
>>>        if (watchdog_cpu != -1)
>>>            watchdog_change(watchdog_cpu);
>
>



More information about the svn-src-stable-10 mailing list