linux-kernel - Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <YaFzDW+n0n7qQ7hm@antec>
Date:   Sat, 27 Nov 2021 08:51:41 +0900
From:   Stafford Horne <shorne@...il.com>
To:     Rob Landley <rob@...dley.net>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Linux-sh list <linux-sh@...r.kernel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Minchan Kim <minchan@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mike Galbraith <umgwanakikbuti@...il.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>, lkft-triage@...ts.linaro.org,
        André Almeida <andrealmeid@...labora.com>
Subject: Re: spinlock.c:306:9: error: implicit declaration of function
 '__raw_write_lock_nested'

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