From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8215 invoked from network); 2 Jun 2021 11:54:38 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2021 11:54:38 -0000 Received: (qmail 24504 invoked by uid 550); 2 Jun 2021 11:54:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24485 invoked from network); 2 Jun 2021 11:54:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622634864; bh=DRPbMGaGkWlVR1cqNQ9oChtVJlJgYgmFrui0sodxYmo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=p5DXB/Cg049dmCGnUqLpekINEMLtQV2QYW+dowjevZzAZ3wrlTGyuNmZ0odhIMH5G RigrgEMZX5ceYfLNYLrJ6U2g9VP3nUuMJHzO6TUib8iglzopD7fIGmVjLbsWsiiAQH U0jzuD4a//1vAudAikvHP1IYwW/VTWoNxb2DYxRnPPVdTqapGsAGaxvPmOFN5sHSTR tNvtp5S68S8U3bfXRlutf5cx5/jmZ8qKztXsnYnH9MhEr6rviXaBdBSX4zemZRfI0X OKNU2dRSlVMZ/HDZ1NkYRDG5D+QGn/sSZGpbTKJ9Z7D44Pu0rm1iKcYv9jbU5WZz+c 4guKmudE5ptzg== X-Gm-Message-State: AOAM530t3M3P5HV3QPAusUOPxh8RBfzhfoqk+7kWboW+3qxQ2J2cyHZj zf2gGhYt2WbDFRN+ay18aRocODGs/SomCE1zP+g= X-Google-Smtp-Source: ABdhPJyQOXdLvz3KWzWZu5NG6AaU+rkAlz/KcPWyIG3kN+kt/LqeKESBztXN8HZbN2DJvTPWDxBrA4M0jVl9hrJHU9s= X-Received: by 2002:a7b:c849:: with SMTP id c9mr4854759wml.84.1622634862660; Wed, 02 Jun 2021 04:54:22 -0700 (PDT) MIME-Version: 1.0 References: <20210510185837.GD2031@voyager> <20210524220004.GD2546@brightrain.aerifal.cx> In-Reply-To: From: Arnd Bergmann Date: Wed, 2 Jun 2021 13:52:43 +0200 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com Cc: Rich Felker , Markus Wichmann , Florian Weimer Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Backwards kernel compatibility On Wed, Jun 2, 2021 at 9:38 AM Martin Vajnar wrot= e: > > Hi Rich, > > thank you for such detailed reply.> Cc: > Cc: Martin Vajnar > Cc: musl@lists.openwall.com > Acked-by: Will Deacon > Signed-off-by: Michael Weiser > Signed-off-by: Will Deacon > Signed-off-by: Greg Kroah-Hartman > Signed-off-by: Arnd Bergmann > --- > This was backported to v4.14 and later, but is missing in v4.4 and > before, apparently because of a trivial merge conflict. This is > a manual backport I did after I saw a report about the issue > by Martin Vajnar on the musl mailing list. > Signed-off-by: Arnd Bergmann > --- > arch/arm64/kernel/traps.c | 8 -------- > 1 file changed, 8 deletions(-) > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > index 9322be69ca09..db4163808c76 100644 > --- a/arch/arm64/kernel/traps.c > +++ b/arch/arm64/kernel/traps.c > @@ -363,14 +363,6 @@ asmlinkage long do_ni_syscall(struct pt_regs *regs) > } > #endif > > - if (show_unhandled_signals && printk_ratelimit()) { > - pr_info("%s[%d]: syscall %d\n", current->comm, > - task_pid_nr(current), (int)regs->syscallno); > - dump_instr("", regs); > - if (user_mode(regs)) > - __show_regs(regs); > - } > - > return sys_ni_syscall(); > } > > -- > 2.29.2 > > > =C3=BAt 25. 5. 2021 v 0:00 odes=C3=ADlatel Rich Felker = napsal: > > > > On Mon, May 24, 2021 at 03:52:44PM +0200, Martin Vajnar wrote: > > > Hi, Markus, > > > > > > sorry for the late reply it was quite busy lately. You're describing > > > exactly the issue, we are facing in our project. We need to use old k= ernel > > > which we have only in binary form and have headers for it. At the sam= e time > > > we would like to have the latest musl running on it. > > > > > > The problem we encounter is that for unsupported (or better said, not > > > supported yet) syscalls we get performance overhead because of the EN= OSYS. > > > > Can you give some information on what syscalls these are and if/how > > you measured the performance overhead as being significant? > > > The main source of overhead comes from the kernel 4.4 which on arm64 > produces stack traces when not implemented syscall is invoked: > > https://github.com/torvalds/linux/blob/afd2ff9b7e1b367172f18ba7f693df= b62bdcb2dc/arch/arm64/kernel/traps.c#L369 That is clearly a bug that was fixed in mainline and backported to linux-4.= 14 but not 4.4 or 4.9. I've sent a manual backport for inclusion in those kern= els now. Arnd