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;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
Subject: Re: WARNING in debug_mutex_unlock
From:   Hao Sun <sunhao.th@gmail.com>
In-Reply-To: <be494ee3-864d-1a33-e14d-d27712ab6248@meta.com>
Date:   Mon, 16 Jan 2023 10:24:09 +0800
Cc:     bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        John Fastabend <john.fastabend@gmail.com>,
        Andrii Nakryiko <andrii@kernel.org>,
        Martin KaFai Lau <martin.lau@linux.dev>,
        Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
        KP Singh <kpsingh@kernel.org>,
        Stanislav Fomichev <sdf@google.com>,
        Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>,
        David Miller <davem@davemloft.net>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4BBA1C3-C704-49D3-8E13-18875B27FB47@gmail.com>
References: <20230109074425.12556-1-sunhao.th@gmail.com>
 <be494ee3-864d-1a33-e14d-d27712ab6248@meta.com>
To:     Yonghong Song <yhs@meta.com>
Precedence: bulk


> On 13 Jan 2023, at 2:45 PM, Yonghong Song <yhs@meta.com> wrote:
>=20
>=20
>=20
> On 1/8/23 11:44 PM, Hao Sun wrote:
>> Hi,
>> The following warning can be triggered with the C reproducer in
>> the link. The repro starts 32 threads, each attaches a tracepoint
>> into `ext4_mark_inode_dirty`. The prog loads the following insns
>> that simply sends signal to current proc, and then wait.
>> Seems issues in queued irq_work with `do_bpf_send_signal`, also
>> I'm wondering what if the task in `send_signal_irq_work` exited,
>> at the time the callback invoked.
>=20
> Somehow, I cannot reproduce the issue in my qemu environment
> with below kernel config and C reproducer.
>=20
> But could you try the following patch to see whether it
> fixed the issue in your environment?

Tested the below patch on my local machine, seems fixed the issue.

Before applying the patch, the reproducer can still trigger the
reported issue on a latest bpf-next build; After applying the
patch, the warning no longer appears.

The test is conducted on: dfff86f8eb6a (=E2=80=9CMerge branch =
'samples/bpf:
modernize BPF functionality test programs'")


>=20
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 23ce498bca97..1b26d51caf31 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -831,6 +831,7 @@ static void do_bpf_send_signal(struct irq_work =
*entry)
>=20
>        work =3D container_of(entry, struct send_signal_irq_work, =
irq_work);
>        group_send_sig_info(work->sig, SEND_SIG_PRIV, work->task, =
work->type);
> +       put_task_struct(work->task);
> }
>=20
> static int bpf_send_signal_common(u32 sig, enum pid_type type)
> @@ -862,7 +863,7 @@ static int bpf_send_signal_common(u32 sig, enum =
pid_type type)
>                 * to the irq_work. The current task may change when =
queued
>                 * irq works get executed.
>                 */
> -               work->task =3D current;
> +               work->task =3D get_task_struct(current);
>                work->sig =3D sig;
>                work->type =3D type;
>                irq_work_queue(&work->irq_work);
>=20