Re: [PATCH v1 2/2] iio: adc: tsc2046: fix sleeping in atomic context warning and a deadlock after iio_trigger_poll() call

On Mon, Jul 05, 2021 at 05:54:40AM +0200, Oleksij Rempel wrote:

Hi Jonathan,

On Sun, Jul 04, 2021 at 06:57:10PM +0100, Jonathan Cameron wrote:

quoted

On Fri, 25 Jun 2021 08:59:22 +0200
Oleksij Rempel [off-list ref] wrote:

quoted

If iio_trigger_poll() is called after IRQ was disabled, we will call
reenable_trigger() directly from hard IRQ or hrtimer context instead of
IRQ thread. In this case we will run in to multiple issue as sleeping in atomic
context and a deadlock.

Hmm. This sounds like a problem that might bite us in other circumstances.

So do I have the basic issue right in thinking we have a race between
calling iio_trigger_poll() and having no devices still using that trigger?
Thus we end up with all of trig->subirqs not being enabled.

There was a previous discussion that the calls to iio_trigger_notify_done() in
iio_trigger_poll() are only meant to decrement the counter, as the assumption
was that the calls via threads would always happen later.  Unfortunately this
is all clearly a little bit racy and I suspect not many of the reenable() callbacks
are safe if they are called in interrupt context.

Perhaps an alternative would be to schedule the reenable() if we hit it from
that path thus ensuring it doesn't happen in a place where we can't sleep?

Would something like that solve your problem?

Yes :)

But the initial design of the driver wasn't that good, there were two
variables to decide what to do and now there is a proper state machine.
I see this as a cleanup, that also fixes the problem with the
re-enable().

quoted

I'd do it by having a new function

iio_trigger_notify_done_schedule() that uses a work struct to call
trig->ops->reenable(trig) from a context that can sleep.

Said that, the driver doesn't need the re-enable from sleeping context
anymore. If you provide an initial patch I can test that.

quoted

It's a rare corner case so I don't really care that in theory we might have
a device that was safe to reenable the trigger without sleeping.  That makes
it easier to just have one path for this which allows sleeping.

Sure, having always the same (i.e. sleeping context) makes it easier for
the driver, especially if the non sleeping re-enable is only called
during shutdown of the trigger-consumer if an interrupt comes in.

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |