On Tue, 24 Nov 2020 18:49:28 +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, which has a ambiguous semantics due to the BH
> disabled confusion, so add a comment to emphasize that.
>
> And the softirq context can be interrupted by hard IRQ or NMI
> context, lockdep_assert_in_softirq() need to assert about hard
> IRQ or NMI context too.
>
> Suggested-by: Jakub Kicinski <k...@kernel.org>
> Signed-off-by: Yunsheng Lin <linyunsh...@huawei.com>
> ---
> V3: add comment to emphasize the ambiguous semantics.
> ---
> include/linux/lockdep.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> index f559487..8d60f46 100644
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -594,6 +594,13 @@ do {
> \
> this_cpu_read(hardirqs_enabled))); \
> } while (0)
>
> +/* Much like in_softirq() - semantics are ambiguous, use carefully. */
I've added both of the comments I suggested in the reply to Peter here
and applied to net-next.
Thanks for working on this.
> +#define lockdep_assert_in_softirq() \
> +do { \
> + WARN_ON_ONCE(__lockdep_enabled && \
> + (!in_softirq() || in_irq() || in_nmi())); \
> +} while (0)
