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