All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: Marek Vasut <marek.vasut@gmail.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Richard Weinberger <richard@nod.at>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	MTD Maling List <linux-mtd@lists.infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] mtd: partitions: Handle add_mtd_device() failures gracefully
Date: Thu, 26 Apr 2018 19:56:58 +0200	[thread overview]
Message-ID: <CAMuHMdWRyZYX+oKN-nxzKbCqZn1zojKwX8Gv6tGg=UZSa3k_LA@mail.gmail.com> (raw)
In-Reply-To: <20180426195303.1f08d2cd@bbrezillon>

Hi Boris,

On Thu, Apr 26, 2018 at 7:53 PM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> On Tue, 10 Apr 2018 15:26:20 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Mon, Apr 9, 2018 at 11:59 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> > On 04/09/2018 02:25 PM, Geert Uytterhoeven wrote:
>> >> Currently add_mtd_device() failures are plainly ignored, which may lead
>> >> to kernel crashes later.
>>
>> >> Fix this by ignoring and freeing partitions that failed to add in
>> >> add_mtd_partitions().  The same issue is present in mtd_add_partition(),
>> >> so fix that as well.
>> >>
>> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> >> ---
>> >> I don't know if it is worthwhile factoring out the common handling.
>> >>
>> >> Should allocate_partition() fail instead?  There's a comment saying
>> >> "let's register it anyway to preserve ordering".
>>
>> >> --- a/drivers/mtd/mtdpart.c
>> >> +++ b/drivers/mtd/mtdpart.c
>>
>> >> @@ -746,7 +753,15 @@ int add_mtd_partitions(struct mtd_info *master,
>> >>               list_add(&slave->list, &mtd_partitions);
>> >>               mutex_unlock(&mtd_partitions_mutex);
>> >>
>> >> -             add_mtd_device(&slave->mtd);
>> >> +             ret = add_mtd_device(&slave->mtd);
>> >> +             if (ret) {
>> >> +                     mutex_lock(&mtd_partitions_mutex);
>> >> +                     list_del(&slave->list);
>> >> +                     mutex_unlock(&mtd_partitions_mutex);
>> >> +                     free_partition(slave);
>> >> +                     continue;
>> >> +             }
>> >
>> > Why is the partition even in the list in the first place ? Can we avoid
>> > adding it rather than adding and removing it ?
>>
>> Hence my question "Should allocate_partition() fail instead?".
>
> I'd prefer this option too. Can you prepare a new version doing that?

OK, then I have another question ;-)

Should this be a special failure, so all other valid partitions on the
same FLASH
are still added, or should it be fatal, so no partitions are added at all?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2018-04-26 17:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09 12:25 [PATCH] mtd: partitions: Handle add_mtd_device() failures gracefully Geert Uytterhoeven
2018-04-09 21:59 ` Marek Vasut
2018-04-10 13:26   ` Geert Uytterhoeven
2018-04-10 14:37     ` Marek Vasut
2018-04-10 14:47       ` Geert Uytterhoeven
2018-04-10 16:34         ` Steve deRosier
2018-04-26 17:53     ` Boris Brezillon
2018-04-26 17:56       ` Geert Uytterhoeven [this message]
2018-04-26 18:09         ` 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='CAMuHMdWRyZYX+oKN-nxzKbCqZn1zojKwX8Gv6tGg=UZSa3k_LA@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=boris.brezillon@bootlin.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=geert+renesas@glider.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marek.vasut@gmail.com \
    --cc=richard@nod.at \
    /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.