Re: [PATCH] iio: adc: ina2xx: avoid kthread_stop() with stale task_struct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2 Jul 2018 17:44:42 +0900
Akinobu Mita <akinobu.mita@xxxxxxxxx> wrote:

> 2018年7月1日(日) 2:40 Jonathan Cameron <jic23@xxxxxxxxxx>:
> >
> > On Mon, 25 Jun 2018 00:05:21 +0900
> > Akinobu Mita <akinobu.mita@xxxxxxxxx> wrote:
> >  
> > > When the buffer is enabled for ina2xx driver, a dedicated kthread is
> > > invoked to capture mesurement data.  When the buffer is disabled, the
> > > kthread is stopped.
> > >
> > > However if the kthread gets register access errors, it immediately exits
> > > and when the malfunctional buffer is disabled, the stale task_struct
> > > pointer is accessed as there is no kthread to be stopped.
> > >
> > > A similar issue in the usbip driver is prevented by kthread_get_run and
> > > kthread_stop_put helpers by increasing usage count of the task_struct.
> > > This change applies the same solution.
> > >
> > > Cc: Stefan Brüns <stefan.bruens@xxxxxxxxxxxxxx>
> > > Cc: Jonathan Cameron <jic23@xxxxxxxxxx>
> > > Signed-off-by: Akinobu Mita <akinobu.mita@xxxxxxxxx>  
> > Seems fine, but this is a fix so should have an appropriate fixes
> > tag.  Feel free to send one in reply to this thread rather than a v2.  
> 
> It seems like this problem has been there ever since the ina2xx driver
> was added.
> 
> Fixes: c43a102e67db ("iio: ina2xx: add support for TI INA2xx Power Monitors")
> 
Thanks, added.
> > Without a fixes tag it can be very hard to know exactly where
> > a patch 'should' apply.  I also have little visibility on
> > how important backporting htis issue is.  What would actually trigger
> > the issue and is it likely to be seen in the wild?  
> 
> This issue was actually triggered in the system with an I2C controller
> that occasionally malfunctions due to a software bug in the controller
> driver.

In that case I'm not going to rush it, but rather will take it via the
next merge window.

> 
> BTW, there is no way to notify this error to the process that is calling
> poll() or read() to the buffer.  Maybe we should implement the mechanism
> for returning POLLHUP or POLLERR events.

I'm certainly not against adding something like that to notify on error
cases.  In general, minor hardware failures are not well handled in the
kernel - there is no 'standard' way of doing it.  Every now and then
it is discussed but no one ever takes it any further.

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan

> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux