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: <20200318165846.GC3090655@kroah.com>
Date:   Wed, 18 Mar 2020 17:58:46 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Wambui Karuga <wambui.karugax@...il.com>,
        Dave Airlie <airlied@...ux.ie>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 10/17] drm/vram-helper: make
 drm_vram_mm_debugfs_init() return 0

On Wed, Mar 18, 2020 at 05:31:47PM +0100, Daniel Vetter wrote:
> On Wed, Mar 18, 2020 at 5:03 PM Wambui Karuga <wambui.karugax@...il.com> wrote:
> >
> >
> >
> > On Wed, 18 Mar 2020, Daniel Vetter wrote:
> >
> > > On Tue, Mar 10, 2020 at 04:31:14PM +0300, Wambui Karuga wrote:
> > >> Since 987d65d01356 (drm: debugfs: make
> > >> drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
> > >> fails and should return void. Therefore, remove its use as the
> > >> return value of drm_vram_mm_debugfs_init(), and have the function
> > >> return 0 directly.
> > >>
> > >> v2: have drm_vram_mm_debugfs_init() return 0 instead of void to avoid
> > >> introducing build issues and build breakage.
> > >>
> > >> References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
> > >> Signed-off-by: Wambui Karuga <wambui.karugax@...il.com>
> > >> Acked-by: Thomas Zimmermann <tzimmermann@...e.de>
> > >> ---
> > >>  drivers/gpu/drm/drm_gem_vram_helper.c | 10 ++++------
> > >>  1 file changed, 4 insertions(+), 6 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
> > >> index 92a11bb42365..c8bcc8609650 100644
> > >> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> > >> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> > >> @@ -1048,14 +1048,12 @@ static const struct drm_info_list drm_vram_mm_debugfs_list[] = {
> > >>   */
> > >>  int drm_vram_mm_debugfs_init(struct drm_minor *minor)
> > >>  {
> > >> -    int ret = 0;
> > >> -
> > >>  #if defined(CONFIG_DEBUG_FS)
> > >
> > > Just noticed that this #if here is not needed, we already have a dummy
> > > function for that case. Care to write a quick patch to remove it? On top
> > > of this patch series here ofc, I'm in the processing of merging the entire
> > > pile.
> > >
> > > Thanks, Daniel
> > Hi Daniel,
> > Without this check here, and compiling without CONFIG_DEBUG_FS, this
> > function is run and the drm_debugfs_create_files() does not have access to
> > the parameters also protected by an #if above this function. So the change
> > throws an error for me. Is that correct?
> 
> Hm right. Other drivers don't #ifdef out their debugfs file functions
> ... kinda a bit disappointing that we can't do this in the neatest way
> possible.
> 
> Greg, has anyone ever suggested to convert the debugfs_create_file
> function (and similar things) to macros that don't use any of the
> arguments, and then also annotating all the static functions/tables as
> __maybe_unused and let the compiler garbage collect everything?
> Instead of explicit #ifdef in all the drivers ...

No, no one has suggested that, having the functions be static inline
should make it all "just work" properly if debugfs is not enabled.  The
variables will not be used, so the compiler should just optimize them
away properly.

No checks for CONFIG_DEBUG_FS should be needed anywhere in .c code.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ