All of lore.kernel.org
 help / color / mirror / Atom feed
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 

  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 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.