linux-kernel - Re: [PATCH 0/2] Add framework for user controlled driver probes

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: <Zva9zUY3DwEPeXwI@NAB-HP-ProDesk-600sony.com>
Date: Fri, 27 Sep 2024 19:44:37 +0530
From: Nayeemahmed Badebade <nayeemahmed.badebade@...y.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
        rafael@...nel.org, yoshihiro.toyama@...y.com,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 0/2] Add framework for user controlled driver probes

Hi Greg,

Sorry for the delay in our response.
Please find our reply to your comments:

On Tue, Sep 17, 2024 at 12:11:22PM +0200, Greg KH wrote:
> > On Fri, Sep 13, 2024 at 06:36:38AM +0200, Greg KH wrote:
> > > > This patch series introduces a new framework in the form of a driver
> > > > probe-control, aimed at addressing the need for deferring the probes
> > > > from built-in drivers in kernels where modules are not used.
> > > 
> > > Wait, why?
> > >
> > 
> > We have a scenario where a driver cannot be built as a module and ends up
> > as a built-in driver. We don't want to probe this driver during boot as its
> > not required at the time of booting.
> > Example: drivers/pci/controller/dwc/pci-imx6.c
> > So the intention is to only postpone some driver probes similar to:
> > https://elinux.org/Deferred_Initcalls
> > But instead of delaying initcall execution(which requires initmem to be kept
> > and not freed during boot) we are trying to delay driver probes as this is
> > much simpler.
> > The proposed driver is a generic solution for managing such driver
> > probes.
> 
> Again, please fix the drivers that are having problems with this, and
> build them as a module and load them when you need/want them and can be
> probed correctly.
> 

Sure, we will try to do that.

> > > > In such scenario, delaying the initialization of certain devices such
> > > > as pcie based devices not needed during boot and giving user the control
> > > > on probing these devices post boot, can help reduce overall boot time.
> > > > This is achieved without modifying the driver code, simply by configuring
> > > > the platform device tree.
> > > 
> > > PCI devices should not be on the platform device tree.
> > >
> > 
> > You are right, we are referring to the pci host controller that will be
> > listed in device tree and skipping its probe during boot as an example
> > here.
> 
> pci host controllers should really be availble at boot time, wow your
> hardware is b0rked, sorry.  Just make it a module and load it when you
> want/need it.
> 
> > > And what's wrong with async probing?  That was written for this very
> > > issue.
> > >
> > 
> > We have explored async probe as an option, but we noticed below:
> > 1) Probe initiated via async
> > 2) Boot continues with other setup.
> > 3) Boot reaches stage where ip configuration is to be done via
> >    ip_auto_config() and 1) is still in progress, then boot waits for all
> >    async calls to be completed before proceeding with network setup.
> >    ip_auto_config()
> >     -> wait_for_devices()
> >       -> wait_for_device_probe()
> >          -> async_synchronize_full()
> > 4) Similar thing happens with rootfs mount step in prepare_namespace()
> >    initcall
> 
> Again, if you make the problem driver as a module you should be ok,
> right?
> 

Yes.

> > So to avoid getting blocked on these probes which are not required
> > during boot, we proposed this driver for managing such built-in driver
> > probes execution.
> 
> Fix the broken drivers please :)
> 

Sure, we will do that.
Thank you for your feedback.

Regards,
Nayeem