* [GIT PULL] uml-for-6.16-rc4
@ 2025-06-25 12:14 Johannes Berg
2025-06-25 18:17 ` Linus Torvalds
2025-06-25 18:23 ` pr-tracker-bot
0 siblings, 2 replies; 6+ messages in thread
From: Johannes Berg @ 2025-06-25 12:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-um, Richard Weinberger, Anton Ivanov
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(-)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [GIT PULL] uml-for-6.16-rc4 2025-06-25 12:14 [GIT PULL] uml-for-6.16-rc4 Johannes Berg @ 2025-06-25 18:17 ` Linus Torvalds 2025-06-26 2:44 ` Tiwei Bie 2025-06-25 18:23 ` pr-tracker-bot 1 sibling, 1 reply; 6+ messages in thread From: Linus Torvalds @ 2025-06-25 18:17 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-kernel, linux-um, Richard Weinberger, Anton Ivanov 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] uml-for-6.16-rc4 2025-06-25 18:17 ` Linus Torvalds @ 2025-06-26 2:44 ` Tiwei Bie 2025-06-26 3:48 ` Linus Torvalds 0 siblings, 1 reply; 6+ messages in thread From: Tiwei Bie @ 2025-06-26 2:44 UTC (permalink / raw) To: Linus Torvalds, Johannes Berg Cc: linux-kernel, linux-um, Richard Weinberger, Anton Ivanov 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] uml-for-6.16-rc4 2025-06-26 2:44 ` Tiwei Bie @ 2025-06-26 3:48 ` Linus Torvalds 2025-06-26 14:18 ` Tiwei Bie 0 siblings, 1 reply; 6+ messages in thread From: Linus Torvalds @ 2025-06-26 3:48 UTC (permalink / raw) To: Tiwei Bie Cc: Johannes Berg, linux-kernel, linux-um, Richard Weinberger, Anton Ivanov 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] uml-for-6.16-rc4 2025-06-26 3:48 ` Linus Torvalds @ 2025-06-26 14:18 ` Tiwei Bie 0 siblings, 0 replies; 6+ messages in thread From: Tiwei Bie @ 2025-06-26 14:18 UTC (permalink / raw) To: Linus Torvalds Cc: Johannes Berg, linux-kernel, linux-um, Richard Weinberger, Anton Ivanov 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] uml-for-6.16-rc4 2025-06-25 12:14 [GIT PULL] uml-for-6.16-rc4 Johannes Berg 2025-06-25 18:17 ` Linus Torvalds @ 2025-06-25 18:23 ` pr-tracker-bot 1 sibling, 0 replies; 6+ messages in thread From: pr-tracker-bot @ 2025-06-25 18:23 UTC (permalink / raw) To: Johannes Berg Cc: Linus Torvalds, linux-kernel, linux-um, Richard Weinberger, Anton Ivanov 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-06-26 14:18 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-06-25 12:14 [GIT PULL] uml-for-6.16-rc4 Johannes Berg 2025-06-25 18:17 ` Linus Torvalds 2025-06-26 2:44 ` Tiwei Bie 2025-06-26 3:48 ` Linus Torvalds 2025-06-26 14:18 ` Tiwei Bie 2025-06-25 18:23 ` pr-tracker-bot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®