Hi Ingo,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: e1ef035d272ef4dbfdda98e58699698305138856
commit: ffb61c6346d0f02b2a03377a3edac838c1f09b45 Revert "x86/bug: Macrofy the BUG table section handling, to work around GCC inlining bugs"
date: 13 days ago
config: i386-randconfig-sb0-01012038 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout ffb61c6346d0f02b2a03377a3edac838c1f09b45
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from arch/x86/include/asm/atomic.h:8:0,
from include/linux/atomic.h:7,
from include/linux/jump_label.h:250,
from include/linux/static_key.h:1,
from arch/x86/include/asm/nospec-branch.h:6,
from arch/x86/include/asm/paravirt_types.h:46,
from arch/x86/include/asm/ptrace.h:94,
from arch/x86/include/asm/math_emu.h:5,
from arch/x86/include/asm/processor.h:12,
from arch/x86/include/asm/cpufeature.h:5,
from arch/x86/include/asm/thread_info.h:53,
from include/linux/thread_info.h:38,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:81,
from include/linux/spinlock.h:51,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:6,
from include/linux/mm.h:10,
from mm/slub.c:13:
mm/slub.c: In function '__slab_free':
>> arch/x86/include/asm/cmpxchg.h:245:2: error: 'asm' operand has impossible constraints
asm volatile(pfx "cmpxchg%c5b %1" \
^
arch/x86/include/asm/cmpxchg.h:256:2: note: in expansion of macro '__cmpxchg_double'
__cmpxchg_double(LOCK_PREFIX, p1, p2, o1, o2, n1, n2)
^
include/asm-generic/atomic-instrumented.h:457:2: note: in expansion of macro 'arch_cmpxchg_double'
arch_cmpxchg_double(__ai_p1, (p2), (o1), (o2), (n1), (n2)); \
^
mm/slub.c:403:7: note: in expansion of macro 'cmpxchg_double'
if (cmpxchg_double(&page->freelist, &page->counters,
^
vim +/asm +245 arch/x86/include/asm/cmpxchg.h
3d94ae0c Jeremy Fitzhardinge 2011-09-28 235
cdcd6298 Jan Beulich 2012-01-02 236 #define __cmpxchg_double(pfx, p1, p2, o1, o2, n1, n2) \
cdcd6298 Jan Beulich 2012-01-02 237 ({ \
cdcd6298 Jan Beulich 2012-01-02 238 bool __ret; \
cdcd6298 Jan Beulich 2012-01-02 239 __typeof__(*(p1)) __old1 = (o1), __new1 = (n1); \
cdcd6298 Jan Beulich 2012-01-02 240 __typeof__(*(p2)) __old2 = (o2), __new2 = (n2); \
cdcd6298 Jan Beulich 2012-01-02 241 BUILD_BUG_ON(sizeof(*(p1)) != sizeof(long)); \
cdcd6298 Jan Beulich 2012-01-02 242 BUILD_BUG_ON(sizeof(*(p2)) != sizeof(long)); \
cdcd6298 Jan Beulich 2012-01-02 243 VM_BUG_ON((unsigned long)(p1) % (2 * sizeof(long))); \
cdcd6298 Jan Beulich 2012-01-02 244 VM_BUG_ON((unsigned long)((p1) + 1) != (unsigned long)(p2)); \
c808c09b Uros Bizjak 2018-09-28 @245 asm volatile(pfx "cmpxchg%c5b %1" \
c808c09b Uros Bizjak 2018-09-28 246 CC_SET(e) \
c808c09b Uros Bizjak 2018-09-28 247 : CC_OUT(e) (__ret), \
c808c09b Uros Bizjak 2018-09-28 248 "+m" (*(p1)), "+m" (*(p2)), \
c808c09b Uros Bizjak 2018-09-28 249 "+a" (__old1), "+d" (__old2) \
c808c09b Uros Bizjak 2018-09-28 250 : "i" (2 * sizeof(long)), \
cdcd6298 Jan Beulich 2012-01-02 251 "b" (__new1), "c" (__new2)); \
cdcd6298 Jan Beulich 2012-01-02 252 __ret; \
cdcd6298 Jan Beulich 2012-01-02 253 })
cdcd6298 Jan Beulich 2012-01-02 254
:::::: The code at line 245 was first introduced by commit
:::::: c808c09b527cd60d9a0d53799935f75e2452174d x86/asm: Use CC_SET()/CC_OUT() in __cmpxchg_double()
:::::: TO: Uros Bizjak <[email protected]>
:::::: CC: Borislav Petkov <[email protected]>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On Tue, Jan 22, 2019 at 12:53:11PM +0800, kbuild test robot wrote:
> Hi Ingo,
>
> FYI, the error/warning still remains.
Guys,
we already discussed this:
https://lists.01.org/pipermail/kbuild-all/2018-December/056206.html
but you keep reporting it.
You need to fix your reported issues tracking or otherwise no one will
bother anymore.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Tue, Jan 22, 2019 at 11:08:34AM +0100, Borislav Petkov wrote:
> On Tue, Jan 22, 2019 at 12:53:11PM +0800, kbuild test robot wrote:
> > Hi Ingo,
> >
> > FYI, the error/warning still remains.
>
> Guys,
>
> we already discussed this:
>
> https://lists.01.org/pipermail/kbuild-all/2018-December/056206.html
>
> but you keep reporting it.
>
> You need to fix your reported issues tracking or otherwise no one will
> bother anymore.
thanks for the feedback, we will blacklist this. So may i understand based on
the thread at https://lists.01.org/pipermail/kbuild-all/2018-December/056225.html,
this is gcc-4.9 problem?
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
> _______________________________________________
> kbuild-all mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/kbuild-all
On Tue, Jan 22, 2019 at 07:13:59PM +0800, Philip Li wrote:
> thanks for the feedback, we will blacklist this. So may i understand based on
> the thread at https://lists.01.org/pipermail/kbuild-all/2018-December/056225.html,
> this is gcc-4.9 problem?
AFAICT, this triggers only on gcc-4.9, 32-bit build. Or do you have
other configurations which trigger it?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On 1/22/19 7:55 PM, Borislav Petkov wrote:
> On Tue, Jan 22, 2019 at 07:13:59PM +0800, Philip Li wrote:
>> thanks for the feedback, we will blacklist this. So may i understand based on
>> the thread at https://lists.01.org/pipermail/kbuild-all/2018-December/056225.html,
>> this is gcc-4.9 problem?
> AFAICT, this triggers only on gcc-4.9, 32-bit build. Or do you have
> other configurations which trigger it?
Hi Boris,
we have added it to the blacklist, and there's no other configuration
found in the past reports.
Best Regards,
Rong Chen
On Wed, Jan 30, 2019 at 11:28:40AM +0800, Rong Chen wrote:
> we have added it to the blacklist, and there's no other configuration found
> in the past reports.
Thanks.
We'll dig it out again if it becomes more prominent.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.