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: Mon, 26 Nov 2018 13:37:46 +0100 [thread overview]
Message-ID: <20181126133746.2b4d1fe2@bbrezillon> (raw)
In-Reply-To: <acfe35c1-52b3-2960-b79d-949ee373b62c@openedev.com>
On Mon, 26 Nov 2018 16:42:48 +0530
Jagan Teki <jagan@openedev.com> wrote:
> On 26/11/18 2:12 PM, Boris Brezillon wrote:
> > Hi Jagan,
> >
> > On Thu, 22 Nov 2018 09:40:56 +0100
> > Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> >
> >>>> + /*
> >>>> + * 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.
> >
> > I'm about to send a new version fixing the problem I mentioned in patch
> > 3, but before doing that, I'd like to know if my answer convinced you or
> > if you'd still prefer this message to go away (or be placed in
> > mtdcore/mtdpart.c).
>
>
> I'm thinking of having the message still in MTD by showing which
> interface it would belongs, along with the details.
Then we'd need something less
next prev parent reply other threads:[~2018-11-26 12:37 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
2018-11-26 8:42 ` Boris Brezillon
2018-11-26 11:12 ` Jagan Teki
2018-11-26 12:37 ` Boris Brezillon [this message]
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=20181126133746.2b4d1fe2@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