From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D85C2C4332F for ; Wed, 24 Nov 2021 10:44:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233745AbhKXKr0 (ORCPT ); Wed, 24 Nov 2021 05:47:26 -0500 Received: from mout.kundenserver.de ([212.227.17.10]:60301 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229540AbhKXKrY (ORCPT ); Wed, 24 Nov 2021 05:47:24 -0500 Received: from mail-wr1-f44.google.com ([209.85.221.44]) by mrelayeu.kundenserver.de (mreue109 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MQeI4-1n1QaZ1oyE-00Nftt; Wed, 24 Nov 2021 11:44:13 +0100 Received: by mail-wr1-f44.google.com with SMTP id r8so3343353wra.7; Wed, 24 Nov 2021 02:44:13 -0800 (PST) X-Gm-Message-State: AOAM530VHEW/qLUHJ612faaJDB+f4Top7myvtPt6hy4lmPFcyyTo2eoG cWF2zO9iJy/tOdAreMlEFSmqKigiBw93k7Q/YQM= X-Google-Smtp-Source: ABdhPJxfKmbt+vf7yW7iEZ+Pe1Z0V7tK3T1pBVG5pdSDlxjUaEAk6QQCj7BdeGupZ5+9VcvgxO0WFCpGajEcoNKFPl8= X-Received: by 2002:adf:f088:: with SMTP id n8mr17540560wro.411.1637750652924; Wed, 24 Nov 2021 02:44:12 -0800 (PST) MIME-Version: 1.0 References: <8767803d-57b9-698c-ca27-d47e7117758d@landley.net> In-Reply-To: <8767803d-57b9-698c-ca27-d47e7117758d@landley.net> From: Arnd Bergmann Date: Wed, 24 Nov 2021 11:43:56 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: spinlock.c:306:9: error: implicit declaration of function '__raw_write_lock_nested' 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@lists.linaro.org Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:cd7TT7udPC5q/AA2Et3O+w8pDqXvjI/521RNNmptP9MB0W1/YRZ gWusxm9RhnhMBipi6uS8siCGiZs1c2YIHLRl8409NxraCCnBJYh6k1bQdzT9Ajo4OUNt9K0 U5+4AJmTihhjPaGQQrpCPnacBUQwvgIFzaYCJKcjxj0LY/Y6p3JQ49cLyofppvEcYr9YOBC VCIG1Am0ttoqpn7SwIvEA== X-UI-Out-Filterresults: notjunk:1;V03:K0:/ID+ibo8dEI=:4R2wsP3Dr/9hPbL11wSFcD 7eDbi3MyV6Fjx0ZrlGLi3BuSDeQA0FHestmIobX1zhrvnE+qBAwh+k2qnQ7cWIrKLkfNswcRO xXHeIGTLfxCcJPz0XoxZi+v/b1U4VENDZEipwAOylCX35SwlfvpQEjshdbzrqKgYeaP2lOovo q2Q74h1tssT0aK8zz99kVMXXPklATYhXgtgnlxRaIT71umYOPxgRvMSQLqOP3ZIaK5erMQIdj rLXA7C+Nz5+IqNfmLB7+0yKVZpLLZQSMFG0TIOyy6Aq1FTWKaLRCZsq1ozoCcjArclpqUfgOw axfPGNSuIQulW5nvFGhR5LINe+xbbU5SM8qyBOG83ivlhtBYu8oCVx1IJZQAimhAPiuh6Ivnd Fd1jUCQ36p0ZTGtJUD5D0E2BHPdLZEZgP1Mg2bcXIjCbkGbJJoZAsVVO+cCQskdBEk59iyAbu 9uyEgdwIWdc0BJB9y40EUWC+M2+bWMcQrbAHHoOe0QXRb517F5a4eLMyU9Mc5MKvZgT5QMmN/ fU8tdFIqLoT4mCupPIUBsMCAytXma1YRw4BuapRrHpdEhCWPeQpB4uwcSzsdi0QwUvmD5mkqE tvoU+qth0DVIANpb62yvlpOpJejdBWL9N01GcKAZqFOPjJWq3rLEeRuGV9t01SsK6gkWhSyTh ZJV0CiOYMVDH1mDNwrtbMESZyLMtKZAPkANuhBATVgqNxADMpy84kBALQaRTnQzkUZyfYKxO0 iZQkcTb0RkC9a2xoOOyOT5jaOrbBmZLM9l1zAdp7uT3iB6Ci/+2hSTC348fAdtG7f1ThPHpbB mzGO/f+RlMnW2+7piZVtfmNMg+dT908XMrIqo8L0AZ5OamwpRs= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 24, 2021 at 11:01 AM Rob Landley 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