[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a1-zevdOST+vTF2rCv5Q46Kjf9U76SqFteUensesN=0RQ@mail.gmail.com>
Date: Tue, 14 Nov 2017 13:37:42 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Nicolai Stange <nicstange@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] debugfs: fix debugfs_real_fops() build error
On Tue, Nov 14, 2017 at 12:50 PM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> 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?
As I said, all calls to debugfs_real_fops() are from a read/write
file operation, which gets discarded when CONFIG_DEBUG_FS
is disabled, because debugfs_create_file() and similar functions
don't use the file_operations structure pointing to them.
There is no link error, unless someone uses debugfs_real_fops()
in a function that does not get discarded. If we ever get a
function calling debugfs_real_fops() when DEBUG_FS is
turned off and we call that function from somewhere else,
we definitely want to get the link error over dereferencing
container_of(NULL, type, member).
Arnd
Powered by blists - more mailing lists