All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arseny Solokha <asolokha@kb.kras.ru>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Scott Wood <scottwood@freescale.com>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/mm: bail out early when flushing TLB page
Date: Mon, 02 Feb 2015 12:07:00 +0700	[thread overview]
Message-ID: <54CF05F4.3040406@kb.kras.ru> (raw)
In-Reply-To: <1422736026.6200.14.camel@kernel.crashing.org>

> On Fri, 2015-01-30 at 19:08 +0700, Arseny Solokha wrote:
>> MMU_NO_CONTEXT is conditionally defined as 0 or (unsigned int)-1. However,
>> in __flush_tlb_page() a corresponding variable is only tested for open
>> coded 0, which can cause NULL pointer dereference if `mm' argument was
>> legitimately passed as such.
>>
>> Bail out early in case the first argument is NULL, thus eliminate confusion
>> between different values of MMU_NO_CONTEXT and avoid disabling and then
>> re-enabling preemption unnecessarily.
> 
> So the comment above isn't quite right... we don't *test* it for open
> coded 0, we test it for MMU_NO_CONTEXT, however we *set* it to 0 for
> NULL mm.
> 
> This is actually correct... on all except 8xx :-) 0 *is* the PID of the
> kernel context, and NULL mm usually means kernel context.

> However, it's correct that this function will not deal properly with a
> NULL mm for other reasons. It must only be called for user contexts.
> 
> Instead of just returning, I would WARN_ON, because if it's ever called
> for a kernel page, then it will not do what's expected and that will
> need fixing. Just a silent return isn't right.

Does this also hold true for __local_flush_tlb_page()? It's called from
local_flush_tlb_page() as follows:

  __local_flush_tlb_page(vma ? vma->vm_mm : NULL, vmaddr,
  			 mmu_get_tsize(mmu_virtual_psize), 0);

However, if MMU_NO_CONTEXT is 0 and __local_flush_tlb_page() is called with mm
set to NULL, it's effectively a no-op. What else am I missing?

Thanks,

Arsény


> This is different from returning on MMU_NO_CONTEXT, in this case, we
> know there's no active TLB entries for the process, and thus nothing to
> flush.
> 
> Cheers,
> Ben.
> 
>> Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
>> ---
>>  arch/powerpc/mm/tlb_nohash.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
>> index f38ea4d..ab0616b 100644
>> --- a/arch/powerpc/mm/tlb_nohash.c
>> +++ b/arch/powerpc/mm/tlb_nohash.c
>> @@ -284,8 +284,11 @@ void __flush_tlb_page(struct mm_struct *mm, unsigned long vmaddr,
>>  	struct cpumask *cpu_mask;
>>  	unsigned int pid;
>>  
>> +	if (unlikely(!mm))
>> +		return;
>> +
>>  	preempt_disable();
>> -	pid = mm ? mm->context.id : 0
> 
> Here we test mm, if we pass NULL, that means the kernel mm which has PID
> 0, which is not MMU_NO_CONTEXT
>> ;
>> +	pid = mm->context.id;
>>  	if (unlikely(pid == MMU_NO_CONTEXT))
>>  		goto bail;
>>  	cpu_mask = mm_cpumask(mm);

WARNING: multiple messages have this Message-ID (diff)
From: Arseny Solokha <asolokha@kb.kras.ru>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Scott Wood <scottwood@freescale.com>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/mm: bail out early when flushing TLB page
Date: Mon, 02 Feb 2015 12:07:00 +0700	[thread overview]
Message-ID: <54CF05F4.3040406@kb.kras.ru> (raw)
In-Reply-To: <1422736026.6200.14.camel@kernel.crashing.org>

> On Fri, 2015-01-30 at 19:08 +0700, Arseny Solokha wrote:
>> MMU_NO_CONTEXT is conditionally defined as 0 or (unsigned int)-1. However,
>> in __flush_tlb_page() a corresponding variable is only tested for open
>> coded 0, which can cause NULL pointer dereference if `mm' argument was
>> legitimately passed as such.
>>
>> Bail out early in case the first argument is NULL, thus eliminate confusion
>> between different values of MMU_NO_CONTEXT and avoid disabling and then
>> re-enabling preemption unnecessarily.
> 
> So the comment above isn't quite right... we don't *test* it for open
> coded 0, we test it for MMU_NO_CONTEXT, however we *set* it to 0 for
> NULL mm.
> 
> This is actually correct... on all except 8xx :-) 0 *is* the PID of the
> kernel context, and NULL mm usually means kernel context.

> However, it's correct that this function will not deal properly with a
> NULL mm for other reasons. It must only be called for user contexts.
> 
> Instead of just returning, I would WARN_ON, because if it's ever called
> for a kernel page, then it will not do what's expected and that will
> need fixing. Just a silent return isn't right.

Does this also hold true for __local_flush_tlb_page()? It's called from
local_flush_tlb_page() as follows:

  __local_flush_tlb_page(vma ? vma->vm_mm : NULL, vmaddr,
  			 mmu_get_tsize(mmu_virtual_psize), 0);

However, if MMU_NO_CONTEXT is 0 and __local_flush_tlb_page() is called with mm
set to NULL, it's effectively a no-op. What else am I missing?

Thanks,

Arsény


> This is different from returning on MMU_NO_CONTEXT, in this case, we
> know there's no active TLB entries for the process, and thus nothing to
> flush.
> 
> Cheers,
> Ben.
> 
>> Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
>> ---
>>  arch/powerpc/mm/tlb_nohash.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
>> index f38ea4d..ab0616b 100644
>> --- a/arch/powerpc/mm/tlb_nohash.c
>> +++ b/arch/powerpc/mm/tlb_nohash.c
>> @@ -284,8 +284,11 @@ void __flush_tlb_page(struct mm_struct *mm, unsigned long vmaddr,
>>  	struct cpumask *cpu_mask;
>>  	unsigned int pid;
>>  
>> +	if (unlikely(!mm))
>> +		return;
>> +
>>  	preempt_disable();
>> -	pid = mm ? mm->context.id : 0
> 
> Here we test mm, if we pass NULL, that means the kernel mm which has PID
> 0, which is not MMU_NO_CONTEXT
>> ;
>> +	pid = mm->context.id;
>>  	if (unlikely(pid == MMU_NO_CONTEXT))
>>  		goto bail;
>>  	cpu_mask = mm_cpumask(mm);

  reply	other threads:[~2015-02-02  5:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-30 12:08 [PATCH] powerpc/mm: bail out early when flushing TLB page Arseny Solokha
2015-01-30 12:08 ` Arseny Solokha
2015-01-30 21:53 ` Scott Wood
2015-01-30 21:53   ` Scott Wood
2015-01-31  4:18   ` Arseny Solokha
2015-01-31  4:18     ` Arseny Solokha
2015-01-31 20:27 ` Benjamin Herrenschmidt
2015-01-31 20:27   ` Benjamin Herrenschmidt
2015-02-02  5:07   ` Arseny Solokha [this message]
2015-02-02  5:07     ` Arseny Solokha
2015-02-02  5:28 ` [PATCH] powerpc/mm: warn on flushing tlb page in kernel context Arseny Solokha
2015-02-02  5:28   ` Arseny Solokha

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=54CF05F4.3040406@kb.kras.ru \
    --to=asolokha@kb.kras.ru \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    --cc=scottwood@freescale.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.