On Thu, 1 Apr 2021 00:02:57 +0200
Vasily Gorbik wrote:
> I only tested it on s390 (manually + ftrace selftest), quite frankly.
> If it qualifies:
You reported the bug, thus tested-by from the reporter always
qualifies ;-)
>
> Tested-by: Vasily Gorbik # s390 only
Thanks,
-- Steve
On Wed, Mar 31, 2021 at 05:09:00PM -0400, Steven Rostedt wrote:
> On Wed, 31 Mar 2021 22:51:15 +0200
> Vasily Gorbik wrote:
>
> > It does! Thanks for the explanation and for the fix. I wonder why nobody
> > noticed and complained about that since v5.6.
>
> Because it didn't lose data, just
On Wed, 31 Mar 2021 22:51:15 +0200
Vasily Gorbik wrote:
> It does! Thanks for the explanation and for the fix. I wonder why nobody
> noticed and complained about that since v5.6.
Because it didn't lose data, just added extra junk.
>
> Acked-by: Vasily Gorbik
Want to give a "tested-by" too?
On Wed, Mar 31, 2021 at 10:37:49AM -0400, Steven Rostedt wrote:
> But after writing all of the above, I think I found a bug! It's this:
>
> size = nr_entries * sizeof(unsigned long);
> event = __trace_buffer_lock_reserve(buffer, TRACE_STACK,
>
On Wed, 31 Mar 2021 13:52:45 +0200
Vasily Gorbik wrote:
> Hi Steven,
>
> At least on s390 since commit cbc3b92ce037 ("tracing: Set kernel_stack's
> caller size properly") kernel stack trace contains 8 garbage values in the
> end.
> I assume those are supposed to be filled by
Hi Steven,
At least on s390 since commit cbc3b92ce037 ("tracing: Set kernel_stack's
caller size properly") kernel stack trace contains 8 garbage values in the end.
I assume those are supposed to be filled by ftrace_trace_userstack, which is
only implemented on x86.
sshd-804 [050]
6 matches
Mail list logo
