Re: [patch 05/24] Text Edit Lock - Architecture Independent Code

2007-12-21 Thread Mathieu Desnoyers
e it is useless, I don't see how this patch snippet applies to my patchset at all. If you suggest to change the way locking is currently done in kprobes, please do this in a separate thread, as a RFC ? Mathieu > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mai

RE: [patch 05/24] Text Edit Lock - Architecture Independent Code

2007-12-20 Thread zhangxiliang
{ > > mutex_lock(&kprobe_mutex); > > if (p->break_handler) > > I think "mutex_lock" and "mutex_unlock" shoud be in architecture code. > In "__register_kprobe" funtion, its implement > "arch_prepare_kprobe&quo

RE: [patch 05/24] Text Edit Lock - Architecture Independent Code

2007-12-20 Thread zhangxiliang
the other embeded system chips in future. > -Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Mathieu Desnoyers > Sent: Friday, December 21, 2007 9:55 AM > To: [EMAIL PROTECTED]; Ingo Molnar; > linux-kernel@vger.kernel.org > Cc: Mathieu

[patch 05/24] Text Edit Lock - Architecture Independent Code

2007-12-20 Thread Mathieu Desnoyers
This is an architecture independant synchronization around kernel text modifications through use of a global mutex. A mutex has been chosen so that kprobes, the main user of this, can sleep during memory allocation between the memory read of the instructions it must replace and the memory write of