linux-kernel - Re: [PATCH v3 0/2] Exynos IOMMU: proper runtime PM support (use device dependencies)

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:   Sat, 24 Sep 2016 03:25:17 +0200
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     Marek Szyprowski <m.szyprowski@...sung.com>,
        Tobias Jakobi <tjakobi@...h.uni-bielefeld.de>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        iommu@...ts.linux-foundation.org,
        linux-samsung-soc@...r.kernel.org, Joerg Roedel <joro@...tes.org>,
        Inki Dae <inki.dae@...sung.com>, Kukjin Kim <kgene@...nel.org>,
        Krzysztof Kozlowski <k.kozlowski@...sung.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Mark Brown <broonie@...nel.org>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Kevin Hilman <khilman@...nel.org>
Subject: Re: [PATCH v3 0/2] Exynos IOMMU: proper runtime PM support (use device dependencies)

On Friday, September 23, 2016 03:50:02 PM Lukas Wunner wrote:
> On Fri, Sep 23, 2016 at 02:49:20PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, September 20, 2016 10:51:13 AM Marek Szyprowski wrote:
> > > On 2016-09-19 23:45, Tobias Jakobi wrote:
> > > > I did some tests with the new version today. Sadly the reboot/shutdown
> > > > issues are still present.
> > > 
> > > Thanks for the report. I've managed to reproduce this issue and it is again
> > > caused by modifying device on devices_kset list before it will be finally
> > > added by device_add(). I thought that the new patchset allows creating
> > > links to a device, which has not been yet added to system device list.
> 
> Hm, Marek, why isn't it possible to set up the links from the consumer's
> ->probe hook in this case?
> 
> 
> > > Should it be allowed to create a link to device, which
> > > has not yet been added to system device list by device_add()?
> > 
> > While it would be easy to require both the consumer and producer devices to
> > be registered for creating a link between them, that would just make it
> > harder to use links in the first place.
> > 
> > So ideally, it should be possible to create links between devices before
> > registering them, but since I didn't take that into account in the current
> > patch series, some quite substantial changes are needed to cover that.
> > 
> > Additional link states come to mind, but then the "stateless" links are
> > affected by this problem too.
> 
> device_link_add() could be changed to call device_reorder_to_tail()
> only if device_is_registered(consumer) returns true.
> 
> That's an inline function defined in <linux/device.h> which returns
> dev->kobj.state_in_sysfs, a flag which is set in kobject_add().

I know what that function is, but using it alone is not sufficient,
because dev->kobj.state_in_sysfs is set before the device is added to
dpm_list.

> Then device_add() would have to check if any links are already
> set up and reorder the consumer behind the suppliers.
> 
> Doesn't seem to be *that* complex, but probably I'm missing something,
> this is just off the cuff...

There are some cases to consider and some races to avoid AFAICS.

It all gets a lot simpler if device_link_add() is allowed to return NULL when
the supplier device passed to it has not been registered yet.  That looks like
a reasonable thing to do to me, but I wonder if someone has a use case in which
it would be a substantial limitation.

Thanks,
Rafael