linux-kernel - Re: [PATCH] debugfs: fix debugfs_real

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: <20171114115059.GB26814@kroah.com>
Date:   Tue, 14 Nov 2017 12:50:59 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Nicolai Stange <nicstange@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] debugfs: fix debugfs_real_fops() build error

On Tue, Nov 14, 2017 at 12:40:31PM +0100, Arnd Bergmann wrote:
> Some drivers use debugfs_real_fops() even when CONFIG_DEBUG_FS is disabled,
> which now leads to a build error:
> 
> In file included from include/linux/list.h:9:0,
>                  from include/linux/wait.h:7,
>                  from include/linux/wait_bit.h:8,
>                  from include/linux/fs.h:6,
>                  from drivers/net/wireless/broadcom/b43legacy/debugfs.c:26:
> drivers/net/wireless/broadcom/b43legacy/debugfs.c: In function 'b43legacy_debugfs_read':
> drivers/net/wireless/broadcom/b43legacy/debugfs.c:224:23: error: implicit declaration of function 'debugfs_real_fops'; did you mean 'debugfs_create_bool'? [-Werror=implicit-function-declaration]
> 
> My first impulse was to add another 'static inline' dummy function
> returning NULL for it, which would work fine. However, most callers
> feed the pointer into container_of(), so it seems a little dangerous
> here. Since all the callers are inside of a read/write file operation
> that gets eliminated in this configuration, so having an 'extern'
> declaration seems better here. If it ever gets used in a dangerous
> way, that will now result in a link error.

Ok, but does your patch really "fix" anything?  The linker should now
complain, not the compiler, for these types of configurations?

thanks,

greg k-h