linux-kernel - Re: [PATCH] parport: daisy: do not try to load lowlevel driver

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, 25 Mar 2019 22:34:36 +0000
From:   Sudip Mukherjee <sudipm.mukherjee@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Michal Kubecek <mkubecek@...e.cz>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] parport: daisy: do not try to load lowlevel driver

Hi Linus,

On Mon, Mar 25, 2019 at 9:49 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Mon, Mar 25, 2019 at 2:13 PM Sudip Mukherjee
> <sudipm.mukherjee@...il.com> wrote:
> >
> > We do not need to search for ports and bind the initial list of ports
> > to daisy driver as daisy driver is always the first driver to use the
> > new found parport and we know when the parport bus is registering the
> > list of parport will always be empty. So, proceed with the daisy_drv
> > registration even if the list of parport is empty.
>
> This is completely hacky and senseless.

I admit its hacky. :(

>
> The problem as far as I can tell is that the daisy driver shouldn't
> register early at all, and shouldn't be a subsys initcall. It should
> just be a driver initcall, and happen naturally after the parport
> subsystem has been initialized.

yes, but the daisy driver has to be the first one to register even
before any of the ports have actually registered and then it will try
to load the lowlevel driver. In x86, parport_pc will register the port
and then announce it. When the port is announced daisy_driver should
check that port and this happens even before the port is added to the
list. So, we will always be in this situation that when daisy driver
registers the port list is empty.

>
> This patch just makes the code even *less* understandable.
>
> I'm going to revert that problematic commit.
>
> If you can get it working without that incorrect and senseless tie-in
> of the daisy driver registration with the regular partport init
> sequence, we can revisit this.

I will find a better way to do this.


-- 
Regards
Sudip