[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180518062034.GB27960@gmail.com>
Date: Fri, 18 May 2018 08:20:34 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
Ingo Molnar <mingo@...hat.com>,
"H . Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Steven Rostedt <rostedt@...dmis.org>,
Laura Abbott <labbott@...hat.com>, Josef Bacik <jbacik@...com>,
Alexei Starovoitov <ast@...nel.org>,
Ravi Bangoria <ravi.bangoria@...ux.vnet.ibm.com>
Subject: Re: [PATCH -tip v3 4/7] kprobes: Ignore break_handler
* Masami Hiramatsu <mhiramat@...nel.org> wrote:
> Ignore break_handler related code because it was only
> used by jprobe and jprobe is removed.
I changed this description to:
============
Subject: kprobes: Don't call the ->break_handler() in generic kprobes code
Don't call the ->break_handler() from the core kprobes code, because it was only
used by jprobes which got removed.
( In a followup patch we'll remove the remaining calls in low level
arch handlers as well and remove the callback altogether. )
============
Please try to be a lot less vague in changelogs when it's possible and relevant!
I.e. saying "Ignore break_handler related code" is annoyingly vague, it doesn't
explain things well at all. Saying "Don't call the ->break_handler()" is just as
compact, yet it also makes it very clear what's done in the patch...
Thanks,
Ingo
Powered by blists - more mailing lists