From: Greg KH <gregkh@linuxfoundation.org>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Angelo Compagnucci <angelo.compagnucci@gmail.com>,
Julia Lawall <julia.lawall@inria.fr>,
linux-iio@vger.kernel.org
Subject: Re: [iio:fixes-togreg 19/19] drivers/iio/adc/mcp3422.c:147:3-9: preceding lock on line 137 (fwd)
Date: Tue, 1 Sep 2020 11:08:59 +0200 [thread overview]
Message-ID: <20200901090859.GA148841@kroah.com> (raw)
In-Reply-To: <20200901095041.0000279e@Huawei.com>
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@gmail.com> wrote:
>
> > Il giorno lun 31 ago 2020 alle ore 09:48 Julia Lawall
> > <julia.lawall@inria.fr> 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@inria.fr> 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@vger.kernel.org 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
next prev parent reply other threads:[~2020-09-01 9:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-29 20:29 [iio:fixes-togreg 19/19] drivers/iio/adc/mcp3422.c:147:3-9: preceding lock on line 137 (fwd) Julia Lawall
[not found] ` <CA+TH9VkAo4CgCVDGvQumfePvNCg9ffwEHbqic7TsYJn4VZ3aTw@mail.gmail.com>
2020-08-31 7:48 ` Julia Lawall
[not found] ` <CA+TH9VmQq3=Kf=f72CSn2ZziKP3YP6qjsXQL1nXzS-O8FscBWw@mail.gmail.com>
2020-09-01 8:50 ` Jonathan Cameron
2020-09-01 9:08 ` Greg KH [this message]
2020-09-01 10:05 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200901090859.GA148841@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=angelo.compagnucci@gmail.com \
--cc=julia.lawall@inria.fr \
--cc=linux-iio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.