fsnotify: avoid gcc-10 zero-length-bounds warning
diff mbox series

Message ID 20200505143028.1290686-1-arnd@arndb.de
State New
Headers show
Series
  • fsnotify: avoid gcc-10 zero-length-bounds warning
Related show

Commit Message

Arnd Bergmann May 5, 2020, 2:30 p.m. UTC
gcc-10 warns about accesses into the f_handle[] zero-length array.

fs/notify/fdinfo.c: In function 'show_mark_fhandle':
fs/notify/fdinfo.c:66:47: error: array subscript 'i' is outside the bounds of an interior zero-length array 'unsigned char[0]' [-Werror=zero-length-bounds]
   66 |   seq_printf(m, "%02x", (int)f.handle.f_handle[i]);
      |                              ~~~~~~~~~~~~~~~~~^~~
In file included from fs/notify/fdinfo.c:3:
include/linux/fs.h:988:16: note: while referencing 'f_handle'
  988 |  unsigned char f_handle[0];
      |                ^~~~~~~~

This is solved by using a flexible array instead.

Cc: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Gustavo has done the same thing as part of a treewide change, but keeping
this separate lets us backport it to stable kernels more easily later.
---
 include/linux/fs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Gustavo A. R. Silva May 5, 2020, 2:39 p.m. UTC | #1
On 5/5/20 09:30, Arnd Bergmann wrote:
> gcc-10 warns about accesses into the f_handle[] zero-length array.
> 
> fs/notify/fdinfo.c: In function 'show_mark_fhandle':
> fs/notify/fdinfo.c:66:47: error: array subscript 'i' is outside the bounds of an interior zero-length array 'unsigned char[0]' [-Werror=zero-length-bounds]
>    66 |   seq_printf(m, "%02x", (int)f.handle.f_handle[i]);
>       |                              ~~~~~~~~~~~~~~~~~^~~
> In file included from fs/notify/fdinfo.c:3:
> include/linux/fs.h:988:16: note: while referencing 'f_handle'
>   988 |  unsigned char f_handle[0];
>       |                ^~~~~~~~
> 
> This is solved by using a flexible array instead.
> 
> Cc: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Gustavo has done the same thing as part of a treewide change, but keeping
> this separate lets us backport it to stable kernels more easily later.

Arnd,

I wonder why would we need to backport these changes to -stable... merely
because of the use of a new version of GCC?

Thanks
--
Gustavo
Arnd Bergmann May 5, 2020, 3 p.m. UTC | #2
On Tue, May 5, 2020 at 4:35 PM Gustavo A. R. Silva
<gustavo@embeddedor.com> wrote:
> On 5/5/20 09:30, Arnd Bergmann wrote:
> > gcc-10 warns about accesses into the f_handle[] zero-length array.
> >
> > fs/notify/fdinfo.c: In function 'show_mark_fhandle':
> > fs/notify/fdinfo.c:66:47: error: array subscript 'i' is outside the bounds of an interior zero-length array 'unsigned char[0]' [-Werror=zero-length-bounds]
> >    66 |   seq_printf(m, "%02x", (int)f.handle.f_handle[i]);
> >       |                              ~~~~~~~~~~~~~~~~~^~~
> > In file included from fs/notify/fdinfo.c:3:
> > include/linux/fs.h:988:16: note: while referencing 'f_handle'
> >   988 |  unsigned char f_handle[0];
> >       |                ^~~~~~~~
> >
> > This is solved by using a flexible array instead.
> >
> > Cc: Gustavo A. R. Silva <gustavo@embeddedor.com>
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > Gustavo has done the same thing as part of a treewide change, but keeping
> > this separate lets us backport it to stable kernels more easily later.
>
> Arnd,
>
> I wonder why would we need to backport these changes to -stable... merely
> because of the use of a new version of GCC?

Yes, we usually backport trivial warning fixes to stable kernels to allow
building those with any modern compiler version.

       Arnd
Gustavo A. R. Silva May 5, 2020, 3:11 p.m. UTC | #3
On 5/5/20 10:00, Arnd Bergmann wrote:
> On Tue, May 5, 2020 at 4:35 PM Gustavo A. R. Silva
> <gustavo@embeddedor.com> wrote:
>> On 5/5/20 09:30, Arnd Bergmann wrote:
>>> gcc-10 warns about accesses into the f_handle[] zero-length array.
>>>
>>> fs/notify/fdinfo.c: In function 'show_mark_fhandle':
>>> fs/notify/fdinfo.c:66:47: error: array subscript 'i' is outside the bounds of an interior zero-length array 'unsigned char[0]' [-Werror=zero-length-bounds]
>>>    66 |   seq_printf(m, "%02x", (int)f.handle.f_handle[i]);
>>>       |                              ~~~~~~~~~~~~~~~~~^~~
>>> In file included from fs/notify/fdinfo.c:3:
>>> include/linux/fs.h:988:16: note: while referencing 'f_handle'
>>>   988 |  unsigned char f_handle[0];
>>>       |                ^~~~~~~~
>>>
>>> This is solved by using a flexible array instead.
>>>
>>> Cc: Gustavo A. R. Silva <gustavo@embeddedor.com>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>> Gustavo has done the same thing as part of a treewide change, but keeping
>>> this separate lets us backport it to stable kernels more easily later.
>>
>> Arnd,
>>
>> I wonder why would we need to backport these changes to -stable... merely
>> because of the use of a new version of GCC?
> 
> Yes, we usually backport trivial warning fixes to stable kernels to allow
> building those with any modern compiler version.
> 

OK. So, if you anticipate that this is going to happen, I can split up my
treewide patch into separate per-subsystem patches.  I can replace the
treewide patch in my tree today, so the changes are reflected in tomorrow's
linux-next.

--
Gustavo
Arnd Bergmann May 5, 2020, 3:23 p.m. UTC | #4
On Tue, May 5, 2020 at 5:07 PM Gustavo A. R. Silva
<gustavo@embeddedor.com> wrote:
> On 5/5/20 10:00, Arnd Bergmann wrote:
> > On Tue, May 5, 2020 at 4:35 PM Gustavo A. R. Silva
> > <gustavo@embeddedor.com> wrote:
> >> On 5/5/20 09:30, Arnd Bergmann wrote:
> >> I wonder why would we need to backport these changes to -stable... merely
> >> because of the use of a new version of GCC?
> >
> > Yes, we usually backport trivial warning fixes to stable kernels to allow
> > building those with any modern compiler version.
> >
>
> OK. So, if you anticipate that this is going to happen, I can split up my
> treewide patch into separate per-subsystem patches.  I can replace the
> treewide patch in my tree today, so the changes are reflected in tomorrow's
> linux-next.

I only needed a few patches to address all the warnings, so you don't need to
split up the patch for this purpose, though it may be easier to get it merged
anyway.

I see now that Linus has already applied the same fix as part of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d82973e032e2
It's just not yet in today's linux-next, but  my patch is now obsolete.

Linus, let me know if you would like me to Cc you on the other gcc-10
warning fixes I have and possibly apply some directly. I have patches
for all gcc-10 and clang-10 warnings now, and am in the process of
getting them out to the subsystem maintainers.

     Arnd
Linus Torvalds May 5, 2020, 4:58 p.m. UTC | #5
On Tue, May 5, 2020 at 8:24 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> Linus, let me know if you would like me to Cc you on the other gcc-10
> warning fixes I have and possibly apply some directly.

Sure. If you have any of the "trivially correct, and doesn't make code
look worse", push them my way.

I only did the ones that looked trivial and fairly core - didn't want
to step on any driver toes etc.

                  Linus
David Laight May 7, 2020, 8:01 a.m. UTC | #6
From: Arnd Bergmann
> Sent: 05 May 2020 16:00
...
> Yes, we usually backport trivial warning fixes to stable kernels to allow
> building those with any modern compiler version.

In this case wouldn't it be better to backport a change that disables
the specific compiler warning?

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Patch
diff mbox series

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 8690dc56e883..b229c55a8232 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -986,7 +986,7 @@  struct file_handle {
 	__u32 handle_bytes;
 	int handle_type;
 	/* file identifier */
-	unsigned char f_handle[0];
+	unsigned char f_handle[];
 };
 
 static inline struct file *get_file(struct file *f)