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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150820190518.GA3154@kernel.org>
Date:	Thu, 20 Aug 2015 16:05:18 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Dean Nelson <dnelson@...hat.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>, a.p.zijlstra@...llo.org,
	mingo@...hat.com, 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

Em Thu, Aug 20, 2015 at 12:56:25PM -0500, Dean Nelson escreveu:
> 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.

Ok, so I'll use Steven's text and will stick a Reviewed-by: Steven, ack?

- Arnaldo
--
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