Re: [PATCH] x86/cmpxchg: Add safety for bad sizes

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 2026-01-27 16:53, Jan Beulich wrote:
> On 27.01.2026 11:23, Andrew Cooper wrote:
> > @@ -66,6 +68,8 @@ static always_inline unsigned long __xchg(
> >                         : [x] "+r" (x), [ptr] "+m" (*(volatile 
> > uint64_t *)ptr)
> >                         :: "memory" );
> >          break;
> > +    default:
> > +        __bad_xchg_size();
> What has come of the plans to emit an assembly error directive in such
> situations?
>
> Also for Misra's sake "break" will be wanted.
Or mark the function noreturn for instance

> > @@ -106,6 +110,8 @@ static always_inline unsigned long __cmpxchg(
> >                         : [new] "r" (new), "a" (old)
> >                         : "memory" );
> >          return prev;
> > +    default:
> > +        BUG();
> >      }
> >      return old;
> >  }
> > @@ -137,6 +143,8 @@ static always_inline unsigned long cmpxchg_local_(
> >                         : "=a" (prev), [ptr] "+m" (*(uint64_t *)ptr)
> >                         : [new] "r" (new), "a" (old) );
> >          break;
> > +    default:
> > +        BUG();
> >      }
> >
> >      return prev;
> Hmm. If for some reason hvmemul_cmpxchg() ended up hitting either of 
> these,
> we'd immediately have an XSA. Imo these want to be ASSERT_UNREACHABLE()
> with plausible recovery for release builds.
>
> Jan
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253