Re: [BUGFIX PATCH] kprobes/x86: Remove IRQ disabling from jprobe handlers

[Ingo Molnar]

* Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote:

> On Wed, 4 Oct 2017 12:41:01 +0200
> Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> 
> > 
> > * Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote:
> > 
> > > Hmm, actually we can not disable jprobe, that has no separate Kconfig.
> > > So we need to introduce new kconfig for that.
> > > 
> > > And, there are several network protocols using jprobe to trace events.
> > > (e.g. NET_DCCPPROBE and NET_TCPPROBE)
> > > I think they need to migrate to trace-event at first.
> > > 
> > > So, how about below idea?
> > > 
> > > 1. Introduce CONFIG_JPROBE_API which only separate jprobe general parts
> > >      (no arch dependent code involves) and make it default n.
> > > 2. Mark break_handler and jprobe APIs deprecated so that no new user comes up.
> > > 3. migrate in-kernel jprobe user to trace-event or ftrace.
> > >    (may take some time)
> > 
> > So my suggestion would be to just return from register_jprobe() and don't register 
> > anything.
> 
> with CONFIG_JPROBE_API=n, is that right?

No, unconditionally off with a WARN_ON_ONCE() warning in the registry function and 
the deactivation of all in-kernel uses (such as self-tests).

The point is to make people that _truly_ rely on it complain - not just make them 
silently turn on a Kconfig option ...

> > Yes, there are usecases of jprobes in the kernel, but they all look 
> > pretty ancient and unused.
> 
> Hmm, in that case, should we also remove those users? If we disable such way
> those features are just useless.

My hypothesis is that those features are not used (hence useless), but we should 
first test whether there's any reliance before we remove code.

Thanks,

	Ingo