From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0216254405918563221==" MIME-Version: 1.0 From: Masami Hiramatsu 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 Message-ID: <20171003112628.932b9c9737a609de5ea7772d@kernel.org> In-Reply-To: List-Id: --===============0216254405918563221== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, 2 Oct 2017 09:19:10 -0700 Linus Torvalds wrote: > On Mon, Oct 2, 2017 at 8:46 AM, Masami Hiramatsu = 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 --===============0216254405918563221==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751267AbdJCC0d (ORCPT ); Mon, 2 Oct 2017 22:26:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:58044 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751120AbdJCC0c (ORCPT ); Mon, 2 Oct 2017 22:26:32 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E0962188D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=mhiramat@kernel.org Date: Tue, 3 Oct 2017 11:26:28 +0900 From: Masami Hiramatsu To: Linus Torvalds Cc: Peter Zijlstra , kernel test robot , Ingo Molnar , Alexei Starovoitov , Alexei Starovoitov , Ananth N Mavinakayanahalli , "Paul E . McKenney" , Steven Rostedt , Thomas Gleixner , LKML , "H. Peter Anvin" , tipbuild@zytor.com, LKP Subject: Re: [kprobes/x86] a19b2e3d78: WARNING:at_kernel/locking/lockdep.c:#trace_hardirqs_off_caller Message-Id: <20171003112628.932b9c9737a609de5ea7772d@kernel.org> In-Reply-To: References: <20170930231251.emiuyrapdgzpcylp@inn> <20171002073316.aw6aueg7rimqnuoq@hirez.programming.kicks-ass.net> <20171003004605.8da2be5a86be135f792d29bd@kernel.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2 Oct 2017 09:19:10 -0700 Linus Torvalds wrote: > On Mon, Oct 2, 2017 at 8:46 AM, Masami Hiramatsu 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