netdev - Re: seqlock lockdep false positives?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e745809b-b6c7-7b6a-b598-4e3bbd3e48d7@gmail.com>
Date:   Tue, 9 Mar 2021 11:12:34 +0100
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        "Erhard F." <erhard_f@...lbox.org>
Cc:     "Ahmed S. Darwish" <a.darwish@...utronix.de>,
        Jakub Kicinski <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: seqlock lockdep false positives?



On 3/9/21 8:54 AM, Peter Zijlstra wrote:
> On Mon, Mar 08, 2021 at 09:42:08PM +0100, Erhard F. wrote:
> 
>> I can confirm that your patch on top of 5.12-rc2 makes the lockdep
>> splat disappear (Ahmeds' 1st patch not installed).
> 
> Excellent, I'll queue the below in locking/urgent then.
> 
> 
> ---
> Subject: u64_stats,lockdep: Fix u64_stats_init() vs lockdep
> From: Peter Zijlstra <peterz@...radead.org>
> Date: Mon, 8 Mar 2021 09:38:12 +0100
> 
> Jakub reported that:
> 
>     static struct net_device *rtl8139_init_board(struct pci_dev *pdev)
>     {
> 	    ...
> 	    u64_stats_init(&tp->rx_stats.syncp);
> 	    u64_stats_init(&tp->tx_stats.syncp);
> 	    ...
>     }
> 
> results in lockdep getting confused between the RX and TX stats lock.
> This is because u64_stats_init() is an inline calling seqcount_init(),
> which is a macro using a static variable to generate a lockdep class.
> 
> By wrapping that in an inline, we negate the effect of the macro and
> fold the static key variable, hence the confusion.
> 
> Fix by also making u64_stats_init() a macro for the case where it
> matters, leaving the other case an inline for argument validation
> etc.
> 
> Reported-by: Jakub Kicinski <kuba@...nel.org>
> Debugged-by: "Ahmed S. Darwish" <a.darwish@...utronix.de>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> Tested-by: "Erhard F." <erhard_f@...lbox.org>
> Link: https://lkml.kernel.org/r/YEXicy6+9MksdLZh@hirez.programming.kicks-ass.net
> ---
>  include/linux/u64_stats_sync.h |    7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> --- a/include/linux/u64_stats_sync.h
> +++ b/include/linux/u64_stats_sync.h
> @@ -115,12 +115,13 @@ static inline void u64_stats_inc(u64_sta
>  }
>  #endif
>  
> +#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
> +#define u64_stats_init(syncp)	seqcount_init(&(syncp)->seq)
> +#else
>  static inline void u64_stats_init(struct u64_stats_sync *syncp)
>  {
> -#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
> -	seqcount_init(&syncp->seq);
> -#endif
>  }
> +#endif
>  
>  static inline void u64_stats_update_begin(struct u64_stats_sync *syncp)
>  {
> 

Interesting !

It seems seqcount_latch_init() might benefit from something similar.