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]

Message-ID: <20150820130558.4f3a2e35@grimm.local.home>
Date:	Thu, 20 Aug 2015 13:05:58 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Dean Nelson <dnelson@...hat.com>
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 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.

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

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