On Tue, 1 Sep 2020 11:08:59 +0200
Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> 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.
Great. Angelo replied very quickly so you should have it now
(thanks Angelo!)
Thanks for your help.
Jonathan
>
> thanks,
>
> greg k-h
