linux-kernel - Re: WARNING in debug_mutex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 16 Jan 2023 22:02:37 -0800
From:   Yonghong Song <yhs@...a.com>
To:     Hao Sun <sunhao.th@...il.com>
Cc:     bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        John Fastabend <john.fastabend@...il.com>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
        KP Singh <kpsingh@...nel.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
        David Miller <davem@...emloft.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: WARNING in debug_mutex_unlock



On 1/15/23 6:24 PM, Hao Sun wrote:
> 
> 
>> On 13 Jan 2023, at 2:45 PM, Yonghong Song <yhs@...a.com> wrote:
>>
>>
>>
>> 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.
>>
>> Somehow, I cannot reproduce the issue in my qemu environment
>> with below kernel config and C reproducer.
>>
>> 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 (“Merge branch 'samples/bpf:
> modernize BPF functionality test programs'")

Thanks for testing. I will submit a patch shortly with your
Reported-by and Tested-by.

> 
> 
>>
>> 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)
>>
>>         work = 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);
>> }
>>
>> 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 = current;
>> +               work->task = get_task_struct(current);
>>                 work->sig = sig;
>>                 work->type = type;
>>                 irq_work_queue(&work->irq_work);
>>
>