linux-kernel - Re: [PATCH v2 1/2] drm: Add a drm_drv_enabled() to check if drivers should be enabled

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>] [day] [month] [year] [list]

Message-ID: <87lf23ae87.fsf@intel.com>
Date:   Thu, 04 Nov 2021 21:54:32 +0200
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Sam Ravnborg <sam@...nborg.org>,
        Javier Martinez Canillas <javierm@...hat.com>
Cc:     David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        dri-devel@...ts.freedesktop.org,
        Gurchetan Singh <gurchetansingh@...omium.org>,
        Gerd Hoffmann <kraxel@...hat.com>,
        amd-gfx@...ts.freedesktop.org,
        VMware Graphics <linux-graphics-maintainer@...are.com>,
        Ben Skeggs <bskeggs@...hat.com>, nouveau@...ts.freedesktop.org,
        Dave Airlie <airlied@...hat.com>,
        intel-gfx@...ts.freedesktop.org,
        Peter Robinson <pbrobinson@...il.com>,
        Michel Dänzer <michel@...nzer.net>,
        Hans de Goede <hdegoede@...hat.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        virtualization@...ts.linux-foundation.org,
        Pekka Paalanen <pekka.paalanen@...labora.com>,
        "Pan\, Xinhui" <Xinhui.Pan@....com>, linux-kernel@...r.kernel.org,
        spice-devel@...ts.freedesktop.org,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Alex Deucher <alexander.deucher@....com>,
        Christian König <christian.koenig@....com>
Subject: Re: [PATCH v2 1/2] drm: Add a drm_drv_enabled() to check if drivers should be enabled

On Thu, 04 Nov 2021, Sam Ravnborg <sam@...nborg.org> wrote:
> Hi Javier,
>
>> 
>> >>>  
>> >>> -	if (vgacon_text_force() && i915_modparams.modeset == -1)
>> >>> +	ret = drm_drv_enabled(&driver);
>> >>
>> >> You pass the local driver variable here - which looks wrong as this is
>> >> not the same as the driver variable declared in another file.
>> >
>> 
>> Yes, Jani mentioned it already. I got confused and thought that the driver
>> variable was also defined in the same compilation unit...
>> 
>> Maybe I could squash the following change?
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
>> index b18a250e5d2e..b8f399b76363 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -89,7 +89,7 @@
>>  #include "intel_region_ttm.h"
>>  #include "vlv_suspend.h"
>>  
>> -static const struct drm_driver driver;
>> +const struct drm_driver driver;
> No, variables with such a generic name will clash.
>
> Just add a
> const drm_driver * i915_drm_driver(void)
> {
> 	return &driver;
> }
>
> And then use this function to access the drm_driver variable.

Agreed on the general principle of exposing interfaces over data.

But... why? I'm still at a loss what problem this solves. We pass
&driver to exactly one place, devm_drm_dev_alloc(), and it's neatly
hidden away.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center