From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D3C5C71130 for ; Mon, 7 Jul 2025 20:29:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6EA66B03E7; Mon, 7 Jul 2025 16:29:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B1FC46B03E8; Mon, 7 Jul 2025 16:29:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A35276B03E9; Mon, 7 Jul 2025 16:29:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 91E3C6B03E7 for ; Mon, 7 Jul 2025 16:29:52 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 39D9212890A for ; Mon, 7 Jul 2025 20:29:52 +0000 (UTC) X-FDA: 83638609824.05.3B80154 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf21.hostedemail.com (Postfix) with ESMTP id 9C0CE1C000A for ; Mon, 7 Jul 2025 20:29:50 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LoB2iX7G; spf=pass (imf21.hostedemail.com: domain of alx@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=alx@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751920190; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=E9XVJnkm9rNvuY7wlcSvsZbkTX8oHoDg8FF51VrLuO8=; b=8VJVjf2ApMikVj/DFJyb1fZEVr02F9HUhmTzhLd90u7ed667dLyCOGe0ybB1ItjNUyyozH gv69/17BPBe66HAHI0IQh0tarQUrQ0cKAKUo9+oKl9GjcqWEUB5SfTKSmlQWFqvwL5hv+T /AOJUqlF4QV8zXOsAiEbQgl+BRO5+Tw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751920190; a=rsa-sha256; cv=none; b=mLQy0zhv3f3zqvs8SkVRCiG3UXFPDg+MZI2879ouBmQ6fTdeCkq5sdCoB7SNz5GTYdqx74 N94kI5yK9aKfbnQsEWVBHsuSfsDeCE/jQcmT4xLN+qivKyICVpMUCgIfphY6cIl3/dSMnF hCLppFJVKnRVEP5lpYa2SbedYrAS4WI= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LoB2iX7G; spf=pass (imf21.hostedemail.com: domain of alx@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=alx@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id CEA5C6111F; Mon, 7 Jul 2025 20:29:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 678F2C4CEE3; Mon, 7 Jul 2025 20:29:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751920189; bh=KaVF9Ika1Iq/rw5JBpEqeImU31PCs6bqzlHNSQVTiWU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LoB2iX7GwIPMHbCQequWgcamiRQuaMGvkg4ELR1vaCbhzPPF3h58ByrezX1MhEAL+ WT2Tbg9Tdb92vUry9ZKvo2yXI7nlUqoWcF8wMvOnYq/GwNm2aqJFMAWPzaknfM+20C 3wcPXqVIeRtwTZyivD6ttTBM5CJqoT38d7dJAfCOL/Wh0vEnvBtQFNy/QMZAFKGEDI rUsO2bMmtlgneg5LR5ZgL5DS+3G2N+Euph0bycMVA7pgSj0279Ei9R2idnA0YK/oJJ 6FEa+0ZLOq6n/bWt61LeSAnhFLE8XRrosmOC6X+CThJlchIix0KgOiOZQpyuwb8XwC xgh4hU16jbQDQ== Date: Mon, 7 Jul 2025 22:29:40 +0200 From: Alejandro Colomar To: Linus Torvalds Cc: linux-mm@kvack.org, linux-hardening@vger.kernel.org, Kees Cook , Christopher Bazley , shadow <~hallyn/shadow@lists.sr.ht>, linux-kernel@vger.kernel.org, Andrew Morton , kasan-dev@googlegroups.com, Dmitry Vyukov , Alexander Potapenko , Marco Elver , Christoph Lameter , David Rientjes , Vlastimil Babka , Roman Gushchin , Harry Yoo , Andrew Clayton , Sven Schnelle , Heiko Carstens , Tvrtko Ursulin , "Huang, Ying" , Lee Schermerhorn , Christophe JAILLET , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Chao Yu Subject: Re: [RFC v3 3/7] mm: Use seprintf() instead of less ergonomic APIs Message-ID: References: <033bf00f1fcf808245ae150346019aa7b997ea11.1751862634.git.alx@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hm3euuqedab7podc" Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9C0CE1C000A X-Stat-Signature: uyzioa4s9hmuru5owpj6z3as6xee16oz X-HE-Tag: 1751920190-924092 X-HE-Meta: U2FsdGVkX18IRMtEEcvxRjn3OW9iF1rnujhS5R2E4ZjQTQt3LZIq+zXMszGdlIcez+hzXLoBGMjcDcB8i2rDybYqB8AgAOfaE56b/qG2e/0SVFRqh8VDajtmuhSLbYaB8hKPF2qse97L4K5Vzz2bXHxLaiiHQjz7nFrGe1wLwWfAByG4HjwsUTS5i33C3odCv7xcEG5ajsLV7gWqLJ6bsIMqfV2rNNY0IHd7rcYKeQQxTPytEi8LjWf0AgOiH9v0h81t/XYsKSg2bckGj/qOHrVc4xoz0+GYx4w4R2bH9BxvjmvtNxqkT2sAHzcnfCjMz/EneqgfsXraQvy8J6a6+HkHoW94k9bwmGZ8EfweF0qnD6PoaCbydtkSmUdyiR/nHoRpFzqC4FsoriJw4WyAvg6RsO7XMbGKduCF7JIPJE1YckixK1ONThy3rDaGJlhbSbZD82gQ+Sp+aEtEEe3JwhZoG60DzYwNuO6W9EHsJw4NRJOch6WklLa+YLxqmdcACVJRq4HJjWPW1Sdbyp7XaVlacez/JKHZ7x8XK/+jAWFaY0Inot7ViUpumkcM6V6Ivq2B/qESIV2g+RsUauwOupEMEYNbWcoWDTNOM2kFNCS9Lbkpjk4kuyA5Wzeyw66S+qW3TtLV+wQWE0v0/tPWVyCNIRzz4uEl0D1XfCN53hojZ2nypG5d+v5vTmEos7w3iUc7bZiG1LPI904ok25ZYaJpnDwylfj7Hvg0SJxQmDncfJ840sCiMXn1TWmf3xVsT3zWqhvdP86YuDhbF90TmCd4xl9/ldjdRnrocH8brf08Gf7hNcS79QXz91hvY7ZtDeS35xVCBo5dvwl/vbu0Vl0nqWXsDxSy36dZ9YqLxcuItYIyOCRQBB4uWNbvULCQ0n6d/z+4V98HbWJU3zII/h/oqdaI6HtRynEwVXpIF9QLbBdTdZm6Q7DzG58ocOtK2NqBBDe1Omx2mbdg2CZ 8g9l3I08 txmmzj3w/Ely/KQBq3E8Ve7ZBxvnf0clhXICAs9lzd8p8QXblIV9JXqn/E3gULDc30Pvf7+7WcCsKefFENA8jlsq5NrQbwM4U0me+1WkZw/phOxLGjXYaltf+dbwMTg2cS2TABa9oi2VN60E21OL17QoEqstZJAMLeqHqFtW1960wzm21d5q1MaFGGybuCdAdukKJrcbhCBikKIyu9bBjehVHNIHo6BI1K/4xocCai5gVmCoagcdVlUL1ovp2l0egjPwrOCFoBQGEjBR7etwXjfrAnU7Y+VXch2YokgdsXrUVn5F1oXHQIO7hi/10b3ry7NedbOuXHR6eHekEeASCuCHQnhqjT46kEgsi6M05NdRGIoezoPkRnw1xDBpa0MjRKLlsklmxfpIrFU/CfXpZm0+a63SZJMj0a0pnEQEksK/T2NbzujfuLe2UrerBfGiBENhbFwNYygl67itSDHdKrHK7441RWWGi8AAVM27JYcp9R3s4YCSG1ygKExQtsn3DpwUVBrBnT33IRXnq31r+iZUZCsujEBLvl0hxoOAC2kIvWnk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --hm3euuqedab7podc Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable From: Alejandro Colomar To: Linus Torvalds Cc: linux-mm@kvack.org, linux-hardening@vger.kernel.org, Kees Cook , Christopher Bazley , shadow <~hallyn/shadow@lists.sr.ht>, linux-kernel@vger.kernel.org, Andrew Morton , kasan-dev@googlegroups.com, Dmitry Vyukov , Alexander Potapenko , Marco Elver , Christoph Lameter , David Rientjes , Vlastimil Babka , Roman Gushchin , Harry Yoo , Andrew Clayton , Sven Schnelle , Heiko Carstens , Tvrtko Ursulin , "Huang, Ying" , Lee Schermerhorn , Christophe JAILLET , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Chao Yu Subject: Re: [RFC v3 3/7] mm: Use seprintf() instead of less ergonomic APIs References: <033bf00f1fcf808245ae150346019aa7b997ea11.1751862634.git.alx@kernel.org> MIME-Version: 1.0 In-Reply-To: Hi Linus, On Mon, Jul 07, 2025 at 12:17:11PM -0700, Linus Torvalds wrote: > On Sun, 6 Jul 2025 at 22:06, Alejandro Colomar wrote: > > > > - p +=3D snprintf(p, ID_STR_LENGTH - (p - name), "%07u", s->size); > > + p =3D seprintf(p, e, "%07u", s->size); >=20 > I am *really* not a fan of introducing yet another random non-standard > string function. I am in the C Committee, and have proposed this API for standardization. I have a feeling that the committee might be open to it. > This 'seprintf' thing really seems to be a completely made-up thing. > Let's not go there. It just adds more confusion - it may be a simpler > interface, but it's another cogniitive load thing, I understand the part of your concern that relates to . However, I've shown how in mm/, I got rid of most snprintf() and scnprintf() calls. I could even get rid of the remaining snprintf() ones; I didn't do it to avoid churn, but they're just 3, so I could do it, as a way to remove all uses of snprintf(3). I also got rid of all scnprintf() uses except for 2. Not because those two cannot be removed, but because the code was scary enough that I didn't dare touch it. I'd like someone to read it and confirm that it can be replaced. > and honestly, that > "beginning and end" interface is not great. Just look at the diffs. It is great, in terms of writing less code. In some cases, it makes sense to pass a size. Those cases are when you don't want to chain several calls. That's the case of stprintf(), and it's wrapper STPRINTF(), which calls ARRAY_SIZE() internally. But most of the time you want to chain calls, and 'end' beats 'size' there. > I think we'd be better off with real "character buffer" interfaces, > and they should be *named* that way, not be yet another "random > character added to the printf family". You might want to do that, but I doubt it's an easy change. On the other hand, this change is trivial, and can be done incrementally, without needing to modify the buffer since its inception. And you can come back later to wrap this in some API that does what you want. Nothing stops you from doing that. But this fixes several cases of UB in a few files that I've looked at, with minimal diffs. > The whole "add a random character" thing is a disease. But at least > with printf/fprintf/vprintf/vsnprintf/etc, it's a _standard_ disease, > so people hopefully know about it. seprint(2) was implemented in Plan9 many decades ago. It's not standard, because somehow Plan9 has been ignored by history, but the name has a long history. Plus, I'm making seprintf() standard (if I can convince the committee). Yesterday night, I presented the proposal to the committee, informally (via email). You can read a copy here: I'll present it formally in a month, since I have a batch of proposals for the committee in the works. Have a lovely day! Alex > So I really *really* don't like things like seprintf(). It just makes me = go WTF? >=20 > Interfaces that have worked for us are things like "seq_printf()", which >=20 > (a) has sane naming, not "add random characters" >=20 > (b) has real abstractions (in that case 'struct seq_file') rather > than adding random extra arguments to the argument list. >=20 > and we do have something like that in 'struct seq_buf'. I'm not > convinced that's the optimal interface, but I think it's *better*. > Because it does both encapsulate a proper "this is my buffer" type, > and has a proper "this is a buffer operation" function name. >=20 > So I'd *much* rather people would try to convert their uses to things > like that, than add random letter combinations. >=20 > Linus --=20 --hm3euuqedab7podc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmhsLi0ACgkQ64mZXMKQ wqmzHhAAiWAsGEbvSPpIRKjHFLRmZ1qgrHgSd2MJ5KPyYritnzqRD0gE1mRApWtk kfVZhvAa0ud09ds81/+KW/SAYw5VsHdJuyDpLxfNNaP0sKJRuTUgHPmjqBsj3N3F 4MtyXQ1P6YjydvSUQ200zKyXaPBsPTqJEz2M+gXxNgghYp07sEYcEEKKV1X1j6vK atcQsESKA+/+V9kPiHFgGQsaX7/e/nvSVpao5gnZ8oIxsqDN/zPosSks7wxBptyJ FSMMer6X3IUsh7innNWu4QSPXObRGS5BJol6Ev1d5IKvXTkmxipe4vXWO7OQ9Un4 LNBAqD8+SQWbqHFHjEH1VUqr9wzJNFnJrjGUsz+kwtV4dHtbATi/7peYZA7Ht0CA arhageKLWRn2JUM5beeIug/CJHZ150+m/M1Dc0Ec6K9rxJUj10sP/t09WIljrJzF 4D8lBcrZVMjz+NkOWQNn55ZN9VU7r/6y57Dv090D0ysBmmE2fG7GzGbJJMYqEGrb nXAFN1giVxeg2t/tlbzAGJ09EZkxinK0EHEzY/4bgT5gDw/tMMBqsX4qTp7qa9Va JzUTGvdbS5I1Px04zRDJrOvNyx5vyFRj+ZROPop/tO3Jucf1BWE2sxBezKoCK1zl 3NiRecJc2x2mDZnh2mDRcMuEMkprSbFB/5KS56i0ayITLsqauSk= =E6l+ -----END PGP SIGNATURE----- --hm3euuqedab7podc--