kernel/git/stable/linux.git/Documentation/admin-guide, branch linux-6.18.y

memcg: make the v1 soft limit knob inert

2026-09-11T09:49:13+00:00

commit a3417097fb107cea3358b19bcbb4eb655fd67f8c upstream. The v1 soft limit has been deprecated since v6.12 and nobody has reported depending on it. Start the removal by decoupling the interface from the implementation: keep memory.soft_limit_in_bytes, but ignore writes to it and always report the maximum value on read similar to what memory.kmem.limit_in_bytes already does. Writes are still parsed, so malformed input keeps returning -EINVAL. The knob now also behaves the same everywhere: it used to return -EOPNOTSUPP on PREEMPT_RT, where soft limit reclaim has always been disabled. This also fixes the syzbot report linked below. Soft limit reclaim is the only caller that runs shrink_lruvec() from kswapd against a specific memcg, so it is the only way to reach lru_gen_shrink_lruvec() and in turn set_mm_walk(), which warns when called from kswapd. Link: https://lore.kernel.org/20260811203203.3456029-2-shakeel.butt@linux.dev Signed-off-by: Shakeel Butt Reported-by: syzbot+12ee2725d5fde63a9c96@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a7a6929.b50370da.49fe0.005e.GAE@google.com/ Acked-by: Michal Hocko Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Johannes Weiner Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

zloop: truncate finished zones to zone capacity

2026-09-07T15:22:59+00:00

commit 72e67c118642634c25465db0c8bcfa54c4ce086c upstream. The size of a sequential zone backing file records the amount of data written and is used to restore the zone state. A backing file whose size is equal to the zone capacity is restored as a full zone, while a file larger than the zone capacity is rejected as invalid. However, zloop_finish_zone() currently truncates the backing file to the zone size. For devices with a reduced zone capacity, finishing a zone therefore creates a backing file larger than the zone capacity. After the device is removed and later re-added, that zone file is rejected instead of being restored as a full zone. Truncate finished sequential zones to the zone capacity, matching the persistent representation accepted by zloop_update_seq_zone() for a full zone. Suggested-by: Damien Le Moal Fixes: eb0570c7df23 ("block: new zoned loop block device driver") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Reviewed-by: Christoph Hellwig Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/B39E5FD81D1A07F4+20260804023403.939767-1-raoxu@uniontech.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

x86/CPU: Add a tlbi= cmdline switch

2026-08-19T16:18:18+00:00

commit abe7c8b09bd72a9c726016257c6281f129b4c02d upstream. With the recently found INVLPGB / TLBSYNC issue, there has been some interest in disabling INVLPGB-based TLB flushing, in order to rule out that CPU issue as a cause of userspace crashes. Add a kernel command line option to control the TLB flushing behavior. If the need arises, we will add a "tlbi=broadcast" for the case when TLB invalidation broadcasts need to be explicitly selected, but this is not needed now yet. [ bp: Rewrite commit message, move to cpu/common.c, add documentation. ] Fixes: 767ae437a32d ("x86/mm: Add INVLPGB feature and Kconfig entry") Suggested-by: Borislav Petkov Signed-off-by: Rik van Riel Signed-off-by: Borislav Petkov (AMD) Cc: Link: https://patch.msgid.link/20260729204341.3eb0b5ea@fangorn Signed-off-by: Greg Kroah-Hartman

usb: core: Add quirk for 255-bytes initial config read

2026-08-19T16:17:50+00:00

commit 152f174a13618bec1f842d2deb69245cb2ace51f upstream. Certain third-party USB game controllers exposing (or spoofing) an Xbox 360-compatible interface (VID:PID 045e:028e) fail to enumerate under Linux. The device disconnects from the bus without responding to the initial GET_DESCRIPTOR(CONFIGURATION) request, and the kernel logs 'unable to read config index 0 descriptor/start: -71'. The device then falls back to a secondary Android HID mode (with a different VID:PID), losing XInput functionality including rumble support. The failure reproduces across multiple machines, host controller types, and kernel versions including current mainline and LTS. The device enumerates correctly and remains in XInput mode under Windows. Notably, the device enumerates correctly in Android mode when the same 9-byte request is issued for that mode's configuration descriptor, confirming the firmware bug is specific to the XInput mode. usbmon traces from Linux and Wireshark/USBPcap traces from Windows are identical up to the point of failure, with no visible protocol-level difference explaining the divergence. The root cause was identified when Michal Pecio discovered via a QEMU bus-level capture that Windows does not use wLength=9 for the initial config descriptor request; it uses wLength=255. Alan Stern subsequently confirmed this with a bus analyzer on a different USB 2.0 device, and Michal verified the behavior goes back to Windows 95 OSR2.1. So, add a new quirk flag USB_QUIRK_WINDOWS_CONFIG_REQ_SIZE which causes usb_get_configuration() to issue a 255 byte sized configuration request instead of USB_DT_CONFIG_SIZE (9) for the initial GET_DESCRIPTOR(CONFIGURATION) request, mimicking long-standing Windows behavior. This patch intentionally does not add any new VID:PID entries using this quirk. Some affected Xbox 360-compatible controllers spoof Microsoft's VID:PID, while genuine Microsoft controllers already enumerate correctly and do not require this quirk. Other affected clone devices use their own VID:PID pairs and can be added individually as they are identified. Suggested-by: Alan Stern Suggested-by: Michal Pecio Closes: https://lore.kernel.org/linux-usb/CAFgddh+JWdT4LLwMc5qjM8q_pBu-fRo2qADR5ovAKoGHWMQrRw@mail.gmail.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Acked-by: Alan Stern Signed-off-by: Nikhil Solanke Link: https://patch.msgid.link/20260728195158.65162-2-nikhilsolanke5@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

cpufreq: Documentation: fix conservative governor freq_step description

2026-07-24T14:16:03+00:00

[ Upstream commit 03120e1425262c7d11f93362a88e579a1720390b ] The conservative governor documentation incorrectly states that setting freq_step to 0 will use the default 5% frequency step. In reality, since at least commit 8e677ce83bf4 ("[CPUFREQ] conservative: fixup governor to function more like ondemand logic"), freq_step=0 has always caused the governor to skip frequency updates entirely. Correct the documentation to reflect the actual behavior: freq_step=0 disables frequency changes by the governor entirely. Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation") Signed-off-by: Pengjie Zhang Reviewed-by: Zhongqiu Han [ rjw: Subject adjustment ] Link: https://patch.msgid.link/20260603055635.1549943-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: Documentation: fix sampling_down_factor range

2026-07-24T14:15:52+00:00

[ Upstream commit 85524e651d20944399322d46fb97960337831d43 ] The ondemand governor implementation accepts sampling_down_factor values from 1 to 100000 via MAX_SAMPLING_DOWN_FACTOR, but the documentation in admin-guide/pm/cpufreq.rst still says the valid range is 1 to 100. Update the documentation to match the actual code. Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation") Reviewed-by: Zhongqiu Han Signed-off-by: Pengjie Zhang Link: https://patch.msgid.link/20260518133457.2408463-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

Documentation: intel_pstate: Fix description of asymmetric packing with SMT

2026-06-01T15:50:59+00:00

[ Upstream commit ee047fc7a2da90554410128195058c409a391d43 ] Patchset [1], including commits 046a5a95c3b0 ("x86/sched/itmt: Give all SMT siblings of a core the same priority") 995998ebdebd ("x86/sched: Remove SD_ASYM_PACKING from the SMT domain flags") overhauled asym_packing handling in the scheduler on x86 hybrid processors with SMT. It removed SD_ASYM_PACKING from the x86 SMT scheduling domain and made all SMT siblings of a core share the same priority. As a result, asym_packing operates only across physical cores, spreading tasks among them and only using idle SMT siblings once all physical cores are busy. Fix the documentation to reflect this behavior. Fixes: f20af84c29b2 ("cpufreq: intel_pstate: Document hybrid processor support") Link: https://lore.kernel.org/r/20230406203148.19182-1-ricardo.neri-calderon@linux.intel.com [1] Signed-off-by: Ricardo Neri [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260424-rneri-fix-intel-pstate-doc-smt-asym-packing-v1-1-317bf7d5c362@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

Docs/admin-guide/mm/damon/reclaim: warn commit_inputs vs param updates race

2026-04-22T11:22:28+00:00

commit 0beba407d4585a15b0dc09f2064b5b3ddcb0e857 upstream. Patch series "Docs/admin-guide/mm/damon: warn commit_inputs vs other params race". Writing 'Y' to the commit_inputs parameter of DAMON_RECLAIM and DAMON_LRU_SORT, and writing other parameters before the commit_inputs request is completely processed can cause race conditions. While the consequence can be bad, the documentation is not clearly describing that. Add clear warnings. The issue was discovered [1,2] by sashiko. This patch (of 2): DAMON_RECLAIM handles commit_inputs request inside kdamond thread, reading the module parameters. If the user updates the module parameters while the kdamond thread is reading those, races can happen. To avoid this, the commit_inputs parameter shows whether it is still in the progress, assuming users wouldn't update parameters in the middle of the work. Some users might ignore that. Add a warning about the behavior. The issue was discovered in [1] by sashiko. Link: https://lore.kernel.org/20260329153052.46657-2-sj@kernel.org Link: https://lore.kernel.org/20260319161620.189392-3-objecting@objecting.org [1] Link: https://lore.kernel.org/20260319161620.189392-2-objecting@objecting.org [3] Fixes: 81a84182c343 ("Docs/admin-guide/mm/damon/reclaim: document 'commit_inputs' parameter") Signed-off-by: SeongJae Park Cc: # 5.19.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

usb: core: new quirk to handle devices with zero configurations

2026-04-02T11:23:01+00:00

[ Upstream commit 9f6a983cfa22ac662c86e60816d3a357d4b551e9 ] Some USB devices incorrectly report bNumConfigurations as 0 in their device descriptor, which causes the USB core to reject them during enumeration. logs: usb 1-2: device descriptor read/64, error -71 usb 1-2: no configurations usb 1-2: can't read configurations, error -22 However, these devices actually work correctly when treated as having a single configuration. Add a new quirk USB_QUIRK_FORCE_ONE_CONFIG to handle such devices. When this quirk is set, assume the device has 1 configuration instead of failing with -EINVAL. This quirk is applied to the device with VID:PID 5131:2007 which exhibits this behavior. Signed-off-by: Jie Deng Link: https://patch.msgid.link/20260227084931.1527461-1-dengjie03@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

cgroup/cpuset: Don't fail cpuset.cpus change in v2

2026-03-04T12:19:56+00:00

[ Upstream commit 6e6f13f6d5095f3a432da421e78f4d7d51ef39c8 ] Commit fe8cd2736e75 ("cgroup/cpuset: Delay setting of CS_CPU_EXCLUSIVE until valid partition") introduced a new check to disallow the setting of a new cpuset.cpus.exclusive value that is a superset of a sibling's cpuset.cpus value so that there will at least be one CPU left in the sibling in case the cpuset becomes a valid partition root. This new check does have the side effect of failing a cpuset.cpus change that make it a subset of a sibling's cpuset.cpus.exclusive value. With v2, users are supposed to be allowed to set whatever value they want in cpuset.cpus without failure. To maintain this rule, the check is now restricted to only when cpuset.cpus.exclusive is being changed not when cpuset.cpus is changed. The cgroup-v2.rst doc file is also updated to reflect this change. Signed-off-by: Waiman Long Reviewed-by: Chen Ridong Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin