linux-kernel - Re: perf script: rwtop: SIGALRM and pipe read race

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: <20120917171257.GD31375@ghostprotocols.net>
Date:	Mon, 17 Sep 2012 10:12:58 -0700
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	David Ahern <dsahern@...il.com>
Cc:	Andrew Jones <drjones@...hat.com>, linux-kernel@...r.kernel.org,
	a.p.zijlstra@...llo.nl, paulus@...ba.org, mingo@...hat.com,
	tzanussi@...il.com
Subject: Re: perf script: rwtop: SIGALRM and pipe read race

Em Mon, Sep 17, 2012 at 10:32:36AM -0600, David Ahern escreveu:
> On 9/17/12 10:02 AM, Arnaldo Carvalho de Melo wrote:
> >Em Mon, Sep 17, 2012 at 09:16:19AM -0600, David Ahern escreveu:
> >>On 9/17/12 8:55 AM, David Ahern wrote:
> >>>2. the rwtop.pl script is not handling negative return values ($ret < 0)
> >>>properly -- the '$ret > 0' check is succeeding even though $ret is
> >>>negative (e.g., -EAGAIN) leading to astronomical read values
> >>
> >>I think perl is treating $ret as an unsigned integer.
> >>
> >>Again, I know little about perl, but this change to
> >>./scripts/perl/rwtop.pl makes it behave properly:
> >>
> >>     my $n = sprintf("%d", $ret);
> >>
> >>     if ($n > 0) {

> >
> >I think what you figured out makes sense, its the best we have and you
> >found it to get it back working, could you please send the two patches
> >properly signed-off, etc?
> 
> I'll do that for the readn.
> 
> The above change seems like a workaround - not a proper fix. Why is
> perl treating it like an unsigned int? The trace format for the read
> syscall shows long. How is the binding done for perl? I can't make
> heads or tails of it scanning the files under perl. If we are forced
> to do a hack like the above is there a better way? I tried (int)
> $ret and perl did not like that. Any other (better) options?

Its possible that changes made to support non tracepoint events
introduced this problem, so perhaps bisecting it, as this wasn't present
some time ago, i.e. those big numbers :-\

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