All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: stefan@agner.ch
Cc: linux-tegra@vger.kernel.org, Richard Weinberger <richard@nod.at>,
	linux-mtd@lists.infradead.org
Subject: [bug report] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver
Date: Tue, 3 Jul 2018 17:19:57 +0300	[thread overview]
Message-ID: <20180703141957.j27w6efnkhij5blz@kili.mountain> (raw)

Hello Stefan Agner,

The patch d7d9f8ec77fe: "mtd: rawnand: add NVIDIA Tegra NAND Flash
controller driver" from Jun 24, 2018, leads to the following static
checker warning:

	drivers/mtd/nand/raw/tegra_nand.c:476 tegra_nand_select_chip()
	warn: array off by one? 'nand->cs[die_nr]'

drivers/mtd/nand/raw/tegra_nand.c
   465  static void tegra_nand_select_chip(struct mtd_info *mtd, int die_nr)
   466  {
   467          struct nand_chip *chip = mtd_to_nand(mtd);
   468          struct tegra_nand_chip *nand = to_tegra_chip(chip);
   469          struct tegra_nand_controller *ctrl = to_tegra_ctrl(chip->controller);
   470  
   471          if (die_nr < 0 || die_nr > 1) {
   472                  ctrl->cur_cs = -1;
   473                  return;
   474          }
   475  
   476          ctrl->cur_cs = nand->cs[die_nr];
   477  }

The story is that nand->cs[] is a one element array.  Some people use
one element arrays like this as variable size arrays.  It's better to
use a zero size array, but I think that might be a GCC feature and not
everyone knows you can do that.  Smatch treats this one as unknown size
because apparently it can't tie it back to the kmalloc().

But it really is a one element array and the condition is off by one.

But really one element arrays are super weird.  Why not just use a
pointer?

regards,
dan carpenter

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

WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: stefan@agner.ch
Cc: Richard Weinberger <richard@nod.at>,
	linux-mtd@lists.infradead.org, linux-tegra@vger.kernel.org
Subject: [bug report] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver
Date: Tue, 3 Jul 2018 17:19:57 +0300	[thread overview]
Message-ID: <20180703141957.j27w6efnkhij5blz@kili.mountain> (raw)

Hello Stefan Agner,

The patch d7d9f8ec77fe: "mtd: rawnand: add NVIDIA Tegra NAND Flash
controller driver" from Jun 24, 2018, leads to the following static
checker warning:

	drivers/mtd/nand/raw/tegra_nand.c:476 tegra_nand_select_chip()
	warn: array off by one? 'nand->cs[die_nr]'

drivers/mtd/nand/raw/tegra_nand.c
   465  static void tegra_nand_select_chip(struct mtd_info *mtd, int die_nr)
   466  {
   467          struct nand_chip *chip = mtd_to_nand(mtd);
   468          struct tegra_nand_chip *nand = to_tegra_chip(chip);
   469          struct tegra_nand_controller *ctrl = to_tegra_ctrl(chip->controller);
   470  
   471          if (die_nr < 0 || die_nr > 1) {
   472                  ctrl->cur_cs = -1;
   473                  return;
   474          }
   475  
   476          ctrl->cur_cs = nand->cs[die_nr];
   477  }

The story is that nand->cs[] is a one element array.  Some people use
one element arrays like this as variable size arrays.  It's better to
use a zero size array, but I think that might be a GCC feature and not
everyone knows you can do that.  Smatch treats this one as unknown size
because apparently it can't tie it back to the kmalloc().

But it really is a one element array and the condition is off by one.

But really one element arrays are super weird.  Why not just use a
pointer?

regards,
dan carpenter

             reply	other threads:[~2018-07-03 14:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-03 14:19 Dan Carpenter [this message]
2018-07-03 14:19 ` [bug report] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver Dan Carpenter
2018-07-03 20:04 ` Boris Brezillon
2018-07-03 20:04   ` Boris Brezillon
2018-07-04  7:43   ` Stefan Agner
2018-07-04  7:43     ` Stefan Agner
2018-07-04  7:52     ` Boris Brezillon
2018-07-04  7:52       ` Boris Brezillon
2018-07-04  8:14       ` Stefan Agner
2018-07-04  8:14         ` Stefan Agner

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=20180703141957.j27w6efnkhij5blz@kili.mountain \
    --to=dan.carpenter@oracle.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=richard@nod.at \
    --cc=stefan@agner.ch \
    /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.