Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
From:   Nadav Amit <nadav.amit@gmail.com>
Content-Type: text/plain;
        charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Subject: Missing clobber on alternative use on Linux UM 32-bit
Message-Id: <24BD0906-C6FE-499C-9A4A-00C56E6EE84A@gmail.com>
Date:   Sat, 4 Nov 2023 11:25:31 +0200
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>
To:     Richard Weinberger <richard@nod.at>, linux-um@lists.infradead.org
Precedence: bulk

I was reading (again) the x86 C macro of =E2=80=9Calternative()=E2=80=9D =
and I was a bit
surprised it does clobber the flags (=E2=80=9Ccc=E2=80=9D) as a =
precaution.

  #define alternative(oldinstr, newinstr, ft_flags) \
	asm_inline volatile (ALTERNATIVE(oldinstr, newinstr, ft_flags) : =
: : "memory")

Actually there seems to be only one instance of problematic cases - in =
um/32-bit:

  #define mb() alternative("lock; addl $0,0(%%esp)", "mfence", =
X86_FEATURE_XMM2)
  #define rmb() alternative("lock; addl $0,0(%%esp)", "lfence", =
X86_FEATURE_XMM2)
  #define wmb() alternative("lock; addl $0,0(%%esp)", "sfence", =
X86_FEATURE_XMM)

Presumably, if XMM or XMM2 are not supported, there would be instances =
where addl
would be able to change eflags arithmetic flags without the compiler =
being aware
of it.

As it only affects 32-bit Linux UM - I don=E2=80=99t easily have an =
environment to test
the fix. An alternative (word-pun unintended) is to add =E2=80=9Ccc=E2=80=9D=
 as a precaution
to the alternative macro.