From: Jakub Kicinski <kuba@kernel.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>, netdev <netdev@vger.kernel.org>,
Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH net-next 1/4] net: fix possible race in skb_attempt_defer_free()
Date: Mon, 16 May 2022 11:15:54 -0700 [thread overview]
Message-ID: <20220516111554.5585a6b5@kernel.org> (raw)
In-Reply-To: <20220516042456.3014395-2-eric.dumazet@gmail.com>
On Sun, 15 May 2022 21:24:53 -0700 Eric Dumazet wrote:
> A cpu can observe sd->defer_count reaching 128,
> and call smp_call_function_single_async()
>
> Problem is that the remote CPU can clear sd->defer_count
> before the IPI is run/acknowledged.
>
> Other cpus can queue more packets and also decide
> to call smp_call_function_single_async() while the pending
> IPI was not yet delivered.
>
> This is a common issue with smp_call_function_single_async().
> Callers must ensure correct synchronization and serialization.
>
> I triggered this issue while experimenting smaller threshold.
> Performing the call to smp_call_function_single_async()
> under sd->defer_lock protection did not solve the problem.
>
> Commit 5a18ceca6350 ("smp: Allow smp_call_function_single_async()
> to insert locked csd") replaced an informative WARN_ON_ONCE()
> with a return of -EBUSY, which is often ignored.
> Test of CSD_FLAG_LOCK presence is racy anyway.
If I'm reading this right this is useful for backports but in net-next
it really is a noop? The -EBUSY would be perfectly safe to ignore?
Just checking.
next prev parent reply other threads:[~2022-05-16 18:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 4:24 [PATCH net-next 0/4] net: polish skb defer freeing Eric Dumazet
2022-05-16 4:24 ` [PATCH net-next 1/4] net: fix possible race in skb_attempt_defer_free() Eric Dumazet
2022-05-16 18:15 ` Jakub Kicinski [this message]
2022-05-16 18:24 ` Eric Dumazet
2022-05-16 18:54 ` Jakub Kicinski
2022-05-16 4:24 ` [PATCH net-next 2/4] net: use napi_consume_skb() in skb_defer_free_flush() Eric Dumazet
2022-05-16 4:24 ` [PATCH net-next 3/4] net: add skb_defer_max sysctl Eric Dumazet
2022-05-16 20:39 ` Jakub Kicinski
2022-05-16 20:43 ` Eric Dumazet
2022-05-16 4:24 ` [PATCH net-next 4/4] net: call skb_defer_free_flush() before each napi_poll() Eric Dumazet
2022-05-16 18:21 ` Jakub Kicinski
2022-05-16 18:26 ` Eric Dumazet
2022-05-16 18:56 ` Jakub Kicinski
2022-05-16 10:40 ` [PATCH net-next 0/4] net: polish skb defer freeing patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220516111554.5585a6b5@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.