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: <CAD=FV=Up-JW8RtMLQ_pAG3e0d8NnpT+rDiguxcz3DnVUz_7Jbw@mail.gmail.com>
Date:   Mon, 30 Nov 2020 10:11:19 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Linus Torvalds <torvalds@...ux-foundation.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>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [GIT PULL] ARM: SoC fixes for v5.10, part 3

Hi,

On Mon, Nov 30, 2020 at 9:44 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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()".

Right, so basically this is like how MMC did it before my patches.  I
was just trying to save the extra 40 ms.

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

I guess that's more of a heuristic though, right?  There may be
computers with an internal USB hub before the storage.  There may also
be computers (small embedded raspberry-pi-type-things) where the
primary storage for the system is expected to be an external USB
device, possibly connected through a hub.

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

So I guess the answer here is: strive very hard but you don't have to
guarantee that every corner case is covered?

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

Yes, storage devices are special, but the point I was trying to make
is that with SoCs there may be a whole lot of devices (with complex
dependencies) in the path of storage devices.  They can need clocks,
regulators, GPIOs, etc and any of those things could be slow to probe
and we might want to speed up boot by making them async.  They also
could be parented on busses that could be slow to probe or might
themselves have dependencies on clocks, regulators, GPIOs, etc.  It
won't always be obvious which of these things are in the path of a
block device.

In a traditional PC I think there are fewer dependencies?

I guess the question is: why is static assignment of numbers not an
acceptable solution to the problem?  It gives us the desired fixed
numbers and automatically avoids all weird probe ordering / dependency
problems.

-Doug