linux-kernel - Re: [RFC/RFT][PATCH v3 0/5] Functional dependencies between devices

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:   Wed, 28 Sep 2016 13:42:20 +0200
From:   Lukas Wunner <lukas@...ner.de>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:     Linux PM list <linux-pm@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Mark Brown <broonie@...nel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Kevin Hilman <khilman@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        "Luis R. Rodriguez" <mcgrof@...e.com>,
        Jonathan Corbet <corbet@....net>
Subject: Re: [RFC/RFT][PATCH v3 0/5] Functional dependencies between devices

On Wed, Sep 28, 2016 at 02:33:21AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, September 27, 2016 02:34:29 PM Lukas Wunner wrote:
> > I made some notes while reviewing the state machine in patch 2 of this
> > series and thought, why not rework it into something that could eventually
> > go into the Documentation/ tree?
> > 
> > So here's an initial draft.  There's some introductory text plus
> > a description of the state machine.  Just putting this out there now
> > to ease reviewers' lives, despite the obvious WIP status.  I'll try to
> > amend it as the series converges.
> > 
> > This is already rst-formatted but I haven't actually run it through
> > sphinx yet.
> 
> Thanks a lot for doing this!
> 
> It looks good to me in general.  I think it would be good to add it to the
> series at one point (if you don't mind).

Sure thing, thanks.

> I'm only a bit reluctant about advertising the usage of links between
> children and parents, because that doesn't look like the right tool for
> the purpose (as I said before, I'd prefer to add a device flag causing
> the parent driver to be probed before the child one if needed).

That wouldn't cover the unbinding of the child when the parent unbinds
though, so it would only be a subset of the functionality offered by
device links.

I actually don't know of a use case where driver presence is needed
between parent and child.  But the patches look like they should work
out of the box in such a scenario, so I was thinking, why forbid it?
Someone might just try that because they think it should obviously work,
and then they'll find out at runtime that it's forbidden.  That gives
us only a score of 5 in Rusty's API rating scheme.

However for consistency, if you do want to forbid it, I think it should
be forbidden for all ancestors of the device, not just the parent as v3
does it.  (Suspend/resume + shutdown ordering is already handled for
hierarchical dependencies, i.e. all ancestors.)

Thanks,

Lukas