[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251217151159.2eee1081@gandalf.local.home>
Date: Wed, 17 Dec 2025 15:11:59 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Kees Cook <kees@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Linux Trace Kernel
<linux-trace-kernel@...r.kernel.org>, Thorsten Blum
<thorsten.blum@...ux.dev>, Josh Poimboeuf <jpoimboe@...nel.org>, Peter
Zijlstra <peterz@...radead.org>, "Gustavo A. R. Silva"
<gustavoars@...nel.org>, David Laight <david.laight.linux@...il.com>
Subject: Re: [PATCH] unwind: Show that entries of struct unwind_cache is not
bound by nr_entries
On Mon, 17 Nov 2025 13:28:59 -0800
Kees Cook <kees@...nel.org> wrote:
> struct unwind_cache {
> struct_group_tagged(unwind_cache_hdr, hdr,
> unsigned long unwind_completed;
> unsigned int nr_entries;
> );
> unsigned long entries[(SZ_4K - sizeof(struct unwind_cache_hdr)) / sizeof(long)];
> };
This may help automated tooling, but it is horrendous to read. I value
readability much higher than static analyzers.
Hence, I'm leaving the code as is, and just keep NAKing patches that try to
add __counted_by() to entries.
-- Steve
>
> #define UNWIND_MAX_ENTRIES ARRAY_SIZE(((struct unwind_cache*)NULL)->entries)
>
> And this checks out for me:
>
> UNWIND_MAX_ENTRIES:510
> sizeof(struct unwind_cache):4096
>
> No hiding things from the compiler, and you can treat "entries" like a
> real array (since it is one now).
Powered by blists - more mailing lists