All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Colin King <colin.king@canonical.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH][next] mtd: rawnand: ensure return variable is initialized
Date: Mon, 7 Jun 2021 08:57:11 +0200	[thread overview]
Message-ID: <20210607085711.65c64c58@xps13> (raw)
In-Reply-To: <20210601121401.GY1955@kadam>

Hi Dan,

Dan Carpenter <dan.carpenter@oracle.com> wrote on Tue, 1 Jun 2021
15:14:02 +0300:

> On Thu, May 27, 2021 at 05:03:09PM +0200, Miquel Raynal wrote:
> > Hi Colin,
> > 
> > Colin King <colin.king@canonical.com> wrote on Thu, 27 May 2021
> > 15:50:48 +0100:
> >   
> > > From: Colin Ian King <colin.king@canonical.com>
> > > 
> > > Currently there are corner cases where spec_times is NULL and
> > > chip->parameters.onfi or when best_mode is zero where ret is  
> > 
> >                        ^
> > something is missing here, the sentence is not clear
> >   
> > > not assigned a value and an uninitialized return value can be
> > > returned. Fix this by ensuring ret is initialized to -EINVAL.  
> > 
> > I don't see how this situation can happen.
> > 
> > In both cases, no matter the value of best_mode, the for loop will
> > always execute at least one time (mode 0) so ret will be populated.
> > 
> > Maybe the robot does not know that best_mode cannot be negative and
> > should be defined unsigned, but the current patch is invalid.
> >  
> 
> People think list counter unsigned is a good idea, but it's a terrible
> idea and has caused hundreds of bugs for me to fix/report over the
> years.  *grumble*.
> 
> Anyway, I was revisiting this code because it showed up as a Smatch
> warning and the bug appears to be real.
> 
> 	best_mode = fls(chip->parameters.onfi->sdr_timing_modes) - 1;
> 
> The "onfi->sdr_timing_modes" comes from the hardware in nand_onfi_detect()
> and nothing checks that it is non-zero so "best_mode = fls(0) - 1;" is
> negative and "ret" is uninitialized.

In the ONFI specification, the sdr_timing_mode field is defined as
follow:

SDR timing mode support
BIT  VALUE MEANING
6-15 N/A   Reserved (0)
5    1     supports timing mode 5
4    1     supports timing mode 4
3    1     supports timing mode 3
2    1     supports timing mode 2
1    1     supports timing mode 1
0    1     supports timing mode 0, shall be 1

IOW sdr_timing_modes *cannot* be 0, or it is a truly deep and crazily
impacting hardware bug (so far I am not aware of any chip not returning
the right timing mode 0 value). Hence my proposal to turn best_mode as
unsigned. I honestly don't know what is the best option here and am
fully open to other suggestions to silence the robot.

Thanks,
Miquèl

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Colin King <colin.king@canonical.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH][next] mtd: rawnand: ensure return variable is initialized
Date: Mon, 7 Jun 2021 08:57:11 +0200	[thread overview]
Message-ID: <20210607085711.65c64c58@xps13> (raw)
In-Reply-To: <20210601121401.GY1955@kadam>

Hi Dan,

Dan Carpenter <dan.carpenter@oracle.com> wrote on Tue, 1 Jun 2021
15:14:02 +0300:

> On Thu, May 27, 2021 at 05:03:09PM +0200, Miquel Raynal wrote:
> > Hi Colin,
> > 
> > Colin King <colin.king@canonical.com> wrote on Thu, 27 May 2021
> > 15:50:48 +0100:
> >   
> > > From: Colin Ian King <colin.king@canonical.com>
> > > 
> > > Currently there are corner cases where spec_times is NULL and
> > > chip->parameters.onfi or when best_mode is zero where ret is  
> > 
> >                        ^
> > something is missing here, the sentence is not clear
> >   
> > > not assigned a value and an uninitialized return value can be
> > > returned. Fix this by ensuring ret is initialized to -EINVAL.  
> > 
> > I don't see how this situation can happen.
> > 
> > In both cases, no matter the value of best_mode, the for loop will
> > always execute at least one time (mode 0) so ret will be populated.
> > 
> > Maybe the robot does not know that best_mode cannot be negative and
> > should be defined unsigned, but the current patch is invalid.
> >  
> 
> People think list counter unsigned is a good idea, but it's a terrible
> idea and has caused hundreds of bugs for me to fix/report over the
> years.  *grumble*.
> 
> Anyway, I was revisiting this code because it showed up as a Smatch
> warning and the bug appears to be real.
> 
> 	best_mode = fls(chip->parameters.onfi->sdr_timing_modes) - 1;
> 
> The "onfi->sdr_timing_modes" comes from the hardware in nand_onfi_detect()
> and nothing checks that it is non-zero so "best_mode = fls(0) - 1;" is
> negative and "ret" is uninitialized.

In the ONFI specification, the sdr_timing_mode field is defined as
follow:

SDR timing mode support
BIT  VALUE MEANING
6-15 N/A   Reserved (0)
5    1     supports timing mode 5
4    1     supports timing mode 4
3    1     supports timing mode 3
2    1     supports timing mode 2
1    1     supports timing mode 1
0    1     supports timing mode 0, shall be 1

IOW sdr_timing_modes *cannot* be 0, or it is a truly deep and crazily
impacting hardware bug (so far I am not aware of any chip not returning
the right timing mode 0 value). Hence my proposal to turn best_mode as
unsigned. I honestly don't know what is the best option here and am
fully open to other suggestions to silence the robot.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  parent reply	other threads:[~2021-06-07  6:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 14:50 [PATCH][next] mtd: rawnand: ensure return variable is initialized Colin King
2021-05-27 14:50 ` Colin King
2021-05-27 15:03 ` Miquel Raynal
2021-05-27 15:03   ` Miquel Raynal
2021-05-27 15:22   ` Colin Ian King
2021-05-27 15:22     ` Colin Ian King
2021-06-01 12:14   ` Dan Carpenter
2021-06-01 12:14     ` Dan Carpenter
2021-06-01 12:58     ` Dan Carpenter
2021-06-01 12:58       ` Dan Carpenter
2021-06-07  6:57     ` Miquel Raynal [this message]
2021-06-07  6:57       ` Miquel Raynal
2021-06-08  6:10       ` Dan Carpenter
2021-06-08  6:10         ` Dan Carpenter

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=20210607085711.65c64c58@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=colin.king@canonical.com \
    --cc=dan.carpenter@oracle.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    /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.