mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Nicholas Piggin <npiggin@gmail.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Segher Boessenkool <segher@kernel.crashing.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Zhouyi Zhou <zhouzhouyi@gmail.com>
Subject: Re: [PATCH v2] powerpc: Fix irq_soft_mask_set() and irq_soft_mask_return() with sanitizer
Date: Tue, 30 Aug 2022 05:24:59 +0000	[thread overview]
Message-ID: <e022754d-b4d3-bc9f-cc79-2cf556180459@csgroup.eu> (raw)
In-Reply-To: <CMJ3VICKD1CI.SVFJOKYJPKZQ@bobo>



Le 30/08/2022 à 07:15, Nicholas Piggin a écrit :
> On Wed Aug 24, 2022 at 2:39 AM AEST, Christophe Leroy wrote:
>> In ppc, compiler based sanitizer will generate instrument instructions
>> around statement WRITE_ONCE(local_paca->irq_soft_mask, mask):
>>

[...]

>>
>> If there is a context switch before "stb     r9,2354(r31)", r31 may
>> not equal to r13, in such case, irq soft mask will not work.
>>
>> The same problem occurs in irq_soft_mask_return() with
>> READ_ONCE(local_paca->irq_soft_mask).
> 
> WRITE_ONCE doesn't require address generation to be atomic with the
> store so this is a bug without sanitizer too. I have seen gcc put r13
> into a nvgpr before.
> 
> READ_ONCE maybe could be argued is safe in this case because data
> could be stale when you use it anyway, but pointless and risky
> in some cases (imagine cpu offline -> store poison value to irq soft
> mask.
> 
>> This patch partially reverts commit ef5b570d3700 ("powerpc/irq: Don't
>> open code irq_soft_mask helpers") with a more modern inline assembly.
>>
>> Reported-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
>> Fixes: ef5b570d3700 ("powerpc/irq: Don't open code irq_soft_mask helpers")
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> ---
>> v2: Use =m constraint for stb instead of m constraint
>> ---
>>   arch/powerpc/include/asm/hw_irq.h | 9 ++++++---
>>   1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
>> index 26ede09c521d..815420988ef3 100644
>> --- a/arch/powerpc/include/asm/hw_irq.h
>> +++ b/arch/powerpc/include/asm/hw_irq.h
>> @@ -113,7 +113,11 @@ static inline void __hard_RI_enable(void)
>>   
>>   static inline notrace unsigned long irq_soft_mask_return(void)
>>   {
>> -	return READ_ONCE(local_paca->irq_soft_mask);
>> +	unsigned long flags;
>> +
>> +	asm volatile("lbz%X1 %0,%1" : "=r" (flags) : "m" (local_paca->irq_soft_mask));
>> +
>> +	return flags;
>>   }
>>   
>>   /*
>> @@ -140,8 +144,7 @@ static inline notrace void irq_soft_mask_set(unsigned long mask)
>>   	if (IS_ENABLED(CONFIG_PPC_IRQ_SOFT_MASK_DEBUG))
>>   		WARN_ON(mask && !(mask & IRQS_DISABLED));
>>   
>> -	WRITE_ONCE(local_paca->irq_soft_mask, mask);
>> -	barrier();
>> +	asm volatile("stb%X0 %1,%0" : "=m" (local_paca->irq_soft_mask) : "r" (mask) : "memory");
> 
> This is still slightly concerning to me. Is there any guarantee that the
> compiler would not use a different sequence for the address here?
> 
> Maybe explicit r13 is required.
> 

local_paca is defined as:

	register struct paca_struct *local_paca asm("r13");

Why would the compiler use another register ? If so, do we also have an 
issue with the use of current_stack_pointer in irq.c ?

Segher ?

  reply	other threads:[~2022-08-30  5:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-23 16:39 Christophe Leroy
2022-08-30  5:15 ` Nicholas Piggin
2022-08-30  5:24   ` Christophe Leroy [this message]
2022-08-30  9:01     ` Nicholas Piggin
2022-08-30  9:10       ` Christophe Leroy
2022-08-31 22:45         ` Segher Boessenkool
2022-09-01  5:22           ` Christophe Leroy
2022-09-01  7:37             ` Gabriel Paubert
2022-09-01  7:47               ` Christophe Leroy
2022-09-01 17:48                 ` Segher Boessenkool
2022-09-01 18:07               ` Segher Boessenkool
2022-09-02 15:57           ` Peter Bergner
2022-09-02 17:10             ` Segher Boessenkool

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=e022754d-b4d3-bc9f-cc79-2cf556180459@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=segher@kernel.crashing.org \
    --cc=zhouzhouyi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®