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]

Message-ID: <5477203.SfEP4qzOYB@vostro.rjw.lan>
Date:   Thu, 29 Sep 2016 02:51:45 +0200
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Lukas Wunner <lukas@...ner.de>
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 Wednesday, September 28, 2016 01:42:20 PM Lukas Wunner wrote:
> 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.)

Well, there is a difference between allowing something to be done and
documenting it as a good idea. :-)

Thanks,
Rafael