Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 10 Sep 2018 18:41:04 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Jia-Ju Bai <baijiaju1990@gmail.com>
Cc:     gregkh@linuxfoundation.org, rafael@kernel.org,
        David Howells <dhowells@redhat.com>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linus.walleij@linaro.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] [Resend] Possible sleep-in-atomic-context bugs involving
 regmap_lock_mutex()
Message-ID: <20180910174104.GD10889@sirena.org.uk>
References: <9bcef57b-1a5c-cd16-8e44-932ef3be08cb@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="zbGR4y+acU1DwHSi"
Content-Disposition: inline
In-Reply-To: <9bcef57b-1a5c-cd16-8e44-932ef3be08cb@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--zbGR4y+acU1DwHSi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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.

--zbGR4y+acU1DwHSi
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAluWrK8ACgkQJNaLcl1U
h9D2Ggf+IRS/Vo6RNxCedLlyo6Clb2Lft0qW0jvtMBVOpOLeTe3zF394SWdyz+cC
RCRqSfDSc0EotIjip8x01HfCsKAGLHSmsnVhVHkiVC7h68lOJvDo9yHOdqTJJxrB
cSno1c7dRPbE8xPtgYcw+RXh/PmWYwnIgYryv7yyzFfWOYifd/6Psrcctl4y06bW
+W9yj3WRxABuL206Ww/chnz8zEGOLknisL+CxO971buZ6rme1DnQjBDYwMO652Xm
u4l4FK4lPQxxTi50vcKfrg2Xq/vzwsJQk8DY1pt5k/Kmr8hzSeM2P4OtQqltoRx3
bgcNWu5Hghq8f9GqAx3p6Zzryj//zA==
=WEKA
-----END PGP SIGNATURE-----

--zbGR4y+acU1DwHSi--