netdev - Re: [PATCH net-next v2 1/2] lockdep: Introduce in

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: <20201123142725.GQ3021@hirez.programming.kicks-ass.net>
Date:   Mon, 23 Nov 2020 15:27:25 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Yunsheng Lin <linyunsheng@...wei.com>
Cc:     mingo@...hat.com, will@...nel.org, viro@...iv.linux.org.uk,
        kyk.segfault@...il.com, davem@...emloft.net, kuba@...nel.org,
        linmiaohe@...wei.com, martin.varghese@...ia.com, pabeni@...hat.com,
        pshelar@....org, fw@...len.de, gnault@...hat.com,
        steffen.klassert@...unet.com, vladimir.oltean@....com,
        edumazet@...gle.com, saeed@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, linuxarm@...wei.com,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH net-next v2 1/2] lockdep: Introduce in_softirq lockdep
 assert

On Sat, Nov 21, 2020 at 11:06:15AM +0800, Yunsheng Lin wrote:
> The current semantic for napi_consume_skb() is that caller need
> to provide non-zero budget when calling from NAPI context, and
> breaking this semantic will cause hard to debug problem, because
> _kfree_skb_defer() need to run in atomic context in order to push
> the skb to the particular cpu' napi_alloc_cache atomically.
> 
> So add the lockdep_assert_in_softirq() to assert when the running
> context is not in_softirq, in_softirq means softirq is serving or
> BH is disabled. Because the softirq context can be interrupted by
> hard IRQ or NMI context, so lockdep_assert_in_softirq() need to
> assert about hard IRQ or NMI context too.
> 
> Suggested-by: Jakub Kicinski <kuba@...nel.org>
> Signed-off-by: Yunsheng Lin <linyunsheng@...wei.com>
> ---
>  include/linux/lockdep.h | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> index f559487..f5e3d81 100644
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -594,6 +594,12 @@ do {									\
>  		      this_cpu_read(hardirqs_enabled)));		\
>  } while (0)

Due to in_softirq() having a deprication notice (due to it being
awefully ambiguous), could we have a nice big comment here that explains
in detail understandable to !network people (me) why this is actually
correct?

I'm not opposed to the thing, if that his what you need, it's fine, but
please put on a comment that explains that in_softirq() is ambiguous and
when you really do need it anyway.

> +#define lockdep_assert_in_softirq()					\
> +do {									\
> +	WARN_ON_ONCE(__lockdep_enabled			&&		\
> +		     (!in_softirq() || in_irq() || in_nmi()));		\
> +} while (0)
> +
>  #else
>  # define might_lock(lock) do { } while (0)
>  # define might_lock_read(lock) do { } while (0)
> @@ -605,6 +611,7 @@ do {									\
>  
>  # define lockdep_assert_preemption_enabled() do { } while (0)
>  # define lockdep_assert_preemption_disabled() do { } while (0)
> +# define lockdep_assert_in_softirq() do { } while (0)
>  #endif
>  
>  #ifdef CONFIG_PROVE_RAW_LOCK_NESTING
> -- 
> 2.8.1
>