From: Yonghong Song <yhs@meta.com>
To: Teng Qi <starmiku1207184332@gmail.com>
Cc: ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com,
andrii@kernel.org, martin.lau@linux.dev, song@kernel.org,
yhs@fb.com, kpsingh@kernel.org, sdf@google.com,
haoluo@google.com, jolsa@kernel.org, davem@davemloft.net,
kuba@kernel.org, hawk@kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2] kernel: bpf: syscall: fix a possible sleep-in-atomic bug in __bpf_prog_put()
Date: Tue, 30 May 2023 22:38:29 -0700 [thread overview]
Message-ID: <40fc10d4-b68d-83c3-b659-e291031df5bd@meta.com> (raw)
In-Reply-To: <CALyQVaxuONP8WXSVGhT2ih12ae0FwE3C+A1s4O7LArTHERmAxg@mail.gmail.com>
On 5/30/23 10:30 PM, Teng Qi wrote:
>> I would really like you to create a test case
>> to demonstrate with a rcu or spin-lock warnings based on existing code
>> base. With a test case, it would hard to see whether we need this
>> patch or not.
>
> Ok, I will try to construct a test case.
>
>> Please put 'Fixes' right before 'Signed-off-by' in the above.
>
> Ok.
>
>> Could we have cases where in software context we have irqs_disabled()?
>
> What do you mean about software context?
sorry. i mean softirq context.
>
> On Wed, May 31, 2023 at 1:46 AM Yonghong Song <yhs@meta.com> wrote:
>>
>>
>>
>> On 5/30/23 12:06 AM, starmiku1207184332@gmail.com wrote:
>>> From: Teng Qi <starmiku1207184332@gmail.com>
>>>
>>> __bpf_prog_put() indirectly calls kvfree() through bpf_prog_put_deferred()
>>> which is unsafe under atomic context. The current
>>> condition ‘in_irq() || irqs_disabled()’ in __bpf_prog_put() to ensure safety
>>> does not cover cases involving the spin lock region and rcu read lock region.
>>> Since __bpf_prog_put() is called by various callers in kernel/, net/ and
>>> drivers/, and potentially more in future, it is necessary to handle those
>>> cases as well.
>>>
>>> Although we haven`t found a proper way to identify the rcu read lock region,
>>> we have noticed that vfree() calls vfree_atomic() with the
>>> condition 'in_interrupt()' to ensure safety.
>>
>> I would really like you to create a test case
>> to demonstrate with a rcu or spin-lock warnings based on existing code
>> base. With a test case, it would hard to see whether we need this
>> patch or not.
>>
>>>
>>> To make __bpf_prog_put() safe in practice, we propose calling
>>> bpf_prog_put_deferred() with the condition 'in_interrupt()' and
>>> using the work queue for any other context.
>>>
>>> We also added a comment to indicate that the safety of __bpf_prog_put()
>>> relies implicitly on the implementation of vfree().
>>>
>>> Signed-off-by: Teng Qi <starmiku1207184332@gmail.com>
>>> ---
>>> v2:
>>> remove comments because of self explanatory of code.
>>>
>>> Fixes: d809e134be7a ("bpf: Prepare bpf_prog_put() to be called from irq context.")
>>
>> Please put 'Fixes' right before 'Signed-off-by' in the above.
>>
>>> ---
>>> kernel/bpf/syscall.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>>> index 14f39c1e573e..96658e5874be 100644
>>> --- a/kernel/bpf/syscall.c
>>> +++ b/kernel/bpf/syscall.c
>>> @@ -2099,7 +2099,7 @@ static void __bpf_prog_put(struct bpf_prog *prog)
>>> struct bpf_prog_aux *aux = prog->aux;
>>>
>>> if (atomic64_dec_and_test(&aux->refcnt)) {
>>> - if (in_irq() || irqs_disabled()) {
>>> + if (!in_interrupt()) {
>>
>> Could we have cases where in software context we have irqs_disabled()?
>>
>>> INIT_WORK(&aux->work, bpf_prog_put_deferred);
>>> schedule_work(&aux->work);
>>> } else {
prev parent reply other threads:[~2023-05-31 5:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-30 7:06 [PATCH v2] kernel: bpf: syscall: fix a possible sleep-in-atomic bug in __bpf_prog_put() starmiku1207184332
2023-05-30 8:33 ` Ratheesh Kannoth
2023-05-30 17:45 ` Yonghong Song
2023-05-31 5:30 ` Teng Qi
2023-05-31 5:38 ` Yonghong Song [this message]
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=40fc10d4-b68d-83c3-b659-e291031df5bd@meta.com \
--to=yhs@meta.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=haoluo@google.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=starmiku1207184332@gmail.com \
--cc=yhs@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox