Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'

From: Arnd Bergmann <arnd@arndb.de>
To: Rob Landley <rob@landley.net>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
	"Naresh Kamboju" <naresh.kamboju@linaro.org>,
	"Linux-Next Mailing List" <linux-next@vger.kernel.org>,
	"open list" <linux-kernel@vger.kernel.org>,
	"Linux-sh list" <linux-sh@vger.kernel.org>,
	"Stephen Rothwell" <sfr@canb.auug.org.au>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>, "Will Deacon" <will@kernel.org>,
	"Waiman Long" <longman@redhat.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Minchan Kim" <minchan@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Mike Galbraith" <umgwanakikbuti@gmail.com>,
	"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
	"Sergey Senozhatsky" <senozhatsky@chromium.org>,
	"Yoshinori Sato" <ysato@users.sourceforge.jp>,
	"Rich Felker" <dalias@libc.org>,
	lkft-triage@lists.linaro.org,
	"André Almeida" <andrealmeid@collabora.com>
Subject: Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested'
Date: Thu, 25 Nov 2021 08:25:09 +0100	[thread overview]
Message-ID: <CAK8P3a0XGz=F0nPAW8T-VvfH5bPuGTNiPZ18N+Z6Sj_M_6TrPA@mail.gmail.com> (raw)
In-Reply-To: <7d5a5249-40ee-9a42-c6a0-a5defa3703c1@landley.net>

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