s390/cmpxchg: fix sign extension bugs
For 1 and 2 byte operands for xchg and cmpxchg the old and new values get or'ed into the larger 4 byte old value before the compare and swap instruction gets executed. This is done without using the proper byte mask before or'ing the values. If the caller passed in negative old or new values these got sign extended by the caller. Which in turn means that either the old value never matches, or, even worse, unrelated bytes would be changed in memory. Luckily there don't seem to be any callers around yet, since that would have resulted in the specification exception fixed in an earlies patch. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Loading
Please register or sign in to comment