linux-kernel - Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.

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: <CACvgo53fuoPVjBAkZbWFPVxosObjvxoDgFdR_BkSTgevqyGg9g@mail.gmail.com>
Date:   Wed, 21 Sep 2016 13:09:33 +0100
From:   Emil Velikov <emil.l.velikov@...il.com>
To:     Peter Griffin <peter.griffin@...aro.org>
Cc:     Arnd Bergmann <arnd@...db.de>,
        LAKML <linux-arm-kernel@...ts.infradead.org>,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
        kernel@...inux.com, vinod.koul@...el.com, patrice.chotard@...com,
        dan.j.williams@...el.com, David Airlie <airlied@...ux.ie>,
        Gerd Hoffmann <kraxel@...hat.com>, ohad@...ery.com,
        bjorn.andersson@...aro.org,
        devicetree <devicetree@...r.kernel.org>,
        linux-remoteproc@...r.kernel.org,
        ML dri-devel <dri-devel@...ts.freedesktop.org>,
        "open list:VIRTIO GPU DRIVER" 
        <virtualization@...ts.linux-foundation.org>,
        dmaengine@...r.kernel.org, lee.jones@...aro.org
Subject: Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.

On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@...aro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@...aro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
Might be worth taking a closer look into these at some point.

>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>>
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>>
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
On the USB case I'm not sure what the reasoning behind the USB vs
USB_COMMON split. In seems that one could just fold them, but that's
another topic. On the MFD side... it follows the select {,mis,ab}use.
With one (the only one?) MFD driver not using/selecting MFD_CORE doing
it's own version of mfd_add_devices... which could be reworked,
possibly.

> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?
>
Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
reasonable, but it'll be great to hear others as well.

Thanks
Emil