[v2] byteswap: try to avoid __builtin_constant_p gcc bug

Message ID 1780465.XdtPJpi8Tt@wuerfel
State New
Headers show

Commit Message

Arnd Bergmann May 2, 2016, 9:48 p.m.
This is another attempt to avoid a regression in wwn_to_u64() after
that started using get_unaligned_be64(), which in turn ran into a
bug on gcc-4.9 through 6.1.

The regression got introduced due to the combination of two
separate workarounds (e3bde9568d99 and ef3fb2422ffe) that each
try to sidestep distinct problems with gcc behavior (code growth
and increased stack usage). Unfortunately after both have been
applied, a more series gcc bug has been uncovered, leading to
incorrect object code that discards part of a function and
causes undefined behavior.

As part of this problem is how __builtin_constant_p gets evaluated
on an argument passed by reference into an inline function, this
avoids the use of __builtin_constant_p() for all architectures
that set CONFIG_ARCH_USE_BUILTIN_BSWAP. Most architectures do not
set ARCH_SUPPORTS_OPTIMIZED_INLINING, which means they probably
do not suffer from the problem in the qla2xxx driver, but they
might still run into it elsewhere.

Both of the original workarounds were only merged in the 4.6 kernel,
and the bug that is fixed by this patch should only appear if
both are there, so we probably don't need to backport the fix.
On the other hand, it works by simplifying the code path and
should not have any negative effects.

Link: https://lkml.org/lkml/headers/2016/4/12/1103
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
Fixes: e3bde9568d99 ("include/linux/unaligned: force inlining of byteswap operations")
Fixes: ef3fb2422ffe ("scsi: fc: use get/put_unaligned64 for wwn access")
Tested-by: Josh Poimboeuf <jpoimboe@redhat.com> # on gcc-5.3

Tested-by: Quinn Tran <quinn.tran@qlogic.com>

Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

----
This contains the extra cast to fix up 64-bit builds, and has
an expanded changelog, compared to the original version.

  * __swahw32 - return a word-swapped 32-bit value

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Arnd Bergmann May 2, 2016, 11:10 p.m. | #1
On Monday 02 May 2016 16:02:18 Andrew Morton wrote:
> On Mon, 02 May 2016 23:48:19 +0200 Arnd Bergmann <arnd@arndb.de> wrote:

> 

> > This is another attempt to avoid a regression in wwn_to_u64() after

> > that started using get_unaligned_be64(), which in turn ran into a

> > bug on gcc-4.9 through 6.1.

> 

> I'm still getting a couple screenfuls of things like

> 

> net/tipc/name_distr.c: In function 'tipc_named_process_backlog':

> net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'unsigned int'

> net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'unsigned int'

> net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'unsigned int'

> net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 7 has type 'unsigned int'


I've built a few thousand kernels (arm32 with gcc-6.1) with the patch applied,
but didn't see this one. What target architecture and compiler version produced
this? Does it go away if you add a (__u32) cast? I don't even know what the
warning is trying to tell me.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andrew Morton May 2, 2016, 11:32 p.m. | #2
On Tue, 03 May 2016 01:10:16 +0200 Arnd Bergmann <arnd@arndb.de> wrote:

> On Monday 02 May 2016 16:02:18 Andrew Morton wrote:

> > On Mon, 02 May 2016 23:48:19 +0200 Arnd Bergmann <arnd@arndb.de> wrote:

> > 

> > > This is another attempt to avoid a regression in wwn_to_u64() after

> > > that started using get_unaligned_be64(), which in turn ran into a

> > > bug on gcc-4.9 through 6.1.

> > 

> > I'm still getting a couple screenfuls of things like

> > 

> > net/tipc/name_distr.c: In function 'tipc_named_process_backlog':

> > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'unsigned int'

> > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'unsigned int'

> > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'unsigned int'

> > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 7 has type 'unsigned int'

> 

> I've built a few thousand kernels (arm32 with gcc-6.1) with the patch applied,

> but didn't see this one. What target architecture and compiler version produced

> this? Does it go away if you add a (__u32) cast? I don't even know what the

> warning is trying to tell me.


heh, I didn't actually read it.

Hopefully we can write this off as a gcc-4.4.4 glitch. 4.8.4 is OK.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tomas Winkler June 21, 2016, 9:02 a.m. | #3
On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:

>> On Tue, 03 May 2016 01:10:16 +0200 Arnd Bergmann <arnd@arndb.de> wrote:

>>

>> > On Monday 02 May 2016 16:02:18 Andrew Morton wrote:

>> > > On Mon, 02 May 2016 23:48:19 +0200 Arnd Bergmann <arnd@arndb.de> wrote:

>> > >

>> > > > This is another attempt to avoid a regression in wwn_to_u64() after

>> > > > that started using get_unaligned_be64(), which in turn ran into a

>> > > > bug on gcc-4.9 through 6.1.

>> > >

>> > > I'm still getting a couple screenfuls of things like

>> > >

>> > > net/tipc/name_distr.c: In function 'tipc_named_process_backlog':

>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'unsigned int'

>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'unsigned int'

>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'unsigned int'

>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 7 has type 'unsigned int'

>> >

>> > I've built a few thousand kernels (arm32 with gcc-6.1) with the patch applied,

>> > but didn't see this one. What target architecture and compiler version produced

>> > this? Does it go away if you add a (__u32) cast? I don't even know what the

>> > warning is trying to tell me.

>>

>> heh, I didn't actually read it.

>>

>> Hopefully we can write this off as a gcc-4.4.4 glitch. 4.8.4 is OK.

>

> Ah, old compiler. I've tried gcc-4.3 now on ARM, and I don't get this warning

> (just a lot "may be used uninitialized"), but unlike gcc-4.4, my version doesn't

> actually get into the code path I have changed because __builtin_bswap32 was only

> introduced with 4.4.

>

> I don't have gcc-4.4 and 4.5 here, but the warning does show up with 4.6, 4.7

> and 4.8:

>

> drivers/soc/sunxi/sunxi_sram.c: In function ‘sunxi_sram_show’:

> drivers/soc/sunxi/sunxi_sram.c:103:7: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘unsigned int’ [-Wformat=]

>

> 4.8 is probably still common enough that we should try to address this.

> This change addresses the problem for me with ARM gcc-4.8, but adding

> two more type casts. This also makes the 16/32/64 bit swaps all

> look the same. I would expect this to also have the same effect on 4.4.

>

> Please fold into the previous patch.

>

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

>

> diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h

> index d737804af181..8f3a8f606fd9 100644

> --- a/include/uapi/linux/swab.h

> +++ b/include/uapi/linux/swab.h

> @@ -97,7 +97,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)

>   * @x: value to byteswap

>   */

>  #ifdef __HAVE_BUILTIN_BSWAP16__

> -#define __swab16(x) __builtin_bswap16((__u16)(x))

> +#define __swab16(x) (__u16)__builtin_bswap16((__u16)(x))

>  #else

>  #define __swab16(x)                            \

>         (__builtin_constant_p((__u16)(x)) ?     \

> @@ -110,7 +110,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)

>   * @x: value to byteswap

>   */

>  #ifdef __HAVE_BUILTIN_BSWAP32__

> -#define __swab32(x) __builtin_bswap32((__u32)(x))

> +#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))

>  #else

>  #define __swab32(x)                            \

>         (__builtin_constant_p((__u32)(x)) ?     \


>


I wonder if this doesn't break switch statement that requires a
constant expression, there few cases like this over the kernel.

switch(val) {
case cpu_to_le32(IXGBE_RXDADV_STAT_FCSTAT_FCPRSP):

http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c#L458


Thanks
Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tomas Winkler June 22, 2016, 8:24 a.m. | #4
On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler <tomasw@gmail.com> wrote:
> On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:

>> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:

>>> On Tue, 03 May 2016 01:10:16 +0200 Arnd Bergmann <arnd@arndb.de> wrote:

>>>

>>> > On Monday 02 May 2016 16:02:18 Andrew Morton wrote:

>>> > > On Mon, 02 May 2016 23:48:19 +0200 Arnd Bergmann <arnd@arndb.de> wrote:

>>> > >

>>> > > > This is another attempt to avoid a regression in wwn_to_u64() after

>>> > > > that started using get_unaligned_be64(), which in turn ran into a

>>> > > > bug on gcc-4.9 through 6.1.

>>> > >

>>> > > I'm still getting a couple screenfuls of things like

>>> > >

>>> > > net/tipc/name_distr.c: In function 'tipc_named_process_backlog':

>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'unsigned int'

>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'unsigned int'

>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'unsigned int'

>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 7 has type 'unsigned int'

>>> >

>>> > I've built a few thousand kernels (arm32 with gcc-6.1) with the patch applied,

>>> > but didn't see this one. What target architecture and compiler version produced

>>> > this? Does it go away if you add a (__u32) cast? I don't even know what the

>>> > warning is trying to tell me.

>>>

>>> heh, I didn't actually read it.

>>>

>>> Hopefully we can write this off as a gcc-4.4.4 glitch. 4.8.4 is OK.

>>

>> Ah, old compiler. I've tried gcc-4.3 now on ARM, and I don't get this warning

>> (just a lot "may be used uninitialized"), but unlike gcc-4.4, my version doesn't

>> actually get into the code path I have changed because __builtin_bswap32 was only

>> introduced with 4.4.

>>

>> I don't have gcc-4.4 and 4.5 here, but the warning does show up with 4.6, 4.7

>> and 4.8:

>>

>> drivers/soc/sunxi/sunxi_sram.c: In function ‘sunxi_sram_show’:

>> drivers/soc/sunxi/sunxi_sram.c:103:7: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘unsigned int’ [-Wformat=]

>>

>> 4.8 is probably still common enough that we should try to address this.

>> This change addresses the problem for me with ARM gcc-4.8, but adding

>> two more type casts. This also makes the 16/32/64 bit swaps all

>> look the same. I would expect this to also have the same effect on 4.4.

>>

>> Please fold into the previous patch.

>>

>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

>>

>> diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h

>> index d737804af181..8f3a8f606fd9 100644

>> --- a/include/uapi/linux/swab.h

>> +++ b/include/uapi/linux/swab.h

>> @@ -97,7 +97,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)

>>   * @x: value to byteswap

>>   */

>>  #ifdef __HAVE_BUILTIN_BSWAP16__

>> -#define __swab16(x) __builtin_bswap16((__u16)(x))

>> +#define __swab16(x) (__u16)__builtin_bswap16((__u16)(x))

>>  #else

>>  #define __swab16(x)                            \

>>         (__builtin_constant_p((__u16)(x)) ?     \

>> @@ -110,7 +110,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)

>>   * @x: value to byteswap

>>   */

>>  #ifdef __HAVE_BUILTIN_BSWAP32__

>> -#define __swab32(x) __builtin_bswap32((__u32)(x))

>> +#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))

>>  #else

>>  #define __swab32(x)                            \

>>         (__builtin_constant_p((__u32)(x)) ?     \

>

>>

>

> I wonder if this doesn't break switch statement that requires a

> constant expression, there few cases like this over the kernel.

>

> switch(val) {

> case cpu_to_le32(IXGBE_RXDADV_STAT_FCSTAT_FCPRSP):

>

> http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c#L458

>


I'm asking because sparse and checkpatch doesn't agree on that ping
sparse issues
'error: bad constant expression'
When changing to __constant_cpu_to_le32 sparse is happy but
checkpatch.ps is complaining
__constant_cpu_to_le32 should be cpu_to_le32



 Thanks
 Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann June 23, 2016, 9:29 a.m. | #5
On Thursday, June 23, 2016 9:27:30 AM CEST Tomas Winkler wrote:
> On Wed, Jun 22, 2016 at 3:25 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> > On Wednesday, June 22, 2016 2:44:21 PM CEST Tomas Winkler wrote:

> >> >

> >> > There are more than 20 files that have the statement: case cpu_to_...

> >> > Sparse complains about: case __builtin_bswap, not about __builtin_constant_p.

> >>

> >> There is even much more in the header files used in  initializers,

> >> which also require constants.  I wonder if __builtin_bswap produces

> >> constant expression correctly under gcc?

> >

> > In gcc-4.8 or later yes. gcc-4.6/4.7 on powerpc was a special case that we

> > have worked around now, as the 16-bit byteswap there was not a constant

> > expression, unlike the 32-bit and 64-bit ones.

> 

> Can you please give any references to that?


The patch description for the last change has a good explanation:

commit 8634de6d254462e6953b7dac772a1df4f44c8030
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Fri May 6 09:22:25 2016 -0500

    compiler-gcc: require gcc 4.8 for powerpc __builtin_bswap16()
    
    gcc support for __builtin_bswap16() was supposedly added for powerpc in
    gcc 4.6, and was then later added for other architectures in gcc 4.8.
    
    However, Stephen Rothwell reported that attempting to use it on powerpc
    in gcc 4.6 fails with:
    
      lib/vsprintf.c:160:2: error: initializer element is not constant
      lib/vsprintf.c:160:2: error: (near initialization for 'decpair[0]')
      lib/vsprintf.c:160:2: error: initializer element is not constant
      lib/vsprintf.c:160:2: error: (near initialization for 'decpair[1]')
      ...
    
    I'm not entirely sure what those errors mean, but I don't see them on
    gcc 4.8.  So let's consider gcc 4.8 to be the official starting point
    for __builtin_bswap16().
    
    Arnd Bergmann adds:
     "I found the commit in gcc-4.8 that replaced the powerpc-specific
      implementation of __builtin_bswap16 with an architecture-independent
      one.  Apparently the powerpc version (gcc-4.6 and 4.7) just mapped to
      the lhbrx/sthbrx instructions, so it ended up not being a constant,
      though the intent of the patch was mainly to add support for the
      builtin to x86:
    
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52624
    
      has the patch that went into gcc-4.8 and more information."
    
    Fixes: 7322dd755e7d ("byteswap: try to avoid __builtin_constant_p gcc bug")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>

    Acked-by: Arnd Bergmann <arnd@arndb.de>

    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


 include/linux/compiler-gcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


> Just to make sure we are on the same line , the  bottom line is that

> sparse has to be adjusted.


Yes, that sounds right. I don't know if sparse actually tracks the
value of the constant, or if it's good enough for sparse to know that
a constant input to __builtin_bswap results in a constant output.
If that is the case, we could just #define __builtin_bswap32(x) (x)
in the kernel headers when building with sparse, and have it work
for older sparse versions too.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
index 3f10e5317b46..de56fd54428d 100644
--- a/include/uapi/linux/swab.h
+++ b/include/uapi/linux/swab.h
@@ -45,9 +45,7 @@ 
 
 static inline __attribute_const__ __u16 __fswab16(__u16 val)
 {
-#ifdef __HAVE_BUILTIN_BSWAP16__
-	return __builtin_bswap16(val);
-#elif defined (__arch_swab16)
+#if defined (__arch_swab16)
 	return __arch_swab16(val);
 #else
 	return ___constant_swab16(val);
@@ -56,9 +54,7 @@  static inline __attribute_const__ __u16 __fswab16(__u16 val)
 
 static inline __attribute_const__ __u32 __fswab32(__u32 val)
 {
-#ifdef __HAVE_BUILTIN_BSWAP32__
-	return __builtin_bswap32(val);
-#elif defined(__arch_swab32)
+#if defined(__arch_swab32)
 	return __arch_swab32(val);
 #else
 	return ___constant_swab32(val);
@@ -67,9 +63,7 @@  static inline __attribute_const__ __u32 __fswab32(__u32 val)
 
 static inline __attribute_const__ __u64 __fswab64(__u64 val)
 {
-#ifdef __HAVE_BUILTIN_BSWAP64__
-	return __builtin_bswap64(val);
-#elif defined (__arch_swab64)
+#if defined (__arch_swab64)
 	return __arch_swab64(val);
 #elif defined(__SWAB_64_THRU_32__)
 	__u32 h = val >> 32;
@@ -102,28 +96,40 @@  static inline __attribute_const__ __u32 __fswahb32(__u32 val)
  * __swab16 - return a byteswapped 16-bit value
  * @x: value to byteswap
  */
+#ifdef __HAVE_BUILTIN_BSWAP16__
+#define __swab16(x) __builtin_bswap16((__u16)(x))
+#else
 #define __swab16(x)				\
 	(__builtin_constant_p((__u16)(x)) ?	\
 	___constant_swab16(x) :			\
 	__fswab16(x))
+#endif
 
 /**

  * __swab32 - return a byteswapped 32-bit value
  * @x: value to byteswap
  */
+#ifdef __HAVE_BUILTIN_BSWAP32__
+#define __swab32(x) __builtin_bswap32((__u32)(x))
+#else
 #define __swab32(x)				\
 	(__builtin_constant_p((__u32)(x)) ?	\
 	___constant_swab32(x) :			\
 	__fswab32(x))
+#endif
 
 /**
  * __swab64 - return a byteswapped 64-bit value
  * @x: value to byteswap
  */
+#ifdef __HAVE_BUILTIN_BSWAP64__
+#define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
+#else
 #define __swab64(x)				\
 	(__builtin_constant_p((__u64)(x)) ?	\
 	___constant_swab64(x) :			\
 	__fswab64(x))
+#endif
 
 /**