All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
To: Michael Neuling <mikey@neuling.org>,
	Christophe LEROY <christophe.leroy@c-s.fr>,
	mpe@ellerman.id.au
Cc: "Michal Suchánek" <msuchanek@suse.de>,
	linuxppc-dev@lists.ozlabs.org,
	"Haren Myneni" <haren@linux.vnet.ibm.com>,
	"Nicholas Piggin" <npiggin@gmail.com>
Subject: Re: [PATCH v2] powerpc: Avoid code patching freed init sections
Date: Wed, 12 Sep 2018 18:21:58 -0700	[thread overview]
Message-ID: <e8a68da4-1c58-b30b-ccd0-f37a9e7c330c@linux.vnet.ibm.com> (raw)
In-Reply-To: <29d3467a9314f5b80f93d241ae2566c48b546bfe.camel@neuling.org>

On 09/12/2018 05:36 PM, Michael Neuling wrote:
> 
>>> --- a/arch/powerpc/lib/code-patching.c
>>> +++ b/arch/powerpc/lib/code-patching.c
>>> @@ -23,11 +23,33 @@
>>>   #include <asm/code-patching.h>
>>>   #include <asm/setup.h>
>>>   
>>> +
>>
>> This blank line is not needed
> 
> Ack
> 
>>
>>> +static inline bool in_init_section(unsigned int *patch_addr)
>>> +{
>>> +	if (patch_addr < (unsigned int *)__init_begin)
>>> +		return false;
>>> +	if (patch_addr >= (unsigned int *)__init_end)
>>> +		return false;
>>> +	return true;
>>> +}
>>
>> Can we use the existing function init_section_contains() instead of this 
>> new function ?
> 
> Nice, I was looking for something like that... 
> 
>>> +
>>> +static inline bool init_freed(void)
>>> +{
>>> +	return (system_state >= SYSTEM_RUNNING);
>>> +}
>>> +
>>
>> I would call this function differently, for instance init_is_finished(), 
>> because as you mentionned it doesn't exactly mean that init memory is freed.
> 
> Talking to Nick and mpe offline I think we are going to have to add a flag when
> we free init mem rather than doing what we have now since what we have now has a
> potential race. That change will eliminate the function entirely.
> 
>>>   static int __patch_instruction(unsigned int *exec_addr, unsigned int
>>> instr,
>>>   			       unsigned int *patch_addr)
>>>   {
>>>   	int err;
>>>   
>>> +	/* Make sure we aren't patching a freed init section */
>>> +	if (in_init_section(patch_addr) && init_freed()) {
>>
>> The test must be done on exec_addr, not on patch_addr, as patch_addr is 
>> the address where the instruction as been remapped RW for allowing its 
>> modification.
> 
> Thanks for the catch
> 
>> Also I think it should be tested the other way round, because the 
>> init_freed() is a simpler test which will be false most of the time once 
>> the system is running so it should be checked first.
> 
> ok, I'll change.
> 
>>> +		printk(KERN_DEBUG "Skipping init section patching addr:
>>> 0x%lx\n",
>>
>> Maybe use pr_debug() instead.
> 
> Sure.
> 
>>
>>> +			(unsigned long)patch_addr);
>>
>> Please align second line as per Codying style.
> 
> Sorry I can't see what's wrong. You're (or Cody :-P) going to have to spell it
> this out for me...

I suspect that the suggestion is the opening parenthesis of "(unsigned long)" should sit directly under the "K" of "KERN_DEBUG". I'm pretty sure Documentation/process/coding-style.rst is very adamant that all identation is always 8 characters and spaces should never be used, but there still seems to be a lot of places/suggestions that argument lists that spill over multiple lines should be space indented to align with the very first argument at the top level. So, I guess I'm not sure what the desire is here. Although moving to pr_debug might fit it to a single line anyways. ;)

-Tyrel

> 
>>
>>> +		return 0;
>>> +	}
>>> +
>>>   	__put_user_size(instr, patch_addr, 4, err);
>>>   	if (err)
>>>   		return err;
>>>
>>
>> I think it would be better to put this verification in 
>> patch_instruction() instead, to avoid RW mapping/unmapping the 
>> instruction to patch when we are not going to do the patching.
> 
> If we do it there then we miss the raw_patch_intruction case.
> 
> IMHO I don't think we need to optimise this rare and non-critical path. 
> 
> Mikey
> 

  reply	other threads:[~2018-09-13  1:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12  5:20 [PATCH v2] powerpc: Avoid code patching freed init sections Michael Neuling
2018-09-12  6:23 ` Christophe LEROY
2018-09-13  0:36   ` Michael Neuling
2018-09-13  1:21     ` Tyrel Datwyler [this message]
2018-09-13  5:38       ` Christophe LEROY
2018-09-13  5:48         ` Michael Neuling
2018-09-13  5:45     ` Christophe LEROY

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=e8a68da4-1c58-b30b-ccd0-f37a9e7c330c@linux.vnet.ibm.com \
    --to=tyreld@linux.vnet.ibm.com \
    --cc=christophe.leroy@c-s.fr \
    --cc=haren@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mikey@neuling.org \
    --cc=mpe@ellerman.id.au \
    --cc=msuchanek@suse.de \
    --cc=npiggin@gmail.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.