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
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
