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@xxxxxxxxxxxxxxxxxx>
To: David Miller <davem@xxxxxxxxxxxxx>
CC: netdev@xxxxxxxxxxxxxxx, linux-s390@xxxxxxxxxxxxxxx,
schwidefsky@xxxxxxxxxx, heiko.carstens@xxxxxxxxxx, utz.bacher@xxxxxxxxxx
On 08/09/2016 11:32 PM, David Miller wrote:
From: Ursula Braun <ubraun@xxxxxxxxxxxxxxxxxx>
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
