On Tue, Sep 01, 2020 at 09:50:41AM +0100, Jonathan Cameron wrote:
> On Mon, 31 Aug 2020 11:09:53 +0200
> Angelo Compagnucci <angelo.compagnucci@xxxxxxxxx> wrote:
>
> > Il giorno lun 31 ago 2020 alle ore 09:48 Julia Lawall
> > <julia.lawall@xxxxxxxx> ha scritto:
> > >
> > >
> > >
> > > On Mon, 31 Aug 2020, Angelo Compagnucci wrote:
> > >
> > > > Hi Julia,
> > > >
> > > > Il giorno sab 29 ago 2020 alle ore 22:29 Julia Lawall
> > > > <julia.lawall@xxxxxxxx> ha scritto:
> > > > >
> > > > > Please check whether there should be a mutex_unlock before line 147.
> > > >
> > > > Having a mutex_unlock before line 147 is wrong here, cause the lock
> > > > should be held for the entire reading operation. Adding an unlock
> > > > before the lock means that a concurrent call can unlock the lock
> > > > previously held by another call and the result ends up mixing the
> > > > reading for the first call to the reading of the second call.
> > >
> > > OK, I don't know the calling context. But you have a function where the
> > > lock is held on the failure path and is released on the success path,
> > > which seems at least a little strange.
> >
> > I see.
> >
> > I have to respin!
> >
> > Thanks for your support!
> Hi Julia, Angelo,
>
> Please can we cc linux-iio@xxxxxxxxxxxxxxx for such reports.
> The fix has headed upstream. So we need to chase it with a fix asap.
>
> Greg, would you prefer a following fix (please cc Greg directly) or
> to revert the patch?
>
> 3f1093d83d71 ("iio: adc: mcp3422: fix locking scope")
>
> Sorry I missed this one. Was working on wrong computer to access
> the account this went to.
A patch is always easier for me to apply than a revert is.
thanks,
greg k-h
