linux-kernel - Re: [PATCH 1/2] mtd: spi-nor: rework spi nor read and write.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <201507291903.36020.marex@denx.de>
Date:	Wed, 29 Jul 2015 19:03:35 +0200
From:	Marek Vasut <marex@...x.de>
To:	Michal Suchanek <hramrach@...il.com>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	Han Xu <han.xu@...escale.com>,
	Rafał Miłecki <zajec5@...il.com>,
	Alison Chaiken <alison_chaiken@...tor.com>,
	Huang Shijie <b32955@...escale.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	Gabor Juhos <juhosg@...nwrt.org>,
	"Bean Huo 霍斌斌 (beanhuo)" 
	<beanhuo@...ron.com>,
	MTD Maling List <linux-mtd@...ts.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] mtd: spi-nor: rework spi nor read and write.

On Wednesday, July 29, 2015 at 06:16:21 AM, Michal Suchanek wrote:
> On 28 July 2015 at 20:15, Marek Vasut <marex@...x.de> wrote:
> > On Tuesday, July 28, 2015 at 11:23:02 AM, Michal Suchanek wrote:
> >> The spi_nor read and write functions pass thru the mtd retlen to the
> >> chip-specific read and write function. This makes it difficult to check
> >> for errors in read and write functions and these errors are not checked.
> >> This leads to silent data corruption.
> >> 
> >> This patch styles the chip-specific read and write function as unix
> >> read(2) and write(2) and updates the retlen in the spi-nor generic
> >> driver.
> >> 
> >> This also makes it possible to check for write errors.
> >> When pl330 fails to transfer the flash data over SPI I get I/O error
> >> instead of 4M of zeroes.
> >> 
> >> I do not have sst and fsl hardware to test with.
> >> 
> >> Signed-off-by: Michal Suchanek <hramrach@...il.com>
> >> ---
> >> 
> >>  drivers/mtd/devices/m25p80.c      | 33 ++++++++++++++---------
> >>  drivers/mtd/spi-nor/fsl-quadspi.c | 29 ++++++++++----------
> >>  drivers/mtd/spi-nor/spi-nor.c     | 57
> >> 
> >> ++++++++++++++++++++++++++++----------- include/linux/mtd/spi-nor.h
> >> 
> >> |  8 +++---
> >>  
> >>  4 files changed, 81 insertions(+), 46 deletions(-)
> >> 
> >> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> >> index d313f948b..d8f064b 100644
> >> --- a/drivers/mtd/devices/m25p80.c
> >> +++ b/drivers/mtd/devices/m25p80.c
> >> @@ -75,14 +75,15 @@ static int m25p80_write_reg(struct spi_nor *nor, u8
> >> opcode, u8 *buf, int len, return spi_write(spi, flash->command, len +
> >> 1);
> >> 
> >>  }
> >> 
> >> -static void m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
> >> -                     size_t *retlen, const u_char *buf)
> >> +static ssize_t m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
> >> +                         const u_char *buf)
> >> 
> >>  {
> >>  
> >>       struct m25p *flash = nor->priv;
> >>       struct spi_device *spi = flash->spi;
> >>       struct spi_transfer t[2] = {};
> >>       struct spi_message m;
> >>       int cmd_sz = m25p_cmdsz(nor);
> >> 
> >> +     ssize_t ret;
> >> 
> >>       spi_message_init(&m);
> >> 
> >> @@ -100,9 +101,14 @@ static void m25p80_write(struct spi_nor *nor,
> >> loff_t to, size_t len, t[1].len = len;
> >> 
> >>       spi_message_add_tail(&t[1], &m);
> >> 
> >> -     spi_sync(spi, &m);
> >> +     ret = spi_sync(spi, &m);
> >> +     if (ret)
> >> +             return ret;
> >> 
> >> -     *retlen += m.actual_length - cmd_sz;
> >> +     ret = m.actual_length - cmd_sz;
> >> +     if (ret < 0)
> >> +             return -EIO;
> >> +     return ret;
> > 
> > I'd prefer to just add the return value and keep the retlen to keep error
> > codes and transfer length separate.
> 
> I prefer to not pass around retlen because passing it around
> 
>  - causes code duplication
>  - makes the code harder to understand

Not sure I want to argue on this one, since it looks like a matter of taste.
Adding the error return first and removing the retlen second might make the
patch more readable though.

> > btw. you change the transfer length from unsigned to signed type -- long
> > transfer might get interpreted as an error.
> 
> Note that ssize_t is supposed to be enough for write(2) so when it
> does not suffice you have a real system-wide problem.
> 
> That aside NOR flash sizes tend to be in the order of megabytes so
> this concern is very theoretical.

I do hope so :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/