While building Linux next 20211123 tag for sh with gcc-11
following warnings / errors noticed.
make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=sh
CROSS_COMPILE=sh4-linux-gnu- 'CC=sccache sh4-linux-gnu-gcc'
'HOSTCC=sccache gcc'
Generating include/generated/machtypes.h
<stdin>:1517:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1559:2: warning: #warning syscall futex_waitv not implemented [-Wcpp]
In file included from arch/sh/include/asm/hw_irq.h:6,
from include/linux/irq.h:594,
from include/asm-generic/hardirq.h:17,
from arch/sh/include/asm/hardirq.h:9,
from include/linux/hardirq.h:11,
from include/linux/interrupt.h:11,
from include/linux/serial_core.h:13,
from include/linux/serial_sci.h:6,
from arch/sh/kernel/cpu/sh4a/setup-shx3.c:10:
include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) /
sizeof (void)' does not compute the number of array elements
[-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 :
sizeof(a)/sizeof(*a)
| ^
include/linux/sh_intc.h:107:9: note: in expansion of macro '_INTC_ARRAY'
107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
| ^~~~~~~~~~~
include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs,
\
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-shx3.c:309:8: note: in expansion of
macro 'DECLARE_INTC_DESC'
309 | static DECLARE_INTC_DESC(intc_desc, "shx3", vectors, groups,
| ^~~~~~~~~~~~~~~~~
include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) /
sizeof (void)' does not compute the number of array elements
[-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 :
sizeof(a)/sizeof(*a)
| ^
include/linux/sh_intc.h:107:34: note: in expansion of macro '_INTC_ARRAY'
107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
| ^~~~~~~~~~~
include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs,
\
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-shx3.c:309:8: note: in expansion of
macro 'DECLARE_INTC_DESC'
309 | static DECLARE_INTC_DESC(intc_desc, "shx3", vectors, groups,
| ^~~~~~~~~~~~~~~~~
include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) /
sizeof (void)' does not compute the number of array elements
[-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 :
sizeof(a)/sizeof(*a)
| ^
include/linux/sh_intc.h:107:34: note: in expansion of macro '_INTC_ARRAY'
107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
| ^~~~~~~~~~~
include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs,
\
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-shx3.c:322:8: note: in expansion of
macro 'DECLARE_INTC_DESC'
322 | static DECLARE_INTC_DESC(intc_desc_irq, "shx3-irq", vectors_irq, groups,
| ^~~~~~~~~~~~~~~~~
include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) /
sizeof (void)' does not compute the number of array elements
[-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 :
sizeof(a)/sizeof(*a)
| ^
include/linux/sh_intc.h:107:9: note: in expansion of macro '_INTC_ARRAY'
107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
| ^~~~~~~~~~~
include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs,
\
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-shx3.c:337:8: note: in expansion of
macro 'DECLARE_INTC_DESC'
337 | static DECLARE_INTC_DESC(intc_desc_irl, "shx3-irl", vectors_irl, groups,
| ^~~~~~~~~~~~~~~~~
include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) /
sizeof (void)' does not compute the number of array elements
[-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 :
sizeof(a)/sizeof(*a)
| ^
include/linux/sh_intc.h:107:34: note: in expansion of macro '_INTC_ARRAY'
107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
| ^~~~~~~~~~~
include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs,
\
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-shx3.c:337:8: note: in expansion of
macro 'DECLARE_INTC_DESC'
337 | static DECLARE_INTC_DESC(intc_desc_irl, "shx3-irl", vectors_irl, groups,
| ^~~~~~~~~~~~~~~~~
kernel/locking/spinlock.c: In function '_raw_write_lock_nested':
kernel/locking/spinlock.c:306:9: error: implicit declaration of
function '__raw_write_lock_nested'; did you mean
'_raw_write_lock_nested'? [-Werror=implicit-function-declaration]
306 | __raw_write_lock_nested(lock, subclass);
| ^~~~~~~~~~~~~~~~~~~~~~~
| _raw_write_lock_nested
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:288: kernel/locking/spinlock.o] Error 1
make[3]: Target '__build' not remade because of errors.
make[2]: *** [scripts/Makefile.build:571: kernel/locking] Error 2
fs/ext4/readpage.c: In function 'ext4_mpage_readpages':
fs/ext4/readpage.c:413:1: warning: the frame size of 1140 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
413 | }
| ^
make[2]: Target '__build' not remade because of errors.
make[1]: *** [Makefile:1989: kernel] Error 2
fs/mpage.c: In function '__mpage_writepage':
fs/mpage.c:672:1: warning: the frame size of 1156 bytes is larger than
1024 bytes [-Wframe-larger-than=]
672 | }
| ^
fs/mpage.c: In function 'do_mpage_readpage':
fs/mpage.c:336:1: warning: the frame size of 1092 bytes is larger than
1024 bytes [-Wframe-larger-than=]
336 | }
| ^
make[1]: Target '__all' not remade because of errors.
make: *** [Makefile:226: __sub-make] Error 2
make: Target '__all' not remade because of errors.
Build config:
https://builds.tuxbuild.com/21J9mb3wsbGi616UxQbxP3DSTGv/config
Reported-by: Linux Kernel Functional Testing <[email protected]>
meta data:
-----------
git describe: next-20211123
git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git_sha: aacdecce8147c20b01f865b4e214bb8dbe8c4af1
git_short_log: aacdecce8147 (\"Add linux-next specific files for 20211123\")
target_arch: sh
toolchain: gcc-11
steps to reproduce:
tuxmake --runtime podman --target-arch sh --toolchain gcc-11 --kconfig
shx3_defconfig
https://builds.tuxbuild.com/21J9mb3wsbGi616UxQbxP3DSTGv/tuxmake_reproducer.sh
--
Linaro LKFT
https://lkft.linaro.org
On Tue, Nov 23, 2021 at 12:38 PM Naresh Kamboju
<[email protected]> wrote:
>
> While building Linux next 20211123 tag for sh with gcc-11
> following warnings / errors noticed.
Nothing in here looks like a recent regression from either the kernel
or gcc-11.
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=sh
> CROSS_COMPILE=sh4-linux-gnu- 'CC=sccache sh4-linux-gnu-gcc'
> 'HOSTCC=sccache gcc'
> Generating include/generated/machtypes.h
> <stdin>:1517:2: warning: #warning syscall clone3 not implemented [-Wcpp]
> <stdin>:1559:2: warning: #warning syscall futex_waitv not implemented [-Wcpp]
These happen with any compiler version, someone needs to write the correct
entry code for clone3 and hook up futex_waitv().
> include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements
These are old bugs, they show up in any kernel version with gcc-8 or higher.
> fs/mpage.c:336:1: warning: the frame size of 1092 bytes is larger than
I see these going back to gcc-6, it looks like this is caused by
CONFIG_PAGE_SIZE_64KB.
Arnd
Hi Arnd,
On Tue, Nov 23, 2021 at 2:50 PM Arnd Bergmann <[email protected]> wrote:
> On Tue, Nov 23, 2021 at 12:38 PM Naresh Kamboju
> <[email protected]> wrote:
> >
> > While building Linux next 20211123 tag for sh with gcc-11
> > following warnings / errors noticed.
>
> Nothing in here looks like a recent regression from either the kernel
> or gcc-11.
Except for:
kernel/locking/spinlock.c:306:9: error: implicit declaration of
function '__raw_write_lock_nested'; did you mean
'_raw_write_lock_nested'? [-Werror=implicit-function-declaration]
306 | __raw_write_lock_nested(lock, subclass);
| ^~~~~~~~~~~~~~~~~~~~~~~
| _raw_write_lock_nested
Which was also reported for other architectures:
https://lore.kernel.org/all/[email protected]/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 2021-11-23 15:48:34 [+0100], Geert Uytterhoeven wrote:
> Except for:
>
> kernel/locking/spinlock.c:306:9: error: implicit declaration of
> function '__raw_write_lock_nested'; did you mean
> '_raw_write_lock_nested'? [-Werror=implicit-function-declaration]
> 306 | __raw_write_lock_nested(lock, subclass);
> | ^~~~~~~~~~~~~~~~~~~~~~~
> | _raw_write_lock_nested
>
> Which was also reported for other architectures:
> https://lore.kernel.org/all/[email protected]/
I'm on it. Almost done.
> Gr{oetje,eeting}s,
>
> Geert
Sebastian
Andrew, please merge it into:
locking/rwlocks: introduce write_lock_nested
locking-rwlocks-introduce-write_lock_nested.patch
And if someone could test it, I get sh4 defconfig built with and without
lockdep. x86 seems still to build, too. So it can't be that bad.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
---
include/linux/rwlock_api_smp.h | 2 +-
kernel/locking/spinlock.c | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/linux/rwlock_api_smp.h b/include/linux/rwlock_api_smp.h
index f0c535ec4e654..60049df00532d 100644
--- a/include/linux/rwlock_api_smp.h
+++ b/include/linux/rwlock_api_smp.h
@@ -47,7 +47,7 @@ _raw_write_unlock_irqrestore(rwlock_t *lock, unsigned long flags)
#ifdef CONFIG_INLINE_WRITE_LOCK
#define _raw_write_lock(lock) __raw_write_lock(lock)
-#define _raw_write_lock_nested(lock, subclass) __raw_write_lock_nested(lock, subclass)
+#define _raw_write_lock_nested(lock) __raw_write_lock(lock)
#endif
#ifdef CONFIG_INLINE_READ_LOCK_BH
diff --git a/kernel/locking/spinlock.c b/kernel/locking/spinlock.c
index 996811efa6d6e..7f49baaa49793 100644
--- a/kernel/locking/spinlock.c
+++ b/kernel/locking/spinlock.c
@@ -301,6 +301,10 @@ void __lockfunc _raw_write_lock(rwlock_t *lock)
}
EXPORT_SYMBOL(_raw_write_lock);
+#ifndef CONFIG_DEBUG_LOCK_ALLOC
+#define __raw_write_lock_nested(lock, subclass) __raw_write_lock(((void)(subclass), (lock)))
+#endif
+
void __lockfunc _raw_write_lock_nested(rwlock_t *lock, int subclass)
{
__raw_write_lock_nested(lock, subclass);
--
2.34.0
Andrew, please merge it into:
locking/rwlocks: introduce write_lock_nested
locking-rwlocks-introduce-write_lock_nested.patch
And if someone could test it, I get sh4 defconfig built with and without
lockdep. x86 seems still to build, too. So it can't be that bad.
v1…v2: I noticed a typo in _raw_write_lock_nested() and decided that it
is no needed so now it is removed for !CONFIG_INLINE_WRITE_LOCK.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
---
include/linux/rwlock_api_smp.h | 1 -
kernel/locking/spinlock.c | 4 ++++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/rwlock_api_smp.h b/include/linux/rwlock_api_smp.h
index f0c535ec4e654..dceb0a59b6927 100644
--- a/include/linux/rwlock_api_smp.h
+++ b/include/linux/rwlock_api_smp.h
@@ -47,7 +47,6 @@ _raw_write_unlock_irqrestore(rwlock_t *lock, unsigned long flags)
#ifdef CONFIG_INLINE_WRITE_LOCK
#define _raw_write_lock(lock) __raw_write_lock(lock)
-#define _raw_write_lock_nested(lock, subclass) __raw_write_lock_nested(lock, subclass)
#endif
#ifdef CONFIG_INLINE_READ_LOCK_BH
diff --git a/kernel/locking/spinlock.c b/kernel/locking/spinlock.c
index 996811efa6d6e..7f49baaa49793 100644
--- a/kernel/locking/spinlock.c
+++ b/kernel/locking/spinlock.c
@@ -301,6 +301,10 @@ void __lockfunc _raw_write_lock(rwlock_t *lock)
}
EXPORT_SYMBOL(_raw_write_lock);
+#ifndef CONFIG_DEBUG_LOCK_ALLOC
+#define __raw_write_lock_nested(lock, subclass) __raw_write_lock(((void)(subclass), (lock)))
+#endif
+
void __lockfunc _raw_write_lock_nested(rwlock_t *lock, int subclass)
{
__raw_write_lock_nested(lock, subclass);
--
2.34.0
Hi all,
On Tue, 23 Nov 2021 18:01:34 +0100 Sebastian Andrzej Siewior <[email protected]> wrote:
>
> Andrew, please merge it into:
> locking/rwlocks: introduce write_lock_nested
> locking-rwlocks-introduce-write_lock_nested.patch
>
> And if someone could test it, I get sh4 defconfig built with and without
> lockdep. x86 seems still to build, too. So it can't be that bad.
>
> v1…v2: I noticed a typo in _raw_write_lock_nested() and decided that it
> is no needed so now it is removed for !CONFIG_INLINE_WRITE_LOCK.
>
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
> ---
> include/linux/rwlock_api_smp.h | 1 -
> kernel/locking/spinlock.c | 4 ++++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/rwlock_api_smp.h b/include/linux/rwlock_api_smp.h
> index f0c535ec4e654..dceb0a59b6927 100644
> --- a/include/linux/rwlock_api_smp.h
> +++ b/include/linux/rwlock_api_smp.h
> @@ -47,7 +47,6 @@ _raw_write_unlock_irqrestore(rwlock_t *lock, unsigned long flags)
>
> #ifdef CONFIG_INLINE_WRITE_LOCK
> #define _raw_write_lock(lock) __raw_write_lock(lock)
> -#define _raw_write_lock_nested(lock, subclass) __raw_write_lock_nested(lock, subclass)
> #endif
>
> #ifdef CONFIG_INLINE_READ_LOCK_BH
> diff --git a/kernel/locking/spinlock.c b/kernel/locking/spinlock.c
> index 996811efa6d6e..7f49baaa49793 100644
> --- a/kernel/locking/spinlock.c
> +++ b/kernel/locking/spinlock.c
> @@ -301,6 +301,10 @@ void __lockfunc _raw_write_lock(rwlock_t *lock)
> }
> EXPORT_SYMBOL(_raw_write_lock);
>
> +#ifndef CONFIG_DEBUG_LOCK_ALLOC
> +#define __raw_write_lock_nested(lock, subclass) __raw_write_lock(((void)(subclass), (lock)))
> +#endif
> +
> void __lockfunc _raw_write_lock_nested(rwlock_t *lock, int subclass)
> {
> __raw_write_lock_nested(lock, subclass);
> --
> 2.34.0
>
I have added that patch to iinux-next today.
--
Cheers,
Stephen Rothwell
On 11/23/21 5:38 AM, Naresh Kamboju wrote:
> While building Linux next 20211123 tag for sh with gcc-11
> following warnings / errors noticed.
>
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=sh
> CROSS_COMPILE=sh4-linux-gnu- 'CC=sccache sh4-linux-gnu-gcc'
> 'HOSTCC=sccache gcc'
> Generating include/generated/machtypes.h
> <stdin>:1517:2: warning: #warning syscall clone3 not implemented [-Wcpp]
> <stdin>:1559:2: warning: #warning syscall futex_waitv not implemented [-Wcpp]
Here's a fix for those first two:
From: Rob Landley <[email protected]>
Wire up clone3 and futex_waitv syscalls for arch/sh
Signed-off-by: Rob Landley <[email protected]>
---
arch/sh/kernel/syscalls/syscall.tbl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/sh/kernel/syscalls/syscall.tbl
b/arch/sh/kernel/syscalls/syscall.tbl
index 208f131659c5..65c3a94bff48 100644
--- a/arch/sh/kernel/syscalls/syscall.tbl
+++ b/arch/sh/kernel/syscalls/syscall.tbl
@@ -437,7 +437,7 @@
432 common fsmount sys_fsmount
433 common fspick sys_fspick
434 common pidfd_open sys_pidfd_open
-# 435 reserved for clone3
+435 common clone3 sys_clone3
436 common close_range sys_close_range
437 common openat2 sys_openat2
438 common pidfd_getfd sys_pidfd_getfd
@@ -451,3 +451,4 @@
446 common landlock_restrict_self sys_landlock_restrict_self
# 447 reserved for memfd_secret
448 common process_mrelease sys_process_mrelease
+449 common futex_waitv sys_futex_waitv
Rob
On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <[email protected]> wrote:
> On 11/23/21 5:38 AM, Naresh Kamboju wrote:
>
> diff --git a/arch/sh/kernel/syscalls/syscall.tbl
> b/arch/sh/kernel/syscalls/syscall.tbl
> index 208f131659c5..65c3a94bff48 100644
> --- a/arch/sh/kernel/syscalls/syscall.tbl
> +++ b/arch/sh/kernel/syscalls/syscall.tbl
> @@ -437,7 +437,7 @@
> 432 common fsmount sys_fsmount
> 433 common fspick sys_fspick
> 434 common pidfd_open sys_pidfd_open
> -# 435 reserved for clone3
> +435 common clone3 sys_clone3
> 436 common close_range sys_close_range
> 437 common openat2 sys_openat2
> 438 common pidfd_getfd sys_pidfd_getfd
Did you test clone3? This needs a custom wrapper on most architectures
to have sensible calling conventions. If sh doesn't need it, that should
be explained in the changelog text.
> @@ -451,3 +451,4 @@
> 446 common landlock_restrict_self sys_landlock_restrict_self
> # 447 reserved for memfd_secret
> 448 common process_mrelease sys_process_mrelease
> +449 common futex_waitv sys_futex_waitv
I don't know what's going on with this one, I don't actually see
a reason why it isn't already wired up on all architectures. If we add
this, it should probably be done for all architectures at once as a
bugfix, but it's possible that this is intentionally only used on
x86 and arm.
André, can you comment on this?
Arnd
On 11/23/21 7:19 AM, Arnd Bergmann wrote:
> On Tue, Nov 23, 2021 at 12:38 PM Naresh Kamboju
> <[email protected]> wrote:
>>
>> While building Linux next 20211123 tag for sh with gcc-11
>> following warnings / errors noticed.
>
> Nothing in here looks like a recent regression from either the kernel
> or gcc-11.
>
>> make --silent --keep-going --jobs=8
>> O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=sh
>> CROSS_COMPILE=sh4-linux-gnu- 'CC=sccache sh4-linux-gnu-gcc'
>> 'HOSTCC=sccache gcc'
>> Generating include/generated/machtypes.h
>> <stdin>:1517:2: warning: #warning syscall clone3 not implemented [-Wcpp]
>> <stdin>:1559:2: warning: #warning syscall futex_waitv not implemented [-Wcpp]
>
> These happen with any compiler version, someone needs to write the correct
> entry code for clone3 and hook up futex_waitv().
I did a naieve "add them both to the .tbl" patch and the result booted to a
shell prompt, but that doesn't mean much. What arch-specific entry code does
clone3 need here? The SYSCALL_DEFINE2(clone3) in kernel/fork.c seems reasonably
straightforward? (Unlike the #ifdef stack around the previous clone...)
>> include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements
>
> These are old bugs, they show up in any kernel version with gcc-8 or higher.
I looked at trying to fix that but it seems to be a compiler bug. Gcc is warning
about an ? : else case that's dead code eliminated. It's already GOT a test
protecting it from being evaluated...
>> fs/mpage.c:336:1: warning: the frame size of 1092 bytes is larger than
>
> I see these going back to gcc-6, it looks like this is caused by
> CONFIG_PAGE_SIZE_64KB.
In which case the stack size is going to be 64k as well?
> Arnd
Rob
On Wed, Nov 24, 2021 at 11:01 AM Rob Landley <[email protected]> wrote:
> On 11/23/21 7:19 AM, Arnd Bergmann wrote:
> >
> > These happen with any compiler version, someone needs to write the correct
> > entry code for clone3 and hook up futex_waitv().
>
> I did a naieve "add them both to the .tbl" patch and the result booted to a
> shell prompt, but that doesn't mean much. What arch-specific entry code does
> clone3 need here? The SYSCALL_DEFINE2(clone3) in kernel/fork.c seems reasonably
> straightforward? (Unlike the #ifdef stack around the previous clone...)
I forget the exact issue, but I can see that 4 out of the 13
architectures that set
__ARCH_WANT_SYS_CLONE3 provide a custom version: arc, m68k,
mips and parisc. Have a look at what those do to see if you need the same
changes.
> >> include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements
> >
> > These are old bugs, they show up in any kernel version with gcc-8 or higher.
>
> I looked at trying to fix that but it seems to be a compiler bug. Gcc is warning
> about an ? : else case that's dead code eliminated. It's already GOT a test
> protecting it from being evaluated...
I wouldn't call it a bug in the compiler, as there is no definite
correct ordering
between dead-code-elimination and warning generation. IIRC I fixed a bunch
of these on other architectures, and those did turn out to be actual code issues
that would go unnoticed otherwise.
> >> fs/mpage.c:336:1: warning: the frame size of 1092 bytes is larger than
> >
> > I see these going back to gcc-6, it looks like this is caused by
> > CONFIG_PAGE_SIZE_64KB.
>
> In which case the stack size is going to be 64k as well?
No, the stack is still 4KB or 8KB, depending on CONFIG_4KSTACKS, it gets
allocated using
stack = kmem_cache_alloc_node(thread_stack_cache, THREADINFO_GFP, node);
from a THREAD_SIZE-sized naturally-aligned kmem cache in this case.
Using 1KB of stack space is definitely a red flag that something is going
wrong. This could be a bug in kernel code, in the compiler, or in the
combination of the two.
Arnd
On Wed, Nov 24, 2021 at 2:15 PM André Almeida <[email protected]> wrote:
> Às 04:49 de 24/11/21, Arnd Bergmann escreveu:
> > On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <[email protected]> wrote:
> >> On 11/23/21 5:38 AM, Naresh Kamboju wrote:
> >> @@ -451,3 +451,4 @@
> >> 446 common landlock_restrict_self sys_landlock_restrict_self
> >> # 447 reserved for memfd_secret
> >> 448 common process_mrelease sys_process_mrelease
> >> +449 common futex_waitv sys_futex_waitv
> >
> > I don't know what's going on with this one, I don't actually see
> > a reason why it isn't already wired up on all architectures. If we add
> > this, it should probably be done for all architectures at once as a
> > bugfix, but it's possible that this is intentionally only used on
> > x86 and arm.
> >
> > André, can you comment on this?
> >
> I've added entries for the archs that I've actually tested, but there
> should not be any arch-specific problems in futex_waitv. I'll submit a
> patch to wire it up for the remaining architectures.
Ok, thank you.
Arnd
Hi Arnd,
Às 04:49 de 24/11/21, Arnd Bergmann escreveu:
> On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <[email protected]> wrote:
>> On 11/23/21 5:38 AM, Naresh Kamboju wrote:
>> @@ -451,3 +451,4 @@
>> 446 common landlock_restrict_self sys_landlock_restrict_self
>> # 447 reserved for memfd_secret
>> 448 common process_mrelease sys_process_mrelease
>> +449 common futex_waitv sys_futex_waitv
>
> I don't know what's going on with this one, I don't actually see
> a reason why it isn't already wired up on all architectures. If we add
> this, it should probably be done for all architectures at once as a
> bugfix, but it's possible that this is intentionally only used on
> x86 and arm.
>
> André, can you comment on this?
>
> Arnd
>
I've added entries for the archs that I've actually tested, but there
should not be any arch-specific problems in futex_waitv. I'll submit a
patch to wire it up for the remaining architectures.
Wireup futex_waitv syscall for all remaining archs.
Signed-off-by: André Almeida <[email protected]>
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/ia64/kernel/syscalls/syscall.tbl | 1 +
arch/m68k/kernel/syscalls/syscall.tbl | 1 +
arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
arch/powerpc/kernel/syscalls/syscall.tbl | 1 +
arch/sh/kernel/syscalls/syscall.tbl | 1 +
arch/sparc/kernel/syscalls/syscall.tbl | 1 +
arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
8 files changed, 8 insertions(+)
diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl
index e4a041cd5715..ca5a32228cd6 100644
--- a/arch/alpha/kernel/syscalls/syscall.tbl
+++ b/arch/alpha/kernel/syscalls/syscall.tbl
@@ -488,3 +488,4 @@
556 common landlock_restrict_self sys_landlock_restrict_self
# 557 reserved for memfd_secret
558 common process_mrelease sys_process_mrelease
+559 common futex_waitv sys_futex_waitv
diff --git a/arch/ia64/kernel/syscalls/syscall.tbl b/arch/ia64/kernel/syscalls/syscall.tbl
index 6fea1844fb95..707ae121f6d3 100644
--- a/arch/ia64/kernel/syscalls/syscall.tbl
+++ b/arch/ia64/kernel/syscalls/syscall.tbl
@@ -369,3 +369,4 @@
446 common landlock_restrict_self sys_landlock_restrict_self
# 447 reserved for memfd_secret
448 common process_mrelease sys_process_mrelease
+449 common futex_waitv sys_futex_waitv
diff --git a/arch/m68k/kernel/syscalls/syscall.tbl b/arch/m68k/kernel/syscalls/syscall.tbl
index 7976dff8f879..45bc32a41b90 100644
--- a/arch/m68k/kernel/syscalls/syscall.tbl
+++ b/arch/m68k/kernel/syscalls/syscall.tbl
@@ -448,3 +448,4 @@
446 common landlock_restrict_self sys_landlock_restrict_self
# 447 reserved for memfd_secret
448 common process_mrelease sys_process_mrelease
+449 common futex_waitv sys_futex_waitv
diff --git a/arch/microblaze/kernel/syscalls/syscall.tbl b/arch/microblaze/kernel/syscalls/syscall.tbl
index 6b0e11362bd2..2204bde3ce4a 100644
--- a/arch/microblaze/kernel/syscalls/syscall.tbl
+++ b/arch/microblaze/kernel/syscalls/syscall.tbl
@@ -454,3 +454,4 @@
446 common landlock_restrict_self sys_landlock_restrict_self
# 447 reserved for memfd_secret
448 common process_mrelease sys_process_mrelease
+449 common futex_waitv sys_futex_waitv
diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl
index 7bef917cc84e..15109af9d075 100644
--- a/arch/powerpc/kernel/syscalls/syscall.tbl
+++ b/arch/powerpc/kernel/syscalls/syscall.tbl
@@ -528,3 +528,4 @@
446 common landlock_restrict_self sys_landlock_restrict_self
# 447 reserved for memfd_secret
448 common process_mrelease sys_process_mrelease
+449 common futex_waitv sys_futex_waitv
diff --git a/arch/sh/kernel/syscalls/syscall.tbl b/arch/sh/kernel/syscalls/syscall.tbl
index 208f131659c5..d9539d28bdaa 100644
--- a/arch/sh/kernel/syscalls/syscall.tbl
+++ b/arch/sh/kernel/syscalls/syscall.tbl
@@ -451,3 +451,4 @@
446 common landlock_restrict_self sys_landlock_restrict_self
# 447 reserved for memfd_secret
448 common process_mrelease sys_process_mrelease
+449 common futex_waitv sys_futex_waitv
diff --git a/arch/sparc/kernel/syscalls/syscall.tbl b/arch/sparc/kernel/syscalls/syscall.tbl
index c37764dc764d..46adabcb1720 100644
--- a/arch/sparc/kernel/syscalls/syscall.tbl
+++ b/arch/sparc/kernel/syscalls/syscall.tbl
@@ -494,3 +494,4 @@
446 common landlock_restrict_self sys_landlock_restrict_self
# 447 reserved for memfd_secret
448 common process_mrelease sys_process_mrelease
+449 common futex_waitv sys_futex_waitv
diff --git a/arch/xtensa/kernel/syscalls/syscall.tbl b/arch/xtensa/kernel/syscalls/syscall.tbl
index 104b327f8ac9..3e3e1a506bed 100644
--- a/arch/xtensa/kernel/syscalls/syscall.tbl
+++ b/arch/xtensa/kernel/syscalls/syscall.tbl
@@ -419,3 +419,4 @@
446 common landlock_restrict_self sys_landlock_restrict_self
# 447 reserved for memfd_secret
448 common process_mrelease sys_process_mrelease
+449 common futex_waitv sys_futex_waitv
--
2.33.1
On Wed, Nov 24, 2021 at 5:21 AM André Almeida <[email protected]> wrote:
>
> Wireup futex_waitv syscall for all remaining archs.
>
> Signed-off-by: André Almeida <[email protected]>
> ---
> arch/alpha/kernel/syscalls/syscall.tbl | 1 +
> arch/ia64/kernel/syscalls/syscall.tbl | 1 +
> arch/m68k/kernel/syscalls/syscall.tbl | 1 +
> arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
> arch/powerpc/kernel/syscalls/syscall.tbl | 1 +
> arch/sh/kernel/syscalls/syscall.tbl | 1 +
> arch/sparc/kernel/syscalls/syscall.tbl | 1 +
> arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
> 8 files changed, 8 insertions(+)
For xtensa:
Acked-by: Max Filippov <[email protected]>
--
Thanks.
-- Max
André Almeida <[email protected]> writes:
> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl
> index 7bef917cc84e..15109af9d075 100644
> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
> @@ -528,3 +528,4 @@
> 446 common landlock_restrict_self sys_landlock_restrict_self
> # 447 reserved for memfd_secret
> 448 common process_mrelease sys_process_mrelease
> +449 common futex_waitv sys_futex_waitv
Tested-by: Michael Ellerman <[email protected]> (powerpc)
The selftest doesn't build with old headers, I needed this:
diff --git a/tools/testing/selftests/futex/include/futex2test.h b/tools/testing/selftests/futex/include/futex2test.h
index 9d305520e849..e6422321e9d0 100644
--- a/tools/testing/selftests/futex/include/futex2test.h
+++ b/tools/testing/selftests/futex/include/futex2test.h
@@ -8,6 +8,10 @@
#define u64_to_ptr(x) ((void *)(uintptr_t)(x))
+#ifndef __NR_futex_waitv
+#define __NR_futex_waitv 449
+#endif
+
/**
* futex_waitv - Wait at multiple futexes, wake on any
* @waiters: Array of waiters
cheers
On 11/24/21 1:49 AM, Arnd Bergmann wrote:
> On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <[email protected]> wrote:
>> On 11/23/21 5:38 AM, Naresh Kamboju wrote:
>>
>> diff --git a/arch/sh/kernel/syscalls/syscall.tbl
>> b/arch/sh/kernel/syscalls/syscall.tbl
>> index 208f131659c5..65c3a94bff48 100644
>> --- a/arch/sh/kernel/syscalls/syscall.tbl
>> +++ b/arch/sh/kernel/syscalls/syscall.tbl
>> @@ -437,7 +437,7 @@
>> 432 common fsmount sys_fsmount
>> 433 common fspick sys_fspick
>> 434 common pidfd_open sys_pidfd_open
>> -# 435 reserved for clone3
>> +435 common clone3 sys_clone3
>> 436 common close_range sys_close_range
>> 437 common openat2 sys_openat2
>> 438 common pidfd_getfd sys_pidfd_getfd
>
> Did you test clone3?
Haven't got anything that's using it (musl-libc doesn't know about it yet) but
it looked straightforward? (Unlike the #ifdef stack around the previous clone...)
I can try building tools/testing/selftests/clone3 if you like, but for some
reason the clone3 tests want -lcap which isn't in my cross compiler. (Because to
test a clone system call, you need to manipulate capability bits. Of course.)
Right, comment out the LDLIBS line in the makefile and the first 3 built, let's
try those... Hmmm, it's saying the syscall isn't supported, because it's using
syscall.h out of the cross compiler headers (not THIS kernel's #includes) which
of course doesn't have it, and then clone3_selftests.h falls back to:
#ifndef __NR_clone3
#define __NR_clone3 -1
#endif
Right, stick a 435 in there and... it's still skipping it. Why is it still
skipping it... because the RUNTIME syscall is returning ENOSYS. Ok, I have to go
stick printk() calls into the kernel. (Do I have to #define those
#YES_I_WANT_THIS_SYSCALL_WHY_WOULDNT_I macros? Hmmm...)
But yeah, you're right: the naive patch doesn't look like it actually works.
Just shuts up the #warnings.
> This needs a custom wrapper on most architectures
> to have sensible calling conventions.
Define "sensible" in this context? It's a new 2 argument syscall? (Do you mean a
libc wrapper?)
> If sh doesn't need it, that should
> be explained in the changelog text.
I'm happy to try to fix stuff up, but I don't understand the objection. Does it
do something other than what the old clone did, except without the need to pass
more arguments than we necessarily have registers defined for? (Calls the same
clone plumbing, which should call back into arch/sh/kernel/process_32.c already...?)
The most recent clone3 arch addition was commit 59a4e0d5511b which also just
pulled in the generic version. (Via #define NO_REALLY_I_WANT_THIS_SYSCALL rather
than editing the tbl file? Looks like I've got some reading to do...)
>> @@ -451,3 +451,4 @@
>> 446 common landlock_restrict_self sys_landlock_restrict_self
>> # 447 reserved for memfd_secret
>> 448 common process_mrelease sys_process_mrelease
>> +449 common futex_waitv sys_futex_waitv
>
> I don't know what's going on with this one, I don't actually see
> a reason why it isn't already wired up on all architectures.
Me neither, I'm just trying to stay ahead of warnings due to the encroaching
-Werror culture going on within the kernel clique.
> If we add
> this, it should probably be done for all architectures at once as a
> bugfix, but it's possible that this is intentionally only used on
> x86 and arm.
>
> André, can you comment on this?
I see elsethread the second syscall got handled and is going in through another
tree, I'll leave off on that part...
Rob
On Thu, Nov 25, 2021 at 12:38 AM Rob Landley <[email protected]> wrote:
> On 11/24/21 1:49 AM, Arnd Bergmann wrote:
> > On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <[email protected]> wrote:
> > Did you test clone3?
>
> Haven't got anything that's using it (musl-libc doesn't know about it yet) but
> it looked straightforward? (Unlike the #ifdef stack around the previous clone...)
>
> I can try building tools/testing/selftests/clone3 if you like, but for some
> reason the clone3 tests want -lcap which isn't in my cross compiler. (Because to
> test a clone system call, you need to manipulate capability bits. Of course.)
> Right, comment out the LDLIBS line in the makefile and the first 3 built, let's
> try those... Hmmm, it's saying the syscall isn't supported, because it's using
> syscall.h out of the cross compiler headers (not THIS kernel's #includes) which
> of course doesn't have it, and then clone3_selftests.h falls back to:
>
> #ifndef __NR_clone3
> #define __NR_clone3 -1
> #endif
>
> Right, stick a 435 in there and... it's still skipping it. Why is it still
> skipping it... because the RUNTIME syscall is returning ENOSYS. Ok, I have to go
> stick printk() calls into the kernel. (Do I have to #define those
> #YES_I_WANT_THIS_SYSCALL_WHY_WOULDNT_I macros? Hmmm...)
This specific syscall is protected by a macro so it doesn't get implicitly
enabled without architecture specific review for those architectures using
include/uapi/asm-generic/unistd.h.
> > This needs a custom wrapper on most architectures
> > to have sensible calling conventions.
>
> Define "sensible" in this context? It's a new 2 argument syscall? (Do you mean a
> libc wrapper?)
>
> > If sh doesn't need it, that should
> > be explained in the changelog text.
>
> I'm happy to try to fix stuff up, but I don't understand the objection. Does it
> do something other than what the old clone did, except without the need to pass
> more arguments than we necessarily have registers defined for? (Calls the same
> clone plumbing, which should call back into arch/sh/kernel/process_32.c already...?)
>
> The most recent clone3 arch addition was commit 59a4e0d5511b which also just
> pulled in the generic version. (Via #define NO_REALLY_I_WANT_THIS_SYSCALL rather
> than editing the tbl file? Looks like I've got some reading to do...)
The best reference I could find is:
https://lore.kernel.org/linux-api/[email protected]/
If fork() and clone() don't need special handling on arch/sh, then
clone3 shouldn't
need it either, unless the existing ones are also wrong. It looks like
some architectures
override these to avoid leaking register state from the kernel to the
child process.
Arnd
On 11/25/21 1:25 AM, Arnd Bergmann wrote:
> On Thu, Nov 25, 2021 at 12:38 AM Rob Landley <[email protected]> wrote:
>> On 11/24/21 1:49 AM, Arnd Bergmann wrote:
>> > On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <[email protected]> wrote:
>
>> > Did you test clone3?
>>
>> Haven't got anything that's using it (musl-libc doesn't know about it yet) but
>> it looked straightforward? (Unlike the #ifdef stack around the previous clone...)
>>
>> I can try building tools/testing/selftests/clone3 if you like, but for some
>> reason the clone3 tests want -lcap which isn't in my cross compiler. (Because to
>> test a clone system call, you need to manipulate capability bits. Of course.)
>> Right, comment out the LDLIBS line in the makefile and the first 3 built, let's
>> try those... Hmmm, it's saying the syscall isn't supported, because it's using
>> syscall.h out of the cross compiler headers (not THIS kernel's #includes) which
>> of course doesn't have it, and then clone3_selftests.h falls back to:
>>
>> #ifndef __NR_clone3
>> #define __NR_clone3 -1
>> #endif
>>
>> Right, stick a 435 in there and... it's still skipping it. Why is it still
>> skipping it... because the RUNTIME syscall is returning ENOSYS. Ok, I have to go
>> stick printk() calls into the kernel. (Do I have to #define those
>> #YES_I_WANT_THIS_SYSCALL_WHY_WOULDNT_I macros? Hmmm...)
>
> This specific syscall is protected by a macro so it doesn't get implicitly
> enabled without architecture specific review for those architectures using
> include/uapi/asm-generic/unistd.h.
Sigh.
>> > This needs a custom wrapper on most architectures
>> > to have sensible calling conventions.
>>
>> Define "sensible" in this context? It's a new 2 argument syscall? (Do you mean a
>> libc wrapper?)
>>
>> > If sh doesn't need it, that should
>> > be explained in the changelog text.
>>
>> I'm happy to try to fix stuff up, but I don't understand the objection. Does it
>> do something other than what the old clone did, except without the need to pass
>> more arguments than we necessarily have registers defined for? (Calls the same
>> clone plumbing, which should call back into arch/sh/kernel/process_32.c already...?)
>>
>> The most recent clone3 arch addition was commit 59a4e0d5511b which also just
>> pulled in the generic version. (Via #define NO_REALLY_I_WANT_THIS_SYSCALL rather
>> than editing the tbl file? Looks like I've got some reading to do...)
>
> The best reference I could find is:
>
> https://lore.kernel.org/linux-api/[email protected]/
Does not say what the special handling is. Does not provide an example of said
special handling. Implied that only three do NOT need special handling, two of
which are x86 and arm, which seems... convenient.
Right, let's see what "grep -r clone arch/" says:
m68k/kernel/process.c is obviously overriding
arc/include/syscalls.h has sys_clone_wrapper()
nios2/kernel/process.c has nios2_clone()
openrisc/kernel/entry.S has __sys_clone()
sparc/kernel/process.c has sparce_clone()
h8300/kernel/process.c has its own sys_clone()
ia64/kernel/process.c has ia64_clone()
user mode linux is just weird.
So the architectures that wrap clone are m68k, arc, nios2, openrisc, sparc,
h8300, and ia64.
Implying that the ones that DON'T are alpha, arm64, hexagon, nds32, parisc,
s390, csky, microblaze, powerpc, sh, x86, arm, mips, riscv, and xtensa.
Which would mean 2/3 of architectures don't wrap clone, and thus arch/sh not
doing so isn't unusual.
> If fork() and clone() don't need special handling on arch/sh, then
> clone3 shouldn't
> need it either, unless the existing ones are also wrong. It looks like
> some architectures
> override these to avoid leaking register state from the kernel to the
> child process.
$ cd arch/sh
$ grep -r clone
tools/Makefile:# Shamelessly cloned from ARM.
kernel/process_32.c:int copy_thread(unsigned long clone_flags, unsigned long
usp, unsigned long arg,
kernel/process_32.c: if (clone_flags & CLONE_SETTLS)
kernel/syscalls/syscall.tbl:120 common clone sys_clone
kernel/syscalls/syscall.tbl:435 common clone3 sys_clone3
$ grep -r fork
include/asm/cacheflush.h: * - flush_cache_dup mm(mm) handles cache flushing
when forking
kernel/entry-common.S: .globl ret_from_fork
kernel/entry-common.S:ret_from_fork:
kernel/cpu/init.c: * state prior to hand forking the idle loop.
kernel/process_32.c:asmlinkage void ret_from_fork(void);
kernel/process_32.c: p->thread.pc = (unsigned long) ret_from_fork;
kernel/syscalls/syscall.tbl:2 common fork sys_fork
kernel/syscalls/syscall.tbl:190 common vfork sys_vfork
Hard to prove a negative, but I'm not seeing any wrappers. It's got some
callbacks, but I think the existing plumbing is calling them already?
> Arnd
Rob
On Thu, Nov 25, 2021 at 06:10:54AM -0600, Rob Landley wrote:
> On 11/25/21 1:25 AM, Arnd Bergmann wrote:
...
> >
> > The best reference I could find is:
> >
> > https://lore.kernel.org/linux-api/[email protected]/
>
> Does not say what the special handling is. Does not provide an example of said
> special handling. Implied that only three do NOT need special handling, two of
> which are x86 and arm, which seems... convenient.
>
> Right, let's see what "grep -r clone arch/" says:
>
> m68k/kernel/process.c is obviously overriding
> arc/include/syscalls.h has sys_clone_wrapper()
> nios2/kernel/process.c has nios2_clone()
> openrisc/kernel/entry.S has __sys_clone()
> sparc/kernel/process.c has sparce_clone()
> h8300/kernel/process.c has its own sys_clone()
> ia64/kernel/process.c has ia64_clone()
> user mode linux is just weird.
>
> So the architectures that wrap clone are m68k, arc, nios2, openrisc, sparc,
> h8300, and ia64.
This got me reading/refreshing my memory, we have a wrapper for clone in
openrisc, but not clone3. The wrapper ensures we save registers which get
clobbered by switch hence we need it for clone/fork.
It looks like clone3 missing this wrapper may be an issue. Though, I have been
running the whole glibc test suite on this without seeing any issues.
I will patch this anyway.
> Implying that the ones that DON'T are alpha, arm64, hexagon, nds32, parisc,
> s390, csky, microblaze, powerpc, sh, x86, arm, mips, riscv, and xtensa.
>
> Which would mean 2/3 of architectures don't wrap clone, and thus arch/sh not
> doing so isn't unusual.
>
> > If fork() and clone() don't need special handling on arch/sh, then
> > clone3 shouldn't
> > need it either, unless the existing ones are also wrong. It looks like
> > some architectures
> > override these to avoid leaking register state from the kernel to the
> > child process.
I would agree with this.
-Stafford