All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@redhat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Nick Piggin <npiggin@suse.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andi Kleen <andi@firstfloor.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Arjan van de Ven <arjan@infradead.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH -tip 5/4] Expands irq-off region in text_poke()
Date: Fri, 06 Mar 2009 16:57:47 -0500	[thread overview]
Message-ID: <49B19C5B.30805@redhat.com> (raw)
In-Reply-To: <20090306210116.GB20603@Krystal>



Mathieu Desnoyers wrote:
> * Masami Hiramatsu (mhiramat@redhat.com) wrote:
>> Ingo Molnar wrote:
>>> * Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
>>>
>>>> * Ingo Molnar (mingo@elte.hu) wrote:
>>>>> * Masami Hiramatsu <mhiramat@redhat.com> wrote:
>>>>>
>>>>>> @@ -523,14 +526,17 @@ void *__kprobes text_poke(void *addr, co
>>>>>>  		pages[1] = virt_to_page(addr + PAGE_SIZE);
>>>>>>  	}
>>>>>>  	BUG_ON(!pages[0]);
>>>>>> -	if (!pages[1])
>>>>>> -		nr_pages = 1;
>>>>>> -	vaddr = vmap(pages, nr_pages, VM_MAP, PAGE_KERNEL);
>>>>>> -	BUG_ON(!vaddr);
>>>>>> -	local_irq_disable();
>>>>>> +	local_irq_save(flags);
>>>>>> +	set_fixmap(FIX_TEXT_POKE0, page_to_phys(pages[0]));
>>>>>> +	if (pages[1])
>>>>>> +		set_fixmap(FIX_TEXT_POKE1, page_to_phys(pages[1]));
>>>>>> +	vaddr = (char *)fix_to_virt(FIX_TEXT_POKE0);
>>>>>>  	memcpy(&vaddr[(unsigned long)addr & ~PAGE_MASK], opcode, len);
>>>>>> -	local_irq_enable();
>>>>>> -	vunmap(vaddr);
>>>>>> +	clear_fixmap(FIX_TEXT_POKE0);
>>>>>> +	if (pages[1])
>>>>>> +		clear_fixmap(FIX_TEXT_POKE1);
>>>>>> +	local_flush_tlb();
>>>>>> +	local_irq_restore(flags);
>>>>>>  	sync_core();
>>>>> I'm not sure at all about this widening of the irq-atomic 
>>>>> section and the idea of allowing non-locked access on single-CPU 
>>>>> situations - we dont really want to micro-optimize any of this 
>>>>> on such a level, holding the text lock is a robust rule all code 
>>>>> should be listening to. (Creating locking assymetry always 
>>>>> inserts a certain amount of fragility - adding to an already 
>>>>> fragile concept here.)
>>>>>
>>>>> And note that there's no reason why text_poke could not be used 
>>>>> in stop_machine_run() - the stop_machine_run() handler must not 
>>>>> take the text_lock of course - but outside code calling 
>>>>> stop_machine_run() can do it and can hence serialize properly.
>>>>>
>>>>> Note that even if we did this then your v2 patch is not fully 
>>>>> correct: you need to move the sync_core() at the end of the 
>>>>> sequence inside the critical section too. (right now this is 
>>>>> mostly harmless because the INVLPG inside the clear_fixmap() 
>>>>> happens to be serializing so it has an implicit sync_core() 
>>>>> property - but nevertheless we better do this straight away to 
>>>>> not cause problems later down the line.)
>>>>>
>>>>> 	Ingo
>>>> Agreed. The alternatives_smp_lock/alternatives_smp_unlock 
>>>> specific case does not bring us much if it has no perceivable 
>>>> performance impact. It's better to keep a standard interface 
>>>> and clear requirements.
>>> Note that i dont object to another aspect of this same change: 
>>> the fact that it makes the whole sequence more atomic and more 
>>> defensive [which is never bad of fragile interfaces].
>>>
>>> I only got worried about the "lets use this without the text 
>>> lock" ideas.
>>>
>>> So if Masami-san sends a delta patch with a different changelog 
>>> and with the sync_core() bit moved inside the critical section, 
>>> i'll apply that too.
>> OK, here is the delta patch.
>>
>> Expand irq-atomic region to cover fixmap using code and sync_core.
>>
>> Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
>> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
>> Cc: Ingo Molnar <mingo@elte.hu>
>> ---
>>  arch/x86/kernel/alternative.c |    4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Index: linux-2.6-tip/arch/x86/kernel/alternative.c
>> ===================================================================
>> --- linux-2.6-tip.orig/arch/x86/kernel/alternative.c
>> +++ linux-2.6-tip/arch/x86/kernel/alternative.c
>> @@ -526,13 +526,12 @@ void *__kprobes text_poke(void *addr, co
>>  		pages[1] = virt_to_page(addr + PAGE_SIZE);
>>  	}
>>  	BUG_ON(!pages[0]);
>> +	local_irq_save(flags);
>>  	set_fixmap(FIX_TEXT_POKE0, page_to_phys(pages[0]));
>>  	if (pages[1])
>>  		set_fixmap(FIX_TEXT_POKE1, page_to_phys(pages[1]));
>>  	vaddr = (char *)fix_to_virt(FIX_TEXT_POKE0);
>> -	local_irq_save(flags);
>>  	memcpy(&vaddr[(unsigned long)addr & ~PAGE_MASK], opcode, len);
>> -	local_irq_restore(flags);
>>  	clear_fixmap(FIX_TEXT_POKE0);
>>  	if (pages[1])
>>  		clear_fixmap(FIX_TEXT_POKE1);
>> @@ -540,6 +539,7 @@ void *__kprobes text_poke(void *addr, co
>>  	sync_core();
>>  	/* Could also do a CLFLUSH here to speed up CPU recovery; but
>>  	   that causes hangs on some VIA CPUs. */
>> +	local_irq_restore(flags);
>>  	for (i = 0; i < len; i++)
>>  		BUG_ON(((char *)addr)[i] != ((char *)opcode)[i]);
> 
> I think irq off should cover the BUG_ON too. This safety check assumes
> we are the only ones modifying "addr".

I think others don't change without text_mutex, don't it?

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com


  reply	other threads:[~2009-03-06 21:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-06 15:34 [PATCH -tip 0/4] Text edit lock and atomic text_poke() Masami Hiramatsu
2009-03-06 15:35 ` [PATCH -tip 1/4] Text Edit Lock - Architecture Independent Code (v2) Masami Hiramatsu
2009-03-08 15:51   ` [tip:tracing/core] tracing, Text Edit Lock - Architecture Independent Code Mathieu Desnoyers
2009-03-06 15:36 ` [PATCH -tip 2/4]Text Edit Lock - kprobes architecture independent support (v3) Masami Hiramatsu
2009-03-08 15:51   ` [tip:tracing/core] tracing, Text Edit Lock - kprobes architecture independent support Mathieu Desnoyers
2009-03-06 15:37 ` [PATCH -tip 3/4]Text Edit Lock - Smp alternatives support Masami Hiramatsu
2009-03-06 18:11   ` Mathieu Desnoyers
2009-03-06 18:40     ` Masami Hiramatsu
2009-03-08 15:51   ` [tip:tracing/core] tracing, Text Edit Lock - SMP " Masami Hiramatsu
2009-03-06 15:37 ` [PATCH -tip 4/4] Atomic text_poke() with fixmap Masami Hiramatsu
2009-03-06 18:13   ` Mathieu Desnoyers
2009-03-06 18:18     ` Ingo Molnar
2009-03-06 18:33     ` [PATCH -tip 4/4] Atomic text_poke() with fixmap take2 Masami Hiramatsu
2009-03-06 18:45       ` Mathieu Desnoyers
2009-03-06 19:08       ` Ingo Molnar
2009-03-06 19:15         ` Mathieu Desnoyers
2009-03-06 19:22           ` Ingo Molnar
2009-03-06 20:25             ` [PATCH -tip 5/4] Expands irq-off region in text_poke() Masami Hiramatsu
2009-03-06 21:01               ` Mathieu Desnoyers
2009-03-06 21:57                 ` Masami Hiramatsu [this message]
2009-03-07  1:42                   ` Mathieu Desnoyers
2009-03-09 16:40                     ` Masami Hiramatsu
2009-03-10 21:57                       ` [tip:tracing/core] x86: expand " Masami Hiramatsu
2009-03-08 15:51   ` [tip:tracing/core] x86: implement atomic text_poke() via fixmap Masami Hiramatsu
2009-03-06 18:09 ` [PATCH -tip 0/4] Text edit lock and atomic text_poke() Mathieu Desnoyers
2009-03-06 18:12   ` Steven Rostedt

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=49B19C5B.30805@redhat.com \
    --to=mhiramat@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    --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.