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  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]
Date:   Fri, 22 May 2020 14:10:55 -0300
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        davem@...emloft.net, gregkh@...uxfoundation.org,
        netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
        nhorman@...hat.com, sassmann@...hat.com,
        Fred Oh <fred.oh@...ux.intel.com>
Subject: Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF
 client

On Fri, May 22, 2020 at 10:33:20AM -0500, Pierre-Louis Bossart wrote:

> > Maybe not great, but at least it is consistent with all the lifetime
> > models and the operation of the driver core.
> 
> I agree your comments are valid ones, I just don't have a solution to be
> fully compliant with these models and report failures of the driver probe
> for a child device due to configuration issues (bad audio topology, etc).


> My understanding is that errors on probe are explicitly not handled in the
> driver core, see e.g. comments such as:

Yes, but that doesn't really apply here...
 
> /*
>  * Ignore errors returned by ->probe so that the next driver can try
>  * its luck.
>  */
> https://elixir.bootlin.com/linux/latest/source/drivers/base/dd.c#L636
> 
> If somehow we could request the error to be reported then probably we
> wouldn't need this complete/wait_for_completion mechanism as a custom
> notification.

That is the same issue as the completion, a driver should not be
making assumptions about ordering like this. For instance what if the
current driver is in the initrd and the 2nd driver is in a module in
the filesystem? It will not probe until the system boots more
completely. 

This is all stuff that is supposed to work properly.

> Not at the moment, no. there are no failures reported in dmesg, and
> the user does not see any card created. This is a silent error.

Creating a partial non-function card until all the parts are loaded
seems like the right way to surface an error like this.

Or don't break the driver up in this manner if all the parts are really
required just for it to function - quite strange place to get into.

What happens if the user unplugs this sub driver once things start
running?

Jason

Powered by blists - more mailing lists