Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230530070610.600063-1-starmiku1207184332@gmail.com> <4f37f760-048b-9d54-14ae-d1f979898625@meta.com>
In-Reply-To: <4f37f760-048b-9d54-14ae-d1f979898625@meta.com>
From:   Teng Qi <starmiku1207184332@gmail.com>
Date:   Wed, 31 May 2023 13:30:23 +0800
Message-ID: <CALyQVaxuONP8WXSVGhT2ih12ae0FwE3C+A1s4O7LArTHERmAxg@mail.gmail.com>
Subject: Re: [PATCH v2] kernel: bpf: syscall: fix a possible sleep-in-atomic
 bug in __bpf_prog_put()
To:     Yonghong Song <yhs@meta.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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

> 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?

On Wed, May 31, 2023 at 1:46=E2=80=AFAM 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_deferre=
d()
> > which is unsafe under atomic context. The current
> > condition =E2=80=98in_irq() || irqs_disabled()=E2=80=99 in __bpf_prog_p=
ut() to ensure safety
> > does not cover cases involving the spin lock region and rcu read lock r=
egion.
> > Since __bpf_prog_put() is called by various callers in kernel/, net/ an=
d
> > drivers/, and potentially more in future, it is necessary to handle tho=
se
> > cases as well.
> >
> > Although we haven`t found a proper way to identify the rcu read lock re=
gion,
> > 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 =3D 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 {