Skip to content

[5.15] Track Steam performance patches #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
kakra wants to merge 45 commits into from
Closed

[5.15] Track Steam performance patches #16

kakra wants to merge 45 commits into from

Conversation

@kakra
Copy link
Owner

@kakra kakra commented Nov 13, 2021 •
edited
Loading

@kakra kakra mentioned this pull request Nov 13, 2021
Closed
@orbea
Copy link

orbea commented Mar 29, 2022

@kakra Is there any information on usage for these patches? I enabled the winesync kernel module, but I am not sure what else needs to be done?

@kakra
Copy link
Owner Author

kakra commented Mar 30, 2022

The winesync kernel module itself does nothing unless you also use the appropriate wine patches. There's very low activity around these patches, last time I looked at it, some commits still contained todo and fixme lines. It seems it has since been rebased. The patches should be here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/fastsync3

This is the commit, that actually opens the winesync device: https://repo.or.cz/wine/zf.git/commitdiff/85481c0a11baabc529c252fd36e58ee9e626860d (search for /dev/winesync) ... just to identify we are using the correct fastsync branch. The other patches following it will be needed, too, and the previous patch.

I don't think that any of the major protonized wine distributions currently include these patches so you'd need to rebase the patchset yourself. They'll conflict with esync and fsync so you'd need to either remove those, or integrate it properly (those conflicts should be easy to resolve, just take care to enable winesync with highest priority when detected, rebuilding of the wineserver protocol headers will be needed after resolving conflicts).

It looks like Tkg has limited support for it but it's not enabled by default: https://github.com/Frogging-Family/wine-tkg-git/tree/master/wine-tkg-git/wine-tkg-patches/misc/fastsync

So with the kernel module enabled, you may receive better support from Tkg on how to actually make use of the module in wine.

Since winesync is still in very early (and silent) stages, I do not currently look into updates for the kernel module, it might be out of date. But I don't think there have been any critical updates to it. If you find evidence for a new kernel patch revision, let me know, and I'd happily update this patchset.

@orbea
Copy link

orbea commented Mar 30, 2022

Thank you, that is useful information. The xanmod project also seems to have kernel patches for winesync, but I haven't compared the patches with what is here.

https://xanmod.org/

If none of the major proton wine builds are using these patches how does this PR relate to steam? Maybe there is something else I missed?

@kakra
Copy link
Owner Author

kakra commented Mar 30, 2022

I just collect patches somehow related to my Steam installation here... It'll also improve non-Steam gaming probably. It's just a personal preference, and I had to give it a name. OTOH, we have to consider that these changes were mostly pushed by Valve activities (directly and indirectly) - so this gives "Steam" some credit for it. ;-)

@kakra
Copy link
Owner Author

kakra commented Mar 30, 2022 •
edited
Loading

I'm using sets of patches for different systems, this is one of the kernel patchsets I'm using for the system that has Steam installed - maybe take it that way... ;-)

@orbea
Copy link

orbea commented Mar 30, 2022

That makes sense, thanks for explaining! I'm not sure how much time I will spend getting winesync to work right now, but I'll update here if I have any more information. :)

@kakra kakra force-pushed the rebase-5.15/steam-patches branch from d3b6690 to cde56e4 Compare June 2, 2022 07:11
kakra pushed a commit that referenced this pull request Aug 1, 2022
@gregkh
bpf, arm64: Use emit_addr_mov_i64() for BPF_PSEUDO_FUNC
feacd73 
[ Upstream commit e4a41c2 ]

The following error is reported when running "./test_progs -t for_each"
under arm64:

  bpf_jit: multi-func JIT bug 58 != 56
  [...]
  JIT doesn't support bpf-to-bpf calls

The root cause is the size of BPF_PSEUDO_FUNC instruction increases
from 2 to 3 after the address of called bpf-function is settled and
there are two bpf-to-bpf calls in test_pkt_access. The generated
instructions are shown below:

  0x48:  21 00 C0 D2    movz x1, #0x1, lsl #32
  0x4c:  21 00 80 F2    movk x1, #0x1

  0x48:  E1 3F C0 92    movn x1, #0x1ff, lsl #32
  0x4c:  41 FE A2 F2    movk x1, #0x17f2, lsl #16
  0x50:  81 70 9F F2    movk x1, #0xfb84

Fixing it by using emit_addr_mov_i64() for BPF_PSEUDO_FUNC, so
the size of jited image will not change.

Fixes: 69c087b ("bpf: Add bpf_for_each_map_elem() helper")
Signed-off-by: Hou Tao <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
@kakra kakra force-pushed the rebase-5.15/steam-patches branch from cde56e4 to 4d58cd7 Compare August 1, 2022 22:03
@kakra kakra added the done To be superseded by next LTS label Dec 27, 2022
@kakra kakra force-pushed the rebase-5.15/steam-patches branch from 4d58cd7 to de844b1 Compare January 10, 2023 09:21
andrealmeid and others added 18 commits January 10, 2023 10:24
@andrealmeid @kakra
futex: Implement sys_futex_waitv()
c006ca5 
Add support to wait on multiple futexes. This is the interface
implemented by this syscall:

futex_waitv(struct futex_waitv *waiters, unsigned int nr_futexes,
	    unsigned int flags, struct timespec *timeout, clockid_t clockid)

struct futex_waitv {
	__u64 val;
	__u64 uaddr;
	__u32 flags;
	__u32 __reserved;
};

Given an array of struct futex_waitv, wait on each uaddr. The thread
wakes if a futex_wake() is performed at any uaddr. The syscall returns
immediately if any waiter has *uaddr != val. *timeout is an optional
absolute timeout value for the operation. This syscall supports only
64bit sized timeout structs. The flags argument of the syscall should be
empty, but it can be used for future extensions. Flags for shared
futexes, sizes, etc. should be used on the individual flags of each
waiter.

__reserved is used for explicit padding and should be 0, but it might be
used for future extensions. If the userspace uses 32-bit pointers, it
should make sure to explicitly cast it when assigning to waitv::uaddr.

Returns the array index of one of the woken futexes. There’s no given
information of how many were woken, or any particular attribute of it
(if it’s the first woken, if it is of the smaller index...).

Signed-off-by: André Almeida <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
@andrealmeid @kakra
futex,x86: Wire up sys_futex_waitv()
c8febfb 
Wire up syscall entry point for x86 arch, for both i386 and x86_64.

Signed-off-by: André Almeida <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
@kakra
winesync: Introduce the winesync driver and character device.
d583c0e 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Reserve a minor device number and ioctl range.
e7a4892 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_CREATE_SEM and WINESYNC_IOC_DELETE.
9e72be7 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_PUT_SEM.
34bab2f 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_WAIT_ANY.
3d2c1a0 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_WAIT_ALL.
d597bb9 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_CREATE_MUTEX.
690a781 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_PUT_MUTEX.
638fa76 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_KILL_OWNER.
43e6bc2 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_READ_SEM.
0259383 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_READ_MUTEX.
e37374c 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
docs: winesync: Add documentation for the winesync uAPI.
e6e331c 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
selftests: winesync: Add some tests for semaphore state.
416a66e 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
selftests: winesync: Add some tests for mutex state.
b1d0815 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
selftests: winesync: Add some tests for WINESYNC_IOC_WAIT_ANY.
abe2505 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
selftests: winesync: Add some tests for WINESYNC_IOC_WAIT_ALL.
72d8579 
Signed-off-by: Kai Krakow <[email protected]>
Zebediah Figura and others added 24 commits January 10, 2023 10:24
@kakra
maintainers: Add an entry for winesync.
9207ab7 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_CREATE_EVENT.
ea22739 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_SET_EVENT.
26b8d0c 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_RESET_EVENT.
9245256 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_PULSE_EVENT.
c94cc05 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce WINESYNC_IOC_READ_EVENT.
f95eadd 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
selftests: winesync: Add some tests for manual-reset event state.
2e6d92d 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
selftests: winesync: Add some tests for auto-reset event state.
ccc60ef 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
selftests: winesync: Add some tests for wakeup signaling with events.
a08e5d1 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
selftests: winesync: Add some tests for invalid object handling with …
1a14a45 
…events.

Signed-off-by: Kai Krakow <[email protected]>
@kakra
docs: winesync: Document event APIs.
5fa39b7 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
winesync: Introduce alertable waits.
1230c4e 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
selftests: winesync: Add tests for alertable waits.
40d97b5 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
serftests: winesync: Add some tests for wakeup signaling via alerts.
c54c87e 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
docs: winesync: Document alertable waits.
9c2eb2a 
Signed-off-by: Kai Krakow <[email protected]>
@andrealmeid @kakra
HID: hidraw: Replace hidraw device table mutex with a rwsem
6296a42 
Currently, the table that stores information about the connected hidraw
devices has a mutex to prevent concurrent hidraw users to manipulate the
hidraw table (e.g. delete an entry) while someone is trying to use
the table (e.g. issuing an ioctl to the device), preventing the kernel
to referencing a NULL pointer. However, since that every user that wants
to access the table for both manipulating it and reading it content,
this prevents concurrent access to the table for read-only operations
for different or the same device (e.g. two hidraw ioctls can't happen at
the same time, even if they are completely unrelated).

This proves to be a bottleneck and gives performance issues when using
multiple HID devices at same time, like VR kits where one can have two
controllers, the headset and some tracking sensors.

To improve the performance, replace the table mutex with a read-write
semaphore, enabling multiple threads to issue parallel syscalls to
multiple devices at the same time while protecting the table for
concurrent modifications.

Signed-off-by: André Almeida <[email protected]>
@heftig @kakra
ZEN: INTERACTIVE: Enable background reclaim of hugepages
3d694bc 
Use [defer+madvise] as default khugepaged defrag strategy:

For some reason, the default strategy to respond to THP fault fallbacks
is still just madvise, meaning stall if the program wants transparent
hugepages, but don't trigger a background reclaim / compaction if THP
begins to fail allocations.  This creates a snowball affect where we
still use the THP code paths, but we almost always fail once a system
has been active and busy for a while.

The option "defer" was created for interactive systems where THP can
still improve performance.  If we have to fallback to a regular page due
to an allocation failure or anything else, we will trigger a background
reclaim and compaction so future THP attempts succeed and previous
attempts eventually have their smaller pages combined without stalling
running applications.

We still want madvise to stall applications that explicitely want THP,
so defer+madvise _does_ make a ton of sense.  Make it the default for
interactive systems, especially if the kernel maintainer left
transparent hugepages on "always".

Reasoning and details in the original patch: https://lwn.net/Articles/711248/

Signed-off-by: Kai Krakow <[email protected]>
@pfactum @kakra
mm: protect mappings under memory pressure
3976731 
Signed-off-by: Oleksandr Natalenko <[email protected]>
@kakra
mm: Support soft dirty flag reset for VA range.
213451d 
Signed-off-by: Kai Krakow <[email protected]>
@kakra
mm: Support soft dirty flag read with reset.
f44419b 
Signed-off-by: Kai Krakow <[email protected]>
@imaami @kakra
blk: elevator: always use bfq unless overridden by flag
338baa5 
Also add ifdefs so that elevator_get_default() remains unchanged with
respect to upstream if CONFIG_IOSCHED_BFQ is disabled.

Signed-off-by: Juuso Alasuutari <[email protected]>
@xanmod @kakra
XANMOD: block: set rq_affinity to force full multithreading I/O requests
f00cb22 
Signed-off-by: Alexandre Frade <[email protected]>
@ckolivas @kakra
Make threaded IRQs optionally the default which can be disabled.
b9881e5 
Signed-off-by: Kai Krakow <[email protected]>
@xanmod @kakra
sched/core: nr_migrate = 128 increases number of tasks to iterate in …
f60df06 
…a single balance run.

Signed-off-by: Alexandre Frade <[email protected]>
@kakra kakra force-pushed the rebase-5.15/steam-patches branch from de844b1 to f60df06 Compare January 10, 2023 09:25
@kakra kakra closed this Mar 11, 2023
kakra pushed a commit that referenced this pull request Sep 9, 2024
@superjamie @gregkh
ethtool: check device is present when getting link settings
94ab317 
[ Upstream commit a699781 ]

A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:

     [exception RIP: qed_get_current_link+17]
  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
 torvalds#13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
 #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
 #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb

 crash> struct net_device.state ffff9a9d21336000
    state = 5,

state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).

This is the same sort of panic as observed in commit 4224cfd
("net-sysfs: add check for netdevice being present to speed_show").

There are many other callers of __ethtool_get_link_ksettings() which
don't have a device presence check.

Move this check into ethtool to protect all callers.

Fixes: d519e17 ("net: export device speed and duplex via sysfs")
Fixes: 4224cfd ("net-sysfs: add check for netdevice being present to speed_show")
Signed-off-by: Jamie Bainbridge <[email protected]>
Link: https://patch.msgid.link/8bae218864beaa44ed01628140475b9bf641c5b0.1724393671.git.jamie.bainbridge@gmail.com
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
kakra pushed a commit that referenced this pull request Apr 20, 2025
@kamaldasu-crypto @gregkh
mtd: rawnand: brcmnand: fix PM resume warning
7266066 
commit ddc210c upstream.

Fixed warning on PM resume as shown below caused due to uninitialized
struct nand_operation that checks chip select field :
WARN_ON(op->cs >= nanddev_ntargets(&chip->base)

[   14.588522] ------------[ cut here ]------------
[   14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8
[   14.588553] Modules linked in: bdc udc_core
[   14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G        W          6.14.0-rc4-g5394eea10651 #16
[   14.588590] Tainted: [W]=WARN
[   14.588593] Hardware name: Broadcom STB (Flattened Device Tree)
[   14.588598] Call trace:
[   14.588604]  dump_backtrace from show_stack+0x18/0x1c
[   14.588622]  r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c
[   14.588625]  show_stack from dump_stack_lvl+0x70/0x7c
[   14.588639]  dump_stack_lvl from dump_stack+0x18/0x1c
[   14.588653]  r5:c08d40b0 r4:c1003cb0
[   14.588656]  dump_stack from __warn+0x84/0xe4
[   14.588668]  __warn from warn_slowpath_fmt+0x18c/0x194
[   14.588678]  r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000
[   14.588681]  warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8
[   14.588695]  r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048
[   14.588697]  nand_reset_op from brcmnand_resume+0x13c/0x150
[   14.588714]  r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040
[   14.588717]  brcmnand_resume from platform_pm_resume+0x34/0x54
[   14.588735]  r5:00000010 r4:c0840a50
[   14.588738]  platform_pm_resume from dpm_run_callback+0x5c/0x14c
[   14.588757]  dpm_run_callback from device_resume+0xc0/0x324
[   14.588776]  r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010
[   14.588779]  device_resume from dpm_resume+0x130/0x160
[   14.588799]  r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0
[   14.588802]  dpm_resume from dpm_resume_end+0x14/0x20
[   14.588822]  r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414
[   14.588826]  r4:00000010
[   14.588828]  dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8
[   14.588848]  r5:c228a414 r4:00000000
[   14.588851]  suspend_devices_and_enter from pm_suspend+0x228/0x2bc
[   14.588868]  r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000
[   14.588871]  r4:00000003
[   14.588874]  pm_suspend from state_store+0x74/0xd0
[   14.588889]  r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003
[   14.588892]  state_store from kobj_attr_store+0x1c/0x28
[   14.588913]  r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250
[   14.588916]  kobj_attr_store from sysfs_kf_write+0x40/0x4c
[   14.588936]  r5:c3502900 r4:c0d92a48
[   14.588939]  sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0
[   14.588956]  r5:c3502900 r4:c3501f40
[   14.588960]  kernfs_fop_write_iter from vfs_write+0x250/0x420
[   14.588980]  r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00
[   14.588983]  r4:c042a88c
[   14.588987]  vfs_write from ksys_write+0x74/0xe4
[   14.589005]  r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00
[   14.589008]  r4:c34f7f00
[   14.589011]  ksys_write from sys_write+0x10/0x14
[   14.589029]  r7:00000004 r6:004421c0 r5:00443398 r4:00000004
[   14.589032]  sys_write from ret_fast_syscall+0x0/0x5c
[   14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0)
[   14.589050] 9fa0:                   00000004 00443398 00000004 00443398 00000004 00000001
[   14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78
[   14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8
[   14.589065] ---[ end trace 0000000000000000 ]---

The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, when
doing PM resume operation in compliance with the controller support for single
die nand chip. Switching from nand_reset_op() to nand_reset() implies more
than just setting the cs field op->cs, it also reconfigures the data interface
(ie. the timings). Tested and confirmed the NAND chip is in sync timing wise
with host after the fix.

Fixes: 97d90da ("mtd: nand: provide several helpers to do common NAND operations")
Cc: [email protected]
Signed-off-by: Kamal Dasu <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
kakra pushed a commit that referenced this pull request May 31, 2025
@fatherMatrix @gregkh
dm: fix unconditional IO throttle caused by REQ_PREFLUSH
b55a97d 
[ Upstream commit 88f7f56 ]

When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush()
generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC,
which causes the flush_bio to be throttled by wbt_wait().

An example from v5.4, similar problem also exists in upstream:

    crash> bt 2091206
    PID: 2091206  TASK: ffff2050df92a300  CPU: 109  COMMAND: "kworker/u260:0"
     #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8
     #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4
     #2 [ffff800084a2f880] schedule at ffff800040bfa4b4
     #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4
     #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc
     #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0
     #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254
     #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38
     #8 [ffff800084a2fa60] generic_make_request at ffff800040570138
     #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4
    #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs]
    #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs]
    #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs]
    torvalds#13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs]
    #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs]
    #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs]
    #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08
    #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc
    #18 [ffff800084a2fe70] kthread at ffff800040118de4

After commit 2def284 ("xfs: don't allow log IO to be throttled"),
the metadata submitted by xlog_write_iclog() should not be throttled.
But due to the existence of the dm layer, throttling flush_bio indirectly
causes the metadata bio to be throttled.

Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes
wbt_should_throttle() return false to avoid wbt_wait().

Signed-off-by: Jinliang Zheng <[email protected]>
Reviewed-by: Tianxiang Peng <[email protected]>
Reviewed-by: Hao Peng <[email protected]>
Signed-off-by: Mikulas Patocka <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
kakra pushed a commit that referenced this pull request Jan 3, 2026
@AlekseiNikiforovIBM @gregkh
s390/fpu: Fix false-positive kmsan report in fpu_vstl()
13dcd63 
[ Upstream commit 14e4e41 ]

A false-positive kmsan report is detected when running ping command.

An inline assembly instruction 'vstl' can write varied amount of bytes
depending on value of 'index' argument. If 'index' > 0, 'vstl' writes
at least 2 bytes.

clang generates kmsan write helper call depending on inline assembly
constraints. Constraints are evaluated compile-time, but value of
'index' argument is known only at runtime.

clang currently generates call to __msan_instrument_asm_store with 1 byte
as size. Manually call kmsan function to indicate correct amount of bytes
written and fix false-positive report.

This change fixes following kmsan reports:

[   36.563119] =====================================================
[   36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70
[   36.563852]  virtqueue_add+0x35c6/0x7c70
[   36.564016]  virtqueue_add_outbuf+0xa0/0xb0
[   36.564266]  start_xmit+0x288c/0x4a20
[   36.564460]  dev_hard_start_xmit+0x302/0x900
[   36.564649]  sch_direct_xmit+0x340/0xea0
[   36.564894]  __dev_queue_xmit+0x2e94/0x59b0
[   36.565058]  neigh_resolve_output+0x936/0xb40
[   36.565278]  __neigh_update+0x2f66/0x3a60
[   36.565499]  neigh_update+0x52/0x60
[   36.565683]  arp_process+0x1588/0x2de0
[   36.565916]  NF_HOOK+0x1da/0x240
[   36.566087]  arp_rcv+0x3e4/0x6e0
[   36.566306]  __netif_receive_skb_list_core+0x1374/0x15a0
[   36.566527]  netif_receive_skb_list_internal+0x1116/0x17d0
[   36.566710]  napi_complete_done+0x376/0x740
[   36.566918]  virtnet_poll+0x1bae/0x2910
[   36.567130]  __napi_poll+0xf4/0x830
[   36.567294]  net_rx_action+0x97c/0x1ed0
[   36.567556]  handle_softirqs+0x306/0xe10
[   36.567731]  irq_exit_rcu+0x14c/0x2e0
[   36.567910]  do_io_irq+0xd4/0x120
[   36.568139]  io_int_handler+0xc2/0xe8
[   36.568299]  arch_cpu_idle+0xb0/0xc0
[   36.568540]  arch_cpu_idle+0x76/0xc0
[   36.568726]  default_idle_call+0x40/0x70
[   36.568953]  do_idle+0x1d6/0x390
[   36.569486]  cpu_startup_entry+0x9a/0xb0
[   36.569745]  rest_init+0x1ea/0x290
[   36.570029]  start_kernel+0x95e/0xb90
[   36.570348]  startup_continue+0x2e/0x40
[   36.570703]
[   36.570798] Uninit was created at:
[   36.571002]  kmem_cache_alloc_node_noprof+0x9e8/0x10e0
[   36.571261]  kmalloc_reserve+0x12a/0x470
[   36.571553]  __alloc_skb+0x310/0x860
[   36.571844]  __ip_append_data+0x483e/0x6a30
[   36.572170]  ip_append_data+0x11c/0x1e0
[   36.572477]  raw_sendmsg+0x1c8c/0x2180
[   36.572818]  inet_sendmsg+0xe6/0x190
[   36.573142]  __sys_sendto+0x55e/0x8e0
[   36.573392]  __s390x_sys_socketcall+0x19ae/0x2ba0
[   36.573571]  __do_syscall+0x12e/0x240
[   36.573823]  system_call+0x6e/0x90
[   36.573976]
[   36.574017] Byte 35 of 98 is uninitialized
[   36.574082] Memory access of size 98 starts at 0000000007aa0012
[   36.574218]
[   36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G    B            N  6.17.0-dirty #16 NONE
[   36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST
[   36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux)
[   36.574755] =====================================================

[   63.532541] =====================================================
[   63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70
[   63.533989]  virtqueue_add+0x35c6/0x7c70
[   63.534940]  virtqueue_add_outbuf+0xa0/0xb0
[   63.535861]  start_xmit+0x288c/0x4a20
[   63.536708]  dev_hard_start_xmit+0x302/0x900
[   63.537020]  sch_direct_xmit+0x340/0xea0
[   63.537997]  __dev_queue_xmit+0x2e94/0x59b0
[   63.538819]  neigh_resolve_output+0x936/0xb40
[   63.539793]  ip_finish_output2+0x1ee2/0x2200
[   63.540784]  __ip_finish_output+0x272/0x7a0
[   63.541765]  ip_finish_output+0x4e/0x5e0
[   63.542791]  ip_output+0x166/0x410
[   63.543771]  ip_push_pending_frames+0x1a2/0x470
[   63.544753]  raw_sendmsg+0x1f06/0x2180
[   63.545033]  inet_sendmsg+0xe6/0x190
[   63.546006]  __sys_sendto+0x55e/0x8e0
[   63.546859]  __s390x_sys_socketcall+0x19ae/0x2ba0
[   63.547730]  __do_syscall+0x12e/0x240
[   63.548019]  system_call+0x6e/0x90
[   63.548989]
[   63.549779] Uninit was created at:
[   63.550691]  kmem_cache_alloc_node_noprof+0x9e8/0x10e0
[   63.550975]  kmalloc_reserve+0x12a/0x470
[   63.551969]  __alloc_skb+0x310/0x860
[   63.552949]  __ip_append_data+0x483e/0x6a30
[   63.553902]  ip_append_data+0x11c/0x1e0
[   63.554912]  raw_sendmsg+0x1c8c/0x2180
[   63.556719]  inet_sendmsg+0xe6/0x190
[   63.557534]  __sys_sendto+0x55e/0x8e0
[   63.557875]  __s390x_sys_socketcall+0x19ae/0x2ba0
[   63.558869]  __do_syscall+0x12e/0x240
[   63.559832]  system_call+0x6e/0x90
[   63.560780]
[   63.560972] Byte 35 of 98 is uninitialized
[   63.561741] Memory access of size 98 starts at 0000000005704312
[   63.561950]
[   63.562824] CPU: 3 UID: 0 PID: 192 Comm: ping Tainted: G    B            N  6.17.0-dirty #16 NONE
[   63.563868] Tainted: [B]=BAD_PAGE, [N]=TEST
[   63.564751] Hardware name: IBM 3931 A01 703 (KVM/Linux)
[   63.564986] =====================================================

Fixes: dcd3e1d ("s390/checksum: provide csum_partial_copy_nocheck()")
Signed-off-by: Aleksei Nikiforov <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

done To be superseded by next LTS

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

9 participants

@kakra @orbea @andrealmeid @heftig @pfactum @imaami @xanmod @ckolivas