linux-kernel - Re: [PATCH v3] tools lib traceevent: add checks for returned EVENT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Aug 2015 12:56:25 -0500
From:	Dean Nelson <dnelson@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	a.p.zijlstra@...llo.org, mingo@...hat.com, acme@...nel.org,
	namhyung@...nel.org, linux-kernel@...r.kernel.org, jolsa@...nel.org
Subject: Re: [PATCH v3] tools lib traceevent: add checks for returned
 EVENT_ERROR type

On 08/20/2015 12:05 PM, Steven Rostedt wrote:
> On Thu, 20 Aug 2015 11:16:32 -0400
> Dean Nelson <dnelson@...hat.com> wrote:
>
>> Running the following perf-stat command on an arm64 system produces the
>> following result...
>>
>>    [root@...ch64 ~]# perf stat -e kmem:mm_page_alloc -a sleep 1
>>      Warning: [kmem:mm_page_alloc] function sizeof not defined
>>      Warning: Error: expected type 4 but read 0
>>    Segmentation fault
>>    [root@...ch64 ~]#
>>
>> The second warning message and SIGSEGV stem from the issue expressed in the
>> first warning message, and are the result of ignoring the EVENT_ERROR type
>> returned back through the call chain.
>>
>> Dealing with the first warning message is beyond the scope of this patch. But
>> the second warning is addressed by this patch's first hunk. And the SIGSEGV is
>> eliminated by its second hunk.
>
> Patch looks fine, but this change log is lacking. I don't think you
> need to resend though. But Arnaldo, can you add more to this change log
> to describe the following, and that's only if I got it right ;-) If I
> didn't get it right, then the change log definitely needs to be
> explained better.

No you definitely got it right.

I thought that was what I was saying by the paragraph beginning with
"The second warning...", with the notion that the 2nd warning and
SIGSEGV "stem from" the 1st warning. And that the latter two issues "are
the result of ignoring the EVENT_ERROR" encountered by the 1st
warning's issue.

At least that is what that paragraph was intended to be all about.
Obviously I failed to communicate.

Yours is clear to me. So why not just replace my poorly done paragraph
with your good  paragraph...


> ====
> The second warning was a result of the first warning not stopping
> processing after it detected the issue. That is, code that found the
> issue reported the first problem, but because it did not exit out of
> the functions smoothly, it caused the other warning to appear and not
> only that, it later caused the SIGSEGV.
> ====

Thanks for the review.


>
> -- Steve
>
> Other than that...
>
> Acked-by: Steven Rostedt <rostedt@...dmis.org.
>
>
>
>>
>> Signed-off-by: Dean Nelson <dnelson@...hat.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/