Re: ld.lld: error: vmlinux.a(af_vsock.o at 1186296) <inline asm>:5:8: unpredictable STXR instruction, status is also a source

On Fri, Jul 10, 2026 at 08:54:28AM -0700, Nathan Chancellor wrote:
>On Fri, Jul 10, 2026 at 04:22:20PM +0200, Stefano Garzarella wrote:
>> On Mon, 6 Jul 2026 at 10:44, kernel test robot <[email protected]> wrote:
>> >
>> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> > head:   8cdeaa50eae8dad34885515f62559ee83e7e8dda
>> > commit: 102eab95f025b4d3f3a6c0a858400aca2af2fe52 vsock: lock down child_ns_mode as write-once
>> > date:   4 months ago
>> > config: arm64-randconfig-001-20260706 (https://download.01.org/0day-ci/archive/20260706/[email protected]/config)
>> > compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
>> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260706/[email protected]/reproduce)
>> >
>> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
>> > the same patch/commit), kindly add following tags
>> > | Fixes: 102eab95f025 ("vsock: lock down child_ns_mode as write-once")
>> > | Reported-by: kernel test robot <[email protected]>
>> > | Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>> >
>> > All errors (new ones prefixed by >>):
>> >
>> > >> ld.lld: error: vmlinux.a(af_vsock.o at 1186296) <inline asm>:5:8: unpredictable STXR instruction, status is also a source
>> >    stlxr   w8, w8, [x21]
>> >    ^
>> >
>>
>> Could this be related to https://github.com/llvm/llvm-project/issues/106380 ?
>> That issue seems fixed in llvm >= 20
>
>Indeed, this is resolved by
>
>  https://github.com/llvm/llvm-project/commit/7183771834d9035ffbedd8f1ff9233b16722b986
>
>in LLVM 20.1.0, I confirmed with a reverse bisect. It looks like

Thanks for checking!

>this issue triggers on undefined values being passed to inline asm but I
>don't see where there is an undefined value in the blamed commit but I
>did not look too hard. Presumably this is around the try_cmpxchg() in

Yeah, I suspected the same.

>vsock_net_set_child_mode(). I am not sure this will be easily to
>workaround so we might just have to leave it broken.

I think so, I can't see any simple workaround :-(

Thanks,
Stefano