[PATCH] fsnotify: avoid gcc-10 zero-length-bounds warning

[PATCH] fsnotify: avoid gcc-10 zero-length-bounds warning

[Arnd Bergmann]

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(-)

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)
-- 
2.26.0

Re: [PATCH] fsnotify: avoid gcc-10 zero-length-bounds warning

[Gustavo A. R. Silva]

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

Re: [PATCH] fsnotify: avoid gcc-10 zero-length-bounds warning

[Arnd Bergmann]

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

Re: [PATCH] fsnotify: avoid gcc-10 zero-length-bounds warning

[Gustavo A. R. Silva]

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

Re: [PATCH] fsnotify: avoid gcc-10 zero-length-bounds warning

[Arnd Bergmann]

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

Re: [PATCH] fsnotify: avoid gcc-10 zero-length-bounds warning

[Linus Torvalds]

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

RE: [PATCH] fsnotify: avoid gcc-10 zero-length-bounds warning

[David Laight]

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)