| Message ID | 20200505143028.1290686-1-arnd@arndb.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fsnotify: avoid gcc-10 zero-length-bounds warning | expand |
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
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
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
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
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
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)
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)
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(-)