netdev - Re: [PATCH v3 net-next] bpf: fix bpf_perf_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: <562D0208.7090608@plumgrid.com>
Date:	Sun, 25 Oct 2015 09:23:36 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	"David S. Miller" <davem@...emloft.net>,
	Wang Nan <wangnan0@...wei.com>, He Kuang <hekuang@...wei.com>,
	Kaixu Xia <xiakaixu@...wei.com>,
	Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 net-next] bpf: fix bpf_perf_event_read() helper

On 10/25/15 2:21 AM, Ingo Molnar wrote:
> Then old crap can be de-emphasised and eventually removed, instead of having to
> live with crap forever ...

strongly disagree. none of the helpers are 'crap'.
bpf_perf_event_read() muxes of -EINVAL into return value, but it's non
ambiguous to the program whether it got an error or real counter value.
So it's not pretty, but it's a reasonable trade off.
Properly written bpf programs will not be hitting the error path (which
is there for safety and protection against buggy programs) and will
consume return value without any extra checks.
bpf_perf_event_read() could have been done via passing a pointer to
stack where counter value can be stored, but that is much slower,
since program would need to init the stack and pass pointers while
helpers are not inlined, so the cost of return via stack is higher
than returning by value. In this case bpf_perf_event_read() can be hot,
so makes sense to optimize and sacrifice 'pretty' factor.

All existing helpers have use cases behind them and none overlap,
so not a single one can be 'deprecated'.
In general I don't think it's worth to make an exception in the kernel
that some interfaces are not ABI. That will give a bad impression on
the kernel overall. Either we have generic deprecation mechanism for
everything or none and my vote is for none.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html