Re: [PATCH 1/4] [RFC] net: Explicitly initialize u64_stats_sync structures for lockdep

[John Stultz <john.stultz@linaro.org>]

On 09/26/2013 12:34 PM, John Stultz wrote:
> On 09/26/2013 12:26 PM, Eric Dumazet wrote:
>> On Thu, 2013-09-26 at 11:34 -0700, John Stultz wrote:
>>> In order to enable lockdep on seqcount/seqlock structures, we
>>> must explicitly initialize any locks.
>>>
>>> diff --git a/include/linux/u64_stats_sync.h b/include/linux/u64_stats_sync.h
>>> index 8da8c4e..c450e11 100644
>>> --- a/include/linux/u64_stats_sync.h
>>> +++ b/include/linux/u64_stats_sync.h
>>> @@ -67,6 +67,13 @@ struct u64_stats_sync {
>>>  #endif
>>>  };
>>>  
>>> +
>>> +#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
>>> +#define u64_stats_init(syncp)	seqcount_init(syncp.seq)
>>> +#else
>>> +#define u64_stats_init(syncp)
>>> +#endif
>>> +
>> I would prefer a function.
>>
>> static inline void u64_stats_init(struct u64_stats_sync *syncp)
>> {
>> #if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
>> 	seqcount_init(&syncp->seq);
>> #endif
>> }
> No objection, though I worry that will obscure the lockdep key name,
> causing all the u64_stat_sync locks to appear the same.
>
> I'll give it a quick shot to see if the compiler inlines it well enough
> to preserve the name.
Yea, unfortunately this causes the reports to all look like:
[   10.370105]  Possible unsafe locking scenario:
[   10.370105]
[   10.370105]        CPU0
[   10.370105]        ----
[   10.370105]   lock(&syncp->seq#5);
[   10.370105]   <Interrupt>
[   10.370105]     lock(&syncp->seq#5);
[   10.370105]
[   10.370105]  *** DEADLOCK ***


Rather then:
[   12.150105]  Possible unsafe locking scenario:
[   12.150105]
[   12.150105]        CPU0
[   12.150105]        ----
[   12.150105]   lock(&af_inet6_stats->syncp.seq);
[   12.150105]   <Interrupt>
[   12.150105]     lock(&af_inet6_stats->syncp.seq);
[   12.150105]
[   12.150105]  *** DEADLOCK ***


So I suspect using the macro is the best approach here. Is that ok?

thanks
-john