[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0xZAHknG8_kc62aaKrKdzD-QwQYHT61_wTbFDYADu-zw@mail.gmail.com>
Date: Thu, 22 Jul 2021 16:01:39 +0200
From: Arnd Bergmann <arnd@...nel.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: linux-arch <linux-arch@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
Al Viro <viro@...iv.linux.org.uk>,
Anton Ivanov <anton.ivanov@...bridgegreys.com>,
Brian Cain <bcain@...eaurora.org>,
Chris Zankel <chris@...kel.net>,
Christian Borntraeger <borntraeger@...ibm.com>,
Christoph Hellwig <hch@....de>, Guo Ren <guoren@...nel.org>,
Heiko Carstens <hca@...ux.ibm.com>,
Helge Deller <deller@....de>, Jeff Dike <jdike@...toit.com>,
Linus Walleij <linus.walleij@...aro.org>,
Max Filippov <jcmvbkbc@...il.com>,
Michal Simek <monstr@...str.eu>,
Richard Weinberger <richard@....at>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Vasily Gorbik <gor@...ux.ibm.com>,
Vineet Gupta <vgupta@...opsys.com>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
linux-csky@...r.kernel.org,
"open list:QUALCOMM HEXAGON..." <linux-hexagon@...r.kernel.org>,
linux-ia64@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
Parisc List <linux-parisc@...r.kernel.org>,
linux-s390 <linux-s390@...r.kernel.org>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@...ts.infradead.org>,
linux-um <linux-um@...ts.infradead.org>,
"open list:TENSILICA XTENSA PORT (xtensa)"
<linux-xtensa@...ux-xtensa.org>,
"moderated list:H8/300 ARCHITECTURE"
<uclinux-h8-devel@...ts.sourceforge.jp>
Subject: Re: [PATCH v3 9/9] asm-generic: reverse GENERIC_{STRNCPY_FROM,
STRNLEN}_USER symbols
On Thu, Jul 22, 2021 at 3:57 PM Johannes Berg <johannes@...solutions.net> wrote:
>
> >
> > The remaining architectures at the moment are: ia64, mips, parisc,
> > s390, um and xtensa. We should probably convert these as well, but
>
> I'm not sure it makes sense to convert um, the implementation uses
> strncpy(), and that should use the libc implementation, which is tuned
> for the actual hardware that the binary is running on, so performance
> wise that might be better.
>
> OTOH, maybe this is all in the noise given the huge syscall overhead in
> um, so maybe unifying it would make more sense.
Right, makes sense. I suppose if we end up converting mips and s390,
we should just do arch/um and the others as well for consistency, even
if that adds some overhead.
Arnd
Powered by blists - more mailing lists