[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <E23F5174-F706-40FC-9072-143B04905208@oracle.com>
Date: Tue, 25 Jan 2022 15:38:22 +0000
From: Chuck Lever III <chuck.lever@...cle.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: Stephen Rothwell <sfr@...b.auug.org.au>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Anna Schumaker <Anna.Schumaker@...app.com>,
Trond Myklebust <trondmy@...il.com>,
Linux NFS Mailing List <linux-nfs@...r.kernel.org>
Subject: Re: linux-next: runtime warning in next-20220125
> On Jan 25, 2022, at 10:36 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Tue, 25 Jan 2022 10:01:38 -0500
> Steven Rostedt <rostedt@...dmis.org> wrote:
>
>> On Tue, 25 Jan 2022 16:21:46 +1100
>> Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> On Tue, 25 Jan 2022 16:05:05 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>>>>
>>>> My qemu boot test of a powerpc pseries_le_defconfig kernel produces the
>>>> following trace:
>>>>
>>>> ------------[ cut here ]------------
>>>> WARNING: CPU: 0 PID: 0 at kernel/trace/trace_events.c:417 trace_event_raw_init+0x194/0x730
>>>> Modules linked in:
>>>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1 #2
>>>> NIP: c0000000002bdbb4 LR: c0000000002bdcb0 CTR: c0000000002bdb70
>>>>
>>>> I have no idea what has caused this :-( Maybe commit
>>>>
>>>> 5544d5318802 ("SUNRPC: Same as SVC_RQST_ENDPOINT, but without the xid")
>>>
>>> Actually, reverting commits
>>>
>>> 6ff851d98af8 ("SUNRPC: Improve sockaddr handling in the svc_xprt_create_error trace point")
>>> 5544d5318802 ("SUNRPC: Same as SVC_RQST_ENDPOINT, but without the xid")
>>> e2d3613db12a ("SUNRPC: Record endpoint information in trace log")
>>>
>>> makes the warning go away.
>>>
>>
>> We added a new way to save items on the ring buffer, but did not update the
>> safety checks to know about them. I'll fix this shortly.
>>
>
> This should fix it:
>
> I'll make it a real patch and start running it through my tests.
Should this be squashed into the patch that adds __get_sockaddr() ?
I have an updated version of that patch that applies on kernels
that have __rel_dynamic_array.
> -- Steve
>
>
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 3147614c1812..f527ae807e77 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -384,6 +384,12 @@ 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(")) {
> + dereference_flags &= ~(1ULL << arg);
> + goto next_arg;
> + }
> +
> /* Find the REC-> in the argument */
> c = strchr(fmt + i, ',');
> r = strstr(fmt + i, "REC->");
--
Chuck Lever
Powered by blists - more mailing lists