linux-kernel - Re: [RFC PATCH 0/6] perf bpf: Probing with local variable

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: <55499453.7070509@plumgrid.com>
Date:	Tue, 05 May 2015 21:10:59 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	Wang Nan <wangnan0@...wei.com>, He Kuang <hekuang@...wei.com>,
	davem@...emloft.net, acme@...nel.org, mingo@...hat.com,
	a.p.zijlstra@...llo.nl, masami.hiramatsu.pt@...achi.com,
	jolsa@...nel.org
CC:	linux-kernel@...r.kernel.org, pi3orama@....com
Subject: Re: [RFC PATCH 0/6] perf bpf: Probing with local variable

On 5/5/15 8:58 PM, Wang Nan wrote:
>> Two high level comments:
>> - can you collapse SEC("config") with SEC("func_name") ?
>> It seems that "func_name" is only used as reference inside "config".
>> I understand that you're proposing one "config" section where multiple
>> descriptions are strcat together, but why? Something like:
>> SEC("kprobe/generic_perform_write+122(file->f_mapping->a_ops, bytes, offset)")
>> int func(...) { ... }
>> should be enough and more concise.
>>
>
> Is it possible to use such a long section name? I introduce 'config' section

yes. of course. I don't know what is the limit, but it's definitely
above 512 characters. It can contains spaces and special chars too.

> since it contains C strings so I can put things to it freely. By using macro trick,
> we can still use not very complex code to describe probing position like this:
>
> #define PROBE(name, config) \
> SEC("config") char name##_config[] = #name config ; \
> SEC(#name)
> PROBE(generic_perform_write, "kprobe: +122(file->f_mapping->a_ops, bytes, offset)")

that's even more obscure :( why hide it behind macros?
I think single 'SEC' macro is already not very clean, but I couldn't
come up with better alternative. Elf sections are free that why I used
them in samples/bpf/ examples, but let's not overuse them.

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