[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ecdca67a-223f-40de-ebfa-89183e15a2a8@linux.microsoft.com>
Date: Thu, 1 Apr 2021 12:44:53 -0500
From: "Madhavan T. Venkataraman" <madvenka@...ux.microsoft.com>
To: Mark Brown <broonie@...nel.org>
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 4/1/21 10:27 AM, Mark Brown wrote:
> 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!
I will make the above changes.
Thanks!
Madhavan
Powered by blists - more mailing lists