linux-kernel - Re: [BUG] [Resend] Possible sleep-in-atomic-context bugs involving regmap_lock

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]

Message-ID: <20180910174104.GD10889@sirena.org.uk>
Date:   Mon, 10 Sep 2018 18:41:04 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Jia-Ju Bai <baijiaju1990@...il.com>
Cc:     gregkh@...uxfoundation.org, rafael@...nel.org,
        David Howells <dhowells@...hat.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linus.walleij@...aro.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] [Resend] Possible sleep-in-atomic-context bugs involving
 regmap_lock_mutex()

On Thu, Aug 30, 2018 at 10:34:20AM +0800, Jia-Ju Bai wrote:

> My static tool DSAC reports many sleep-in-atomic-context bugs involving
> regmap_lock_mutex(), so I wonder whether this function is possible to be
> executed in atomic context.

Have you actually analyzed the code paths that are really taken here?
Static tools really don't cope very well with the pluggable locking in
regmap.  If there are problems I'd suggest reporting them to the authors
of the drivers using them, it's not really anything to do with regmap if
they've messed up their locking.

> Here are some example bugs and their call paths in Linux-4.16 (from bottom
> to top, and [FUNC_PTR] means that there is a function pointer call):

That's quite old now...  not that this has been rapidly developed
recently but still.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)