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]
Message-ID: <55D614C9.8080503@redhat.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ