[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210401152741.GK4758@sirena.org.uk>
Date: Thu, 1 Apr 2021 16:27:41 +0100
From: Mark Brown <broonie@...nel.org>
To: madvenka@...ux.microsoft.com
Cc: mark.rutland@....com, jpoimboe@...hat.com, jthierry@...hat.com,
catalin.marinas@....com, will@...nel.org,
linux-arm-kernel@...ts.infradead.org,
live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 1/4] arm64: Implement infrastructure for stack
trace reliability checks
On Tue, Mar 30, 2021 at 02:09:52PM -0500, madvenka@...ux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka@...ux.microsoft.com>
>
> Implement a check_reliability() function that will contain checks for the
> presence of various features and conditions that can render the stack trace
> unreliable.
This looks good to me with one minor stylistic thing:
> +/*
> + * Special functions where the stack trace is unreliable.
> + */
> +static struct function_range special_functions[] = {
> + { 0, 0 }
> +};
Might be good to put a comment here saying that this is terminating the
list rather than detecting a NULL function pointer:
{ /* sentinel */ }
is a common idiom for that.
Given that it's a fixed array we could also...
> + for (func = special_functions; func->start; func++) {
> + if (pc >= func->start && pc < func->end)
...do these as
for (i = 0; i < ARRAY_SIZE(special_functions); i++)
so you don't need something like that, though that gets awkward when you
have to write out special_functions[i].field a lot.
So many different potential colours for the bikeshed!
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists