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]
Message-ID: <CADVatmMUUmjPmh3ko9uUuB9ONYqz2_3AF+RX_nD1QB=rn-kzxg@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ