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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B7DCECA5FF5 for ; Mon, 5 Oct 2026 20:28:05 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4hz9tq4cXyz2yYK; Tue, 06 Oct 2026 07:28:03 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip="2600:3c0a:e001:78e:0:1991:8:25" ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1791218628; cv=none; b=mVV+xBF2LOhq9MDbndLVByUN6oNsEUyshYROPYQLFe+mfBFA5bu7rlQ+K8ljCTn81lrcLYzX4l7RyaQl358PBOH/EILDMyEnbSRlebGdXIH0XRpxumVSWmUFIqFYBlaoT4JmJcRDkKT7KpDoc7zGgTkvYigJdU2NDA7JgtQBLl1dYHTgSdv/IXdsx7n/7lttUHs2ZuiDs4YxbvIDU4uSYv1tsQS3x0ojwp5keIX/nYc+ia76SCDgkm82U/ntXxIs+0OlUgm0HycDtQLdHWGgNLHYjKXGctxu8Ixm1jfPQFUVU752qcv/sxglxFKqmYpcxZpAiBrHvJX/y+OPjNVRAw== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1791218628; c=relaxed/relaxed; bh=X0AfyKVoCvIdgwkopveGc4Ekelt3ZdLYde10lxY31zU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ovBxcq0CKG6Ke0ZACkewK0NjG7L7eSSMMbzdPlNEqiS7lKGGlmZbRxyzjjLMF6xLVZg912+dJN13Cy07F89gwphHROu6N8dIe9jGcdvH3le8jPol9WefBTD1Bd2G5B+GT5lCqlmzq0vJw835QddRaeSPETq8S6uKUbX3aBll4/RhaC0fNWlB4lFFdLcn6omx9UAVXgnAHz69VNqcXtnuKtO8UtN8KsAwN2zsF2tJIivpCPyxJRdSrJCXw+9UCC98XhCwfXFdZM3ZOi2D/GO8XsoSKW7wHjrUUADR2EASUEMoj1usl8/fyMWza1Zxtplfy04FyqlrG9ezLfpb7U/sOQ== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=S8wsvnK1; dkim-atps=neutral; spf=pass (client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org; envelope-from=alx@kernel.org; receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=S8wsvnK1; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org; envelope-from=alx@kernel.org; receiver=lists.ozlabs.org) Received: from sea.source.kernel.org (sea.source.kernel.org [IPv6:2600:3c0a:e001:78e:0:1991:8:25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4hz4w337RTz2y8G for ; Tue, 06 Oct 2026 03:43:47 +1100 (AEDT) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 1CBB54243C; Mon, 5 Oct 2026 16:43:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D49C1F000FF; Mon, 5 Oct 2026 16:43:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791218625; bh=X0AfyKVoCvIdgwkopveGc4Ekelt3ZdLYde10lxY31zU=; h=Date:From:To:List-Id:Cc:Subject:References:In-Reply-To; b=S8wsvnK1+a/xOmsDZn0LZvJlD3Bnq9DMJ3UsDAxcD9q3HXZkvhSb++WuKxwOAqzAu hrbaDWQ2TKQeK5qAuU/GCEggF3bRaVsp4sqaGr+++rvPx/+wZ0Z2Q7GaXwDA/NY9v8 VKEEIXVnHH73b5warExc4DQfE3COvzbPuwvkwFys7kUtJwKL0pdKUAMEkKYt/ggiMA h8T9M/F4zTywTKPBe9aTCkC/zOvbNC9Rmiv2B7nN0szPOFCqp8uBXlMMfr5Mzw8t4H T3Dr+dtv+eAXxa9TkgXFVj7JR6K5twCoezU1EbX/6Y/45ZD9v8GfwTf7iOdVr9eYpV ZRjdfRd3HaIYA== Date: Mon, 5 Oct 2026 18:43:23 +0200 From: Alejandro Colomar To: Kees Cook List-Id: Cc: Alejandro Colomar , Andy Shevchenko , Bill Wendling , "Matthew Wilcox (Oracle)" , Andrew Morton , David Gow , Petr Mladek , Shuvam Pandey , Steven Rostedt , Jonathan Corbet , Sergey Senozhatsky , =?utf-8?Q?G=C3=BCnther?= Noack , =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , Masami Hiramatsu , Mathieu Desnoyers , Jiri Kosina , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , "Christophe Leroy (CS GROUP)" , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Shivaprasad G Bhat , Thorsten Blum , Alison Schofield , Dave Jiang , Greg Kroah-Hartman , Guangshuo Li , Ira Weiny , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Vishal Verma , Randy Dunlap , Shuah Khan , linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-security-module@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, nvdimm@lists.linux.dev, linux-doc@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v4 05/11] seq_buf: Add seq_buf_strlen() Message-ID: References: <20261003035906.too.263-kees@kernel.org> <20261003035921.1918874-5-kees@kernel.org> <202610040023.A3865A6@keescook> <20261005112209.1e47fa-kees@kernel.org> <20261005155839.d5d200-kees@kernel.org> X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mag73kyr3lvmhsn3" Content-Disposition: inline In-Reply-To: <20261005155839.d5d200-kees@kernel.org> --mag73kyr3lvmhsn3 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable From: Alejandro Colomar To: Kees Cook List-Id: Cc: Alejandro Colomar , Andy Shevchenko , Bill Wendling , "Matthew Wilcox (Oracle)" , Andrew Morton , David Gow , Petr Mladek , Shuvam Pandey , Steven Rostedt , Jonathan Corbet , Sergey Senozhatsky , =?utf-8?Q?G=C3=BCnther?= Noack , =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , Masami Hiramatsu , Mathieu Desnoyers , Jiri Kosina , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , "Christophe Leroy (CS GROUP)" , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Shivaprasad G Bhat , Thorsten Blum , Alison Schofield , Dave Jiang , Greg Kroah-Hartman , Guangshuo Li , Ira Weiny , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Vishal Verma , Randy Dunlap , Shuah Khan , linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-security-module@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, nvdimm@lists.linux.dev, linux-doc@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v4 05/11] seq_buf: Add seq_buf_strlen() Message-ID: References: <20261003035906.too.263-kees@kernel.org> <20261003035921.1918874-5-kees@kernel.org> <202610040023.A3865A6@keescook> <20261005112209.1e47fa-kees@kernel.org> <20261005155839.d5d200-kees@kernel.org> MIME-Version: 1.0 In-Reply-To: <20261005155839.d5d200-kees@kernel.org> Hi Kees, > Date: 2026-10-05 08:58:45-0700 > From: Kees Cook > > On Mon, Oct 05, 2026 at 01:34:10PM +0200, Alejandro Colomar wrote: > > > Yeah, reasonable. :) For v5 I've added this to seq_buf_str()'s kernel= -doc: > > > > > > * A zero-sized seq_buf has nowhere to put a NUL, so the empty string > > > * is returned instead of writing to @s->buffer. Any other seq_buf > > > * returns @s->buffer, even when it holds an empty string, so callers > > > * always get their own buffer back. > > > > Are such buffers actually used on purpose anywhere? Why not keep the > > WARN_ON? >=20 > Yes, though not often: the sched_ext debug dump builds a nested per-CPU > seq_buf from seq_buf_get_buf(), which returns a size of 0 once the dump > buffer has overflowed, and it handles that case on purpose (see the > "$s may already have overflowed" comment in kernel/sched/ext/ext.c). Hmmmm, so IIUC, it is a sentinel value, and not really a buffer size? Did you consider not holding the size of the buffer, but rather an end pointer? It also allows you to find how much you can write to the buffer, but has slightly better semantics: the end doesn't change if you advance the position. 'end' can only change through reallocations (which I don't know if you do in the kernel). It's fundamentally the same issue as was discussed with ARRAY_END() vs ARRAY_SIZE(), where ARRAY_END() is more robust. Also, using NULL as a sentinel value is more readable; otherwise, you wonder why a buffer can have 0 bytes. I think it'd simplify the implementation of the buffer. > Greg asked about the WARN_ON() in v2[1]: a size that comes from a device > or from userspace would have to be checked before every seq_buf_init(), > or it becomes a crash under panic_on_warn, and an empty buffer can just > hold the empty string. So the accessors do that instead. Makes sense. Thanks for clarifying! Have a lovely night! Alex >=20 > [1] https://lore.kernel.org/all/2026091953-cherub-empty-ef35@gregkh/ >=20 > -Kees >=20 > --=20 > Kees Cook --=20 --mag73kyr3lvmhsn3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmrD06QACgkQ64mZXMKQ wqnpdQ//euFjtt+8eCfTbdx8D9yFA98qRQtBNJRMJkzbjRc1WHzJSyAenzDDHRW7 1nfO+8fVD+sABW5saDwArxt4Tve6VP/xyI4ifVoNW5aAqsHaw9ShgZYIIp8xpUUU ACpzeCs1nelWY7X5eQegvND9U2tpW9XQ9BJ5bL/rMCPzqICH4Yk4cUkkqsUcPho4 DYITM73/V/Rh/KZNKJm0FJwegjDCLP0G3WkI9pp/FYX0yYFt9zutVQfQdoLLCJv+ bbA0W9u9U/bTr9yARxP6+KjjwpRXH7b4m/98g6tXng6OJ4exZXNo1XP4e2eQHqXz 1qqjE+X4g1mDXgmD78QMUGUM9vKVzbIjFevvAXtum+qr6Nj01OExY1gOUW27QbDX Umt1EH/Dl5g8qwCMLuARH1jqVzUOORtqc1h408A2HIKjHqHBql4fGelGi/h5pJhO CbSDEaxxr6F1s4KmSWiDAZkSFTn0lLrAW4+5g8scddimgKmo2H2gvyYqAW7nX9Fu g6mO0PzwjtfvQf7mKhBvsjLdkkDH/V33KN23BoM89Sj/u6nONtESiARI7XMlcg8e jnRRASeSXKkver8374YJ0LKv/YW0zKJUJF+W42h9PmmmYumgRWDjzPZmuwCJjn+t 0cN5QFNWVSt8LYxmBbHzPJ7q2J/bW11IibMUg7d9+0eo2N5tw8E= =gQBr -----END PGP SIGNATURE----- --mag73kyr3lvmhsn3--