linux-kernel - Re: [PATCH] mtd: spi-nor: Prefer asynchronous probe

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]

Date:   Mon, 5 Oct 2020 07:53:45 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Michael Walle <michael@...le.cc>
Cc:     LKML <linux-kernel@...r.kernel.org>, linux-mtd@...ts.infradead.org,
        miquel.raynal@...tlin.com, richard@....at,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Vignesh Raghavendra <vigneshr@...com>
Subject: Re: [PATCH] mtd: spi-nor: Prefer asynchronous probe

Hi,

On Sun, Oct 4, 2020 at 7:10 AM Michael Walle <michael@...le.cc> wrote:
>
> Hi,
>
> Am 2020-10-03 19:00, schrieb Doug Anderson:
> > On Sat, Oct 3, 2020 at 9:54 AM Michael Walle <michael@...le.cc> wrote:
> >> While debugging another issue I also noticed that sometimes my
> >> /dev/mtdN devices were reordered. Note that I have two SPI flashes.
> >> Might this also be connected to the async probe?
> >
> > It's likely.  My guess is that you shouldn't really be depending on
> > the numbering.  If you need to depend on the numbering, there should
> > be something that guarantees it like a device tree alias.  We have
> > struggled with similar things on MMC for years and I guess Ulf finally
> > decided that we weren't going to get a better solution than the device
> > tree aliases.
>
> But this has to be supported by spi-nor first, right? So that would also
> be something which has to be added before we can make the probe async.
> And as far as I know there is no such mechanism like /dev/disk/by-X for
> /dev/mtdN.

I did a quick skim and didn't see any mechanism like this for the MTD
layer, so I think you're right.  Something like this would almost
certainly need to be added.  As per the discussion in the MMC threads
about this, though, probably whatever you have working right now is
"by luck".  It may be stable from boot to boot, but I don't think
there are any guarantees that a new kernel version won't come along
and shuffle your IDs around.  Presumably it would be a good idea for
MTD folks to come up with some sort of solution here...

-Doug