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]
Message-ID: <1ecbbf35-2664-9132-fdd4-d835f792cb18@huawei.com>
Date:   Mon, 5 Sep 2022 14:30:50 +0800
From:   Ye Weihua <yeweihua4@...wei.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
CC:     <keescook@...omium.org>, <oleg@...hat.com>, <tglx@...utronix.de>,
        <chang.seok.bae@...el.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] signal: fix deadlock caused by calling printk() under
 sighand->siglock


On 2022/8/27 5:23, Eric W. Biederman wrote:
> While the patch below will in theory fix the reported deadlock, I don't
> think it is a good choice of fix.  As a rule we want to allow printk to
> be callable in as many places as possible, so that it can be used for
> debugging.  There are enough places that take siglock that outlawing
> printk under siglock will make the kernel unstable.
>
> I tried to read the current kernel and verify this deadlock to see if I
> could suggest a better location to change the code to fix the deadlock.
> Say modifying task_work_add to not take siglock.  The current
> task_work_add does not take siglock.  I encountered a few other
> significant function differences as well.  One significant difference is
> that io_poll_double_wake no longer exists.
>
> I think the amb-pl011.c driver might even be more different yet.
>
> Can you reproduce this on current kernels?
>
> Reading the code I think this is already fixed.
>
> Perhaps you want to read the code of the affected subsystems and pick
> some appropriate changes to backport to 5.10?
>
> Eric
>
> .

Thank you for your reply.


I tested it on the current version for a few days using the same case 
and the

problem didn't occur again. You're right, the problem has been fixed. 
I've read

some of the code and learned about some of the changes, and I'll try to 
backport

the relevant patches to the problem version later.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ