LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
@ 2021-11-23 11:38 Naresh Kamboju
  2021-11-23 13:19 ` Arnd Bergmann
  2021-11-24  7:31 ` Rob Landley
  0 siblings, 2 replies; 24+ messages in thread
From: Naresh Kamboju @ 2021-11-23 11:38 UTC (permalink / raw)
  To: Linux-Next Mailing List, open list, Linux-sh list
  Cc: Stephen Rothwell, Peter Zijlstra, Ingo Molnar, Will Deacon,
	Waiman Long, Boqun Feng, Minchan Kim, Arnd Bergmann,
	Andrew Morton, Mike Galbraith, Sebastian Andrzej Siewior,
	Sergey Senozhatsky, Yoshinori Sato, Rich Felker, lkft-triage

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 <lkft@linaro.org>

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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-23 11:38 spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' Naresh Kamboju
@ 2021-11-23 13:19 ` Arnd Bergmann
  2021-11-23 14:48   ` Geert Uytterhoeven
  2021-11-24 10:01   ` spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' Rob Landley
  2021-11-24  7:31 ` Rob Landley
  1 sibling, 2 replies; 24+ messages in thread
From: Arnd Bergmann @ 2021-11-23 13:19 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: Linux-Next Mailing List, open list, Linux-sh list,
	Stephen Rothwell, Peter Zijlstra, Ingo Molnar, Will Deacon,
	Waiman Long, Boqun Feng, Minchan Kim, Arnd Bergmann,
	Andrew Morton, Mike Galbraith, Sebastian Andrzej Siewior,
	Sergey Senozhatsky, Yoshinori Sato, Rich Felker, lkft-triage

On Tue, Nov 23, 2021 at 12:38 PM Naresh Kamboju
<naresh.kamboju@linaro.org> 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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-23 13:19 ` Arnd Bergmann
@ 2021-11-23 14:48   ` Geert Uytterhoeven
  2021-11-23 14:50     ` Sebastian Andrzej Siewior
  2021-11-24 10:01   ` spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' Rob Landley
  1 sibling, 1 reply; 24+ messages in thread
From: Geert Uytterhoeven @ 2021-11-23 14:48 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Naresh Kamboju, Linux-Next Mailing List, open list,
	Linux-sh list, Stephen Rothwell, Peter Zijlstra, Ingo Molnar,
	Will Deacon, Waiman Long, Boqun Feng, Minchan Kim, Andrew Morton,
	Mike Galbraith, Sebastian Andrzej Siewior, Sergey Senozhatsky,
	Yoshinori Sato, Rich Felker, lkft-triage

Hi Arnd,

On Tue, Nov 23, 2021 at 2:50 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Nov 23, 2021 at 12:38 PM Naresh Kamboju
> <naresh.kamboju@linaro.org> 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/202111201111.c2ApGeHR-lkp@intel.com/

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-23 14:48   ` Geert Uytterhoeven
@ 2021-11-23 14:50     ` Sebastian Andrzej Siewior
  2021-11-23 16:07       ` [PATCH] locking: Fixup write_lock_nested() implementation Sebastian Andrzej Siewior
  0 siblings, 1 reply; 24+ messages in thread
From: Sebastian Andrzej Siewior @ 2021-11-23 14:50 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Arnd Bergmann, Naresh Kamboju, Linux-Next Mailing List,
	open list, Linux-sh list, Stephen Rothwell, Peter Zijlstra,
	Ingo Molnar, Will Deacon, Waiman Long, Boqun Feng, Minchan Kim,
	Andrew Morton, Mike Galbraith, Sergey Senozhatsky,
	Yoshinori Sato, Rich Felker, lkft-triage

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/202111201111.c2ApGeHR-lkp@intel.com/

I'm on it. Almost done.

> Gr{oetje,eeting}s,
> 
>                         Geert

Sebastian

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

* [PATCH] locking: Fixup write_lock_nested() implementation.
  2021-11-23 14:50     ` Sebastian Andrzej Siewior
@ 2021-11-23 16:07       ` Sebastian Andrzej Siewior
  2021-11-23 17:01         ` [PATCH v2] " Sebastian Andrzej Siewior
  0 siblings, 1 reply; 24+ messages in thread
From: Sebastian Andrzej Siewior @ 2021-11-23 16:07 UTC (permalink / raw)
  To: Geert Uytterhoeven, Andrew Morton, Stephen Rothwell
  Cc: Arnd Bergmann, Naresh Kamboju, Linux-Next Mailing List,
	open list, Linux-sh list, Peter Zijlstra, Ingo Molnar,
	Will Deacon, Waiman Long, Boqun Feng, Minchan Kim,
	Mike Galbraith, Sergey Senozhatsky, Yoshinori Sato, Rich Felker,
	lkft-triage

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 <bigeasy@linutronix.de>
---
 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


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

* [PATCH v2] locking: Fixup write_lock_nested() implementation.
  2021-11-23 16:07       ` [PATCH] locking: Fixup write_lock_nested() implementation Sebastian Andrzej Siewior
@ 2021-11-23 17:01         ` Sebastian Andrzej Siewior
  2021-11-23 22:52           ` Stephen Rothwell
  0 siblings, 1 reply; 24+ messages in thread
From: Sebastian Andrzej Siewior @ 2021-11-23 17:01 UTC (permalink / raw)
  To: Geert Uytterhoeven, Andrew Morton, Stephen Rothwell
  Cc: Arnd Bergmann, Naresh Kamboju, Linux-Next Mailing List,
	open list, Linux-sh list, Peter Zijlstra, Ingo Molnar,
	Will Deacon, Waiman Long, Boqun Feng, Minchan Kim,
	Mike Galbraith, Sergey Senozhatsky, Yoshinori Sato, Rich Felker,
	lkft-triage

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 <bigeasy@linutronix.de>
---
 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


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

* Re: [PATCH v2] locking: Fixup write_lock_nested() implementation.
  2021-11-23 17:01         ` [PATCH v2] " Sebastian Andrzej Siewior
@ 2021-11-23 22:52           ` Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2021-11-23 22:52 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: Geert Uytterhoeven, Andrew Morton, Arnd Bergmann, Naresh Kamboju,
	Linux-Next Mailing List, open list, Linux-sh list,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long,
	Boqun Feng, Minchan Kim, Mike Galbraith, Sergey Senozhatsky,
	Yoshinori Sato, Rich Felker, lkft-triage

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

Hi all,

On Tue, 23 Nov 2021 18:01:34 +0100 Sebastian Andrzej Siewior <bigeasy@linutronix.de> 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 <bigeasy@linutronix.de>
> ---
>  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

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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-23 11:38 spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' Naresh Kamboju
  2021-11-23 13:19 ` Arnd Bergmann
@ 2021-11-24  7:31 ` Rob Landley
  2021-11-24  7:49   ` Arnd Bergmann
  1 sibling, 1 reply; 24+ messages in thread
From: Rob Landley @ 2021-11-24  7:31 UTC (permalink / raw)
  To: Naresh Kamboju, Linux-Next Mailing List, open list, Linux-sh list
  Cc: Stephen Rothwell, Peter Zijlstra, Ingo Molnar, Will Deacon,
	Waiman Long, Boqun Feng, Minchan Kim, Arnd Bergmann,
	Andrew Morton, Mike Galbraith, Sebastian Andrzej Siewior,
	Sergey Senozhatsky, Yoshinori Sato, Rich Felker, lkft-triage

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 <rob@landley.net>

Wire up clone3 and futex_waitv syscalls for arch/sh

Signed-off-by: Rob Landley <rob@landley.net>
---

 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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-24  7:31 ` Rob Landley
@ 2021-11-24  7:49   ` Arnd Bergmann
  2021-11-24 13:15     ` André Almeida
                       ` (2 more replies)
  0 siblings, 3 replies; 24+ messages in thread
From: Arnd Bergmann @ 2021-11-24  7:49 UTC (permalink / raw)
  To: Rob Landley
  Cc: Naresh Kamboju, Linux-Next Mailing List, open list,
	Linux-sh list, Stephen Rothwell, Peter Zijlstra, Ingo Molnar,
	Will Deacon, Waiman Long, Boqun Feng, Minchan Kim, Arnd Bergmann,
	Andrew Morton, Mike Galbraith, Sebastian Andrzej Siewior,
	Sergey Senozhatsky, Yoshinori Sato, Rich Felker, lkft-triage,
	André Almeida

On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <rob@landley.net> 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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-23 13:19 ` Arnd Bergmann
  2021-11-23 14:48   ` Geert Uytterhoeven
@ 2021-11-24 10:01   ` Rob Landley
  2021-11-24 10:43     ` Arnd Bergmann
  1 sibling, 1 reply; 24+ messages in thread
From: Rob Landley @ 2021-11-24 10:01 UTC (permalink / raw)
  To: Arnd Bergmann, Naresh Kamboju
  Cc: Linux-Next Mailing List, open list, Linux-sh list,
	Stephen Rothwell, Peter Zijlstra, Ingo Molnar, Will Deacon,
	Waiman Long, Boqun Feng, Minchan Kim, Andrew Morton,
	Mike Galbraith, Sebastian Andrzej Siewior, Sergey Senozhatsky,
	Yoshinori Sato, Rich Felker, lkft-triage



On 11/23/21 7:19 AM, Arnd Bergmann wrote:
> On Tue, Nov 23, 2021 at 12:38 PM Naresh Kamboju
> <naresh.kamboju@linaro.org> 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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-24 10:01   ` spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' Rob Landley
@ 2021-11-24 10:43     ` Arnd Bergmann
  0 siblings, 0 replies; 24+ messages in thread
From: Arnd Bergmann @ 2021-11-24 10:43 UTC (permalink / raw)
  To: Rob Landley
  Cc: Arnd Bergmann, Naresh Kamboju, Linux-Next Mailing List,
	open list, Linux-sh list, Stephen Rothwell, Peter Zijlstra,
	Ingo Molnar, Will Deacon, Waiman Long, Boqun Feng, Minchan Kim,
	Andrew Morton, Mike Galbraith, Sebastian Andrzej Siewior,
	Sergey Senozhatsky, Yoshinori Sato, Rich Felker, lkft-triage

On Wed, Nov 24, 2021 at 11:01 AM Rob Landley <rob@landley.net> 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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-24  7:49   ` Arnd Bergmann
@ 2021-11-24 13:15     ` André Almeida
  2021-11-24 14:21       ` Arnd Bergmann
  2021-11-24 13:21     ` [PATCH 1/1] futex: Wireup futex_waitv syscall André Almeida
  2021-11-24 23:38     ` spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' Rob Landley
  2 siblings, 1 reply; 24+ messages in thread
From: André Almeida @ 2021-11-24 13:15 UTC (permalink / raw)
  To: Arnd Bergmann, Rob Landley
  Cc: Naresh Kamboju, Linux-Next Mailing List, open list,
	Linux-sh list, Stephen Rothwell, Peter Zijlstra, Ingo Molnar,
	Will Deacon, Waiman Long, Boqun Feng, Minchan Kim, Andrew Morton,
	Mike Galbraith, Sebastian Andrzej Siewior, Sergey Senozhatsky,
	Yoshinori Sato, Rich Felker, lkft-triage

Hi Arnd,

Às 04:49 de 24/11/21, Arnd Bergmann escreveu:
> On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <rob@landley.net> 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.

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

* [PATCH 1/1] futex: Wireup futex_waitv syscall
  2021-11-24  7:49   ` Arnd Bergmann
  2021-11-24 13:15     ` André Almeida
@ 2021-11-24 13:21     ` André Almeida
  2021-11-24 13:49       ` Geert Uytterhoeven
                         ` (3 more replies)
  2021-11-24 23:38     ` spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' Rob Landley
  2 siblings, 4 replies; 24+ messages in thread
From: André Almeida @ 2021-11-24 13:21 UTC (permalink / raw)
  To: linux-kernel, arnd, geert, monstr, mpe, ysato, dalias, davem,
	chris, jcmvbkbc, linux-alpha, linux-ia64, linux-m68k,
	linuxppc-dev, linux-sh, sparclinux, linux-xtensa
  Cc: akpm, andrealmeid, bigeasy, boqun.feng, linux-next, lkft-triage,
	longman, minchan, mingo, naresh.kamboju, peterz, rob,
	senozhatsky, sfr, umgwanakikbuti, will

Wireup futex_waitv syscall for all remaining archs.

Signed-off-by: André Almeida <andrealmeid@collabora.com>
---
 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


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

* Re: [PATCH 1/1] futex: Wireup futex_waitv syscall
  2021-11-24 13:21     ` [PATCH 1/1] futex: Wireup futex_waitv syscall André Almeida
@ 2021-11-24 13:49       ` Geert Uytterhoeven
  2021-11-24 14:29       ` Arnd Bergmann
                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 24+ messages in thread
From: Geert Uytterhoeven @ 2021-11-24 13:49 UTC (permalink / raw)
  To: André Almeida
  Cc: Linux Kernel Mailing List, Arnd Bergmann, Michal Simek,
	Michael Ellerman, Yoshinori Sato, Rich Felker, David S. Miller,
	Chris Zankel, Max Filippov, alpha, linux-ia64, linux-m68k,
	linuxppc-dev, Linux-sh list, sparclinux,
	open list:TENSILICA XTENSA PORT (xtensa),
	Andrew Morton, Sebastian Andrzej Siewior, Boqun Feng, Linux-Next,
	lkft-triage, Waiman Long, Minchan Kim, Ingo Molnar,
	Naresh Kamboju, Peter Zijlstra, Rob Landley, Sergey Senozhatsky,
	Stephen Rothwell, Mike Galbraith, Will Deacon

On Wed, Nov 24, 2021 at 2:21 PM André Almeida <andrealmeid@collabora.com> wrote:
> Wireup futex_waitv syscall for all remaining archs.
>
> Signed-off-by: André Almeida <andrealmeid@collabora.com>

>  arch/m68k/kernel/syscalls/syscall.tbl       | 1 +

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-24 13:15     ` André Almeida
@ 2021-11-24 14:21       ` Arnd Bergmann
  0 siblings, 0 replies; 24+ messages in thread
From: Arnd Bergmann @ 2021-11-24 14:21 UTC (permalink / raw)
  To: André Almeida
  Cc: Arnd Bergmann, Rob Landley, Naresh Kamboju,
	Linux-Next Mailing List, open list, Linux-sh list,
	Stephen Rothwell, Peter Zijlstra, Ingo Molnar, Will Deacon,
	Waiman Long, Boqun Feng, Minchan Kim, Andrew Morton,
	Mike Galbraith, Sebastian Andrzej Siewior, Sergey Senozhatsky,
	Yoshinori Sato, Rich Felker, lkft-triage

On Wed, Nov 24, 2021 at 2:15 PM André Almeida <andrealmeid@collabora.com> wrote:
> Às 04:49 de 24/11/21, Arnd Bergmann escreveu:
> > On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <rob@landley.net> 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

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

* Re: [PATCH 1/1] futex: Wireup futex_waitv syscall
  2021-11-24 13:21     ` [PATCH 1/1] futex: Wireup futex_waitv syscall André Almeida
  2021-11-24 13:49       ` Geert Uytterhoeven
@ 2021-11-24 14:29       ` Arnd Bergmann
  2021-11-24 15:56         ` André Almeida
  2021-11-24 23:18         ` Thomas Gleixner
  2021-11-24 17:23       ` Max Filippov
  2021-11-24 23:07       ` Michael Ellerman
  3 siblings, 2 replies; 24+ messages in thread
From: Arnd Bergmann @ 2021-11-24 14:29 UTC (permalink / raw)
  To: André Almeida
  Cc: Linux Kernel Mailing List, Arnd Bergmann, Geert Uytterhoeven,
	Michal Simek, Michael Ellerman, Yoshinori Sato, Rich Felker,
	David Miller, Chris Zankel, Max Filippov, alpha, linux-ia64,
	linux-m68k, linuxppc-dev, Linux-sh list, sparclinux,
	open list:TENSILICA XTENSA PORT (xtensa),
	Andrew Morton, Sebastian Andrzej Siewior, Boqun Feng,
	Linux-Next Mailing List, lkft-triage, Waiman Long, Minchan Kim,
	Ingo Molnar, Naresh Kamboju, Peter Zijlstra, Rob Landley,
	Sergey Senozhatsky, Stephen Rothwell, Mike Galbraith,
	Will Deacon

On Wed, Nov 24, 2021 at 2:21 PM André Almeida <andrealmeid@collabora.com> wrote:
>
> Wireup futex_waitv syscall for all remaining archs.
>
> Signed-off-by: André Almeida <andrealmeid@collabora.com>

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

I double-checked that futex_waitv() doesn't need any architecture specific
hacks, and that the list above is complete.

Should I take this through the asm-generic tree, or would you send it
through the
tip tree?

        Arnd

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

* Re: [PATCH 1/1] futex: Wireup futex_waitv syscall
  2021-11-24 14:29       ` Arnd Bergmann
@ 2021-11-24 15:56         ` André Almeida
  2021-11-24 23:18         ` Thomas Gleixner
  1 sibling, 0 replies; 24+ messages in thread
From: André Almeida @ 2021-11-24 15:56 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Linux Kernel Mailing List, Geert Uytterhoeven, Michal Simek,
	Michael Ellerman, Yoshinori Sato, Rich Felker, David Miller,
	Chris Zankel, Max Filippov, alpha, linux-ia64, linux-m68k,
	linuxppc-dev, Linux-sh list, sparclinux,
	open list:TENSILICA XTENSA PORT (xtensa),
	Andrew Morton, Sebastian Andrzej Siewior, Boqun Feng,
	Linux-Next Mailing List, lkft-triage, Waiman Long, Minchan Kim,
	Ingo Molnar, Naresh Kamboju, Peter Zijlstra, Rob Landley,
	Sergey Senozhatsky, Stephen Rothwell, Mike Galbraith,
	Will Deacon

Às 11:29 de 24/11/21, Arnd Bergmann escreveu:
> On Wed, Nov 24, 2021 at 2:21 PM André Almeida <andrealmeid@collabora.com> wrote:
>>
>> Wireup futex_waitv syscall for all remaining archs.
>>
>> Signed-off-by: André Almeida <andrealmeid@collabora.com>
> 
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> 
> I double-checked that futex_waitv() doesn't need any architecture specific
> hacks, and that the list above is complete.

Thanks!

> 
> Should I take this through the asm-generic tree, or would you send it
> through the
> tip tree?
> 
I think that adding it to asm-generic tree make sense to me.

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

* Re: [PATCH 1/1] futex: Wireup futex_waitv syscall
  2021-11-24 13:21     ` [PATCH 1/1] futex: Wireup futex_waitv syscall André Almeida
  2021-11-24 13:49       ` Geert Uytterhoeven
  2021-11-24 14:29       ` Arnd Bergmann
@ 2021-11-24 17:23       ` Max Filippov
  2021-11-24 23:07       ` Michael Ellerman
  3 siblings, 0 replies; 24+ messages in thread
From: Max Filippov @ 2021-11-24 17:23 UTC (permalink / raw)
  To: André Almeida
  Cc: LKML, Arnd Bergmann, Geert Uytterhoeven, Michal Simek,
	Michael Ellerman, Yoshinori Sato, Rich Felker, David S. Miller,
	Chris Zankel, open list:ALPHA PORT,
	open list:IA64 (Itanium) PL...,
	open list:M68K ARCHITECTURE, linuxppc-dev, open list:SUPERH,
	open list:SPARC + UltraSPAR...,
	open list:TENSILICA XTENSA PORT (xtensa),
	Andrew Morton, Sebastian Andrzej Siewior, boqun.feng, Linux-Next,
	lkft-triage, longman, Minchan Kim, Ingo Molnar, naresh.kamboju,
	Peter Zijlstra, Rob Landley, Sergey Senozhatsky,
	Stephen Rothwell, umgwanakikbuti, Will Deacon

On Wed, Nov 24, 2021 at 5:21 AM André Almeida <andrealmeid@collabora.com> wrote:
>
> Wireup futex_waitv syscall for all remaining archs.
>
> Signed-off-by: André Almeida <andrealmeid@collabora.com>
> ---
>  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 <jcmvbkbc@gmail.com>

-- 
Thanks.
-- Max

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

* Re: [PATCH 1/1] futex: Wireup futex_waitv syscall
  2021-11-24 13:21     ` [PATCH 1/1] futex: Wireup futex_waitv syscall André Almeida
                         ` (2 preceding siblings ...)
  2021-11-24 17:23       ` Max Filippov
@ 2021-11-24 23:07       ` Michael Ellerman
  3 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2021-11-24 23:07 UTC (permalink / raw)
  To: André Almeida, linux-kernel, arnd, geert, monstr, ysato,
	dalias, davem, chris, jcmvbkbc, linux-alpha, linux-ia64,
	linux-m68k, linuxppc-dev, linux-sh, sparclinux, linux-xtensa
  Cc: akpm, andrealmeid, bigeasy, boqun.feng, linux-next, lkft-triage,
	longman, minchan, mingo, naresh.kamboju, peterz, rob,
	senozhatsky, sfr, umgwanakikbuti, will

André Almeida <andrealmeid@collabora.com> 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 <mpe@ellerman.id.au> (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

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

* Re: [PATCH 1/1] futex: Wireup futex_waitv syscall
  2021-11-24 14:29       ` Arnd Bergmann
  2021-11-24 15:56         ` André Almeida
@ 2021-11-24 23:18         ` Thomas Gleixner
  1 sibling, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2021-11-24 23:18 UTC (permalink / raw)
  To: Arnd Bergmann, André Almeida
  Cc: Linux Kernel Mailing List, Arnd Bergmann, Geert Uytterhoeven,
	Michal Simek, Michael Ellerman, Yoshinori Sato, Rich Felker,
	David Miller, Chris Zankel, Max Filippov, alpha, linux-ia64,
	linux-m68k, linuxppc-dev, Linux-sh list, sparclinux,
	open list:TENSILICA XTENSA PORT (xtensa),
	Andrew Morton, Sebastian Andrzej Siewior, Boqun Feng,
	Linux-Next Mailing List, lkft-triage, Waiman Long, Minchan Kim,
	Ingo Molnar, Naresh Kamboju, Peter Zijlstra, Rob Landley,
	Sergey Senozhatsky, Stephen Rothwell, Mike Galbraith,
	Will Deacon

On Wed, Nov 24 2021 at 15:29, Arnd Bergmann wrote:
> On Wed, Nov 24, 2021 at 2:21 PM André Almeida <andrealmeid@collabora.com> wrote:
>>
>> Wireup futex_waitv syscall for all remaining archs.
>>
>> Signed-off-by: André Almeida <andrealmeid@collabora.com>
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>
> I double-checked that futex_waitv() doesn't need any architecture specific
> hacks, and that the list above is complete.
>
> Should I take this through the asm-generic tree, or would you send it
> through the tip tree?

Feel free to pick it up.

Thanks,

        tglx

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-24  7:49   ` Arnd Bergmann
  2021-11-24 13:15     ` André Almeida
  2021-11-24 13:21     ` [PATCH 1/1] futex: Wireup futex_waitv syscall André Almeida
@ 2021-11-24 23:38     ` Rob Landley
  2021-11-25  7:25       ` Arnd Bergmann
  2 siblings, 1 reply; 24+ messages in thread
From: Rob Landley @ 2021-11-24 23:38 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Naresh Kamboju, Linux-Next Mailing List, open list,
	Linux-sh list, Stephen Rothwell, Peter Zijlstra, Ingo Molnar,
	Will Deacon, Waiman Long, Boqun Feng, Minchan Kim, Andrew Morton,
	Mike Galbraith, Sebastian Andrzej Siewior, Sergey Senozhatsky,
	Yoshinori Sato, Rich Felker, lkft-triage, André Almeida

On 11/24/21 1:49 AM, Arnd Bergmann wrote:
> On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <rob@landley.net> 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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-24 23:38     ` spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' Rob Landley
@ 2021-11-25  7:25       ` Arnd Bergmann
  2021-11-25 12:10         ` Rob Landley
  0 siblings, 1 reply; 24+ messages in thread
From: Arnd Bergmann @ 2021-11-25  7:25 UTC (permalink / raw)
  To: Rob Landley
  Cc: Arnd Bergmann, Naresh Kamboju, Linux-Next Mailing List,
	open list, Linux-sh list, Stephen Rothwell, Peter Zijlstra,
	Ingo Molnar, Will Deacon, Waiman Long, Boqun Feng, Minchan Kim,
	Andrew Morton, Mike Galbraith, Sebastian Andrzej Siewior,
	Sergey Senozhatsky, Yoshinori Sato, Rich Felker, lkft-triage,
	André Almeida

On Thu, Nov 25, 2021 at 12:38 AM Rob Landley <rob@landley.net> wrote:
> On 11/24/21 1:49 AM, Arnd Bergmann wrote:
> > On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <rob@landley.net> 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/20190604160944.4058-2-christian@brauner.io/

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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-25  7:25       ` Arnd Bergmann
@ 2021-11-25 12:10         ` Rob Landley
  2021-11-26 23:51           ` Stafford Horne
  0 siblings, 1 reply; 24+ messages in thread
From: Rob Landley @ 2021-11-25 12:10 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Naresh Kamboju, Linux-Next Mailing List, open list,
	Linux-sh list, Stephen Rothwell, Peter Zijlstra, Ingo Molnar,
	Will Deacon, Waiman Long, Boqun Feng, Minchan Kim, Andrew Morton,
	Mike Galbraith, Sebastian Andrzej Siewior, Sergey Senozhatsky,
	Yoshinori Sato, Rich Felker, lkft-triage, André Almeida

On 11/25/21 1:25 AM, Arnd Bergmann wrote:
> On Thu, Nov 25, 2021 at 12:38 AM Rob Landley <rob@landley.net> wrote:
>> On 11/24/21 1:49 AM, Arnd Bergmann wrote:
>> > On Wed, Nov 24, 2021 at 8:31 AM Rob Landley <rob@landley.net> 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/20190604160944.4058-2-christian@brauner.io/

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

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

* Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
  2021-11-25 12:10         ` Rob Landley
@ 2021-11-26 23:51           ` Stafford Horne
  0 siblings, 0 replies; 24+ messages in thread
From: Stafford Horne @ 2021-11-26 23:51 UTC (permalink / raw)
  To: Rob Landley
  Cc: Arnd Bergmann, Naresh Kamboju, Linux-Next Mailing List,
	open list, Linux-sh list, Stephen Rothwell, Peter Zijlstra,
	Ingo Molnar, Will Deacon, Waiman Long, Boqun Feng, Minchan Kim,
	Andrew Morton, Mike Galbraith, Sebastian Andrzej Siewior,
	Sergey Senozhatsky, Yoshinori Sato, Rich Felker, lkft-triage,
	André Almeida

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/20190604160944.4058-2-christian@brauner.io/
> 
> 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

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

end of thread, other threads:[~2021-11-26 23:53 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-23 11:38 spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' Naresh Kamboju
2021-11-23 13:19 ` Arnd Bergmann
2021-11-23 14:48   ` Geert Uytterhoeven
2021-11-23 14:50     ` Sebastian Andrzej Siewior
2021-11-23 16:07       ` [PATCH] locking: Fixup write_lock_nested() implementation Sebastian Andrzej Siewior
2021-11-23 17:01         ` [PATCH v2] " Sebastian Andrzej Siewior
2021-11-23 22:52           ` Stephen Rothwell
2021-11-24 10:01   ` spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' Rob Landley
2021-11-24 10:43     ` Arnd Bergmann
2021-11-24  7:31 ` Rob Landley
2021-11-24  7:49   ` Arnd Bergmann
2021-11-24 13:15     ` André Almeida
2021-11-24 14:21       ` Arnd Bergmann
2021-11-24 13:21     ` [PATCH 1/1] futex: Wireup futex_waitv syscall André Almeida
2021-11-24 13:49       ` Geert Uytterhoeven
2021-11-24 14:29       ` Arnd Bergmann
2021-11-24 15:56         ` André Almeida
2021-11-24 23:18         ` Thomas Gleixner
2021-11-24 17:23       ` Max Filippov
2021-11-24 23:07       ` Michael Ellerman
2021-11-24 23:38     ` spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' Rob Landley
2021-11-25  7:25       ` Arnd Bergmann
2021-11-25 12:10         ` Rob Landley
2021-11-26 23:51           ` Stafford Horne

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).