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

[Oleksij Rempel <o.rempel@pengutronix.de>]

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:
> > On Fri, 25 Jun 2021 08:59:22 +0200
> > Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> > 
> > > 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().

> > 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.

> > 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 |