netdev - Fwd: Re: [PATCH RESEND net-next 13/15] smc: receive data from RMBE

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: <40f250c2-d865-5bd3-8d20-a2dc2fd7d257@linux.vnet.ibm.com>
Date:	Wed, 10 Aug 2016 17:15:01 +0200
From:	Ursula Braun <ubraun@...ux.vnet.ibm.com>
To:	Dave Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, linux-s390@...r.kernel.org,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Utz Bacher <utz.bacher@...ibm.com>
Subject: Fwd: Re: [PATCH RESEND net-next 13/15] smc: receive data from RMBE

Dave,

sorry, forget my previous mail from today. I now realize that xchg() 
does not help on 32-bit architectures. I have to think about 
alternatives here.

-------- Forwarded Message --------
Subject: Re: [PATCH RESEND net-next 13/15] smc: receive data from RMBE
Date: Wed, 10 Aug 2016 15:44:00 +0200
From: Ursula Braun <ubraun@...ux.vnet.ibm.com>
To: David Miller <davem@...emloft.net>
CC: netdev@...r.kernel.org, linux-s390@...r.kernel.org, 
schwidefsky@...ibm.com, heiko.carstens@...ibm.com, utz.bacher@...ibm.com



On 08/09/2016 11:32 PM, David Miller wrote:
> From: Ursula Braun <ubraun@...ux.vnet.ibm.com>
> Date: Tue,  9 Aug 2016 12:12:58 +0200
>
>> +		xchg(&conn->rx_curs_confirmed.acurs,
>> +		     smc_curs_read(conn->local_tx_ctrl.cons.acurs));
>
> Why in the world do you need to use xchg() in all of these places?
>
> It makes no sense whatsoever, especially since you don't even check
> the return value.
> 98e906b2
> If you need the operation to be atomic, then you have to check the
> return value and do something to recover if something else beat
> you to the xchg() and put something else into the location.
>
> Otherwise, you therefore don't need it be atomic and can avoid
> this expensive operation and just store the value normally.
>
Reviewing my xchg() usages, I really detected some paranoid usages, that 
I am going to remove. But there are still usages (and 
conn->rx_curs_confirmed is one of them), where I need an 8-byte cursor 
field to be read and written atomicaly, even though I do not care 
whether the write operation has been beaten or not. But I do care that 
reading the cursor does not return a partially updated cursor. Isn't 
xchg() a possible solution in this case?