All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	prasanna@in.ibm.com, anil.s.keshavamurthy@intel.com,
	davem@davemloft.net
Subject: Re: [patch 1/8] Kprobes - do not use kprobes mutex in arch code
Date: Mon, 16 Jul 2007 11:12:21 -0400	[thread overview]
Message-ID: <20070716151220.GA23133@Krystal> (raw)
In-Reply-To: <20070716102738.GA4276@in.ibm.com>

* Ananth N Mavinakayanahalli (ananth@in.ibm.com) wrote:
> On Sat, Jul 14, 2007 at 03:20:02PM -0400, Mathieu Desnoyers wrote:
> > * Christoph Hellwig (hch@infradead.org) wrote:
> > > On Fri, Jul 13, 2007 at 09:21:34PM -0400, Mathieu Desnoyers wrote:
> > > > Remove the kprobes mutex from kprobes.h, since it does not belong there. Also
> > > > remove all use of this mutex in the architecture specific code, replacing it by
> > > > a proper mutex lock/unlock in the architecture agnostic code.
> > > 
> > > This is not very nice for avr32/sparc64 which have a noop arch_remove_kprobe
> > > and now need to take a mutex to do nothing.  Maybe you can find a nice
> > > way to avoid that?
> > > 
> > > Except for this issue making kprobes_mutex static to kprobes.c sounds like
> > > a good improvement.
> > > 
> > 
> > Since only unregister_kprobe() calls arch_remove_kprobe(), and only
> > after having removed the struct kprobe from the kprobes list (while the
> > kprobes mutex is held), I wonder if there is any need to hold the
> > kprobes mutex at all when calling arch_remove_kprobe(). It turns out
> > that only get_insn_slot()/free_insn_slot() (which is in
> > kernel/kprobes.c, but called from arch specific code) seems to really
> > use protection of this mutex.
> 
> Right.
> 
> > Would it make sense to protect the kprobe_insn_pages list with a
> > new kprobe_insn_mutex, nestable in the kprobe_mutex ?
> 
> Do you think it is required after your change to make kprobe_mutex
> static? But yes, for architectures that don't need a arch_remove_kprobe,
> the situation is a bit odd... a mutex to do nothing. IIRC, that was the
> primary reason why we made the mutex visible outside of kernel/kprobes.c
> 

After making the kprobe_mutex static, the only alternative we have is to
protect the arch_remove_kprobe (empty on some architectures) call with
kprobe_mutex, which, as Christoph pointed out, is not so great. Besides,
I think the kprobe_insn_mutex would make more sense than taking a mutex
in the arch-specific arch_remove_kprobe() for a resource that is not
clearly identified.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2007-07-16 15:12 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-14  1:21 [patch 0/8] Text Edit Lock Mathieu Desnoyers
2007-07-14  1:21 ` [patch 1/8] Kprobes - do not use kprobes mutex in arch code Mathieu Desnoyers
2007-07-14 10:49   ` Christoph Hellwig
2007-07-14 19:20     ` Mathieu Desnoyers
2007-07-16 10:27       ` Ananth N Mavinakayanahalli
2007-07-16 15:12         ` Mathieu Desnoyers [this message]
2007-07-14 19:30     ` Mathieu Desnoyers
2007-07-14 19:51     ` [PATCH] Kprobes - use a mutex to protect the instruction pages list Mathieu Desnoyers
2007-07-17  5:38       ` Ananth N Mavinakayanahalli
2007-07-14 19:52     ` [PATCH] Kprobes - Declare kprobe_mutex static Mathieu Desnoyers
2007-07-17  5:39       ` Ananth N Mavinakayanahalli
2007-07-17  5:38   ` [patch 1/8] Kprobes - do not use kprobes mutex in arch code Ananth N Mavinakayanahalli
2007-07-14  1:21 ` [patch 2/8] Text Edit Lock - Architecture Independent Code Mathieu Desnoyers
2007-07-14 22:55   ` [PATCH] Immediate Values - Architecture Independent Code - Fixes following HCH comments Mathieu Desnoyers
2007-07-14 22:57     ` (drop : wrong email thread) " Mathieu Desnoyers
2007-07-15  1:28   ` [PATCH] Text Edit Lock - Architecture Independent Code - kerneldoc Mathieu Desnoyers
2007-07-15  9:04     ` Christoph Hellwig
2007-07-15 23:30     ` Mathieu Desnoyers
2007-07-15 23:35   ` [PATCH] Text Edit Lock - Architecture Independent Code for Implementation Mathieu Desnoyers
2007-07-14  1:21 ` [patch 3/8] Text Edit Lock - i386 Mathieu Desnoyers
2007-07-14 16:18   ` Christoph Hellwig
2007-07-14 20:08     ` [PATCH] Text Edit Lock - i386 Use kernel_text_is_ro Mathieu Desnoyers
2007-07-14 23:31   ` [PATCH] Text Edit Lock - i386 Fix endif CONFIG_DEBUG_RODATA Mathieu Desnoyers
2007-07-15  1:29     ` [PATCH] Text Edit Lock - i386 kerneldoc Mathieu Desnoyers
2007-07-15 23:30       ` Mathieu Desnoyers
2007-07-15 23:36   ` [PATCH] Text Edit Lock - i386 kerneldoc implementation Mathieu Desnoyers
2007-07-14  1:21 ` [patch 4/8] Text Edit Lock - x86_64 Mathieu Desnoyers
2007-07-14 20:16   ` [PATCH] Text Edit Lock - x86_64 Use kernel_tex_is_ro Mathieu Desnoyers
2007-07-14 23:32   ` [PATCH] Text Edit Lock - x86_64 Fix !CONFIG_DEBUG_RODATA Mathieu Desnoyers
2007-07-15  1:30     ` [PATCH] Text Edit Lock - x86_64 kerneldoc Mathieu Desnoyers
2007-07-15 23:30       ` Mathieu Desnoyers
2007-07-15 23:38   ` [PATCH] Text Edit Lock - x86_64 kerneldoc implementation Mathieu Desnoyers
2007-07-14  1:21 ` [patch 5/8] Text Edit Lock - Alternative code for i386 and x86_64 Mathieu Desnoyers
2007-07-14  1:21 ` [patch 6/8] Text Edit Lock - Kprobes architecture independent support Mathieu Desnoyers
2007-07-14 19:56   ` [PATCH] Kprobes - no kprobes_mutex needed around arch_remove_kprobe calls Mathieu Desnoyers
2007-07-14  1:21 ` [patch 7/8] Text Edit Lock - kprobes i386 Mathieu Desnoyers
2007-07-14  1:21 ` [patch 8/8] Text Edit Lock - kprobes x86_64 Mathieu Desnoyers
2007-07-14 10:50 ` [patch 0/8] Text Edit Lock Christoph Hellwig
2007-07-14 15:21   ` Mathieu Desnoyers

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=20070716151220.GA23133@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=davem@davemloft.net \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prasanna@in.ibm.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.