From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Masami Hiramatsu <mhiramat@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
hpa@zytor.com, mingo@redhat.com, torvalds@linux-foundation.org,
tglx@linutronix.de, linux-kernel@vger.kernel.org,
linux-tip-commits@vger.kernel.org
Subject: Re: [tip:x86/mm] x86, mm, kprobes: fault.c, simplify notify_page_fault()
Date: Tue, 24 Feb 2009 00:16:16 +0530 [thread overview]
Message-ID: <20090223184616.GA10588@in.ibm.com> (raw)
In-Reply-To: <20090222093109.GE6964@elte.hu>
On Sun, Feb 22, 2009 at 10:31:09AM +0100, Ingo Molnar wrote:
>
> * Masami Hiramatsu <mhiramat@redhat.com> wrote:
>
> > Ingo Molnar wrote:
> > > Author: Ingo Molnar <mingo@elte.hu>
> > > AuthorDate: Fri, 20 Feb 2009 22:42:57 +0100
> > > Commit: Ingo Molnar <mingo@elte.hu>
> > > CommitDate: Sat, 21 Feb 2009 00:09:42 +0100
> > >
> > > x86, mm, kprobes: fault.c, simplify notify_page_fault()
> > >
> > > Impact: cleanup
> > >
> > > Remove an #ifdef from notify_page_fault(). The function still
> > > compiles to nothing in the !CONFIG_KPROBES case.
> > >
> > > Introduce kprobes_built_in() and kprobe_fault_handler() helpers
> > > to allow this - they returns 0 if !CONFIG_KPROBES.
> > >
> > > No code changed:
> > >
> > > text data bss dec hex filename
> > > 4618 32 24 4674 1242 fault.o.before
> > > 4618 32 24 4674 1242 fault.o.after
> >
> > It seems good for me. Thank you for cleanup!
> >
> > Acked-by: Masami Hiramatsu <mhiramat@redhat.com>
>
> another very small thing, while we are discussing kprobes:
>
> I always found that the __kprobes annotation is very confusingly
> euphemistic: what those annotations really mean is not
> 'kprobes', but 'no kprobes'.
Right!
> So how about renaming __kprobes to __nokprobes, similar to how
> we have the notrace attribute?
>
> We have about 350 __kprobes annotations in the kernel, so
> renaming it now would not be practical - but any objections
> against me sending Linus a rename patch somewhere late in the
> next merge window that just does this rename?
No issues with that.
Ananth
prev parent reply other threads:[~2009-02-23 18:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <tip-b18018126f422f5b706fd750373425e10e84b486@kernel.org>
2009-02-20 23:09 ` [tip:x86/mm] x86, mm, kprobes: fault.c, simplify notify_page_fault() Masami Hiramatsu
2009-02-22 9:31 ` Ingo Molnar
2009-02-23 16:21 ` Masami Hiramatsu
2009-02-23 18:46 ` Ananth N Mavinakayanahalli [this message]
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=20090223184616.GA10588@in.ibm.com \
--to=ananth@in.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.