All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org,
	Timo Juhani Lindfors <timo.lindfors@iki.fi>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Pavel Emelyanov <xemul@parallels.com>,
	Jiri Kosina <jkosina@suse.cz>,
	Nadia Yvette Chambers <nyc@holomorphy.com>,
	yrl.pp-manager.tt@hitachi.com,
	"David S. Miller" <davem@davemloft.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Re: [PATCH -tip ] [BUGFIX] kprobes: Move hash_64() into .text.kprobe section
Date: Tue, 12 Mar 2013 20:03:55 +0900	[thread overview]
Message-ID: <513F0B9B.5050307@hitachi.com> (raw)
In-Reply-To: <20130312081628.GA30665@gmail.com>

(2013/03/12 17:16), Ingo Molnar wrote:
> 
> * Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:
> 
>> Beacuse hash_64() is called from the get_kprobe() inside
>> int3 handler, kernel causes int3 recursion and crashes if
>> kprobes user puts a probe on it.
>>
>> Usually hash_64() is inlined into caller function, but in
>> some cases, it has instances by gcc's interprocedural
>> constant propagation.
>>
>> This patch adds __kprobes tag on the hash_64() and moves
>> all those instances into .text.kprobe section so that
>> kprobes can refuse probing on the instances.
>>
>> I've ensured that all hash_64 instances moves to the
>> address between __kprobes_text_start and __kprobes_text_end
>> with this patch as below.
>>
>> ffffffff8138bea0 T __kprobes_text_start
>> ffffffff8138bec0 t hash_64.constprop.8
>> ffffffff8138ef98 t hash_64.constprop.26
>> ffffffff8138efae t hash_64
>> ffffffff8138f066 t hash_64.constprop.43
>> ffffffff8138f649 t hash_64.constprop.25
>> ffffffff8139103a t hash_64.constprop.77
>> ffffffff81391050 t hash_64.constprop.24
>> ffffffff81391066 t hash_64.constprop.40
>> ffffffff8139107c t hash_64.constprop.15
>> ffffffff81391092 T __kprobes_text_end
>>
>> Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
>> Reported-by: Timo Juhani Lindfors <timo.lindfors@iki.fi>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Nadia Yvette Chambers <nyc@holomorphy.com>
>> Cc: Pavel Emelyanov <xemul@parallels.com>
>> Cc: Jiri Kosina <jkosina@suse.cz>
>> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
>> ---
>>  include/linux/hash.h |    3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/hash.h b/include/linux/hash.h
>> index 61c97ae..d83f62f 100644
>> --- a/include/linux/hash.h
>> +++ b/include/linux/hash.h
>> @@ -15,6 +15,7 @@
>>   */
>>  
>>  #include <asm/types.h>
>> +#include <linux/kprobes.h>
> 
> I have no objections to the fix itself, but this inclusion of kprobes.h in 
> hash.h is somewhat sad: kprobes.h is a 'fat' header that includes a lot of 
> header files - while hash.h is a really basic type header included in 
> close to a hundred .c files.
> 
> I think one solution would be for the __kprobes definition to move to a 
> more basic header file - such as types.h or compiler.h (where the 
> 'notrace' attribute is placed too), to stop this header dependency creep.

Agreed, that sounds nice to me too!

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com



  reply	other threads:[~2013-03-12 11:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-11 14:22 [PATCH -tip ] [BUGFIX] kprobes: Move hash_64() into .text.kprobe section Masami Hiramatsu
2013-03-12  4:35 ` Ananth N Mavinakayanahalli
2013-03-12  8:16 ` Ingo Molnar
2013-03-12 11:03   ` Masami Hiramatsu [this message]
2013-03-12  8:21 ` Ingo Molnar
2013-03-12 11:07   ` Masami Hiramatsu
2013-03-12 12:09     ` Ingo Molnar
2013-03-12 16:04 ` Linus Torvalds
2013-03-13  6:58   ` Masami Hiramatsu
2013-03-13 13:28     ` Timo Juhani Lindfors
2013-03-13 13:46       ` Masami Hiramatsu
2013-03-18 20:57         ` Timo Juhani Lindfors
2013-03-19  2:53           ` Masami Hiramatsu
2013-03-21 11:39             ` Ingo Molnar
2013-03-21 13:23               ` 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=513F0B9B.5050307@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=davem@davemloft.net \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nyc@holomorphy.com \
    --cc=timo.lindfors@iki.fi \
    --cc=torvalds@linux-foundation.org \
    --cc=xemul@parallels.com \
    --cc=yrl.pp-manager.tt@hitachi.com \
    /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.