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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox