All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: lkp@lists.01.org
Subject: Re: [kprobes/x86] a19b2e3d78: WARNING:at_kernel/locking/lockdep.c:#trace_hardirqs_off_caller
Date: Tue, 03 Oct 2017 11:26:28 +0900	[thread overview]
Message-ID: <20171003112628.932b9c9737a609de5ea7772d@kernel.org> (raw)
In-Reply-To: <CA+55aFzNT9VcdbyLTffrYXV10yYAYnKa_taG+7gGdeRfa43CDg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

On Mon, 2 Oct 2017 09:19:10 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Oct 2, 2017 at 8:46 AM, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > I'm considering to remove disabling-irq itself from jprobe.
> > (Frankly to say, I would like to remove jprobe itself...)
> 
> Please please please...
> 
> That would be lovely. The jprobe thing is really nasty, and despite
> the thing having been around forever (looking at history, it does back
> to 2004) there are very few users and they all look dubious to me.
> 
> I seriously doubt anybody uses them, and I suspect our current tracing
> infrastructure is just *so* much better and more powerful than jprobes
> was.

I completely agree. Moreover, jprobe can not handle the functions
which is optimized and modified function type by compiler nowadays.

> So I'd heartily recommend just getting rid of jprobes. Or at least
> trying, and seeing if anybody actually even notices (and then
> reverting the removal and looking at what the usage ends up actually
> being).

OK, should I just make a series to remove jprobes and its few users,
or mark APIs obsolete and remove it after next version?

Thank you,

> 
>                             Linus


-- 
Masami Hiramatsu <mhiramat@kernel.org>

WARNING: multiple messages have this Message-ID (diff)
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	kernel test robot <fengguang.wu@intel.com>,
	Ingo Molnar <mingo@kernel.org>, Alexei Starovoitov <ast@fb.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
	"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	tipbuild@zytor.com, LKP <lkp@01.org>
Subject: Re: [kprobes/x86] a19b2e3d78: WARNING:at_kernel/locking/lockdep.c:#trace_hardirqs_off_caller
Date: Tue, 3 Oct 2017 11:26:28 +0900	[thread overview]
Message-ID: <20171003112628.932b9c9737a609de5ea7772d@kernel.org> (raw)
In-Reply-To: <CA+55aFzNT9VcdbyLTffrYXV10yYAYnKa_taG+7gGdeRfa43CDg@mail.gmail.com>

On Mon, 2 Oct 2017 09:19:10 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Oct 2, 2017 at 8:46 AM, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > I'm considering to remove disabling-irq itself from jprobe.
> > (Frankly to say, I would like to remove jprobe itself...)
> 
> Please please please...
> 
> That would be lovely. The jprobe thing is really nasty, and despite
> the thing having been around forever (looking at history, it does back
> to 2004) there are very few users and they all look dubious to me.
> 
> I seriously doubt anybody uses them, and I suspect our current tracing
> infrastructure is just *so* much better and more powerful than jprobes
> was.

I completely agree. Moreover, jprobe can not handle the functions
which is optimized and modified function type by compiler nowadays.

> So I'd heartily recommend just getting rid of jprobes. Or at least
> trying, and seeing if anybody actually even notices (and then
> reverting the removal and looking at what the usage ends up actually
> being).

OK, should I just make a series to remove jprobes and its few users,
or mark APIs obsolete and remove it after next version?

Thank you,

> 
>                             Linus


-- 
Masami Hiramatsu <mhiramat@kernel.org>

  reply	other threads:[~2017-10-03  2:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-30 23:12 [kprobes/x86] a19b2e3d78: WARNING:at_kernel/locking/lockdep.c:#trace_hardirqs_off_caller kernel test robot
2017-09-30 23:12 ` kernel test robot
2017-10-02  7:33 ` Peter Zijlstra
2017-10-02  7:33   ` Peter Zijlstra
2017-10-02 15:46   ` Masami Hiramatsu
2017-10-02 15:46     ` Masami Hiramatsu
2017-10-02 16:05     ` Peter Zijlstra
2017-10-02 16:05       ` Peter Zijlstra
2017-10-03  1:10       ` Masami Hiramatsu
2017-10-03  1:10         ` Masami Hiramatsu
2017-10-02 16:19     ` Linus Torvalds
2017-10-02 16:19       ` Linus Torvalds
2017-10-03  2:26       ` Masami Hiramatsu [this message]
2017-10-03  2:26         ` Masami Hiramatsu
2017-10-03  7:18 ` [BUGFIX PATCH] kprobes/x86: Remove IRQ disabling from jprobe handlers Masami Hiramatsu
2017-10-03  9:33   ` Ingo Molnar
2017-10-03 15:24     ` Masami Hiramatsu
2017-10-03 17:11       ` Ingo Molnar
2017-10-04  6:18         ` Masami Hiramatsu
2017-10-04 10:41           ` Ingo Molnar
2017-10-04 14:08             ` Masami Hiramatsu
2017-10-05  7:57               ` Ingo Molnar
2017-10-05  8:28                 ` Masami Hiramatsu
2017-10-03 17:43   ` [tip:x86/urgent] " tip-bot for Masami Hiramatsu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171003112628.932b9c9737a609de5ea7772d@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=lkp@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.