linux-kernel - Re: [PATCH] [RESEND] drm: fb_helper: fix CONFIG

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: <CAK8P3a0KHwaSNqg_dz8-w6e_EJBrsQw_ti+5aErsSr+8AfV9cA@mail.gmail.com>
Date:   Wed, 27 Oct 2021 15:25:38 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Jani Nikula <jani.nikula@...ux.intel.com>
Cc:     Javier Martinez Canillas <javierm@...hat.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Kees Cook <keescook@...omium.org>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...ux.ie>, Arnd Bergmann <arnd@...db.de>,
        Alex Deucher <alexander.deucher@....com>,
        Christian König <christian.koenig@....com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [RESEND] drm: fb_helper: fix CONFIG_FB dependency

On Wed, Oct 27, 2021 at 3:06 PM Jani Nikula <jani.nikula@...ux.intel.com> wrote:
> On Wed, 27 Oct 2021, Arnd Bergmann <arnd@...nel.org> wrote:
> > This fails because of all the other drivers that try to 'select DRM_KMS_HELPER'.
> > Kconfig will now complain about a symbol that gets selected while its
> > dependencies
> > are not met.
> >
> > To work around that, every single driver that has 'selects DRM_KMS_HELPER' would
> > now have to also list 'depends on (DRM_FBDEV_EMULATION && FB) ||
> > !DRM_FBDEV_EMULATION'.
>
> So the fix would be that nobody selects DRM_KMS_HELPER...

That's not going to help in this case, the way the helper functions work is that
you select them as needed, and you avoid the other dependencies. This part
works fine.

We could probably get rid of this symbol by just making it an unconditional
part of drm.ko, as almost every driver ends up using it anyway.

Arguably, this would make the end result worse, as you'd again get drm.ko
itself to link against the old framebuffer code.

What I'm not sure about is whether drivers/video/fbdev/core/fb.ko could
be split up into smaller parts so DRM_FBDEV_EMULATION could
only depend on a set of common code without the bits that are needed
for the classic fbdev drivers.

      Arnd