On do, 2016-05-05 at 22:44 -0700, Andrew Morton wrote:
> From: Arnd Bergmann <arnd@xxxxxxxx>
> Subject: byteswap: try to avoid __builtin_constant_p gcc bug
>
> 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 ("include/linux/unaligned: force inlining of
> byteswap operations") and ef3fb2422ffe ("scsi: fc: use get/put_unaligned64
> for wwn access")) that each try to sidestep distinct problems with gcc
> behavior (code growth and increased stack usage). Unfortunately after
> both have been applied, a more serious 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.
>
> [arnd@xxxxxxxx: fix older gcc warnings]
> (http://lkml.kernel.org/r/12243652.bxSxEgjgfk@wuerfel)
> 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")
> Link: http://lkml.kernel.org/r/1780465.XdtPJpi8Tt@wuerfel
> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> Reviewed-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> Tested-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx> # on gcc-5.3
> Tested-by: Quinn Tran <quinn.tran@xxxxxxxxxx>
> Cc: Martin Jambor <mjambor@xxxxxxx>
> Cc: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
> Cc: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
> Cc: Denys Vlasenko <dvlasenk@xxxxxxxxxx>
> Cc: Thomas Graf <tgraf@xxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: David Rientjes <rientjes@xxxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: Himanshu Madhani <himanshu.madhani@xxxxxxxxxx>
> Cc: Jan Hubicka <hubicka@xxxxxx>
> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
This became commit 7322dd755e7d ("byteswap: try to avoid
__builtin_constant_p gcc bug"). That commit was included in v4.6-rc7.
Ever since that rc I see this warning when building for x86_64:
net/netfilter/ipvs/ip_vs_sync.c: In function ‘ip_vs_proc_sync_conn’:
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.init_seq’ may be used uninitialized in this function [-Wmaybe-uninitialized]
struct ip_vs_sync_conn_options opt;
^
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.previous_delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void *)&opt+12).init_seq’ may be used uninitialized in this function [-Wmaybe-uninitialized]
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void *)&opt+12).delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void *)&opt+12).previous_delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
(It doesn't show up when building for 32 bits x86. Perhaps there's an
int/long mismatch somewhere in the related code.)
Anyone else seeing this?
It looks like a false positive. I can make it disappear by making sure
ip_vs_proc_seqopt() isn't inlined. But that's not something I dare to
put into a patch for a false positive. Anyone sitting on a better fix?
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
