Re: linux-next: runtime warning after merge of the cel-fixes tree

[Chuck Lever III]

Hi Steven-

> On Apr 7, 2022, at 11:13 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> 
> On Thu, 7 Apr 2022 10:54:46 -0400
> Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> 
>> Hmm, I know we added code to handle "__get_sockaddr()" but I guess this
>> should also be fine for "__get_dynamic_array()" as well.
> 
> Does the below patch fix it?
> 
> (not even compiled tested)
> 
> -- Steve
> 
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index e11e167b7809..043b80f3e19a 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -392,8 +392,9 @@ static void test_event_printk(struct trace_event_call *call)
> 			if (!(dereference_flags & (1ULL << arg)))
> 				goto next_arg;
> 
> -			/* Check for __get_sockaddr */;
> -			if (str_has_prefix(fmt + i, "__get_sockaddr(")) {
> +			/* Check for __get_sockaddr or __get_dynamic_array */;
> +			if (str_has_prefix(fmt + i, "__get_sockaddr(") ||
> +			    str_has_prefix(fmt + i, "__get_dynamic_array(")) {
> 				dereference_flags &= ~(1ULL << arg);
> 				goto next_arg;
> 			}

That looks reasonable for present and future kernels.

We're looking for a solution that can be back-ported to stable,
however, because the patch Mr. Rothwell had to revert is meant
to address a NULL pointer deref that was introduced several years
ago. (Otherwise I would have just used __get_sockaddr() and put
my pencil down).

The simplest option is to take a brute-force approach and
convert the sockaddr to a presentation address with an snprintf()
call in the TP_fast_assign() arm of the tracepoints. Allow that
to be carried into -stable as needed; then in v5.19 apply a
clean-up that converts that mess into a proper __get_sockaddr().

That way, it stays my issue to address without needing to
co-ordinate with fixes in other areas.


--
Chuck Lever