From: Boris Brezillon <boris.brezillon@bootlin.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 11/11] mtd: sf: Make sf_mtd.c more robust
Date: Thu, 22 Nov 2018 09:40:56 +0100 [thread overview]
Message-ID: <20181122094056.21a75afe@bbrezillon> (raw)
In-Reply-To: <CAMty3ZBuLyCvyqpG_7P3PHLWgKeie8djBxRRfMMTcXEmHvGLbQ@mail.gmail.com>
On Thu, 22 Nov 2018 12:40:57 +0530
Jagan Teki <jagan@amarulasolutions.com> wrote:
> On Tue, Nov 20, 2018 at 2:33 AM Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> >
> > SPI flash based MTD devs can be registered/unregistered at any time
> > through the sf probe command or the spi_flash_free() function.
> >
> > This commit does not try to fix the root cause as it would probably
> > require rewriting most of the code and have an mtd_info object
> > instance per spi_flash object (not to mention that the the spi-flash
> > layer is likely to be replaced by a spi-nor layer ported from Linux).
> >
> > Instead, we try to be as safe as can be by checking the code returned
> > by del_mtd_device() and complain loudly when there's nothing we can
> > do about the deregistration failure. When that happens we also reset
> > sf_mtd_info.priv to NULL, and check for NULL pointer in the mtd hooks
> > so that -ENODEV is returned instead of hitting a NULL pointer
> > dereference exception when the MTD instance is later accessed by a user.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> > ---
> > Changes in v3:
> > - New patch
> > ---
> > drivers/mtd/spi/sf_mtd.c | 39 ++++++++++++++++++++++++++++++++++++---
> > 1 file changed, 36 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
> > index aabbc3589435..68c36002bee2 100644
> > --- a/drivers/mtd/spi/sf_mtd.c
> > +++ b/drivers/mtd/spi/sf_mtd.c
> > @@ -18,6 +18,9 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
> > struct spi_flash *flash = mtd->priv;
> > int err;
> >
> > + if (!flash)
> > + return -ENODEV;
> > +
> > instr->state = MTD_ERASING;
> >
> > err = spi_flash_erase(flash, instr->addr, instr->len);
> > @@ -39,6 +42,9 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
> > struct spi_flash *flash = mtd->priv;
> > int err;
> >
> > + if (!flash)
> > + return -ENODEV;
> > +
> > err = spi_flash_read(flash, from, len, buf);
> > if (!err)
> > *retlen = len;
> > @@ -52,6 +58,9 @@ static int spi_flash_mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
> > struct spi_flash *flash = mtd->priv;
> > int err;
> >
> > + if (!flash)
> > + return -ENODEV;
> > +
> > err = spi_flash_write(flash, to, len, buf);
> > if (!err)
> > *retlen = len;
> > @@ -76,8 +85,13 @@ int spi_flash_mtd_register(struct spi_flash *flash)
> > {
> > int ret;
> >
> > - if (sf_mtd_registered)
> > - del_mtd_device(&sf_mtd_info);
> > + if (sf_mtd_registered) {
> > + ret = del_mtd_device(&sf_mtd_info);
> > + if (ret)
> > + return ret;
> > +
> > + sf_mtd_registered = false;
> > + }
> >
> > sf_mtd_registered = false;
> > memset(&sf_mtd_info, 0, sizeof(sf_mtd_info));
> > @@ -110,5 +124,24 @@ int spi_flash_mtd_register(struct spi_flash *flash)
> >
> > void spi_flash_mtd_unregister(void)
> > {
> > - del_mtd_device(&sf_mtd_info);
> > + int ret;
> > +
> > + if (!sf_mtd_registered)
> > + return;
> > +
> > + ret = del_mtd_device(&sf_mtd_info);
> > + if (!ret) {
> > + sf_mtd_registered = false;
> > + return;
> > + }
> > +
> > + /*
> > + * Setting mtd->priv to NULL is the best we can do. Thanks to that,
> > + * the MTD layer can still call mtd hooks without risking a
> > + * use-after-free bug. Still, things should be fixed to prevent the
> > + * spi_flash object from being destroyed when del_mtd_device() fails.
> > + */
> > + sf_mtd_info.priv = NULL;
> > + printf("Failed to unregister MTD %s and the spi_flash object is going away: you're in deep trouble!",
> > + sf_mtd_info.name);
>
> Why do we need this print?
Yes we do, just to keep the user informed that something bad happened
and its spi-flash is no longer usable (at least through the MTD layer).
> can't we do the same thing in MTD core
> itself, so-that it can be generic for all flash objects.
del_mtd_device() can fail, so it's the caller responsibility to decide
what to do when that happens. Some users will propagate the error to
the upper layer and maybe cancel the device removal (AFAICT,
driver->remove() can return an error, not sure what happens in this
case though). For others, like spi-flash, the device will go away, and
all subsequent accesses will fail.
next prev parent reply other threads:[~2018-11-22 8:40 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-19 20:59 [U-Boot] [PATCH v3 00/11] mtd/sf: Various fixes Boris Brezillon
2018-11-19 20:59 ` [U-Boot] [PATCH v3 01/11] mtd: Add a function to report when the MTD dev list has been updated Boris Brezillon
2018-11-21 6:44 ` Heiko Schocher
2018-11-19 20:59 ` [U-Boot] [PATCH v3 02/11] mtd: Parse mtdparts/mtdids again when the MTD " Boris Brezillon
2018-11-21 6:44 ` Heiko Schocher
2018-11-19 20:59 ` [U-Boot] [PATCH v3 03/11] mtd: Delete partitions attached to the device when a device is deleted Boris Brezillon
2018-11-21 6:44 ` Heiko Schocher
2018-11-22 8:32 ` Boris Brezillon
2018-11-19 20:59 ` [U-Boot] [PATCH v3 04/11] mtd: sf: Make sure we don't register the same device twice Boris Brezillon
2018-11-21 6:45 ` Heiko Schocher
2018-11-22 7:04 ` Jagan Teki
2018-11-19 20:59 ` [U-Boot] [PATCH v3 05/11] mtd: Use get_mtdids() instead of env_get("mtdids") in mtd_search_alternate_name() Boris Brezillon
2018-11-21 6:45 ` Heiko Schocher
2018-11-19 20:59 ` [U-Boot] [PATCH v3 06/11] mtd: Be more strict on the "mtdparts=" prefix check Boris Brezillon
2018-11-21 6:45 ` Heiko Schocher
2018-11-19 20:59 ` [U-Boot] [PATCH v3 07/11] mtd: Make sure the name passed in mtdparts fits in mtd_name[] Boris Brezillon
2018-11-21 6:45 ` Heiko Schocher
2018-11-19 20:59 ` [U-Boot] [PATCH v3 08/11] mtd: Make sure we don't parse MTD partitions belonging to another dev Boris Brezillon
2018-11-21 6:46 ` Heiko Schocher
2018-11-19 20:59 ` [U-Boot] [PATCH v3 09/11] mtd: Don't stop MTD partition creation when it fails on one device Boris Brezillon
2018-11-21 6:46 ` Heiko Schocher
2018-11-19 20:59 ` [U-Boot] [PATCH v3 10/11] mtd: sf: Unregister the MTD device prior to removing the spi_flash obj Boris Brezillon
2018-11-21 6:47 ` Heiko Schocher
2018-11-22 7:06 ` Jagan Teki
2018-11-19 20:59 ` [U-Boot] [PATCH v3 11/11] mtd: sf: Make sf_mtd.c more robust Boris Brezillon
2018-11-21 6:47 ` Heiko Schocher
2018-11-22 7:10 ` Jagan Teki
2018-11-22 8:40 ` Boris Brezillon [this message]
2018-11-26 8:42 ` Boris Brezillon
2018-11-26 11:12 ` Jagan Teki
2018-11-26 12:37 ` Boris Brezillon
2018-11-26 12:42 ` Boris Brezillon
2018-11-26 13:05 ` Jagan Teki
2018-11-26 13:25 ` Miquel Raynal
2018-11-27 12:36 ` Boris Brezillon
2018-11-27 15:44 ` Jagan Teki
2018-11-19 21:02 ` [U-Boot] [PATCH v3 00/11] mtd/sf: Various fixes Boris Brezillon
2018-11-21 6:43 ` Heiko Schocher
2018-11-21 12:58 ` Boris Brezillon
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=20181122094056.21a75afe@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=u-boot@lists.denx.de \
/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