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.3 required=5.0 tests=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 29071 invoked from network); 2 Jun 2021 14:56:48 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2021 14:56:48 -0000 Received: (qmail 30389 invoked by uid 550); 2 Jun 2021 14:56:46 -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 30365 invoked from network); 2 Jun 2021 14:56:45 -0000 Date: Wed, 2 Jun 2021 10:56:33 -0400 From: Rich Felker To: Arnd Bergmann Cc: musl@lists.openwall.com, Markus Wichmann , Florian Weimer Message-ID: <20210602145632.GC13220@brightrain.aerifal.cx> References: <20210510185837.GD2031@voyager> <20210524220004.GD2546@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Backwards kernel compatibility On Wed, Jun 02, 2021 at 01:52:43PM +0200, Arnd Bergmann wrote: > On Wed, Jun 2, 2021 at 9:38 AM Martin Vajnar wrote: > > > > 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 > > > > > > út 25. 5. 2021 v 0:00 odesílatel 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 kernel > > > > which we have only in binary form and have headers for it. At the same 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 ENOSYS. > > > > > > 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/afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc/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 kernels > now. Is this practical to hotpatch into kernels on devices that aren't readily upgradable? Rich