linux-kernel - Re: [GIT PULL] ARM: SoC fixes for v5.10, part 3

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKdAkRRq=GK7N1PDJ4zLfJVSsrd1BB=u69aXtJHh=sW4vn5LOg@mail.gmail.com>
Date:   Mon, 30 Nov 2020 09:27:30 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Arnd Bergmann <arnd@...nel.org>,
        Douglas Anderson <dianders@...omium.org>,
        SoC Team <soc@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] ARM: SoC fixes for v5.10, part 3

Hi Linus,

On Fri, Nov 27, 2020 at 3:02 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Fri, Nov 27, 2020 at 12:51 PM Arnd Bergmann <arnd@...nel.org> wrote:
> >
> >  - Some DT patches for the Rockchip RK3399 platform,
> >    in particular fixing the MMC device ordering that
> >    recently became nondeterministic with async probe.
>
> Uhhuh.
>
> I didn't realize this MMC breakage happened.
>
> That's just an MMC bug. Other subsystems have been able to do async
> probing without making device ordering be random.
>
> So this really smells wrong, and I just never realized.
>
> Added Douglas Anderson to the cc - the whole PROBE_PREFER_ASYNCHRONOUS
> behavior appears broken.
>
> You basically should do the device numbering synchronously (or better
> yet - asynchronously, but single-threaded for the subsystem), and then
> asynchronously probe the actual device details after you've numbered
> them reliably.

Generally speaking it is either unnecessary for a lot of devices where
we do not care what number they get, harmful (why do I need to probe
i2c touchscreen and touchpad sequentially if I do not care which one
comes first but my boot will take 0.5 seconds longer if I serialize),
or impossible (if device is hit-pluggable). For many years userspace
has been moving away from static device assignments and we should not
be going back.

There are some devices that are special because it is hard to deal
with devices shifting during early boot, and for them maintaining
static ordering might be beneficial for now, but they are exceptions.

>
> This is not something new - we do this for pretty much all the other
> block devices, and MMC is just doing things wrong.
>
> See SCSI probing for the traditional horrible cases (where just
> spinning up a disk could take tens of seconds).  "Slow probing" is not
> an excuse of "random ordering".

And still my external USB disk will get a "random" /dev/sdX depending
on when I plug it in relative to all other USB sticks.

Thanks.

-- 
Dmitry