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: <CAHk-=whtySEgkH+VFy9oW8Q-+iuivGBo0hOUcee3DvrsBAQUrA@mail.gmail.com>
Date:   Mon, 30 Nov 2020 09:44:03 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Arnd Bergmann <arnd@...nel.org>, SoC Team <soc@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [GIT PULL] ARM: SoC fixes for v5.10, part 3

On Mon, Nov 30, 2020 at 9:04 AM Doug Anderson <dianders@...omium.org> wrote:
>
> Without static assignment, maybe we could do numbering of MMC devices
> in some type of a pre-probe routine?  Is that what you're suggesting?

Yes.

So basically, the way the async probing works for say SCSI is that we
have multiple "layers of asynchroniety". We have the usual "init calls
done asynchronously", but then within the init calls themselves you
can start sub-scans asynchronously.

In order to get reliable ordering between multiple controllers, the
PCI bus is probed in order in pci_init() (or whatever), so each SCSI
controller gets called in a fixed order.

That then gets to scsi_scan_host() does that async_schedule() thing to
actually scan the SCSI buses on that host.

> If so, it seems like it might be a pretty big change to figure out how
> that ought to work (if it can be made to work).

Try to start out doing discovery synchronously, but then any extra
work (actual IO like partition scanning etc) with an "async_work()".

> Just to confirm, I assume you are specifically excluding all block
> devices attached via USB, right?

I have this memory that we tried to scan the root bus in order, just
because people will have internal USB devices that way, and it makes
it *much* easier if they show up in predetermined places.

Note that it really is only the internal devices that matter. Once you
start plugging in an external USB hug and random devices, ordering
clearly won't be reliable.

So this is not a "everything must be ordered". But people who think
that that then means "everythinbg can be random" are wrong. It's
really really inconvenient, because things like disk labels and
various device IDs are not reliable either, and can be very confusing
when two otherwise identical machines look different before you've
installed a full system on them, for example.

So you should strive very hard to make everything that is directly
connected to one SoC always come up in the same order, for example.

And storage devices are special. As Dmitry points out, it doesn't much
matter in what order something like a mouse is scanned. Who cares? If
you have multiple pointer devices, you'll either use them
interchangably, or you'll have some other way to identify them. But
storage is a _lot_ more basic than basically stateless input devices
are.

And no, disk labels really don't always exist. Never ever say "but but
but disk labels".

               Linus