linux-kernel - Re: [PATCH 1/4] ARC: add barriers to futex code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <C2D7FE5348E1B147BCA15975FBA23075665B1595@IN01WEMBXB.internal.synopsys.com>
Date:	Thu, 6 Aug 2015 13:28:08 +0000
From:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:	David Hildenbrand <dahi@...ux.vnet.ibm.com>
CC:	"Peter Zijlstra (Intel)" <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Michel Lespinasse <walken@...gle.com>,
	"arc-linux-dev@...opsys.com" <arc-linux-dev@...opsys.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] ARC: add barriers to futex code

On Thursday 06 August 2015 06:45 PM, David Hildenbrand wrote:
>> The atomic ops on futex need to provide the full barrier just like
>> regular atomics in kernel.
>>
>> Also remove pagefault_enable/disable in futex_atomic_cmpxchg_inatomic()
>> as core code already does that
>>
>> Cc: David Hildenbrand <dahi@...ux.vnet.ibm.com>
>> Cc: Peter Zijlstra (Intel) <peterz@...radead.org>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Cc: Michel Lespinasse <walken@...gle.com>
>> Signed-off-by: Vineet Gupta <vgupta@...opsys.com>
>> ---
>>  arch/arc/include/asm/futex.h | 12 ++++++++----
>>  1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arc/include/asm/futex.h b/arch/arc/include/asm/futex.h
>> index 70cfe16b742d..160656d0a15a 100644
>> --- a/arch/arc/include/asm/futex.h
>> +++ b/arch/arc/include/asm/futex.h
>> @@ -20,6 +20,7 @@
>>
>>  #define __futex_atomic_op(insn, ret, oldval, uaddr, oparg)\
>>  							\
>> +	smp_mb();					\
>>  	__asm__ __volatile__(				\
>>  	"1:	llock	%1, [%2]		\n"	\
>>  		insn				"\n"	\
>> @@ -40,12 +41,14 @@
>>  							\
>>  	: "=&r" (ret), "=&r" (oldval)			\
>>  	: "r" (uaddr), "r" (oparg), "ir" (-EFAULT)	\
>> -	: "cc", "memory")
>> +	: "cc", "memory");				\
>> +	smp_mb();					\
> I think you should drop the ;

OK sure !

>
>>  #else	/* !CONFIG_ARC_HAS_LLSC */
>>
>>  #define __futex_atomic_op(insn, ret, oldval, uaddr, oparg)\
>>  							\
>> +	smp_mb();					\
>>  	__asm__ __volatile__(				\
>>  	"1:	ld	%1, [%2]		\n"	\
>>  		insn				"\n"	\
>> @@ -65,7 +68,8 @@
>>  							\
>>  	: "=&r" (ret), "=&r" (oldval)			\
>>  	: "r" (uaddr), "r" (oparg), "ir" (-EFAULT)	\
>> -	: "cc", "memory")
>> +	: "cc", "memory");				\
>> +	smp_mb();					\
> dito

OK !

>
>>  #endif
>>
>> @@ -151,7 +155,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr, u32 oldval,
>>  	if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
>>  		return -EFAULT;
>>
>> -	pagefault_disable();
>> +	smp_mb();
>>
>>  	__asm__ __volatile__(
>>  #ifdef CONFIG_ARC_HAS_LLSC
>> @@ -178,7 +182,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr, u32 oldval,
>>  	: "r"(oldval), "r"(newval), "r"(uaddr), "ir"(-EFAULT)
>>  	: "cc", "memory");
>>
>> -	pagefault_enable();
>> +	smp_mb();
>>
>>  	*uval = val;
>>  	return val;
> Looks like pagefault_() magic is only required for futex_atomic_op_inuser. So
> this should be fine (and arc seems to be the only arch left that has in in
> _inatomic).
>
> Not sure if you want to change the comment:
>
> /* Compare-xchg with pagefaults disabled.
>  *  Notes:
>  *      -Best-Effort: Exchg happens only if compare succeeds.
>
> Maybe something like "Compare-xchg: pagefaults have to be disabled by the
> caller"

Will do !

> Looks sane to me.

Thx for the quick review David. It seems ARC also needs the preempt disable magic
for !LLSC config. I'll send a separate patch to that effect.

Thx,
-Vineet

>
> David
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/