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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ