netdev - Re: [PATCH 27/53] perf/core: Put size of a sample at the end of it by PERF_SAMPLE

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: <20160112195641.GA34601@ast-mbp.thefacebook.com>
Date:	Tue, 12 Jan 2016 11:56:41 -0800
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	"Wangnan (F)" <wangnan0@...wei.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>, acme@...nel.org,
	linux-kernel@...r.kernel.org, pi3orama@....com, lizefan@...wei.com,
	netdev@...r.kernel.org, davem@...emloft.net,
	Adrian Hunter <adrian.hunter@...el.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	David Ahern <dsahern@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Yunlong Song <yunlong.song@...wei.com>
Subject: Re: [PATCH 27/53] perf/core: Put size of a sample at the end of it
 by PERF_SAMPLE_TAILSIZE

On Tue, Jan 12, 2016 at 08:36:23PM +0800, Wangnan (F) wrote:
> >hmm, in this kernel patch I see that you're adding 8 bytes for
> >every record via this extra TAILSISZE flag and in perf you're
> >walking the ring buffer backwards by reading this 8 byte
> >sizes, comparing header sizes and so on until reaching beginning,
> >where you start dumping it as normal.
> >So for this 'signal to perf' approach to work the ring buffer
> >will contain tailsizes everywhere just so that user space can
> >find the beginning. That's not very pretty. imo if kernel
> >can do header read to adjust data_tail it would make user
> >space side clean. May be there are other solutions.
> >Adding tailsize seems like brute force hack.
> >There must be some nicer way.
> Hi Peter,
> 
>  What's your opinion? Should we reconsider moving size field from header the
> end?
> Or moving whole header to the end of a record?

I think moving the whole header under new TAILHEADER flag is
actually very good idea. The ring buffer will be fully utilized
and no extra bytes necessary. User space would need to parse it
backwards, but for this use case it fits well.