linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: build warnings from Linus' tree
@ 2018-06-11 22:14 Stephen Rothwell
  2018-11-14  4:54 ` Joel Stanley
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Rothwell @ 2018-06-11 22:14 UTC (permalink / raw)
  To: Michael Ellerman, Benjamin Herrenschmidt, PowerPC
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

Hi all,

Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
produced these warning:

ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.

This may just be because I have started building using the native Debian
gcc for the powerpc builds ...

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2018-06-11 22:14 linux-next: build warnings from Linus' tree Stephen Rothwell
@ 2018-11-14  4:54 ` Joel Stanley
  2018-11-14 10:20   ` Michael Ellerman
  0 siblings, 1 reply; 16+ messages in thread
From: Joel Stanley @ 2018-11-14  4:54 UTC (permalink / raw)
  To: Stephen Rothwell, Alan Modra
  Cc: Michael Ellerman, Benjamin Herrenschmidt, linuxppc-dev,
	Linux-Next Mailing List, Linux Kernel Mailing List

Hello Alan,

On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> produced these warning:
>
> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
>
> This may just be because I have started building using the native Debian
> gcc for the powerpc builds ...

Do you know why we started creating these?

If it's intentional, should we be putting including them in the same
way as .hash sections?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282

  .hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }

Cheers,

Joel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2018-11-14  4:54 ` Joel Stanley
@ 2018-11-14 10:20   ` Michael Ellerman
  2018-11-18 11:22     ` Alan Modra
  0 siblings, 1 reply; 16+ messages in thread
From: Michael Ellerman @ 2018-11-14 10:20 UTC (permalink / raw)
  To: Joel Stanley, Stephen Rothwell, Alan Modra
  Cc: Benjamin Herrenschmidt, linuxppc-dev, Linux-Next Mailing List,
	Linux Kernel Mailing List

Joel Stanley <joel@jms.id.au> writes:
> Hello Alan,
>
> On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
>> produced these warning:
>>
>> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
>> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
>> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
>>
>> This may just be because I have started building using the native Debian
>> gcc for the powerpc builds ...
>
> Do you know why we started creating these?

It's controlled by the ld option --hash-style, which AFAICS still
defaults to sysv (generating .hash).

But it seems gcc can be configured to have a different default, and at
least my native ppc64le toolchains are passing gnu, eg:

 /usr/lib/gcc/powerpc64le-linux-gnu/6/collect2 -plugin
 /usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so
 -plugin-opt=/usr/lib/gcc/powerpc64le-linux-gnu/6/lto-wrapper
 -plugin-opt=-fresolution=/tmp/ccw1U2fF.res
 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
 -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
 -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr
 -V -shared -m elf64lppc
 --hash-style=gnu
 ^^^^^^^^^^^^^^^^

So that's presumably why we're seeing it, some GCCs are configured to
use it.

> If it's intentional, should we be putting including them in the same
> way as .hash sections?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282
>
>   .hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }

That would presumably work.

My question though is do we even need it?

From what I can see for it to be useful you need the section as well as
an entry in the dynamic section pointing at it, and we don't have a
dynamic section at all:

  $ readelf -S vmlinux | grep gnu.hash
    [ 4] .gnu.hash         GNU_HASH         c000000000dbbdb0  00dcbdb0
  $ readelf -d vmlinux
  
  There is no dynamic section in this file.

Compare to the vdso:

$ readelf -d arch/powerpc/kernel/vdso64/vdso64.so

Dynamic section at offset 0x868 contains 12 entries:
  Tag        Type                         Name/Value
 0x000000000000000e (SONAME)             Library soname: [linux-vdso64.so.1]
 0x0000000000000004 (HASH)               0x120
 0x000000006ffffef5 (GNU_HASH)           0x170
 0x0000000000000005 (STRTAB)             0x320
 0x0000000000000006 (SYMTAB)             0x1d0
 0x000000000000000a (STRSZ)              269 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000070000003 (PPC64_OPT)          0x0
 0x000000006ffffffc (VERDEF)             0x450
 0x000000006ffffffd (VERDEFNUM)          2
 0x000000006ffffff0 (VERSYM)             0x42e
 0x0000000000000000 (NULL)               0x0


So can't we just discard .gnu.hash? And in fact do we need .hash either?

Actually arm64 discards the latter, and parisc discards both.

Would still be good to hear from Alan or someone else who knows anything
about toolchain stuff, ie. not me :)

cheers

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2018-11-14 10:20   ` Michael Ellerman
@ 2018-11-18 11:22     ` Alan Modra
  2018-12-03 23:24       ` Joel Stanley
  0 siblings, 1 reply; 16+ messages in thread
From: Alan Modra @ 2018-11-18 11:22 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Joel Stanley, Stephen Rothwell, Benjamin Herrenschmidt,
	linuxppc-dev, Linux-Next Mailing List, Linux Kernel Mailing List

On Wed, Nov 14, 2018 at 09:20:23PM +1100, Michael Ellerman wrote:
> Joel Stanley <joel@jms.id.au> writes:
> > Hello Alan,
> >
> > On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> >> produced these warning:
> >>
> >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> >>
> >> This may just be because I have started building using the native Debian
> >> gcc for the powerpc builds ...
> >
> > Do you know why we started creating these?
> 
> It's controlled by the ld option --hash-style, which AFAICS still
> defaults to sysv (generating .hash).
> 
> But it seems gcc can be configured to have a different default, and at
> least my native ppc64le toolchains are passing gnu, eg:
> 
>  /usr/lib/gcc/powerpc64le-linux-gnu/6/collect2 -plugin
>  /usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so
>  -plugin-opt=/usr/lib/gcc/powerpc64le-linux-gnu/6/lto-wrapper
>  -plugin-opt=-fresolution=/tmp/ccw1U2fF.res
>  -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
>  -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
>  -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr
>  -V -shared -m elf64lppc
>  --hash-style=gnu
>  ^^^^^^^^^^^^^^^^
> 
> So that's presumably why we're seeing it, some GCCs are configured to
> use it.
> 
> > If it's intentional, should we be putting including them in the same
> > way as .hash sections?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282
> >
> >   .hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }
> 
> That would presumably work.
> 
> My question though is do we even need it?
> 
> >From what I can see for it to be useful you need the section as well as
> an entry in the dynamic section pointing at it, and we don't have a
> dynamic section at all:
> 
>   $ readelf -S vmlinux | grep gnu.hash
>     [ 4] .gnu.hash         GNU_HASH         c000000000dbbdb0  00dcbdb0
>   $ readelf -d vmlinux
>   
>   There is no dynamic section in this file.
> 
> Compare to the vdso:
> 
> $ readelf -d arch/powerpc/kernel/vdso64/vdso64.so
> 
> Dynamic section at offset 0x868 contains 12 entries:
>   Tag        Type                         Name/Value
>  0x000000000000000e (SONAME)             Library soname: [linux-vdso64.so.1]
>  0x0000000000000004 (HASH)               0x120
>  0x000000006ffffef5 (GNU_HASH)           0x170
>  0x0000000000000005 (STRTAB)             0x320
>  0x0000000000000006 (SYMTAB)             0x1d0
>  0x000000000000000a (STRSZ)              269 (bytes)
>  0x000000000000000b (SYMENT)             24 (bytes)
>  0x0000000070000003 (PPC64_OPT)          0x0
>  0x000000006ffffffc (VERDEF)             0x450
>  0x000000006ffffffd (VERDEFNUM)          2
>  0x000000006ffffff0 (VERSYM)             0x42e
>  0x0000000000000000 (NULL)               0x0
> 
> 
> So can't we just discard .gnu.hash? And in fact do we need .hash either?
> 
> Actually arm64 discards the latter, and parisc discards both.
> 
> Would still be good to hear from Alan or someone else who knows anything
> about toolchain stuff, ie. not me :)

.gnu.hash, like .hash, is used by glibc ld.so for dynamic symbol
lookup.  I imagine you don't need either section in a kernel, so
discarding both sounds reasonable.  Likely you could discard .interp
and .dynstr too, and .dynsym when !CONFIG_PPC32.

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2018-11-18 11:22     ` Alan Modra
@ 2018-12-03 23:24       ` Joel Stanley
  0 siblings, 0 replies; 16+ messages in thread
From: Joel Stanley @ 2018-12-03 23:24 UTC (permalink / raw)
  To: Alan Modra
  Cc: Michael Ellerman, Stephen Rothwell, Benjamin Herrenschmidt,
	linuxppc-dev, Linux-Next Mailing List, Linux Kernel Mailing List

On Sun, 18 Nov 2018 at 21:52, Alan Modra <amodra@gmail.com> wrote:
>
> On Wed, Nov 14, 2018 at 09:20:23PM +1100, Michael Ellerman wrote:
> > Joel Stanley <joel@jms.id.au> writes:
> > > Hello Alan,
> > >
> > > On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > >> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> > >> produced these warning:
> > >>
> > >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> > >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> > >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> > >>
> > >> This may just be because I have started building using the native Debian
> > >> gcc for the powerpc builds ...
> > >
> > > Do you know why we started creating these?
> >
> > It's controlled by the ld option --hash-style, which AFAICS still
> > defaults to sysv (generating .hash).
> >
> > But it seems gcc can be configured to have a different default, and at
> > least my native ppc64le toolchains are passing gnu, eg:
> >
> >  /usr/lib/gcc/powerpc64le-linux-gnu/6/collect2 -plugin
> >  /usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so
> >  -plugin-opt=/usr/lib/gcc/powerpc64le-linux-gnu/6/lto-wrapper
> >  -plugin-opt=-fresolution=/tmp/ccw1U2fF.res
> >  -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
> >  -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
> >  -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr
> >  -V -shared -m elf64lppc
> >  --hash-style=gnu
> >  ^^^^^^^^^^^^^^^^
> >
> > So that's presumably why we're seeing it, some GCCs are configured to
> > use it.
> >
> > > If it's intentional, should we be putting including them in the same
> > > way as .hash sections?
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282
> > >
> > >   .hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }
> >
> > That would presumably work.
> >
> > My question though is do we even need it?
> >
> > >From what I can see for it to be useful you need the section as well as
> > an entry in the dynamic section pointing at it, and we don't have a
> > dynamic section at all:
> >
> >   $ readelf -S vmlinux | grep gnu.hash
> >     [ 4] .gnu.hash         GNU_HASH         c000000000dbbdb0  00dcbdb0
> >   $ readelf -d vmlinux
> >
> >   There is no dynamic section in this file.
> >
> > Compare to the vdso:
> >
> > $ readelf -d arch/powerpc/kernel/vdso64/vdso64.so
> >
> > Dynamic section at offset 0x868 contains 12 entries:
> >   Tag        Type                         Name/Value
> >  0x000000000000000e (SONAME)             Library soname: [linux-vdso64.so.1]
> >  0x0000000000000004 (HASH)               0x120
> >  0x000000006ffffef5 (GNU_HASH)           0x170
> >  0x0000000000000005 (STRTAB)             0x320
> >  0x0000000000000006 (SYMTAB)             0x1d0
> >  0x000000000000000a (STRSZ)              269 (bytes)
> >  0x000000000000000b (SYMENT)             24 (bytes)
> >  0x0000000070000003 (PPC64_OPT)          0x0
> >  0x000000006ffffffc (VERDEF)             0x450
> >  0x000000006ffffffd (VERDEFNUM)          2
> >  0x000000006ffffff0 (VERSYM)             0x42e
> >  0x0000000000000000 (NULL)               0x0
> >
> >
> > So can't we just discard .gnu.hash? And in fact do we need .hash either?
> >
> > Actually arm64 discards the latter, and parisc discards both.
> >
> > Would still be good to hear from Alan or someone else who knows anything
> > about toolchain stuff, ie. not me :)
>
> .gnu.hash, like .hash, is used by glibc ld.so for dynamic symbol
> lookup.  I imagine you don't need either section in a kernel, so
> discarding both sounds reasonable.  Likely you could discard .interp
> and .dynstr too, and .dynsym when !CONFIG_PPC32.

Thanks for the digging Michael, and thanks Alan for clarifying the
details. I'll cook up a patch or two.

Cheers,

Joel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: build warnings from Linus' tree
@ 2019-08-29 21:59 Stephen Rothwell
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Rothwell @ 2019-08-29 21:59 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

Hi all,

With just Linus' tree, today's linux-next build (ppc64le perf) produced
these warnings:

util/parse-events.y:1.1-12: warning: deprecated directive, use '%define api.pure' [-Wdeprecated]
    1 | %pure-parser
      | ^~~~~~~~~~~~
util/parse-events.y: warning: fix-its can be applied.  Rerun with option '--update'. [-Wother]
util/expr.y:13.1-12: warning: deprecated directive, use '%define api.pure' [-Wdeprecated]
   13 | %pure-parser
      | ^~~~~~~~~~~~
util/expr.y: warning: fix-its can be applied.  Rerun with option '--update'. [-Wother]

I assume this is because I have upgraded bison to version 3.4.1 (from
3.3.2).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2018-08-20  0:02 ` Theodore Y. Ts'o
@ 2018-08-20 17:47   ` Miguel Ojeda
  0 siblings, 0 replies; 16+ messages in thread
From: Miguel Ojeda @ 2018-08-20 17:47 UTC (permalink / raw)
  To: Theodore Y. Ts'o, Stephen Rothwell, Linus Torvalds,
	Linux-Next Mailing List, Linux Kernel Mailing List

Hi Ted,

On Mon, Aug 20, 2018 at 2:02 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> P.S.  It's really, really too bad there isn't a simpler way to shut up
> gcc.  You need the #ifdef __GNUC_PREREQ nonsense because otherwise
> older versions of gcc that don't understand the particular warning
> you're trying to suppress will complain loudly.  (Ask me how I
> know....)

Please check out the __nonstring patch I sent (the one Linus is
referring to, I guess) and see if you think it would be a good
solution for your case:

  https://lore.kernel.org/lkml/20180814193813.GA5473@gmail.com/

I just tried the patch below with 8.2 [*] and those two warnings in
fs/ext4 go away as expected.

I think marking those fixed-width fields is a good idea anyway (i.e.
makes it clear that they are not meant to be null-terminated), but I
would like to hear opinions on the matter.

Cheers,
Miguel

[*]

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 0f0edd1cd0cd..3eef4b286895 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1277,13 +1277,13 @@ struct ext4_super_block {
        __le32  s_first_error_time;     /* first time an error happened */
        __le32  s_first_error_ino;      /* inode involved in first error */
        __le64  s_first_error_block;    /* block involved of first error */
-       __u8    s_first_error_func[32]; /* function where the error happened */
+       __u8    s_first_error_func[32] __nonstring;     /* function
where the error happened */
        __le32  s_first_error_line;     /* line number where error happened */
        __le32  s_last_error_time;      /* most recent time of an error */
        __le32  s_last_error_ino;       /* inode involved in last error */
        __le32  s_last_error_line;      /* line number where error happened */
        __le64  s_last_error_block;     /* block involved of last error */
-       __u8    s_last_error_func[32];  /* function where the error happened */
+       __u8    s_last_error_func[32] __nonstring;      /* function
where the error happened */
 #define EXT4_S_ERR_END offsetof(struct ext4_super_block, s_mount_opts)
        __u8    s_mount_opts[64];
        __le32  s_usr_quota_inum;       /* inode for tracking user quota */

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2018-08-20  1:33   ` Adam Borowski
@ 2018-08-20  2:53     ` Theodore Y. Ts'o
  0 siblings, 0 replies; 16+ messages in thread
From: Theodore Y. Ts'o @ 2018-08-20  2:53 UTC (permalink / raw)
  To: Adam Borowski
  Cc: Linus Torvalds, Stephen Rothwell, linux-next, Linux Kernel Mailing List

On Mon, Aug 20, 2018 at 03:33:19AM +0200, Adam Borowski wrote:
> Valid uses of strncpy() do exist (such as SCSI structs), but those deal with
> fixed-width fields.  Thus, gcc is right for warning for at least some of
> misuse of strncpy() for C strings.  The function wasn't designed for them.

The problem is that the kernel has a goodly share of fixed-width
fields.  The ext4 superblock is one of them.  strncpy() is the most
convenient function to do what is needed.  If it's a valid use, then
we need to have a way to get gcc to shut up about them.

	   	   	      	 - Ted

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2018-08-19 23:21 ` Linus Torvalds
@ 2018-08-20  1:33   ` Adam Borowski
  2018-08-20  2:53     ` Theodore Y. Ts'o
  0 siblings, 1 reply; 16+ messages in thread
From: Adam Borowski @ 2018-08-20  1:33 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Stephen Rothwell, linux-next, Linux Kernel Mailing List

On Sun, Aug 19, 2018 at 04:21:57PM -0700, Linus Torvalds wrote:
> On Sun, Aug 19, 2018 at 3:13 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) produced these
> > warnings:
> >
> > fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=]
> >    strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
> >
> > Presumably caused by my update to gcc 8.2.0.
> 
> Yeah. There are some patches to mark some arrays as non-strings to get
> rid of these, but we'll see. Maybe we'll just disable the new gcc
> warning if it causes more pain than it is worth.

Every single use of strncpy() for a C string is either a bug, inefficiency,
or both.  In this particular case the code:

        count = 0;
        for (i = 0; i < CIFS_NUM_PROT; i++) {
                strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
                count += strlen(protocols[i].name) + 1;
                /* null at end of source and target buffers anyway */
        }

* pointlessly clears 16 bytes in every iteration
* calculates the string's length twice
* there's no protection against buffer overflow anyway

So what is the strncpy() there for, when an unbounded copy would be just as
good?  For other cases, there's a bunch of better functions: strlcpy(),
snprintf(), even strlen()+memcpy(), etc.

Valid uses of strncpy() do exist (such as SCSI structs), but those deal with
fixed-width fields.  Thus, gcc is right for warning for at least some of
misuse of strncpy() for C strings.  The function wasn't designed for them.

(Skipped analysis why strncpy is always a bad choice for C strings.)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄⠀⠀⠀⠀ • use glitches to walk on water [Mt14:25-26]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2018-08-19 22:13 Stephen Rothwell
  2018-08-19 22:16 ` Stephen Rothwell
  2018-08-19 23:21 ` Linus Torvalds
@ 2018-08-20  0:02 ` Theodore Y. Ts'o
  2018-08-20 17:47   ` Miguel Ojeda
  2 siblings, 1 reply; 16+ messages in thread
From: Theodore Y. Ts'o @ 2018-08-20  0:02 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linus Torvalds, Linux-Next Mailing List, Linux Kernel Mailing List

On Mon, Aug 20, 2018 at 08:13:23AM +1000, Stephen Rothwell wrote:
> fs/ext4/super.c: In function '__save_error_info':
> fs/ext4/super.c:344:2: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
>   strncpy(es->s_last_error_func, func, sizeof(es->s_last_error_func));
>   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> fs/ext4/super.c:349:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
>    strncpy(es->s_first_error_func, func,
>    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     sizeof(es->s_first_error_func));
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

All of ext4 superblock char[] fields are not necessarily null
terminated, so this is a false positive.  I suppose we could do
something like this:

inline char *
strncpy_I_solemnly_swear_I_know_what_I_am_doing(char *dest,
			const char *src, size_t n)
{
#if __GNUC_PREREQ (8, 2)
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-truncate"
#endif
	return strncpy(dest, src, n);
#if __GNUC_PREREQ (8, 2)
#pragma GCC diagnostic pop
#endif
}

(if we really think this warning is worthwhile enough that we don't
just want to globally disable it, of course)

       		      	       - Ted

P.S.  It's really, really too bad there isn't a simpler way to shut up
gcc.  You need the #ifdef __GNUC_PREREQ nonsense because otherwise
older versions of gcc that don't understand the particular warning
you're trying to suppress will complain loudly.  (Ask me how I
know....)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2018-08-19 22:13 Stephen Rothwell
  2018-08-19 22:16 ` Stephen Rothwell
@ 2018-08-19 23:21 ` Linus Torvalds
  2018-08-20  1:33   ` Adam Borowski
  2018-08-20  0:02 ` Theodore Y. Ts'o
  2 siblings, 1 reply; 16+ messages in thread
From: Linus Torvalds @ 2018-08-19 23:21 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, Linux Kernel Mailing List

On Sun, Aug 19, 2018 at 3:13 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) produced these
> warnings:
>
> fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=]
>    strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
>
> Presumably caused by my update to gcc 8.2.0.

Yeah. There are some patches to mark some arrays as non-strings to get
rid of these, but we'll see. Maybe we'll just disable the new gcc
warning if it causes more pain than it is worth.

                  Linus

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2018-08-19 22:16 ` Stephen Rothwell
@ 2018-08-19 22:40   ` Stephen Rothwell
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Rothwell @ 2018-08-19 22:40 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

Hi all,

On Mon, 20 Aug 2018 08:16:18 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 20 Aug 2018 08:13:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) produced these
> > warnings:
> >   
> ...
> > 
> > Presumably caused by my update to gcc 8.2.0.  
> 
> And this from the x86_64 allmodconfig build:
> 
> scripts/unifdef.c: In function 'Mpass':
> scripts/unifdef.c:453:28: warning: 'strncpy' output truncated before terminating nul copying 4 bytes from a string of the same length [-Wstringop-truncation]
>  static void Mpass (void) { strncpy(keyword, "if  ", 4); Pelif(); }
>                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~

Note that I only upgraded my (host) powerpc compiler.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2018-08-19 22:13 Stephen Rothwell
@ 2018-08-19 22:16 ` Stephen Rothwell
  2018-08-19 22:40   ` Stephen Rothwell
  2018-08-19 23:21 ` Linus Torvalds
  2018-08-20  0:02 ` Theodore Y. Ts'o
  2 siblings, 1 reply; 16+ messages in thread
From: Stephen Rothwell @ 2018-08-19 22:16 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

Hi all,

On Mon, 20 Aug 2018 08:13:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) produced these
> warnings:
> 
...
> 
> Presumably caused by my update to gcc 8.2.0.

And this from the x86_64 allmodconfig build:

scripts/unifdef.c: In function 'Mpass':
scripts/unifdef.c:453:28: warning: 'strncpy' output truncated before terminating nul copying 4 bytes from a string of the same length [-Wstringop-truncation]
 static void Mpass (void) { strncpy(keyword, "if  ", 4); Pelif(); }
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: build warnings from Linus' tree
@ 2018-08-19 22:13 Stephen Rothwell
  2018-08-19 22:16 ` Stephen Rothwell
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Stephen Rothwell @ 2018-08-19 22:13 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 24083 bytes --]

Hi Linus,

Today's linux-next build (powerpc ppc64_defconfig) produced these
warnings:

fs/cifs/cifssmb.c: In function 'CIFSSMBNegotiate':
fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=]
   strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'get_sensor_index_attr',
    inlined from 'create_device_attrs' at drivers/hwmon/ibmpowernv.c:293:8,
    inlined from 'ibmpowernv_probe' at drivers/hwmon/ibmpowernv.c:699:8:
drivers/hwmon/ibmpowernv.c:256:2: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
  strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fs/hfsplus/xattr.c: In function 'copy_name':
fs/hfsplus/xattr.c:416:3: warning: 'strncpy' output truncated before terminating nul copying 4 bytes from a string of the same length [-Wstringop-truncation]
   strncpy(buffer, XATTR_MAC_OSX_PREFIX, XATTR_MAC_OSX_PREFIX_LEN);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fs/ext4/super.c: In function '__save_error_info':
fs/ext4/super.c:344:2: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
  strncpy(es->s_last_error_func, func, sizeof(es->s_last_error_func));
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fs/ext4/super.c:349:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(es->s_first_error_func, func,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    sizeof(es->s_first_error_func));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from include/trace/define_trace.h:97,
                 from include/trace/events/writeback.h:762,
                 from fs/fs-writeback.c:98:
include/trace/events/writeback.h: In function 'perf_trace_writeback_work_class':
include/trace/events/writeback.h:223:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
    wb->bdi->dev ? dev_name(wb->bdi->dev) : "(unknown)", 32);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:222:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'perf_trace_writeback_class':
include/trace/events/writeback.h:277:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:276:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'perf_trace_writeback_bdi_register':
include/trace/events/writeback.h:299:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name, dev_name(bdi->dev), 32);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:292:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_bdi_register,
 ^~~~~~~~~~~
include/trace/events/writeback.h:298:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'perf_trace_wbc_class':
include/trace/events/writeback.h:324:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name, dev_name(bdi->dev), 32);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:323:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'perf_trace_writeback_queue_io':
include/trace/events/writeback.h:375:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:360:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_queue_io,
 ^~~~~~~~~~~
include/trace/events/writeback.h:373:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'perf_trace_writeback_dirty_page':
include/trace/events/writeback.h:69:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
    mapping ? dev_name(inode_to_bdi(mapping->host)->dev) : "(unknown)", 32);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:56:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_dirty_page,
 ^~~~~~~~~~~
include/trace/events/writeback.h:68:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'perf_trace_writeback_dirty_inode_template':
include/trace/events/writeback.h:99:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
    bdi->dev ? dev_name(bdi->dev) : "(unknown)", 32);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:95:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'perf_trace_writeback_write_inode_template':
include/trace/events/writeback.h:179:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
    dev_name(inode_to_bdi(inode)->dev), 32);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:178:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'perf_trace_writeback_sb_inodes_requeue':
include/trace/events/writeback.h:586:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
           dev_name(inode_to_bdi(inode)->dev), 32);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:572:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_sb_inodes_requeue,
 ^~~~~~~~~~~
include/trace/events/writeback.h:585:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h:586:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
           dev_name(inode_to_bdi(inode)->dev), 32);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:572:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_sb_inodes_requeue,
 ^~~~~~~~~~~
include/trace/events/writeback.h:585:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h:586:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
           dev_name(inode_to_bdi(inode)->dev), 32);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:572:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_sb_inodes_requeue,
 ^~~~~~~~~~~
include/trace/events/writeback.h:585:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h:586:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
           dev_name(inode_to_bdi(inode)->dev), 32);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:572:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_sb_inodes_requeue,
 ^~~~~~~~~~~
include/trace/events/writeback.h:585:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'perf_trace_writeback_single_inode_template':
include/trace/events/writeback.h:660:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
    dev_name(inode_to_bdi(inode)->dev), 32);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:659:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
In file included from include/trace/define_trace.h:96,
                 from include/trace/events/writeback.h:762,
                 from fs/fs-writeback.c:98:
include/trace/events/writeback.h: In function 'trace_event_raw_event_writeback_dirty_page':
include/trace/events/writeback.h:69:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
    mapping ? dev_name(inode_to_bdi(mapping->host)->dev) : "(unknown)", 32);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:56:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_dirty_page,
 ^~~~~~~~~~~
include/trace/events/writeback.h:68:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'trace_event_raw_event_writeback_dirty_inode_template':
include/trace/events/writeback.h:99:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
    bdi->dev ? dev_name(bdi->dev) : "(unknown)", 32);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:95:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'trace_event_raw_event_writeback_write_inode_template':
include/trace/events/writeback.h:179:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
    dev_name(inode_to_bdi(inode)->dev), 32);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:178:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'trace_event_raw_event_writeback_work_class':
include/trace/events/writeback.h:223:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
    wb->bdi->dev ? dev_name(wb->bdi->dev) : "(unknown)", 32);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:222:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'trace_event_raw_event_writeback_class':
include/trace/events/writeback.h:277:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:276:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'trace_event_raw_event_writeback_bdi_register':
include/trace/events/writeback.h:299:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name, dev_name(bdi->dev), 32);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:292:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_bdi_register,
 ^~~~~~~~~~~
include/trace/events/writeback.h:298:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'trace_event_raw_event_wbc_class':
include/trace/events/writeback.h:324:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name, dev_name(bdi->dev), 32);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:323:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'trace_event_raw_event_writeback_queue_io':
include/trace/events/writeback.h:375:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:360:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_queue_io,
 ^~~~~~~~~~~
include/trace/events/writeback.h:373:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'trace_event_raw_event_writeback_sb_inodes_requeue':
include/trace/events/writeback.h:586:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
           dev_name(inode_to_bdi(inode)->dev), 32);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:572:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_sb_inodes_requeue,
 ^~~~~~~~~~~
include/trace/events/writeback.h:585:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h:586:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
           dev_name(inode_to_bdi(inode)->dev), 32);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:572:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_sb_inodes_requeue,
 ^~~~~~~~~~~
include/trace/events/writeback.h:585:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h:586:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
           dev_name(inode_to_bdi(inode)->dev), 32);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:572:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_sb_inodes_requeue,
 ^~~~~~~~~~~
include/trace/events/writeback.h:585:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h:586:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
           dev_name(inode_to_bdi(inode)->dev), 32);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
         PARAMS(assign),         \
         ^~~~~~
include/trace/events/writeback.h:572:1: note: in expansion of macro 'TRACE_EVENT'
 TRACE_EVENT(writeback_sb_inodes_requeue,
 ^~~~~~~~~~~
include/trace/events/writeback.h:585:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
include/trace/events/writeback.h: In function 'trace_event_raw_event_writeback_single_inode_template':
include/trace/events/writeback.h:660:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
   strncpy(__entry->name,
   ^~~~~~~~~~~~~~~~~~~~~~
    dev_name(inode_to_bdi(inode)->dev), 32);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/trace/trace_events.h:720:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }       \
    ^~~~~~
include/trace/events/writeback.h:659:2: note: in expansion of macro 'TP_fast_assign'
  TP_fast_assign(
  ^~~~~~~~~~~~~~
In function 'i40e_ptp_create_clock',
    inlined from 'i40e_ptp_init' at drivers/net/ethernet/intel/i40e/i40e_ptp.c:755:8:
drivers/net/ethernet/intel/i40e/i40e_ptp.c:697:2: warning: 'strncpy' specified bound 16 equals destination size [-Wstringop-truncation]
  strncpy(pf->ptp_caps.name, i40e_driver_name, sizeof(pf->ptp_caps.name));
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/qla2xxx/qla_mr.c: In function 'qlafx00_fx_disc':
drivers/scsi/qla2xxx/qla_mr.c:1882:4: warning: 'strncpy' output may be truncated copying 64 bytes from a string of length 64 [-Wstringop-truncation]
    strncpy(phost_info->nodename,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        p_sysid->nodename, NODENAME_LENGTH);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/qla2xxx/qla_mr.c:1886:4: warning: 'strncpy' output may be truncated copying 64 bytes from a string of length 64 [-Wstringop-truncation]
    strncpy(phost_info->release,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
        p_sysid->release, RELEASE_LENGTH);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/qla2xxx/qla_mr.c:1888:4: warning: 'strncpy' output may be truncated copying 64 bytes from a string of length 64 [-Wstringop-truncation]
    strncpy(phost_info->version,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
        p_sysid->version, VERSION_LENGTH);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/qla2xxx/qla_mr.c:1890:4: warning: 'strncpy' output may be truncated copying 64 bytes from a string of length 64 [-Wstringop-truncation]
    strncpy(phost_info->machine,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
        p_sysid->machine, MACHINE_LENGTH);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/qla2xxx/qla_mr.c:1892:4: warning: 'strncpy' output may be truncated copying 64 bytes from a string of length 64 [-Wstringop-truncation]
    strncpy(phost_info->domainname,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        p_sysid->domainname, DOMNAME_LENGTH);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'ibmvfc_gather_partition_info',
    inlined from 'ibmvfc_npiv_login' at drivers/scsi/ibmvscsi/ibmvfc.c:4098:2:
drivers/scsi/ibmvscsi/ibmvfc.c:1156:3: warning: 'strncpy' specified bound 97 equals destination size [-Wstringop-truncation]
   strncpy(vhost->partition_name, name, sizeof(vhost->partition_name));
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'ibmvfc_set_login_info',
    inlined from 'ibmvfc_npiv_login' at drivers/scsi/ibmvscsi/ibmvfc.c:4099:2:
drivers/scsi/ibmvscsi/ibmvfc.c:1194:2: warning: 'strncpy' specified bound 256 equals destination size [-Wstringop-truncation]
  strncpy(login_info->device_name,
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   dev_name(&vhost->host->shost_gendev), IBMVFC_MAX_NAME);
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/ibmvscsi/ibmvfc.c:1199:2: warning: 'strncpy' specified bound 256 equals destination size [-Wstringop-truncation]
  strncpy(login_info->drc_name, location, IBMVFC_MAX_NAME);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Presumably caused by my update to gcc 8.2.0.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build warnings from Linus' tree
  2010-10-28  0:27 Stephen Rothwell
@ 2010-10-28  3:04 ` Mark Brown
  0 siblings, 0 replies; 16+ messages in thread
From: Mark Brown @ 2010-10-28  3:04 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, linux-next, linux-kernel, Sweta Bhatt,
	Roland Dreier, Davide Rizzo, Michael Hennerich, Mike Frysinger,
	Richard Purdie, Joseph Chan

On Thu, Oct 28, 2010 at 11:27:39AM +1100, Stephen Rothwell wrote:

> While building Linus' tree, today's linux-next build (x86_64 allmodconfig)
> produced these warnings:

> sound/soc/soc-core.c: In function 'pmdown_time_set':
> sound/soc/soc-core.c:169: warning: ignoring return value of 'strict_strtol', declared with attribute warn_unused_result

Just cooked up a patch for this but due to timezone/travel on the part
of both myself and Liam it may not make get reviewed and into -next for
a little while.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: build warnings from Linus' tree
@ 2010-10-28  0:27 Stephen Rothwell
  2010-10-28  3:04 ` Mark Brown
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Rothwell @ 2010-10-28  0:27 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Mark Brown, Sweta Bhatt, Roland Dreier,
	Davide Rizzo, Michael Hennerich, Mike Frysinger, Richard Purdie,
	Joseph Chan

[-- Attachment #1: Type: text/plain, Size: 3310 bytes --]

Hi all,

While building Linus' tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

sound/soc/soc-core.c: In function 'pmdown_time_set':
sound/soc/soc-core.c:169: warning: ignoring return value of 'strict_strtol', declared with attribute warn_unused_result
drivers/infiniband/hw/nes/nes.c: In function 'nes_store_wqm_quanta':
drivers/infiniband/hw/nes/nes.c:1115: warning: ignoring return value of 'strict_strtoul', declared with attribute warn_unused_result
drivers/hwmon/lm95241.c: In function 'set_interval':
drivers/hwmon/lm95241.c:132: warning: ignoring return value of 'strict_strtol', declared with attribute warn_unused_result
drivers/hwmon/lm95241.c: In function 'set_type1':
drivers/hwmon/lm95241.c:219: warning: ignoring return value of 'strict_strtol', declared with attribute warn_unused_result
drivers/hwmon/lm95241.c: In function 'set_type2':
drivers/hwmon/lm95241.c:220: warning: ignoring return value of 'strict_strtol', declared with attribute warn_unused_result
drivers/hwmon/lm95241.c: In function 'set_min1':
drivers/hwmon/lm95241.c:248: warning: ignoring return value of 'strict_strtol', declared with attribute warn_unused_result
drivers/hwmon/lm95241.c: In function 'set_min2':
drivers/hwmon/lm95241.c:249: warning: ignoring return value of 'strict_strtol', declared with attribute warn_unused_result
drivers/hwmon/lm95241.c: In function 'set_max1':
drivers/hwmon/lm95241.c:277: warning: ignoring return value of 'strict_strtol', declared with attribute warn_unused_result
drivers/hwmon/lm95241.c: In function 'set_max2':
drivers/hwmon/lm95241.c:278: warning: ignoring return value of 'strict_strtol', declared with attribute warn_unused_result
drivers/video/backlight/adp8860_bl.c: In function 'adp8860_bl_l1_daylight_max_store':
drivers/video/backlight/adp8860_bl.c:506: warning: ignoring return value of 'strict_strtoul', declared with attribute warn_unused_result
drivers/video/via/viafbdev.c: In function 'viafb_dvp0_proc_write':
drivers/video/via/viafbdev.c:1117: warning: ignoring return value of 'strict_strtoul, ', declared with attribute warn_unused_result
drivers/video/via/viafbdev.c: In function 'viafb_dvp1_proc_write':
drivers/video/via/viafbdev.c:1187: warning: ignoring return value of 'strict_strtoul', declared with attribute warn_unused_result
drivers/video/via/viafbdev.c: In function 'viafb_dfph_proc_write':
drivers/video/via/viafbdev.c:1245: warning: ignoring return value of 'strict_strtoul', declared with attribute warn_unused_result
drivers/video/via/viafbdev.c: In function 'viafb_dfpl_proc_write':
drivers/video/via/viafbdev.c:1284: warning: ignoring return value of 'strict_strtoul', declared with attribute warn_unused_result
drivers/video/via/viafbdev.c: In function 'viafb_vt1636_proc_write':
drivers/video/via/viafbdev.c:1353: warning: ignoring return value of 'strict_strtoul', declared with attribute warn_unused_result
drivers/video/via/viafbdev.c:1390: warning: ignoring return value of 'strict_strtoul', declared with attribute warn_unused_result

Exposed by commit a55621f15bc61826969a29e111ba131a55ef45de
("include/linux/kernel.h: add __must_check to strict_strto*()").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2019-08-29 21:59 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-11 22:14 linux-next: build warnings from Linus' tree Stephen Rothwell
2018-11-14  4:54 ` Joel Stanley
2018-11-14 10:20   ` Michael Ellerman
2018-11-18 11:22     ` Alan Modra
2018-12-03 23:24       ` Joel Stanley
  -- strict thread matches above, loose matches on Subject: below --
2019-08-29 21:59 Stephen Rothwell
2018-08-19 22:13 Stephen Rothwell
2018-08-19 22:16 ` Stephen Rothwell
2018-08-19 22:40   ` Stephen Rothwell
2018-08-19 23:21 ` Linus Torvalds
2018-08-20  1:33   ` Adam Borowski
2018-08-20  2:53     ` Theodore Y. Ts'o
2018-08-20  0:02 ` Theodore Y. Ts'o
2018-08-20 17:47   ` Miguel Ojeda
2010-10-28  0:27 Stephen Rothwell
2010-10-28  3:04 ` Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).