linux-kernel - Re: sysfs deferred

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]

Date:   Fri, 13 Jan 2017 08:42:39 +0100
From:   Tomeu Vizoso <tomeu.vizoso@...labora.com>
To:     Ben Hutchings <ben.hutchings@...ethink.co.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Rob Herring <robh@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Mark Brown <broonie@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Russell King <linux@...linux.org.uk>
Subject: Re: sysfs deferred_probe attribute

On 01/12/2017 07:26 PM, Ben Hutchings wrote:
> On Thu, 2017-01-12 at 18:41 +0100, Greg Kroah-Hartman wrote:
>> On Thu, Jan 12, 2017 at 11:27:01AM -0600, Rob Herring wrote:
>>> I just noticed that we have a new device attribute 'deferred_probe'
>>> added in 4.10 with this commit:
>>>
>>> commit 6751667a29d6fd64afb9ce30567ad616b68ed789
>>> Author: Ben Hutchings <ben.hutchings@...ethink.co.uk>
>>> Date:   Tue Aug 16 14:34:18 2016 +0100
>>>
>>>     driver core: Add deferred_probe attribute to devices in sysfs
>>>
>>>     It is sometimes useful to know that a device is on the deferred probe
>>>     list rather than, say, not having a driver available.  Expose this
>>>     information to user-space.
>>>
>>>     Signed-off-by: Ben Hutchings <ben.hutchings@...ethink.co.uk>
>>>     Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>>>
>>>
>>> It seems like a bad idea to add an ABI for an internal kernel feature.
>>> When/if we replace deferred probe with something better based on
>>> functional dependencies are we going to keep this attr around? Or
>>> remove it and assume no userspace uses it?
> 
> It should be removed then (and replaced with some kind of representation
> of dependencies).
> 
>>> Perhaps it should be hidden
>>> behind CONFIG_DEBUG or just make a debugfs file that lists the
>>> deferred list. Then you wouldn't have to hunt for what got deferred.
>>
>> Ah, debugfs would be nice, I'd much prefer that.  I don't know how Ben
>> is using this, but I think that would make more sense to me.
> 
> I'm not using it any programmatic way, and don't intend to.  debugfs
> would be OK, but attaching it to devices was easy to do and seemed to
> make sense.

Russell King started work on printing those devices in the deferred
queue at late_initcall, not sure why it didn't land.

But note that without proper dependency information, you cannot know for
sure if a device deferred its probe just because a dependency doesn't
have a matching driver.

Regards,

Tomeu