linux-kernel - Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 1 Jun 2017 12:43:41 -0500
From:   Larry Finger <Larry.Finger@...inger.net>
To:     Jonathan Corbet <corbet@....net>, Jia-Ju Bai <baijiaju1990@....com>
Cc:     kvalo@...eaurora.org, linux-wireless@...r.kernel.org,
        b43-dev@...ts.infradead.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in
 b43legacy_attr_interfmode_store

On 06/01/2017 11:11 AM, Jonathan Corbet wrote:
> On Thu, 01 Jun 2017 09:05:07 +0800
> Jia-Ju Bai <baijiaju1990@....com> wrote:
> 
>> I admit my patches are not well tested, and they may not well fix the bugs.
>> I am looking forward to opinions and suggestions :)
> 
> May I politely suggest that sending out untested locking changes is a
> dangerous thing to do?  You really should not be changing the locking in a
> piece of kernel code without understanding very well what the lock is
> protecting and being able to say why your changes are safe.  Without that,
> the risk of introducing subtle bugs is very high.
> 
> It looks like you have written a useful tool that could help us to make
> the kernel more robust.  If you are interested in my suggestion, I would
> recommend that you post the sleep-in-atomic scenarios that you are
> finding, but refrain from "fixing" them in any case where you cannot offer
> a strong explanation of why your fix is correct.
> 
> Thanks for working to find bugs in the kernel!

I agree with the suggestion above. Locking changes should only be done in 
conjunction with testing by someone that actually has the hardware.

Larry