From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752918AbbJFWAY (ORCPT ); Tue, 6 Oct 2015 18:00:24 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:35961 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752313AbbJFWAX (ORCPT ); Tue, 6 Oct 2015 18:00:23 -0400 From: Rasmus Villemoes To: Ingo Molnar Cc: Linus Torvalds , Chris Metcalf , open list , Peter Zijlstra , Thomas Gleixner , "H. Peter Anvin" , Borislav Petkov Subject: Re: [PATCH] string: Improve the generic strlcpy() implementation Organization: D03 References: <55F1DD53.1070102@ezchip.com> <20151005112700.GA1096@gmail.com> <87h9m57xwa.fsf@rasmusvillemoes.dk> <20151006080346.GB11523@gmail.com> X-Hashcash: 1:20:151006:linux-kernel@vger.kernel.org::8Wpzrg9+ZGntaTqG:00000000000000000000000000000000017Fg X-Hashcash: 1:20:151006:bp@alien8.de::RdW4KVCZPFzGzZlt:000001iOs X-Hashcash: 1:20:151006:torvalds@linux-foundation.org::NdYPW9vU8xmVNnpL:0000000000000000000000000000000023oD X-Hashcash: 1:20:151006:a.p.zijlstra@chello.nl::LUXqhJiLhZzua5+K:0000000000000000000000000000000000000002njN X-Hashcash: 1:20:151006:tglx@linutronix.de::EkkBcpfa5LbsYNdY:000000000000000000000000000000000000000000033AX X-Hashcash: 1:20:151006:mingo@kernel.org::sA3WuFvZDUJZjjUq:05jHZ X-Hashcash: 1:20:151006:cmetcalf@ezchip.com::m08P7rmxgzSr25NL:0000000000000000000000000000000000000000006zij X-Hashcash: 1:20:151006:hpa@zytor.com::ZglzLyu+AZS9IwI/:00007mnT Date: Wed, 07 Oct 2015 00:00:20 +0200 In-Reply-To: <20151006080346.GB11523@gmail.com> (Ingo Molnar's message of "Tue, 6 Oct 2015 10:03:46 +0200") Message-ID: <8737xnbqtn.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 06 2015, Ingo Molnar wrote: > * Rasmus Villemoes wrote: > >> >> I'm not against making strlcpy more robust, but I think the theoretical race is >> far more likely to manifest through a member of the printf family. > > So the printf family is generally less frequently used in ABI output than string > copies, Huh? snprintf and friends are often used just to copy or concatenate strings (essentially, any format string containing no specifiers other than %s does exactly that) - even if a str*() function could do the same thing. I see no reason to believe this wouldn't also be done in cases where the final string ends up being presented to userspace. > but yeah, since there are 15,000 s[n]printf() calls in the kernel it's > more likely to be an issue not just by virtue of timing, but also by sheer mass of > usage, statistically. Yes. > So I'd improve it all in the following order: > > - fix the strscpy() uninitialized use > > - base strlcpy() on strscpy() via the patch I sent. This makes all users faster > and eliminates the theoretical race. I'm not so sure about that part. I'd strongly suspect that the vast majority of strings handled by strlcpy (and in the future strscpy) are shorter than 32 bytes, so is all the word_at_a_time and pre/post alignment yoga really worth it? strscpy is 299 bytes - that's a lot of instruction cache lines, and it will almost always be cache cold. This isn't an argument against basing strlcpy on strscpy (that would likely just make the former a little smaller), but I'd like to see numbers (cycle counts, distribution of input lengths, ...) before I believe in the performance argument. > - phase out 'simple' strlcpy() uses via an automated patch. This gets rid of > 2,000 strlcpy() call sites in a single pass. That seems to be exactly the kind of mass-conversion Linus referred to above. Also, you can't really do it if strscpy keeps it __must_check annotation, as you'd then introduce 2000+ warnings... Rasmus