public inbox for linux-iio@vger.kernel.org
 help / color / mirror / Atom feed
From: William Breathitt Gray <william.gray@linaro.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jonathan Cameron <jic23@kernel.org>,
	stable@vger.kernel.org
Subject: Re: [RESEND PATCH 5.15 v3 5/5] counter: 104-quad-8: Fix race condition between FLAG and CNTR reads
Date: Tue, 18 Apr 2023 06:12:43 -0400	[thread overview]
Message-ID: <ZD5tG45rXLemtkrX@fedora> (raw)
In-Reply-To: <2023041849-nursing-cling-8729@gregkh>

[-- Attachment #1: Type: text/plain, Size: 3849 bytes --]

On Tue, Apr 18, 2023 at 11:41:29AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Apr 17, 2023 at 09:40:52AM -0400, William Breathitt Gray wrote:
> > On Tue, Apr 11, 2023 at 11:52:20AM -0400, William Breathitt Gray wrote:
> > > commit 4aa3b75c74603c3374877d5fd18ad9cc3a9a62ed upstream.
> > > 
> > > The Counter (CNTR) register is 24 bits wide, but we can have an
> > > effective 25-bit count value by setting bit 24 to the XOR of the Borrow
> > > flag and Carry flag. The flags can be read from the FLAG register, but a
> > > race condition exists: the Borrow flag and Carry flag are instantaneous
> > > and could change by the time the count value is read from the CNTR
> > > register.
> > > 
> > > Since the race condition could result in an incorrect 25-bit count
> > > value, remove support for 25-bit count values from this driver.
> > > 
> > > Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8")
> > > Cc: <stable@vger.kernel.org> # 5.15.x
> > > Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
> > > ---
> > >  drivers/counter/104-quad-8.c | 18 +++---------------
> > >  1 file changed, 3 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> > > index 0caa60537b..643aae0c9f 100644
> > > --- a/drivers/counter/104-quad-8.c
> > > +++ b/drivers/counter/104-quad-8.c
> > > @@ -61,10 +61,6 @@ struct quad8 {
> > >  #define QUAD8_REG_CHAN_OP 0x11
> > >  #define QUAD8_REG_INDEX_INPUT_LEVELS 0x16
> > >  #define QUAD8_DIFF_ENCODER_CABLE_STATUS 0x17
> > > -/* Borrow Toggle flip-flop */
> > > -#define QUAD8_FLAG_BT BIT(0)
> > > -/* Carry Toggle flip-flop */
> > > -#define QUAD8_FLAG_CT BIT(1)
> > >  /* Error flag */
> > >  #define QUAD8_FLAG_E BIT(4)
> > >  /* Up/Down flag */
> > > @@ -121,17 +117,9 @@ static int quad8_count_read(struct counter_device *counter,
> > >  {
> > >  	struct quad8 *const priv = counter->priv;
> > >  	const int base_offset = priv->base + 2 * count->id;
> > > -	unsigned int flags;
> > > -	unsigned int borrow;
> > > -	unsigned int carry;
> > >  	int i;
> > >  
> > > -	flags = inb(base_offset + 1);
> > > -	borrow = flags & QUAD8_FLAG_BT;
> > > -	carry = !!(flags & QUAD8_FLAG_CT);
> > > -
> > > -	/* Borrow XOR Carry effectively doubles count range */
> > > -	*val = (unsigned long)(borrow ^ carry) << 24;
> > > +	*val = 0;
> > >  
> > >  	mutex_lock(&priv->lock);
> > >  
> > > @@ -699,8 +687,8 @@ static ssize_t quad8_count_ceiling_read(struct counter_device *counter,
> > >  
> > >  	mutex_unlock(&priv->lock);
> > >  
> > > -	/* By default 0x1FFFFFF (25 bits unsigned) is maximum count */
> > > -	return sprintf(buf, "33554431\n");
> > > +	/* By default 0xFFFFFF (24 bits unsigned) is maximum count */
> > > +	return sprintf(buf, "16777215\n");
> > >  }
> > >  
> > >  static ssize_t quad8_count_ceiling_write(struct counter_device *counter,
> > > 
> > > base-commit: d86dfc4d95cd218246b10ca7adf22c8626547599
> > > -- 
> > > 2.39.2
> > 
> > Greg,
> > 
> > This patch will no longer apply to 5.15.x when the "counter: Internalize
> > sysfs interface code" patch in the stable-queue tree is merged [0].
> > However, I believe the 6.1 backport [1] will apply instead at that
> > point. What is the best way to handle this situation? Should I resend
> > the 6.1 backport with the stable list Cc tag adjusted for 5.15.x, or are
> > you able to apply the 6.1 backport patch directly to the 5.15.x tree?
> 
> The 6.1.y backport didn't apply either :(
> 
> Can you resend all of these rebased against the next round of stable
> releases when they are released later this week?
> 
> thanks,
> 
> greg k-h

Sure, I'll rebase and resend these after the next round of stable
releases is available.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2023-04-18 10:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-11 15:52 [RESEND PATCH 4.14 v3 1/5] iio: counter: 104-quad-8: Fix race condition between FLAG and CNTR reads William Breathitt Gray
2023-04-11 15:52 ` [RESEND PATCH 4.19 v3 2/5] " William Breathitt Gray
2023-04-11 15:52 ` [RESEND PATCH 5.4 v3 3/5] " William Breathitt Gray
2023-04-11 15:52 ` [RESEND PATCH 5.10 v3 4/5] " William Breathitt Gray
2023-04-11 15:52 ` [RESEND PATCH 5.15 v3 5/5] " William Breathitt Gray
2023-04-17 13:40   ` William Breathitt Gray
2023-04-18  9:41     ` Greg Kroah-Hartman
2023-04-18 10:12       ` William Breathitt Gray [this message]
2023-05-02  8:19     ` Pavel Machek
2023-05-03  0:12       ` William Breathitt Gray

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=ZD5tG45rXLemtkrX@fedora \
    --to=william.gray@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox