On Wed, Jan 28, 2015 at 10:41 PM, Namhyung Kim [off-list ref] wrote:
I think it's not a problem of bpf. An user process can be killed
anytime while it enabed events without bpf. The only thing it should
care is the auto-unload IMHO.
ok. I think it does indeed make sense to decouple the logic.
We can add 'auto_enable' file to achieve desired Ctrl-C behavior.
While the 'auto_enable' file is open the event will be enabled
and writes to 'enable' file will be ignored.
As soon as file closes, the event is auto-disabled.
Then user space will use 'bpf' file to attach/auto-unload
and 'auto_enable' file together.
Seem there would be a use for such 'auto_enable'
without bpf as well.
I'm okay for not calling bpf program in NMI but not for disabling events.
Suppose an user was collecting an event (including in NMI) and then
[s]he also wanted to run a bpf program. So [s]he wrote a program
always return 1. But after attaching the program, it didn't record
the event in NMI.. Isn't that a problem?
ok, I think 'if (in_nmi()) return 1;' will work then, right?
Or you're thinking something else ?
Right. I think bpf programs belong to a user process but events are
global resource. Maybe you also need to consider attaching bpf
program via perf (ioctl?) interface..
yes. I did. Please see my reply to Masami.
ioctl only works for tracepoints.
On Thu, Jan 29, 2015 at 4:04 PM, Alexei Starovoitov [off-list ref] wrote:
On Wed, Jan 28, 2015 at 10:41 PM, Namhyung Kim [off-list ref] wrote:
quoted
I think it's not a problem of bpf. An user process can be killed
anytime while it enabed events without bpf. The only thing it should
care is the auto-unload IMHO.
ok. I think it does indeed make sense to decouple the logic.
We can add 'auto_enable' file to achieve desired Ctrl-C behavior.
While the 'auto_enable' file is open the event will be enabled
and writes to 'enable' file will be ignored.
As soon as file closes, the event is auto-disabled.
Then user space will use 'bpf' file to attach/auto-unload
and 'auto_enable' file together.
Seem there would be a use for such 'auto_enable'
without bpf as well.
Why do you want such an 'auto_enable' feature? I guess it's enough
just to keep an event in the soft-disabled state and run a bpf program
before the check.
quoted
I'm okay for not calling bpf program in NMI but not for disabling events.
Suppose an user was collecting an event (including in NMI) and then
[s]he also wanted to run a bpf program. So [s]he wrote a program
always return 1. But after attaching the program, it didn't record
the event in NMI.. Isn't that a problem?
ok, I think 'if (in_nmi()) return 1;' will work then, right?
Or you're thinking something else ?
Nope, returning 1 would be okay..
quoted
Right. I think bpf programs belong to a user process but events are
global resource. Maybe you also need to consider attaching bpf
program via perf (ioctl?) interface..
yes. I did. Please see my reply to Masami.
ioctl only works for tracepoints.
What was the problem of kprobes then? :)
Thanks,
Namhyung