linux-kernel - Re: Query on device links

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: <CAGETcx_eHbVLmfYy5ggMKgXR1MQosLarrfpJA8j65krbvAzEbg@mail.gmail.com>
Date:   Fri, 21 Feb 2020 22:55:52 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     John Garry <john.garry@...wei.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Query on device links

On Thu, Feb 6, 2020 at 2:32 AM John Garry <john.garry@...wei.com> wrote:
>
> Hi guys,

Sorry it took a while to get back.

>
> According to "Limitations" section @
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/device_link.rst#n110,
> for a managed link, lack of the supplier driver may cause indefinite
> delay in probing of the consumer. Is there any way around this?

Currently, no. There's no way to guarantee ordering AND ignore
supplier failures.

> So I just want the probe order attempt of the supplier and consumer to
> be guaranteed, but the supplier probe may not be successful, i.e. does
> not actually bind.
>
> In my case, I would like to use device_link_add(supplier, consumer,
> DL_FLAG_AUTOPROBE_CONSUMER), but I find the supplier probe may fail (and
> not due to -EPROBE_DEFER), and my consumer remains in limbo.

The requirements seem to contradict each other. If you depend on the
supplier, how can you probe the consumer if the supplier fails?

> You may ask my I want this ordering at all - it is because in
> really_probe(), we do the device DMA configure before the actual device
> driver probe, and I just need that ordering to be ensured between devices.

I'm assuming the supplier in your case is the "dma device" (is it an
iommu?)? So if it fails, how is your consumer probing without the
supplier? I'd think something like a DMA would be fundamental?

Why can't this logic be handled in your consumer driver instead of
using device links? Why can't your consumer driver return
-EPROBE_DEFER if the dma ops are not set up correctly until some point
after which (after late_initcall?) the consumer will continue probing
without returning -EPROBE_DEFER even if the supplier isn't there/dma
ops aren't set up?

Can you give a more concrete example of your devices? Or why the
suggestion above might not work?

-Saravana