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]
Date:   Thu, 27 Feb 2020 13:34:04 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Wambui Karuga <wambui.karugax@...il.com>
Cc:     daniel@...ll.ch, airlied@...ux.ie, mripard@...nel.org,
        maarten.lankhorst@...ux.intel.com, tzimmermann@...e.de,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 02/21] drm: convert the drm_driver.debugfs_init() hook to
 return void.

On Thu, Feb 27, 2020 at 03:29:46PM +0300, Wambui Karuga wrote:
> 
> 
> On Thu, 27 Feb 2020, Greg KH wrote:
> 
> > On Thu, Feb 27, 2020 at 03:02:13PM +0300, Wambui Karuga wrote:
> > > As a result of commit 987d65d01356 (drm: debugfs: make
> > > drm_debugfs_create_files() never fail) and changes to various debugfs
> > > functions in drm/core and across various drivers, there is no need for
> > > the drm_driver.debugfs_init() hook to have a return value. Therefore,
> > > declare it as void.
> > > 
> > > Signed-off-by: Wambui Karuga <wambui.karugax@...il.com>
> > > ---
> > >  include/drm/drm_drv.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > > index 97109df5beac..c6ae888c672b 100644
> > > --- a/include/drm/drm_drv.h
> > > +++ b/include/drm/drm_drv.h
> > > @@ -323,7 +323,7 @@ struct drm_driver {
> > >  	 *
> > >  	 * Allows drivers to create driver-specific debugfs files.
> > >  	 */
> > > -	int (*debugfs_init)(struct drm_minor *minor);
> > > +	void (*debugfs_init)(struct drm_minor *minor);
> > 
> > 
> > Doesn't this patch break the build, or at least, cause lots of build
> > warnings to happen?
> > 
> > Fixing it all up later is good, but I don't think you want to break
> > things at this point in the series.
> > 
> So, should it come last in the series? All functions that use this hook have
> been converted to void in the patchset.

I recommend fixing up the functions to just always return 0 first, and
then in one last patch, change the function itself to return void along
with this.

That would make it easiest to review, and allow no build warnings at any
point in the series, right?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ