[GIT PULL] uml-for-6.16-rc4

[GIT PULL] uml-for-6.16-rc4

[Johannes Berg]

Hi Linus,

For UML we have a few fixes, all from Tiwei and mostly for
recently added code (though one is just a compiler version
thing.)

Please pull and let us know if there's any problem.

Thanks,
johannes



The following changes since commit 86731a2a651e58953fc949573895f2fa6d456841:

  Linux 6.16-rc3 (2025-06-22 13:30:08 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/uml/linux.git tags/uml-for-6.16-rc4

for you to fetch changes up to 2d65fc13be85c336c56af7077f08ccd3a3a15a4a:

  um: vector: Reduce stack usage in vector_eth_configure() (2025-06-25 09:28:17 +0200)

----------------------------------------------------------------
Just a few fixes:
 - fix FP registers in seccomp mode
 - prevent duplicate devices in VFIO support
 - don't ignore errors in UBD thread start
 - reduce stack use with clang 19

----------------------------------------------------------------
Tiwei Bie (4):
      um: ubd: Add missing error check in start_io_thread()
      um: vfio: Prevent duplicate device assignments
      um: Use correct data source in fpregs_legacy_set()
      um: vector: Reduce stack usage in vector_eth_configure()

 arch/um/drivers/ubd_user.c    |  2 +-
 arch/um/drivers/vector_kern.c | 42 +++++++++++++-----------------------------
 arch/um/drivers/vfio_kern.c   | 14 ++++++++++++++
 arch/x86/um/ptrace.c          |  2 +-
 4 files changed, 29 insertions(+), 31 deletions(-)

Re: [GIT PULL] uml-for-6.16-rc4

[Linus Torvalds]

On Wed, 25 Jun 2025 at 05:15, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>  - reduce stack use with clang 19

Interesting. The patch looks fine, I'm wondering if people made a
clang bug report about this behavior with structure assignments?

Even if most other projects likely don't have issues with stack size,
it looks very non-optimal from a performance standpoint too to create
a pointless temporary copy on the stack.

I assume - but didn't check - that gcc didn't do the same stupid thing
for that code?

          Linus

Re: [GIT PULL] uml-for-6.16-rc4

[pr-tracker-bot]

The pull request you sent on Wed, 25 Jun 2025 14:14:19 +0200:

> https://git.kernel.org/pub/scm/linux/kernel/git/uml/linux.git tags/uml-for-6.16-rc4

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2dca89df0d1116f722b4be100e4bfcff858058e8

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] uml-for-6.16-rc4

[Tiwei Bie]

On 2025/6/26 02:17, Linus Torvalds wrote:
> On Wed, 25 Jun 2025 at 05:15, Johannes Berg <johannes@sipsolutions.net> wrote:
>>
>>  - reduce stack use with clang 19
> 
> Interesting. The patch looks fine, I'm wondering if people made a
> clang bug report about this behavior with structure assignments?
> 
> Even if most other projects likely don't have issues with stack size,
> it looks very non-optimal from a performance standpoint too to create
> a pointless temporary copy on the stack.
> 
> I assume - but didn't check - that gcc didn't do the same stupid thing
> for that code?

The behavior of gcc and clang differs. Clang's behavior appears to be
related to the volatile qualifier in arch_spinlock_t:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/spinlock_types_up.h?id=b555cb66583e99158cfef8e91c025252cefae55b#n18

It can be reproduced with this code snippet:

```c
struct foo {
	char a;
	volatile char b;
	char c[512];
};

char bar(void);
void baz(struct foo *p);

void baz(struct foo *p)
{
	*p = (struct foo) { .a = bar() };
}
```

$ clang-19 --version
Ubuntu clang version 19.1.7 (++20250114103320+cd708029e0b2-1~exp1~20250114103432.75)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-19/bin
$ clang-19 -O2 -c test.c
$ objdump -dr ./test.o

./test.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <baz>:
   0:	41 56                	push   %r14
   2:	53                   	push   %rbx
   3:	48 81 ec 18 02 00 00 	sub    $0x218,%rsp
   a:	48 89 fb             	mov    %rdi,%rbx
   d:	4c 8d 74 24 10       	lea    0x10(%rsp),%r14
  12:	ba 01 02 00 00       	mov    $0x201,%edx
  17:	4c 89 f7             	mov    %r14,%rdi
  1a:	31 f6                	xor    %esi,%esi
  1c:	e8 00 00 00 00       	call   21 <baz+0x21>
			1d: R_X86_64_PLT32	memset-0x4
  21:	e8 00 00 00 00       	call   26 <baz+0x26>
			22: R_X86_64_PLT32	bar-0x4
  26:	88 44 24 0f          	mov    %al,0xf(%rsp)
  2a:	0f b6 44 24 0f       	movzbl 0xf(%rsp),%eax
  2f:	88 03                	mov    %al,(%rbx)
  31:	48 ff c3             	inc    %rbx
  34:	ba 01 02 00 00       	mov    $0x201,%edx
  39:	48 89 df             	mov    %rbx,%rdi
  3c:	4c 89 f6             	mov    %r14,%rsi
  3f:	e8 00 00 00 00       	call   44 <baz+0x44>
			40: R_X86_64_PLT32	memcpy-0x4
  44:	48 81 c4 18 02 00 00 	add    $0x218,%rsp
  4b:	5b                   	pop    %rbx
  4c:	41 5e                	pop    %r14
  4e:	c3                   	ret    


$ clang --version
Ubuntu clang version 14.0.0-1ubuntu1.1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ clang -O2 -c test.c
$ objdump -dr ./test.o

./test.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <baz>:
   0:	41 56                	push   %r14
   2:	53                   	push   %rbx
   3:	48 81 ec 18 02 00 00 	sub    $0x218,%rsp
   a:	48 89 fb             	mov    %rdi,%rbx
   d:	4c 8d 74 24 10       	lea    0x10(%rsp),%r14
  12:	ba 01 02 00 00       	mov    $0x201,%edx
  17:	4c 89 f7             	mov    %r14,%rdi
  1a:	31 f6                	xor    %esi,%esi
  1c:	e8 00 00 00 00       	call   21 <baz+0x21>
			1d: R_X86_64_PLT32	memset-0x4
  21:	e8 00 00 00 00       	call   26 <baz+0x26>
			22: R_X86_64_PLT32	bar-0x4
  26:	88 44 24 0f          	mov    %al,0xf(%rsp)
  2a:	8a 44 24 0f          	mov    0xf(%rsp),%al
  2e:	88 03                	mov    %al,(%rbx)
  30:	48 83 c3 01          	add    $0x1,%rbx
  34:	ba 01 02 00 00       	mov    $0x201,%edx
  39:	48 89 df             	mov    %rbx,%rdi
  3c:	4c 89 f6             	mov    %r14,%rsi
  3f:	e8 00 00 00 00       	call   44 <baz+0x44>
			40: R_X86_64_PLT32	memcpy-0x4
  44:	48 81 c4 18 02 00 00 	add    $0x218,%rsp
  4b:	5b                   	pop    %rbx
  4c:	41 5e                	pop    %r14
  4e:	c3                   	ret    


$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -O2 -c test.c
$ objdump -dr ./test.o

./test.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <baz>:
   0:	f3 0f 1e fa          	endbr64 
   4:	53                   	push   %rbx
   5:	48 89 fb             	mov    %rdi,%rbx
   8:	e8 00 00 00 00       	call   d <baz+0xd>
			9: R_X86_64_PLT32	bar-0x4
   d:	48 8d 7b 08          	lea    0x8(%rbx),%rdi
  11:	48 89 d9             	mov    %rbx,%rcx
  14:	48 c7 03 00 00 00 00 	movq   $0x0,(%rbx)
  1b:	48 83 e7 f8          	and    $0xfffffffffffffff8,%rdi
  1f:	41 89 c0             	mov    %eax,%r8d
  22:	31 c0                	xor    %eax,%eax
  24:	48 c7 83 fa 01 00 00 	movq   $0x0,0x1fa(%rbx)
  2b:	00 00 00 00 
  2f:	48 29 f9             	sub    %rdi,%rcx
  32:	81 c1 02 02 00 00    	add    $0x202,%ecx
  38:	c1 e9 03             	shr    $0x3,%ecx
  3b:	f3 48 ab             	rep stos %rax,%es:(%rdi)
  3e:	44 88 03             	mov    %r8b,(%rbx)
  41:	5b                   	pop    %rbx
  42:	c3                   	ret    


After 's/volatile char b;/char b;/', clang-19 produces:

./test.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <baz>:
   0:	53                   	push   %rbx
   1:	48 89 fb             	mov    %rdi,%rbx
   4:	e8 00 00 00 00       	call   9 <baz+0x9>
			5: R_X86_64_PLT32	bar-0x4
   9:	88 03                	mov    %al,(%rbx)
   b:	48 ff c3             	inc    %rbx
   e:	ba 01 02 00 00       	mov    $0x201,%edx
  13:	48 89 df             	mov    %rbx,%rdi
  16:	31 f6                	xor    %esi,%esi
  18:	5b                   	pop    %rbx
  19:	e9 00 00 00 00       	jmp    1e <baz+0x1e>
			1a: R_X86_64_PLT32	memset-0x4

Regards,
Tiwei

Re: [GIT PULL] uml-for-6.16-rc4

[Linus Torvalds]

On Wed, 25 Jun 2025 at 19:44, Tiwei Bie <tiwei.btw@antgroup.com> wrote:
>
> The behavior of gcc and clang differs. Clang's behavior appears to be
> related to the volatile qualifier in arch_spinlock_t:

Ahh. That kind of makes sense.

At the same time, I think clang is being stupid here. Yes, it makes
sense to treat volatile specially in this way - just not for an
initializer.

I realize that initializers can be made to be their own data
structures in modern C (ie taking the address of an initializer and
using the initializer itself as an argument to a function call, for
example), but when an initializer is used to set the value of a
variable, the only real thing there is that variable.

Oh well. The patch certainly looks fine and I obviously already merged
the pull request. It does make me go "I wonder how many other places
clang just generates stupid code due to this".

            Linus

Re: [GIT PULL] uml-for-6.16-rc4

[Tiwei Bie]

On 2025/6/26 11:48, Linus Torvalds wrote:
> On Wed, 25 Jun 2025 at 19:44, Tiwei Bie <tiwei.btw@antgroup.com> wrote:
>>
>> The behavior of gcc and clang differs. Clang's behavior appears to be
>> related to the volatile qualifier in arch_spinlock_t:
> 
> Ahh. That kind of makes sense.

I also just noticed it today after taking a closer look.

> 
> At the same time, I think clang is being stupid here. Yes, it makes
> sense to treat volatile specially in this way - just not for an
> initializer.
> 
> I realize that initializers can be made to be their own data
> structures in modern C (ie taking the address of an initializer and
> using the initializer itself as an argument to a function call, for
> example), but when an initializer is used to set the value of a
> variable, the only real thing there is that variable.

That makes sense!

> 
> Oh well. The patch certainly looks fine and I obviously already merged
> the pull request.

Yeah, I saw that. Thanks! :)

> It does make me go "I wonder how many other places
> clang just generates stupid code due to this".

+1.

Regards,
Tiwei