linux-kernel - Re: [PATCH] nubus: Unconditionally register bus type

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: <CAMuHMdX+utbGHOV1p_oFwaKigxGBMMgkC_v5hWCO4EoVXeqezg@mail.gmail.com>
Date:   Tue, 8 May 2018 09:35:10 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Michael Schmitz <schmitzmic@...il.com>,
        Finn Thain <fthain@...egraphics.com.au>,
        "Linux/m68k" <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Development <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] nubus: Unconditionally register bus type

Hi Greg,

On Tue, May 8, 2018 at 9:25 AM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Tue, May 08, 2018 at 09:07:27AM +0200, Geert Uytterhoeven wrote:
>> On Tue, May 8, 2018 at 9:00 AM, Greg Kroah-Hartman
>> <gregkh@...uxfoundation.org> wrote:
>> > On Mon, May 07, 2018 at 09:51:12AM +1200, Michael Schmitz wrote:
>> >> the BUG() was triggered by loading a Mac Nubus network card module on
>> >> a multiplatform kernel running on an Amiga machine. Up to Finn's Nubus
>> >> core rewrite (this February), we've seen no errors. Since then, Nubus
>> >> drivers fail to register because the Nubus bus is only registered on
>> >> Macs.
>> >>
>> >> Can't see link order involved here at all.
>> >
>> > The link order is totally involved here :)
>> >
>> > Link order determines the order in which init calls are run, so you need
>> > to ensure that your bus code comes before any drivers that use that bus
>> > code in link order.  That way, at init time, your bus is created first,
>> > preventing this type of error to happen.
>>
>> The issue here is not due to link ordering, but due to the bus not being
>> registered on a system that doesn't have that particular bus.
>
> But how can that happen if the bus code is not present in the system at
> that point in time?  Hardware doesn't matter at all here.

The bus code is present in the system.
The bus is just not registered by the NuBus bus driver if the hardware
doesn't have a NuBus host.

>> Akin to booting a kernel on an old PC without PCI, and loading a driver
>> module for a PCI network card. I guess that doesn't crash (because no one
>> has a PC without PCI anymore? ;-)
>
> No, it should work just fine, try it!  :)
>
> The driver will not bind to anything, but the bus code should work
> properly, as long as it is initialized before the driver tries to
> register with that specific bus type.

Hence the NuBus bus code should register the bus irregardless of the
presence of the NuBus host hardware.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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