From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A5C62F4A18 for ; Sat, 28 Mar 2026 16:54:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774716859; cv=none; b=MNRLLMRsvjX7EBXGh3eTXkGvayWcqz8XhPDsIq6NSzBfsOrNqoy99y7zjuirUG41K3RIhrAE/XK3WHm6GXpOB839GO5rNzrdyOjcVO5ik+NX2hK9GKTLg+1GYwyl7QgRPpL/WM3EU/xUuTSAnIPeF3EkCTaFMqFKlJvcMrzT3nE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774716859; c=relaxed/simple; bh=xzxAZRqM3f3BSfQnT9B9nnZkdz16p/gpmalRInh1zq4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jXyNUPMg+yFCZmikdK8ymknON4uvPmsYZUzcHhR5hhRB9LZ17vkXIAAvfxz/rg4KZ1xC4x+cJT/LpYoDVqSayuIbhF5pr1gEWRGRbzA5YQqcyj+ks5QrLEY0sHKfOQ0b3UMtl5pIgammQbGNVPUxsPIohod7Aie3muDGTqH40yg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=SLBb/p1I; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SLBb/p1I" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-43b41b545d9so3345854f8f.2 for ; Sat, 28 Mar 2026 09:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774716857; x=1775321657; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=bskGa9+wIac+9AV4zAHPQV3SylMDRVZ2RcNk/YVR8rE=; b=SLBb/p1IsJUZTzliWVZfRMO2gzE18VAuwR07VkKKxNxkSSlevbAoo5jv4h5mMnk5R3 RoJZDyMep8gU+LW/nWpoZ8Wkc/fr01JqdyK205ztRCprQWOl7Hk33F0/Y9jdIJe05rGX X3wjmDtU4R8GdCtMjTe/Gp7Fe5/F7t4ftYh+KcspsmRfHN++ZrUrza0sTJA/c+DFDMlp ptUYwmUaGf9MjhGVo0Ca5MwphZSR6iSy88TD4xnoctPf3iyl/5eietOdXFsV4koTsCsm rrZ/WxZ7J4bHhmvE15r3iFx6XjzCJztFGbzE2Znpl2i9X3o0vxngQ3ojkTJ3StRCW0yj xytg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774716857; x=1775321657; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=bskGa9+wIac+9AV4zAHPQV3SylMDRVZ2RcNk/YVR8rE=; b=ctBrOpUe6X3w9DHREjVuErEhsVFrrLT6UsDSN4xpJ3CTUyM2OsgKeccnWIIflqlEAi fOmnjh8f23TRoH8jPArUHCnYQNttCE7+WxBnOz1xy57bQ9htjaRO4V091YmiBEn6xAY+ 1gWmB8UsiMowOqMBn/sgD8/EyAhHaCbI6QyR6f+/pGad3qP/s3Zoq507NVIFZlODJUTg EvWStMAf5zwxHBfDbrKMrJQ8Kk34u1cTUx6uO3KEJSNh94/IKO5mfvdnvl6j83+b27bc RVPT7mebkkBZTKJQiG/ImEsePVM2zIqWWHGijfJFjF5PsqC2DumBwhhO+s7gVCBbQ+KU R1KQ== X-Forwarded-Encrypted: i=1; AJvYcCXub6FqWh1aqWOQ7dezZtuNAK2wjPKiogV7/A58FwGoHPACZ/r5s7dP43fIiHZmj4svz1g8e9w5zgSQBWM=@vger.kernel.org X-Gm-Message-State: AOJu0YxkoXG2EaFwJYPY0jnvOnQc5j/XrsBfQBJTBZCuHGOJnQiNNzfa PCCtzzbh3TBy1TvOtvI0MS8V7iZm9HTgWhU5DjZahKydix2jW8pHx//Y35PAZ0pL X-Gm-Gg: ATEYQzzJD5sG6DWJkgtXbxpzQuD0eXAm8wyFkmYtvWMoR1ZWvAX7YBoqOrSN2QXICRw q1Z0MC/J82606ytlGC4mofhyK4i3RlO1q0DOcfBukKVw9DgKk6oEM/X11SvoJ2vgAE7jHnGO3wf fgdC0cxAQ+ltqg0aJqQV+PPZbVHHtfZwn6ZGuK0H7iYVDcNG4j0HjwRDvPHZztNdZoFtUgBjto1 2/z0U+T6lPQSpgzkxWOw0QvsVmy0gGftE0zK3HvB9R2EipP3QzbTnigaerQNkg2J3aQNEa6BwEt Ts064KcDN5l5L2yxue11aabIYIoogAE990LQpAjSekAk9dQSEAQHKHSFVK9QMnjxaZH8z8seUdW 27385FJZeMRyZMC7+qFCWc421KmGR3Js5fJZKw4IZ1P1XhdPmovKGeAAWCX0EVyS2HX2mYn3DXQ Grepem/31/W4jS39VMLj5cZVAuN4t/Rlaz6ES3Xsy0jIvzxWBqMhgTi5n5eQUR1fcxQ9qU0xFau Hk= X-Received: by 2002:a05:6000:2f85:b0:43c:f66e:f2d with SMTP id ffacd0b85a97d-43cf66e113cmr868346f8f.27.1774696095926; Sat, 28 Mar 2026 04:08:15 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43cf21e29b1sm4420470f8f.8.2026.03.28.04.08.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Mar 2026 04:08:15 -0700 (PDT) Date: Sat, 28 Mar 2026 11:08:14 +0000 From: David Laight To: Linus Torvalds Cc: Andrew Morton , Kees Cook , Andy Shevchenko , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH next] string: Optimise strlen() Message-ID: <20260328110814.0a59e12f@pumpkin> In-Reply-To: References: <20260327195737.89537-1-david.laight.linux@gmail.com> <20260327224928.7c4220cb@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 27 Mar 2026 17:29:21 -0700 Linus Torvalds wrote: > On Fri, 27 Mar 2026 at 15:49, David Laight = wrote: > > > > I've not measured strnlen(), but it wouldn't surprise me if argv[] > > processing wouldn't be faster with something like the strlen() in this > > patch. > > After all arguments are usually relatively short. =20 >=20 > No, we used to do those a byte at a time. It was not great. execve() > strings are often actually long because of filenames and environment > variables. >=20 > The trivial cases don't even matter, because all the cost of execve() > are elsewhere for those cases. >=20 > But the cases where the strings *do* matter, they are many and long. Is that the strncpy_from_user() path? >=20 > Again - where did you actually see costs in real profiles? We really > don't tend to have strings in the kernel. The strings we do have are > from user space, and by the time they are in the kernel they typically > aren't C strings any more (or, with pathnames, have other termination > than just the NUL character). I started looking at this because someone was trying to write the 'bit-mask= ing' version for (possibly) RISC-V and I deciding that they weren't making a good job of it and that it probably wasn't worth while (since x86-64 just uses the byte code). So I did some measurements - mostly to prove it was a waste of time. The slight unroll of the C versions was a 'I wonder what effect it would ha= ve' change, I was surprised it doubled throughput. For such a small change it seemed worthwhile. I've just run the tests on an old Haswell box (I don't have any recent Intel cpu). The 'byte' loop (and the unrolled once one) execute at 1 byte/clock. The 'masking longs' loop runs at 4 bytes/clock but matches the byte loop for 16 bytes (mostly because the byte loop is slower). The 'elephant in the room' is the glibc code. That must be using AVX and manages to beat 32 bytes/clock on my zen-5 (slightly under 32 bytes/clock on the Haswell). That makes me think about the exec path, the fp registers need to be trashed which should make them usable in the kernel (even without disabling preemption). You might need them reloaded after being preempted - I'm guessing that is done in the 'return to user' path these days, rather than trapping on first the access? =46rom what I remember kernel_fpu_end() got changed so that it didn't restore the registers - so pretty much just enables preemption. Which means that subsequent kernel_fpu_begin() are also cheap. But code can't request 'kernel_fpu_begin(if_cheap)' and use the fallback slow path if the registers would have to be saved. That could speed up some code for 'medium length' buffers. David =20 >=20 > Linus