build(deps): update jinja2 requirement from <3.1,>=2.3 to >=2.3,<3.2 in /Documentation/sphinx in the pip group across 1 directory#3
Open
dependabot[bot] wants to merge 46 commits intomasterfrom
Conversation
…E_O3 1. Revert (a6036a4 "kbuild: drop support for CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3") 2. Mark -O3 as experimental, as it might cause unwanted regressions for users. 3. Allow all architectures to use the experimental -O3 optimization option. Previously, only ARC was allowed to use this option. Link: https://lore.kernel.org/lkml/20191211104619.114557-1-oleksandr@redhat.com/ Signed-off-by: Oleksandr Natalenko <oleksandr@redhat.com> Link: https://lore.kernel.org/lkml/20220621133526.29662-1-mikoxyzzz@gmail.com/ Signed-off-by: Miko Larsson <mikoxyzzz@gmail.com> Signed-off-by: WangYuli <wangyuli@uniontech.com>
The return value of parse_acpi_topology() is both unnecessary and
unused.
Co-developed-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Yuli Wang <wangyuli@uniontech.com>
---
Changelog:
*v1->v2: Fix missing "return".
v2->v3: Fix missing "{}"
The apic_id here, as declared as a u8 (unsigned char) in struct
acpi_srat_cpu_affinity of acpi/actbl3.h, has a range up to 255.
Evidently, if CONFIG_NR_CPUS becomes 256 or more, the check
"apic_id >= CONFIG_NR_CPUS" will always be false, which will produce
a compiler warning.
Only compile this code if CONFIG_NR_CPUS is at most 255 consequently.
Fix follow error with clang-18 when W=1e:
arch/loongarch/kernel/acpi.c:302:18: error: result of comparison of constant 256 with expression of type 'u8' (aka 'unsigned char') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
302 | if (pa->apic_id >= CONFIG_NR_CPUS) {
| ~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
1 error generated.
Signed-off-by: Yuli Wang <wangyuli@uniontech.com>
It's unnecessary to re-initialize smp_ops.play_dead to play_dead as it naturally goes back to play_dead in the freshly booted kernel upon device resume. Suggested-by: Huacai Chen <chenhuacai@loongson.cn> Co-developed-by: Wentao Guan <guanwentao@uniontech.com> Signed-off-by: Wentao Guan <guanwentao@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com>
The apic_id employed within the acpi_numa_processor_affinity_init() function is derived from the acpi_srat_cpu_affinity structure defined in acpi/actbl3.h. When CONFIG_X86_X2APIC is not enabled, its maximum value is limited to 255. It is only capable of exceeding 256 and 32768 — which corresponds to the definition of MAX_LOCAL_APIC — when CONFIG_X86_X2APIC is activated. Consequently, with CONFIG_X86_X2APIC disabled, this code segment will elicit the compiler's "-Wtautological-constant-out-of-range-compare" warning, as a variable capped at 255 can never satisfy a condition requiring it to be greater than or equal to 256 or 32768. Compiling the kernel with the W=1e flag will, in this scenario, lead to compilation failure. Suggested-by: Huacai Chen <chenhuacai@loongson.cn> Co-developed-by: Wentao Guan <guanwentao@uniontech.com> Signed-off-by: Wentao Guan <guanwentao@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com>
Fix follow error with clang-19:
arch/loongarch/kernel/setup.c:335:40: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand]
335 | if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) && CONFIG_CMDLINE[0]) {
| ^ ~~~~~~~~~~~~~~~~~
arch/loongarch/kernel/setup.c:335:40: note: use '&' for a bitwise operation
335 | if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) && CONFIG_CMDLINE[0]) {
| ^~
| &
arch/loongarch/kernel/setup.c:335:40: note: remove constant to silence this warning
335 | if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) && CONFIG_CMDLINE[0]) {
| ^~~~~~~~~~~~~~~~~~~~
1 error generated.
Fixes: 83da30d ("LoongArch: Fix CMDLINE_EXTEND and CMDLINE_BOOTLOADER handling")
Co-developed-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Yuli Wang <wangyuli@uniontech.com>
Given that uclamp_update_active() is exclusively called by
uclamp_update_active_tasks(), and considering that
uclamp_update_active_tasks() is utilized solely when
CONFIG_UCLAMP_TASK_GROUP is enabled, it follows that
uclamp_update_active() will emit a compilation warning if
CONFIG_UCLAMP_TASK_GROUP is not enabled.
Similar reason of uclamp_rq_reinc_id().
Fix follow errors with clang-19 when W=1e:
kernel/sched/core.c:1818:1: error: unused function 'uclamp_update_active' [-Werror,-Wunused-function]
1818 | uclamp_update_active(struct task_struct *p)
| ^~~~~~~~~~~~~~~~~~~~
kernel/sched/core.c:1800:20: error: unused function 'uclamp_rq_reinc_id' [-Werror,-Wunused-function]
1800 | static inline void uclamp_rq_reinc_id(struct rq *rq, struct task_struct *p,
| ^~~~~~~~~~~~~~~~~~
Signed-off-by: WangYuli <wangyuli@uniontech.com>
Given that when CONFIG_EFI is not enabled, do_mapping is inherently
false. Thus, the mapping_size variable is set but remains unused,
resulting in a compilation warning.
Simply annotating it with __maybe_unused will resolve this compilation
warning.
[ Fix follow errors with clang-19 when W=1e: ]
In file included from drivers/char/tpm/tpm1-cmd.c:21:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/tpm1-cmd.o] Error 1
make[8]: *** Waiting for unfinished jobs....
In file included from drivers/char/tpm/tpm-dev-common.c:19:
In file included from drivers/char/tpm/tpm.h:28:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/tpm-dev-common.o] Error 1
In file included from drivers/char/tpm/tpm2-cmd.c:14:
In file included from drivers/char/tpm/tpm.h:28:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
In file included from drivers/char/tpm/tpm-dev.c:16:
In file included from drivers/char/tpm/tpm-dev.h:6:
In file included from drivers/char/tpm/tpm.h:28:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/tpm-dev.o] Error 1
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/tpm2-cmd.o] Error 1
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/tpmrm-dev.o] Error 1
In file included from drivers/char/tpm/tpm-chip.c:24:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
In file included from drivers/char/tpm/tpm-sysfs.c:16:
In file included from drivers/char/tpm/tpm.h:28:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/tpm-chip.o] Error 1
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/tpm-sysfs.o] Error 1
In file included from drivers/char/tpm/tpm2-sessions.c:71:
In file included from drivers/char/tpm/tpm.h:28:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/tpm2-sessions.o] Error 1
In file included from drivers/char/tpm/tpm-interface.c:28:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/tpm-interface.o] Error 1
In file included from drivers/char/tpm/tpm2-space.c:16:
In file included from drivers/char/tpm/tpm.h:28:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/tpm2-space.o] Error 1
In file included from drivers/char/tpm/eventlog/tpm1.c:24:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/eventlog/tpm1.o] Error 1
In file included from drivers/char/tpm/eventlog/common.c:20:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/eventlog/common.o] Error 1
In file included from drivers/char/tpm/eventlog/tpm2.c:20:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/eventlog/tpm2.o] Error 1
In file included from drivers/char/tpm/tpm_vtpm_proxy.c:24:
In file included from drivers/char/tpm/tpm.h:28:
./include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
167 | int mapping_size;
| ^
1 error generated.
make[8]: *** [scripts/Makefile.build:207: drivers/char/tpm/tpm_vtpm_proxy.o] Error 1
make[7]: *** [scripts/Makefile.build:465: drivers/char/tpm] Error 2
make[6]: *** [scripts/Makefile.build:465: drivers/char] Error 2
make[6]: *** Waiting for unfinished jobs....
Suggested-by: Chen Linxuan <chenlinxuan@uniontech.com>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
…f" attribute On some external USB hard drives, mounting can fail if "lshw" is executed during the process. This occurs because data sent to the device's output endpoint in certain abnormal scenarios does not receive a response, leading to a mount timeout. [ Description of "use_192_bytes_for_3f" in the kernel code: ] /* * Many disks only accept MODE SENSE transfer lengths of * 192 bytes (that's what Windows uses). */ sdev->use_192_bytes_for_3f = 1; The kernel's SCSI driver, when handling devices with this attribute, sends commands with a length of 192 bytes like this: if (sdp->use_192_bytes_for_3f) res = sd_do_mode_sense(sdp, 0, 0x3F, buffer, 192, &data, NULL); However, "lshw" disregards the "use_192_bytes_for_3f" attribute and transmits data with a length of 0xff bytes via ioctl, which can cause some hard drives to hang and become unusable. To resolve this issue, prevent commands with a length of 0xff bytes from being queued via ioctl when it detects the "use_192_bytes_for_3f" attribute on the device. The hard drive device identified with the issue is Lenovo USB 17ef:4531. Tested on HONOR NBLK-WAX9X (C234) Notebook with AMD Ryzen 7 3700U. [ Kernel logs: ] 2024-10-31 13:36:11 localhost kernel: [ 25.770091] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd 2024-10-31 13:36:11 localhost kernel: [ 25.798558] usb 2-2: New USB device found, idVendor=17ef, idProduct=4531, bcdDevice= 5.12 2024-10-31 13:36:11 localhost kernel: [ 25.798562] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 2024-10-31 13:36:11 localhost kernel: [ 25.798564] usb 2-2: Product: Lenovo Portable HDD 2024-10-31 13:36:11 localhost kernel: [ 25.798566] usb 2-2: Manufacturer: Lenovo 2024-10-31 13:36:11 localhost kernel: [ 25.798567] usb 2-2: SerialNumber: 000000001E4C 2024-10-31 13:36:11 localhost kernel: [ 25.820244] usb-storage 2-2:1.0: USB Mass Storage device detected 2024-10-31 13:36:11 localhost kernel: [ 25.820457] scsi host0: usb-storage 2-2:1.0 2024-10-31 13:36:11 localhost kernel: [ 25.820633] usbcore: registered new interface driver usb-storage 2024-10-31 13:36:11 localhost kernel: [ 25.825598] usbcore: registered new interface driver uas 2024-10-31 13:36:14 localhost kernel: [ 28.852179] scsi 0:0:0:0: Direct-Access Lenovo USB Hard Drive 0006 PQ: 0 ANSI: 2 2024-10-31 13:36:14 localhost kernel: [ 28.852961] sd 0:0:0:0: Attached scsi generic sg0 type 0 2024-10-31 13:36:14 localhost kernel: [ 28.891218] sd 0:0:0:0: [sda] 976773164 512-byte logical blocks: (500 GB/466 GiB) 2024-10-31 13:36:14 localhost kernel: [ 28.906892] sd 0:0:0:0: [sda] Write Protect is off 2024-10-31 13:36:14 localhost kernel: [ 28.906896] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 2024-10-31 13:36:14 localhost kernel: [ 28.922606] sd 0:0:0:0: [sda] No Caching mode page found 2024-10-31 13:36:14 localhost kernel: [ 28.922612] sd 0:0:0:0: [sda] Assuming drive cache: write through 2024-10-31 13:36:14 localhost kernel: [ 29.007816] sda: sda1 2024-10-31 13:36:15 localhost kernel: [ 30.180380] sd 0:0:0:0: [sda] Attached SCSI disk 2024-10-31 13:36:16 localhost kernel: [ 30.722863] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x3, stream=0x5, channel=0, format=0x4011 2024-10-31 13:36:16 localhost kernel: [ 30.734139] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011 2024-10-31 13:36:17 localhost kernel: [ 31.396011] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384) 2024-10-31 13:36:18 localhost kernel: [ 32.933537] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x3 2024-10-31 13:36:18 localhost kernel: [ 32.933541] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x2 2024-10-31 13:36:39 localhost kernel: [ 54.242220] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd 2024-10-31 13:36:50 localhost kernel: [ 64.408879] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384) 2024-10-31 13:37:11 localhost kernel: [ 85.466479] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd 2024-10-31 13:37:11 localhost kernel: [ 85.490248] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK 2024-10-31 13:37:11 localhost kernel: [ 85.490255] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 20 00 00 08 00 2024-10-31 13:37:11 localhost kernel: [ 85.490258] print_req_error: I/O error, dev sda, sector 32 2024-10-31 13:37:33 localhost kernel: [ 107.432186] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384) 2024-10-31 13:37:41 localhost kernel: [ 116.194201] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd 2024-10-31 13:37:49 localhost kernel: [ 123.555484] dolphin[7271]: segfault at 10 ip 00007fcccc0d7f76 sp 00007ffe8004b860 error 4 in libKF5CoreAddons.so.5.102.0[7fcccc0a5000+83000] 2024-10-31 13:37:49 localhost kernel: [ 123.555502] Code: d6 90 66 90 41 54 41 89 d4 55 48 89 fd 53 48 89 f3 e8 8e 94 01 00 ba 04 00 00 00 48 89 de 48 89 c7 e8 4e 8f 01 00 84 c0 75 2a <48> 8b 7d 10 48 85 ff 74 21 45 89 e1 48 89 da 48 89 ee 5b 41 b8 01 2024-10-31 13:38:11 localhost kernel: [ 146.229510] usb 2-2: USB disconnect, device number 2 2024-10-31 13:38:11 localhost kernel: [ 146.237993] scsi 0:0:0:0: rejecting I/O to dead device 2024-10-31 13:38:11 localhost kernel: [ 146.238003] print_req_error: I/O error, dev sda, sector 32 2024-10-31 13:38:11 localhost kernel: [ 146.238009] Buffer I/O error on dev sda, logical block 8, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238029] scsi 0:0:0:0: rejecting I/O to dead device 2024-10-31 13:38:11 localhost kernel: [ 146.238030] print_req_error: I/O error, dev sda, sector 36 2024-10-31 13:38:11 localhost kernel: [ 146.238032] Buffer I/O error on dev sda, logical block 9, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238045] scsi 0:0:0:0: rejecting I/O to dead device 2024-10-31 13:38:11 localhost kernel: [ 146.238047] print_req_error: I/O error, dev sda, sector 6291480 2024-10-31 13:38:11 localhost kernel: [ 146.238062] Buffer I/O error on dev sda1, logical block 786431, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238168] Buffer I/O error on dev sda, logical block 8, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238170] Buffer I/O error on dev sda, logical block 9, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238175] Buffer I/O error on dev sda, logical block 8, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238176] Buffer I/O error on dev sda, logical block 9, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238184] Buffer I/O error on dev sda, logical block 8, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238185] Buffer I/O error on dev sda, logical block 9, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238199] Buffer I/O error on dev sda, logical block 40, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238201] Buffer I/O error on dev sda, logical block 41, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238205] Buffer I/O error on dev sda, logical block 8, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238206] Buffer I/O error on dev sda, logical block 9, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238210] Buffer I/O error on dev sda, logical block 8, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238211] Buffer I/O error on dev sda, logical block 9, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238215] Buffer I/O error on dev sda, logical block 8, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238217] Buffer I/O error on dev sda, logical block 9, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238220] Buffer I/O error on dev sda, logical block 8, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238221] Buffer I/O error on dev sda, logical block 9, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238224] Buffer I/O error on dev sda, logical block 8, async page read 2024-10-31 13:38:11 localhost kernel: [ 146.238226] Buffer I/O error on dev sda, logical block 9, async page read 2024-10-31 13:38:12 localhost kernel: [ 146.482007] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x3, stream=0x5, channel=0, format=0x4011 2024-10-31 13:38:12 localhost kernel: [ 146.494064] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011 2024-10-31 13:38:15 localhost kernel: [ 150.065848] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x3 2024-10-31 13:38:15 localhost kernel: [ 150.065852] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x2 2024-10-31 13:38:26 localhost kernel: [ 160.433037] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384) 2024-10-31 13:39:29 localhost kernel: [ 223.444589] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384) Link: https://linux-hardware.org/?id=usb:17ef-4531 Link: https://lore.kernel.org/all/80ef917b-3680-4f85-93ba-c92d2b69ebaa@rowland.harvard.edu/ Link: https://lore.kernel.org/all/ad4bd008-8d0d-439b-879c-e9cf4c89ec56@acm.org/ Link: https://lore.kernel.org/all/4EB8ECD64F601331+e2f01a1f-8da5-4e7b-b909-d920a792756a@uniontech.com/ Reported-by: Xinwei Zhou <zhouxinwei@uniontech.com> Co-developed-by: Xu Rao <raoxu@uniontech.com> Signed-off-by: Xu Rao <raoxu@uniontech.com> Tested-by: Yujing Ming <mingyujing@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com> --- Changelog: *v1->v2: Move the bugfix to the SCSI layer. v2->v3: Optimize code style and comment readability.
The nop instruction surrounding "breakinst:\tbreak\n\t" appears to serve no real purpose. Its introduction can be traced back to commit 51c6022 ("[PATCH] MIPS update") within the Linux history tree [1]. This commit was substantial, comprising 41010 lines, and provides no justification for the insertion of this nop instruction. Based on the MIPS architecture specification, delay slots are only present after jump instructions or MIPS1 load instructions. Consequently, the nop here is not intended to satisfy a delay slot requirement. Thus, this instruction is suspicious and should probably be removed. [1]. https://web.git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Cc: Maciej W. Rozycki <macro@orcam.me.uk> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: WANG Xuerui <kernel@xen0n.name> Cc: Felix Yan <felixonmars@archlinux.org> Cc: Mingcong Bai <jeffbai@aosc.io> Signed-off-by: WangYuli <wangyuli@uniontech.com> --- NOTE: This patch is submitted as an RFC due to my incomplete knowledge of the extensive history of MIPS. The nop instruction in question may indeed have a valid reason for its existence, but its origins are likely too far in the past to easily ascertain. I would be grateful if anyone with relevant historical information could take the time to elaborate on the background, such as specific models or microarchitectures that might be impacted by this change. Thank you all very much for your assistance.
[ General description per its product manual: ] The IT8768E-I is a highly integrated Super I/O using the Low Pin Count Interface. The device’s LPC interface complies with Intel "LPC Interface Specification Rev. 1.1”. The IT8768E-I is ACPI & LANDesk compliant. Integrated in the IT8768E-I are five logical devices, which can be individually enabled or disabled via software configuration registers, and four 16C550standard compatible enhanced UARTs perofrmacing asynchronous communication. The devices also provide GPIO port controlling up to 12 GPIO pins. The IT8768E-I utilizes power-saving circuitry to reduce power consumption, and once a logical device is disabled, the inputs are inhibited with the clock disabled and the outputs are tri-stated. The device requires a single 24/48 MHz clock input and operates with +3.3V power supply. The IT8768E-I is available in 48-pin LQFP. It has been determined that this chip is currently employed within YIHUA STS-320 intelligent teller terminals utilizing PCBA F21-2401 D2000 MB VerA LF motherboards. Add a driver to support it. [ Kernel logs without this driver: ] [ 1.016170] EFI Variables Facility v0.08 2004-May-17 [ 1.034039] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.035215] serial 0000:06:00.0: enabling device (0000 -> 0002) [ 1.035649] 0000:06:00.0: ttyS0 at MMIO 0x64100000 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.035812] 0000:06:00.0: ttyS1 at MMIO 0x64100400 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.035966] 0000:06:00.0: ttyS2 at MMIO 0x64100800 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.036119] 0000:06:00.0: ttyS3 at MMIO 0x64100c00 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.036271] 0000:06:00.0: ttyS4 at MMIO 0x64101000 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.036425] 0000:06:00.0: ttyS5 at MMIO 0x64101400 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.036576] 0000:06:00.0: ttyS6 at MMIO 0x64101800 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.036727] 0000:06:00.0: ttyS7 at MMIO 0x64101c00 (irq = 31, base_baud = 7812500) is a XR17V35X [ Kernel logs with this driver: ] [ 1.017777] EFI Variables Facility v0.08 2004-May-17 [ 1.036036] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.037286] ITES0001:00: ttyS0 at MMIO 0x20000130 (irq = 0, base_baud = 115200) is a 16550A [ 1.037444] ITES0001:01: ttyS1 at MMIO 0x20000138 (irq = 0, base_baud = 115200) is a 16550A [ 1.037607] ITES0001:02: ttyS2 at MMIO 0x20000140 (irq = 0, base_baud = 115200) is a 16550A [ 1.037759] ITES0001:03: ttyS3 at MMIO 0x20000148 (irq = 0, base_baud = 115200) is a 16550A [ 1.037906] ITES0001:04: ttyS4 at MMIO 0x20000150 (irq = 0, base_baud = 115200) is a 16550A [ 1.038056] serial 0000:06:00.0: enabling device (0000 -> 0002) [ 1.038438] 0000:06:00.0: ttyS5 at MMIO 0x64100000 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.038595] 0000:06:00.0: ttyS6 at MMIO 0x64100400 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.038749] 0000:06:00.0: ttyS7 at MMIO 0x64100800 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.038907] 0000:06:00.0: ttyS8 at MMIO 0x64100c00 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.039059] 0000:06:00.0: ttyS9 at MMIO 0x64101000 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.039214] 0000:06:00.0: ttyS10 at MMIO 0x64101400 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.039367] 0000:06:00.0: ttyS11 at MMIO 0x64101800 (irq = 31, base_baud = 7812500) is a XR17V35X [ 1.039519] 0000:06:00.0: ttyS12 at MMIO 0x64101c00 (irq = 31, base_baud = 7812500) is a XR17V35X Reported-by: Zhuozhen He <hezhuozhen@uniontech.com> Tested-by: Guowei Chen <chenguowei@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com>
This patch addresses the PCI I/O port address handling in RISC-V's port-mapped I/O emulation routines when the MMU is not enabled. The changes ensure that: 1. For non-MMU systems, the PCI I/O port addresses are properly calculated in marcos inX and outX when PCI_IOBASE is not defined, this avoids the null pointer calculating warning from the compiler. 2. In asm-generic/io.h, function ioport_map(), casting PCI_IOPORT to type "long" firstly makes it could compute with variable addr directly, which avoids the null pointer calculating warning when PCI_IOPORT is a null pointer in some case. The original implementation used `PCI_IOBASE + (addr)` for MMU-enabled systems, but failed to handle non-MMU cases correctly. This change adds conditional compilation guards (#ifdef CONFIG_MMU) to differentiate between MMU and non-MMU environments, providing consistent behavior for both scenarios. Fixes: 9cc205e ("RISC-V: Make port I/O string accessors actually work") Reported-by: WangYuli <wangyuli@uniontech.com> Signed-off-by: Liu Runrun <liurunrun@uniontech.com>
Due to long-term changes in kernel build configurations, run 'make savedefconfig' to update the build configuration dependencies. This commit does not affect the actual .config file content, in preparation for future modifications to defconfigs. Signed-off-by: WangYuli <wangyuli@uniontech.com>
All compilation issues under arch/riscv/configs/*defconfig have been resolved, and it is now safe to enable CONFIG_WERROR now. Tested-by: WangYuli <wangyuli@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com>
The vmlinux file would be generated when building kernel. Add it to .gitignore to ensure Git does not track it. Signed-off-by: WangYuli <wangyuli@uniontech.com>
This commit provides a default serial.h for uart drivers needing BASE_BAUD. Link: https://github.com/AOSC-Dev/aosc-os-abbs/blob/stable/runtime-kernel/linux-kernel/autobuild/patches/0294-AOSCOS-Staging-sb105x-Fix-build-and-add-MIPS-support.patch Link: https://github.com/AOSC-Dev/aosc-os-abbs/blob/stable/runtime-kernel/linux-kernel/autobuild/patches/0301-AOSCOS-MIPS-serial-drop-STD_FLAGS.patch Co-developed-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Co-developed-by: Kexy Biscuit <kexybiscuit@aosc.io> Signed-off-by: Kexy Biscuit <kexybiscuit@aosc.io> Co-developed-by: Mingcong Bai <jeffbai@aosc.io> Signed-off-by: Mingcong Bai <jeffbai@aosc.io> Signed-off-by: WangYuli <wangyuli@uniontech.com>
This reverts commit aa98b77. The sb105x driver was removed by commit aa98b77 ("staging: sb105x: delete the driver"), but it turns out a number of Lemote Loongson/MIPS devices still rely on this functionality. Fortunately, a dedicated group of hobbyists is stepping up to maintain it, despite the tough road ahead. Building upon the original driver code, this commit incorporates the following changes: *1. Resolve minor merge conflicts in drivers/staging/Kconfig and drivers/staging/Makefile. 2. Fix compilation errors in the current kernel and unset the BROKEN flag. 3. Add MIPS support for this driver. 4. Rectify assorted issues identified by checkpatch.pl. 5. Move this driver from drivers/staging/ to drivers/tty/serial/. 6. Rename del_timer_sync to timer_delete_sync because of commit 8fa7292 ("treewide: Switch/rename to timer_delete[_sync]()"). 7. Fix compile error on arm (for COMPILE_TEST). 8. Add missing SPDX-License-Identifier tags. Acknowledgments: Appreciate the AOSC Linux community [1] kernel developers for their past work maintaining this driver. [2] [1]. https://aosc.io/ [2]. 0293..0308 patch of: https://github.com/AOSC-Dev/aosc-os-abbs/tree/stable/runtime-kernel/linux-kernel/autobuild/patches Co-developed-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Co-developed-by: Kexy Biscuit <kexybiscuit@aosc.io> Signed-off-by: Kexy Biscuit <kexybiscuit@aosc.io> Co-developed-by: Mingcong Bai <jeffbai@aosc.io> Signed-off-by: Mingcong Bai <jeffbai@aosc.io> Signed-off-by: WangYuli <wangyuli@uniontech.com>
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on mips with CPU_LOONGSON64, covering the vdso. NOTE: There is significant diversity among devices within the MIPS architecture, which extends to their kernel code implementations. My testing capabilities are limited to Loongson 3A4000/3B4000 CPUs. Consequently, I have not enabled mseal sysmap support for the entirety of mips64, as I lack the necessary devices for testing. Tested-by: Erpeng Xu <xuerpeng@uniontech.com> Tested-by: WangYuli <wangyuli@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com> --- NOTE: 1. As I am unaware whether other 64-bit MIPS devices function properly, I have not yet modified the MIPS status in mseal_sys_mappings/arch-support.txt. 2. From my perspective, it appears that this architecture also does not rely on remapping the VDSO, VVAR, or any other special mapping. Nevertheless, I believe it would be best to get further confirmation from more expert individuals such as Lorenzo Stoakes and Thomas Bogendoerfer.
Add support for Westone Security Engine Chip Driver. This driver supports the security co-processor in Loongson 3A4000 and 3A5000 processors. It provides hardware acceleration for a range of cryptographic algorithms, such as ECC-based asymmetric cryptography. Link: deepin-community/kernel#713 Link: https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel/pulls/349 Co-developed-by: Tianyang Zhang <zhangtianyang@loongson.cn> Signed-off-by: Tianyang Zhang <zhangtianyang@loongson.cn> Co-developed-by: Liu Peibao <liupeibao@loongson.cn> Signed-off-by: Liu Peibao <liupeibao@loongson.cn> Co-developed-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Co-developed-by: liweihao <liweihao@loongson.cn> Signed-off-by: liweihao <liweihao@loongson.cn> Co-developed-by: Mao Bibo <maobibo@loongson.cn> Signed-off-by: Mao Bibo <maobibo@loongson.cn> Co-developed-by: Qunqin Zhao <zhaoqunqin@loongson.cn> Signed-off-by: Qunqin Zhao <zhaoqunqin@loongson.cn> Co-developed-by: Ming Wang <wangming01@loongson.cn> Signed-off-by: Ming Wang <wangming01@loongson.cn> Signed-off-by: WangYuli <wangyuli@uniontech.com>
During 'make modules_install', the need-compiler variable becomes null, so Makefile.compiler isn't included. This results in call cc-option-yn returning nothing. For more technical details on why need-compiler is null during ‘make modules_install’ and why no compiler invocation is actually needed at this point, please refer to commit 4fe4a63 ("MIPS: Only fiddle with CHECKFLAGS if need-compiler") and commit 805b2e1 ("kbuild: include Makefile.compiler only when compiler is needed"). Commit a79a404 ("MIPS: Fix CONFIG_CPU_DADDI_WORKAROUNDS `modules_install' regression") tried to fix the same issue but it caused a compile error on clang compiler because it doesn't support '-msym32'. Then, commit 18ca63a ("MIPS: Probe toolchain support of -msym32") fixed it but reintroduced the CONFIG_CPU_DADDI_WORKAROUNDS `modules_install' regression. Wrapping this entire code block with #ifdef need-compiler to avoid all issues is the best solution for now. To get rid of spurious "CONFIG_CPU_DADDI_WORKAROUNDS unsupported without -msym32" error. Link: https://lore.kernel.org/all/alpine.DEB.2.21.2502120612000.65342@angie.orcam.me.uk/ Link: https://lore.kernel.org/all/alpine.DEB.2.21.2307180025120.62448@angie.orcam.me.uk/ Fixes: a79a404 ("MIPS: Fix CONFIG_CPU_DADDI_WORKAROUNDS `modules_install' regression") Reported-by: Maciej W. Rozycki <macro@orcam.me.uk> Closes: https://lore.kernel.org/all/alpine.DEB.2.21.2501030535080.49841@angie.orcam.me.uk/ Co-developed-by: Chen Linxuan <chenlinxuan@uniontech.com> Signed-off-by: Chen Linxuan <chenlinxuan@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com>
Given that KBUILD_SYM32=y is a prerequisite for this statement to be executed, it's logically redundant to verify KBUILD_SYM32 is y again. Signed-off-by: WangYuli <wangyuli@uniontech.com>
Declare externally used functions in reset.c to resolve compilation
warnings.
Fix follow errors with gcc-14 when -Werror:
arch/mips/dec/reset.c:22:17: error: no previous prototype for ‘dec_machine_restart’ [-Werror=missing-prototypes]
22 | void __noreturn dec_machine_restart(char *command)
| ^~~~~~~~~~~~~~~~~~~
arch/mips/dec/reset.c:27:17: error: no previous prototype for ‘dec_machine_halt’ [-Werror=missing-prototypes]
27 | void __noreturn dec_machine_halt(void)
| ^~~~~~~~~~~~~~~~
arch/mips/dec/reset.c:32:17: error: no previous prototype for ‘dec_machine_power_off’ [-Werror=missing-prototypes]
32 | void __noreturn dec_machine_power_off(void)
| ^~~~~~~~~~~~~~~~~~~~~
arch/mips/dec/reset.c:38:13: error: no previous prototype for ‘dec_intr_halt’ [-Werror=missing-prototypes]
38 | irqreturn_t dec_intr_halt(int irq, void *dev_id)
| ^~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[7]: *** [scripts/Makefile.build:207: arch/mips/dec/reset.o] Error 1
make[7]: *** Waiting for unfinished jobs....
In passing, also correct the include file ordering in setup.c as it
doesn't merit a separate commit.
Link: https://lore.kernel.org/all/Z8A0JeFYfBxXOFCD@alpha.franken.de/
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
---
Changelog:
*v1->v2: Add Philippe Mathieu-Daudé's "Reviewed-by" tag.
Commit 187933f ("[MIPS] do_IRQ cleanup") introduced dec_irq_dispatch() function. But Subsequent to commit 8f99a16 ("MIPS: Tracing: Add IRQENTRY_EXIT section for MIPS"), the dec_irq_dispatch() function is rendered superfluous. Remove it to eradicate compilation warnings. [ Quoting Maciej W. Rozycki: ] It always has been, since its inception, see commit 187933f ("[MIPS] do_IRQ cleanup"). Up to commit 8f99a16 ("MIPS: Tracing: Add IRQENTRY_EXIT section for MIPS") `do_IRQ' used to be a macro, that's why. At the time `do_IRQ' was converted to a macro `dec_irq_dispatch' was created and previously this place used to call `do_IRQ' too. This cleanup should have been made along with commit 8f99a16, so it's pretty old a technical debt being sorted here. [ Fix follow error with gcc-14 when -Werror: ] arch/mips/dec/setup.c:780:25: error: no previous prototype for ‘dec_irq_dispatch’ [-Werror=missing-prototypes] 780 | asmlinkage unsigned int dec_irq_dispatch(unsigned int irq) | ^~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[7]: *** [scripts/Makefile.build:207: arch/mips/dec/setup.o] Error 1 make[6]: *** [scripts/Makefile.build:465: arch/mips/dec] Error 2 make[5]: *** [scripts/Makefile.build:465: arch/mips] Error 2 make[5]: *** Waiting for unfinished jobs.... make[4]: *** [Makefile:1992: .] Error 2 make[3]: *** [debian/rules:74: build-arch] Error 2 dpkg-buildpackage: error: make -f debian/rules binary subprocess returned exit status 2 make[2]: *** [scripts/Makefile.package:126: bindeb-pkg] Error 2 make[1]: *** [/mnt/83364c87-f5ee-4ae8-b862-930f1bd74feb/Projects/CommitUpstream/LinuxKernel/Temp/linux/Makefile:1625: bindeb-pkg] Error 2 make: *** [Makefile:251: __sub-make] Error 2 Link: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=187933f23679c413706030aefad9e85e79164c44 Link: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8f99a162653531ef25a3dd0f92bfb6332cd2b295 Link: https://lore.kernel.org/all/alpine.DEB.2.21.2502220019210.65342@angie.orcam.me.uk/ Signed-off-by: WangYuli <wangyuli@uniontech.com>
Due to long-term changes in kernel build configurations, run 'make savedefconfig' to update the build configuration dependencies. This commit does not affect the actual .config file content, in preparation for future modifications to decstation_64_defconfig. Signed-off-by: WangYuli <wangyuli@uniontech.com>
…rors All compilation issues under decstation_64_defconfig have been resolved, and it is now safe to enable CONFIG_WERROR now. Signed-off-by: WangYuli <wangyuli@uniontech.com>
LoongArch, MIPS and XTENSA has supported memtest now. Update documentation for them. Link: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dce44566192ec0b38597fdfd435013c2d54653ff Link: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fb8e9f59d6f292c3d9fea6c155c22ea5fc3053ab Signed-off-by: WangYuli <wangyuli@uniontech.com>
There is a spelling mistake of 'restictions' in comments which should be 'restrictions'. This typo was not listed in scripts/spelling.txt, thus it was more difficult to detect. Add it for convenience. This typo is reported by GitHub Copilot code review. [1] [1]. deepin-community/kernel#796 Signed-off-by: WangYuli <wangyuli@uniontech.com>
This patch simply includes the cpuidle Kconfig entries in preparation for cpuidle drivers used on LoongArch systems. Same as commit c095eba ("MIPS: include cpuidle Kconfig menu"). Reported-by: Yang Shao <shaoyang@uniontech.com> Co-developed-by: Lunpeng Wen <wenlunpeng@uniontech.com> Signed-off-by: Lunpeng Wen <wenlunpeng@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com>
Add missing parameter documentation for virtio_dma_buf_attach() function to fix kernel-doc warnings: Warning: drivers/virtio/virtio_dma_buf.c:41 function parameter 'dma_buf' not described in 'virtio_dma_buf_attach' Warning: drivers/virtio/virtio_dma_buf.c:41 function parameter 'attach' not described in 'virtio_dma_buf_attach' The function documentation was missing descriptions for both the 'dma_buf' and 'attach' parameters. Add proper parameter documentation following kernel-doc format. Signed-off-by: WangYuli <wangyuli@uniontech.com>
Add comprehensive detection and automatic fixing capability for full-width (Unicode) characters that are commonly mistaken for ASCII punctuation marks. This helps catch input method editor artifacts that can cause compilation errors or formatting issues. The implementation detects 25 types of full-width characters: - Basic punctuation: ；，。（）！？： - Programming brackets: ［］｛｝＜＞ - Assignment and comparison: ＝ - Arithmetic operators: ＋－＊／＼ - Other programming symbols: ％＃＆｜ Detection covers three areas: 1. Code lines (lines starting with '+') - FULLWIDTH_CHARS 2. Commit messages - FULLWIDTH_CHARS_COMMIT 3. Subject lines - FULLWIDTH_CHARS_SUBJECT Example usage: ./scripts/checkpatch.pl my_patch.patch ./scripts/checkpatch.pl --fix my_patch.patch ./scripts/checkpatch.pl --fix-inplace my_source.c Signed-off-by: WangYuli <wangyuli@uniontech.com>
Avenger-285714
pushed a commit
that referenced
this pull request
Sep 19, 2025
…ux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 changes for 6.17, round #3 - Invalidate nested MMUs upon freeing the PGD to avoid WARNs when visiting from an MMU notifier - Fixes to the TLB match process and TLB invalidation range for managing the VCNR pseudo-TLB - Prevent SPE from erroneously profiling guests due to UNKNOWN reset values in PMSCR_EL1 - Fix save/restore of host MDCR_EL2 to account for eagerly programming at vcpu_load() on VHE systems - Correct lock ordering when dealing with VGIC LPIs, avoiding scenarios where an xarray's spinlock was nested with a *raw* spinlock - Permit stage-2 read permission aborts which are possible in the case of NV depending on the guest hypervisor's stage-2 translation - Call raw_spin_unlock() instead of the internal spinlock API - Fix parameter ordering when assigning VBAR_EL1
Avenger-285714
force-pushed
the
master
branch
2 times, most recently
from
5a20434 to
673504c
Compare
Avenger-285714
force-pushed
the
master
branch
from
c88e7e7 to
4b335e0
Compare
Avenger-285714
pushed a commit
that referenced
this pull request
Oct 24, 2025
Since blamed commit, unregister_netdevice_many_notify() takes the netdev
mutex if the device needs it.
If the device list is too long, this will lock more device mutexes than
lockdep can handle:
unshare -n \
bash -c 'for i in $(seq 1 100);do ip link add foo$i type dummy;done'
BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
depth: 48 max: 48!
48 locks held by kworker/u16:1/69:
#0: ..148 ((wq_completion)netns){+.+.}-{0:0}, at: process_one_work
#1: ..d40 (net_cleanup_work){+.+.}-{0:0}, at: process_one_work
#2: ..bd0 (pernet_ops_rwsem){++++}-{4:4}, at: cleanup_net
#3: ..aa8 (rtnl_mutex){+.+.}-{4:4}, at: default_device_exit_batch
#4: ..cb0 (&dev_instance_lock_key#3){+.+.}-{4:4}, at: unregister_netdevice_many_notify
[..]
Add a helper to close and then unlock a list of net_devices.
Devices that are not up have to be skipped - netif_close_many always
removes them from the list without any other actions taken, so they'd
remain in locked state.
Close devices whenever we've used up half of the tracking slots or we
processed entire list without hitting the limit.
Fixes: 7e4d784 ("net: hold netdev instance lock during rtnetlink operations")
Signed-off-by: Florian Westphal <fw@strlen.de>
Link: https://patch.msgid.link/20251013185052.14021-1-fw@strlen.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Avenger-285714
pushed a commit
that referenced
this pull request
Oct 24, 2025
Expand the prefault memory selftest to add a regression test for a KVM bug where KVM's retry logic would result in (breakable) deadlock due to the memslot deletion waiting on prefaulting to release SRCU, and prefaulting waiting on the memslot to fully disappear (KVM uses a two-step process to delete memslots, and KVM x86 retries page faults if a to-be-deleted, a.k.a. INVALID, memslot is encountered). To exercise concurrent memslot remove, spawn a second thread to initiate memslot removal at roughly the same time as prefaulting. Test memslot removal for all testcases, i.e. don't limit concurrent removal to only the success case. There are essentially three prefault scenarios (so far) that are of interest: 1. Success 2. ENOENT due to no memslot 3. EAGAIN due to INVALID memslot For all intents and purposes, #1 and #2 are mutually exclusive, or rather, easier to test via separate testcases since writing to non-existent memory is trivial. But for #3, making it mutually exclusive with #1 _or_ #2 is actually more complex than testing memslot removal for all scenarios. The only requirement to let memslot removal coexist with other scenarios is a way to guarantee a stable result, e.g. that the "no memslot" test observes ENOENT, not EAGAIN, for the final checks. So, rather than make memslot removal mutually exclusive with the ENOENT scenario, simply restore the memslot and retry prefaulting. For the "no memslot" case, KVM_PRE_FAULT_MEMORY should be idempotent, i.e. should always fail with ENOENT regardless of how many times userspace attempts prefaulting. Pass in both the base GPA and the offset (instead of the "full" GPA) so that the worker can recreate the memslot. Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/r/20250924174255.2141847-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Avenger-285714
force-pushed
the
master
branch
from
4b335e0 to
c533b12
Compare
Avenger-285714
pushed a commit
that referenced
this pull request
Oct 27, 2025
The original code causes a circular locking dependency found by lockdep. ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S U ------------------------------------------------------ xe_fault_inject/5091 is trying to acquire lock: ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660 but task is already holding lock: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&devcd->mutex){+.+.}-{3:3}: mutex_lock_nested+0x4e/0xc0 devcd_data_write+0x27/0x90 sysfs_kf_bin_write+0x80/0xf0 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (kn->active#236){++++}-{0:0}: kernfs_drain+0x1e2/0x200 __kernfs_remove+0xae/0x400 kernfs_remove_by_name_ns+0x5d/0xc0 remove_files+0x54/0x70 sysfs_remove_group+0x3d/0xa0 sysfs_remove_groups+0x2e/0x60 device_remove_attrs+0xc7/0x100 device_del+0x15d/0x3b0 devcd_del+0x19/0x30 process_one_work+0x22b/0x6f0 worker_thread+0x1e8/0x3d0 kthread+0x11c/0x250 ret_from_fork+0x26c/0x2e0 ret_from_fork_asm+0x1a/0x30 -> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}: __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 __flush_work+0x27a/0x660 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&devcd->mutex); lock(kn->active#236); lock(&devcd->mutex); lock((work_completion)(&(&devcd->del_wk)->work)); *** DEADLOCK *** 5 locks held by xe_fault_inject/5091: #0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0 #1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220 #2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280 #3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 #4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660 stack backtrace: CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S U 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)} Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021 Call Trace: <TASK> dump_stack_lvl+0x91/0xf0 dump_stack+0x10/0x20 print_circular_bug+0x285/0x360 check_noncircular+0x135/0x150 ? register_lock_class+0x48/0x4a0 __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 ? __flush_work+0x25d/0x660 ? mark_held_locks+0x46/0x90 ? __flush_work+0x25d/0x660 __flush_work+0x27a/0x660 ? __flush_work+0x25d/0x660 ? trace_hardirqs_on+0x1e/0xd0 ? __pfx_wq_barrier_func+0x10/0x10 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 ? bus_find_device+0xa8/0xe0 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 ? __f_unlock_pos+0x15/0x20 ? __x64_sys_getdents64+0x9b/0x130 ? __pfx_filldir64+0x10/0x10 ? do_syscall_64+0x1a2/0xb60 ? clear_bhb_loop+0x30/0x80 ? clear_bhb_loop+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x76e292edd574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574 RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063 R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000 </TASK> xe 0000:03:00.0: [drm] Xe device coredump has been deleted. Fixes: 01daccf ("devcoredump : Serialize devcd_del work") Cc: Mukesh Ojha <quic_mojha@quicinc.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Danilo Krummrich <dakr@kernel.org> Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v6.1+ Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Cc: Matthew Brost <matthew.brost@intel.com> Acked-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Avenger-285714
force-pushed
the
master
branch
2 times, most recently
from
91aa831 to
e486cb3
Compare
Avenger-285714
pushed a commit
that referenced
this pull request
Nov 12, 2025
Michael Chan says: ==================== bnxt_en: Bug fixes Patches 1, 3, and 4 are bug fixes related to the FW log tracing driver coredump feature recently added in 6.13. Patch #1 adds the necessary call to shutdown the FW logging DMA during PCI shutdown. Patch #3 fixes a possible null pointer derefernce when using early versions of the FW with this feature. Patch #4 adds the coredump header information unconditionally to make it more robust. Patch #2 fixes a possible memory leak during PTP shutdown. Patch #5 eliminates a dmesg warning when doing devlink reload. ==================== Link: https://patch.msgid.link/20251104005700.542174-1-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Avenger-285714
pushed a commit
that referenced
this pull request
Nov 12, 2025
On completion of i915_vma_pin_ww(), a synchronous variant of dma_fence_work_commit() is called. When pinning a VMA to GGTT address space on a Cherry View family processor, or on a Broxton generation SoC with VTD enabled, i.e., when stop_machine() is then called from intel_ggtt_bind_vma(), that can potentially lead to lock inversion among reservation_ww and cpu_hotplug locks. [86.861179] ====================================================== [86.861193] WARNING: possible circular locking dependency detected [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U [86.861226] ------------------------------------------------------ [86.861238] i915_module_loa/1432 is trying to acquire lock: [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50 [86.861290] but task is already holding lock: [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] which lock already depends on the new lock. [86.862251] the existing dependency chain (in reverse order) is: [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0}: [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f0 [86.862454] kernel_init_freeable+0x3cd/0x680 [86.862470] kernel_init+0x1b/0x200 [86.862482] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm+0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [86.862635] iterate_dir+0xcf/0x2b0 [86.862648] __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){++++}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908] kernel_init+0x1b/0x200 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969] __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320 [86.863012] __cpuhp_setup_state+0xb0/0x220 [86.863026] page_alloc_init_cpuhp+0x2d/0x60 [86.863041] mm_core_init+0x22/0x2d0 [86.863054] start_kernel+0x576/0xbd0 [86.863068] x86_64_start_reservations+0x18/0x30 [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [86.863135] __lock_acquire+0x1635/0x2810 [86.863152] lock_acquire+0xc4/0x2f0 [86.863166] cpus_read_lock+0x41/0x100 [86.863180] stop_machine+0x1c/0x50 [86.863194] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.863987] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.864735] __vma_bind+0x55/0x70 [i915] [86.865510] fence_work+0x26/0xa0 [i915] [86.866248] fence_notify+0xa1/0x140 [i915] [86.866983] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.867719] i915_sw_fence_commit+0x39/0x60 [i915] [86.868453] i915_vma_pin_ww+0x462/0x1360 [i915] [86.869228] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.870001] initial_plane_vma+0x307/0x840 [i915] [86.870774] intel_initial_plane_config+0x33f/0x670 [i915] [86.871546] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.872330] i915_driver_probe+0x7fa/0xe80 [i915] [86.873057] i915_pci_probe+0xe6/0x220 [i915] [86.873782] local_pci_probe+0x47/0xb0 [86.873802] pci_device_probe+0xf3/0x260 [86.873817] really_probe+0xf1/0x3c0 [86.873833] __driver_probe_device+0x8c/0x180 [86.873848] driver_probe_device+0x24/0xd0 [86.873862] __driver_attach+0x10f/0x220 [86.873876] bus_for_each_dev+0x7f/0xe0 [86.873892] driver_attach+0x1e/0x30 [86.873904] bus_add_driver+0x151/0x290 [86.873917] driver_register+0x5e/0x130 [86.873931] __pci_register_driver+0x7d/0x90 [86.873945] i915_pci_register_driver+0x23/0x30 [i915] [86.874678] i915_init+0x37/0x120 [i915] [86.875347] do_one_initcall+0x60/0x3f0 [86.875369] do_init_module+0x97/0x2a0 [86.875385] load_module+0x2c54/0x2d80 [86.875398] init_module_from_file+0x96/0xe0 [86.875413] idempotent_init_module+0x117/0x330 [86.875426] __x64_sys_finit_module+0x77/0x100 [86.875440] x64_sys_call+0x24de/0x2660 [86.875454] do_syscall_64+0x91/0xe90 [86.875470] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.875486] other info that might help us debug this: [86.875502] Chain exists of: cpu_hotplug_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [86.875539] Possible unsafe locking scenario: [86.875552] CPU0 CPU1 [86.875563] ---- ---- [86.875573] lock(reservation_ww_class_mutex); [86.875588] lock(reservation_ww_class_acquire); [86.875606] lock(reservation_ww_class_mutex); [86.875624] rlock(cpu_hotplug_lock); [86.875637] *** DEADLOCK *** [86.875650] 3 locks held by i915_module_loa/1432: [86.875663] #0: ffff888101f5c1b0 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x104/0x220 [86.875699] #1: ffffc90002e0b4a0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.876512] #2: ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.877305] stack backtrace: [86.877326] CPU: 0 UID: 0 PID: 1432 Comm: i915_module_loa Tainted: G U 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 PREEMPT(voluntary) [86.877334] Tainted: [U]=USER [86.877336] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0079.2020.0420.1316 04/20/2020 [86.877339] Call Trace: [86.877344] <TASK> [86.877353] dump_stack_lvl+0x91/0xf0 [86.877364] dump_stack+0x10/0x20 [86.877369] print_circular_bug+0x285/0x360 [86.877379] check_noncircular+0x135/0x150 [86.877390] __lock_acquire+0x1635/0x2810 [86.877403] lock_acquire+0xc4/0x2f0 [86.877408] ? stop_machine+0x1c/0x50 [86.877422] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878173] cpus_read_lock+0x41/0x100 [86.878182] ? stop_machine+0x1c/0x50 [86.878191] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878916] stop_machine+0x1c/0x50 [86.878927] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.879652] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.880375] __vma_bind+0x55/0x70 [i915] [86.881133] fence_work+0x26/0xa0 [i915] [86.881851] fence_notify+0xa1/0x140 [i915] [86.882566] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.883286] i915_sw_fence_commit+0x39/0x60 [i915] [86.884003] i915_vma_pin_ww+0x462/0x1360 [i915] [86.884756] ? i915_vma_pin.constprop.0+0x6c/0x1d0 [i915] [86.885513] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.886281] initial_plane_vma+0x307/0x840 [i915] [86.887049] intel_initial_plane_config+0x33f/0x670 [i915] [86.887819] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.888587] i915_driver_probe+0x7fa/0xe80 [i915] [86.889293] ? mutex_unlock+0x12/0x20 [86.889301] ? drm_privacy_screen_get+0x171/0x190 [86.889308] ? acpi_dev_found+0x66/0x80 [86.889321] i915_pci_probe+0xe6/0x220 [i915] [86.890038] local_pci_probe+0x47/0xb0 [86.890049] pci_device_probe+0xf3/0x260 [86.890058] really_probe+0xf1/0x3c0 [86.890067] __driver_probe_device+0x8c/0x180 [86.890072] driver_probe_device+0x24/0xd0 [86.890078] __driver_attach+0x10f/0x220 [86.890083] ? __pfx___driver_attach+0x10/0x10 [86.890088] bus_for_each_dev+0x7f/0xe0 [86.890097] driver_attach+0x1e/0x30 [86.890101] bus_add_driver+0x151/0x290 [86.890107] driver_register+0x5e/0x130 [86.890113] __pci_register_driver+0x7d/0x90 [86.890119] i915_pci_register_driver+0x23/0x30 [i915] [86.890833] i915_init+0x37/0x120 [i915] [86.891482] ? __pfx_i915_init+0x10/0x10 [i915] [86.892135] do_one_initcall+0x60/0x3f0 [86.892145] ? __kmalloc_cache_noprof+0x33f/0x470 [86.892157] do_init_module+0x97/0x2a0 [86.892164] load_module+0x2c54/0x2d80 [86.892168] ? __kernel_read+0x15c/0x300 [86.892185] ? kernel_read_file+0x2b1/0x320 [86.892195] init_module_from_file+0x96/0xe0 [86.892199] ? init_module_from_file+0x96/0xe0 [86.892211] idempotent_init_module+0x117/0x330 [86.892224] __x64_sys_finit_module+0x77/0x100 [86.892230] x64_sys_call+0x24de/0x2660 [86.892236] do_syscall_64+0x91/0xe90 [86.892243] ? irqentry_exit+0x77/0xb0 [86.892249] ? sysvec_apic_timer_interrupt+0x57/0xc0 [86.892256] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.892261] RIP: 0033:0x7303e1b2725d [86.892271] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8b bb 0d 00 f7 d8 64 89 01 48 [86.892276] RSP: 002b:00007ffddd1fdb38 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [86.892281] RAX: ffffffffffffffda RBX: 00005d771d88fd90 RCX: 00007303e1b2725d [86.892285] RDX: 0000000000000000 RSI: 00005d771d893aa0 RDI: 000000000000000c [86.892287] RBP: 00007ffddd1fdbf0 R08: 0000000000000040 R09: 00007ffddd1fdb80 [86.892289] R10: 00007303e1c03b20 R11: 0000000000000246 R12: 00005d771d893aa0 [86.892292] R13: 0000000000000000 R14: 00005d771d88f0d0 R15: 00005d771d895710 [86.892304] </TASK> Call asynchronous variant of dma_fence_work_commit() in that case. v3: Provide more verbose in-line comment (Andi), - mention target environments in commit message. Fixes: 7d1c261 ("drm/i915: Take reservation lock around i915_vma_pin.") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14985 Cc: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Acked-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20251023082925.351307-6-janusz.krzysztofik@linux.intel.com (cherry picked from commit 648ef13) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Avenger-285714
force-pushed
the
master
branch
from
e486cb3 to
73a8558
Compare
Avenger-285714
pushed a commit
that referenced
this pull request
Nov 12, 2025
Add VMX exit handlers for SEAMCALL and TDCALL to inject a #UD if a non-TD guest attempts to execute SEAMCALL or TDCALL. Neither SEAMCALL nor TDCALL is gated by any software enablement other than VMXON, and so will generate a VM-Exit instead of e.g. a native #UD when executed from the guest kernel. Note! No unprivileged DoS of the L1 kernel is possible as TDCALL and SEAMCALL #GP at CPL > 0, and the CPL check is performed prior to the VMX non-root (VM-Exit) check, i.e. userspace can't crash the VM. And for a nested guest, KVM forwards unknown exits to L1, i.e. an L2 kernel can crash itself, but not L1. Note #2! The Intel® Trust Domain CPU Architectural Extensions spec's pseudocode shows the CPL > 0 check for SEAMCALL coming _after_ the VM-Exit, but that appears to be a documentation bug (likely because the CPL > 0 check was incorrectly bundled with other lower-priority #GP checks). Testing on SPR and EMR shows that the CPL > 0 check is performed before the VMX non-root check, i.e. SEAMCALL #GPs when executed in usermode. Note #3! The aforementioned Trust Domain spec uses confusing pseudocode that says that SEAMCALL will #UD if executed "inSEAM", but "inSEAM" specifically means in SEAM Root Mode, i.e. in the TDX-Module. The long- form description explicitly states that SEAMCALL generates an exit when executed in "SEAM VMX non-root operation". But that's a moot point as the TDX-Module injects #UD if the guest attempts to execute SEAMCALL, as documented in the "Unconditionally Blocked Instructions" section of the TDX-Module base specification. Cc: stable@vger.kernel.org Cc: Kai Huang <kai.huang@intel.com> Cc: Xiaoyao Li <xiaoyao.li@intel.com> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20251016182148.69085-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Avenger-285714
force-pushed
the
master
branch
from
73a8558 to
7b4314b
Compare
Avenger-285714
pushed a commit
that referenced
this pull request
Nov 20, 2025
…/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 6.18, take #3 - Only adjust the ID registers when no irqchip has been created once per VM run, instead of doing it once per vcpu, as this otherwise triggers a pretty bad conbsistency check failure in the sysreg code. - Make sure the per-vcpu Fine Grain Traps are computed before we load the system registers on the HW, as we otherwise start running without anything set until the first preemption of the vcpu.
Avenger-285714
force-pushed
the
master
branch
2 times, most recently
from
ca05808 to
13a295f
Compare
Avenger-285714
force-pushed
the
master
branch
from
13a295f to
e392ae8
Compare
Avenger-285714
pushed a commit
that referenced
this pull request
Dec 1, 2025
For some reason, of_find_node_with_property() is creating a spinlock recursion issue along with fwnode_count_parents(), and this issue is making all MediaTek boards unbootable. As of kernel v6.18-rc6, there are only three users of this function, one of which is this driver. Migrate away from of_find_node_with_property() by adding a local scpsys_get_legacy_regmap_node() function, which acts similarly to of_find_node_with_property(), and calling the former in place of the latter. This resolves the following spinlock recursion issue: [ 1.773979] BUG: spinlock recursion on CPU#2, kworker/u24:1/60 [ 1.790485] lock: devtree_lock+0x0/0x40, .magic: dead4ead, .owner: kworker/u24:1/60, .owner_cpu: 2 [ 1.791644] CPU: 2 UID: 0 PID: 60 Comm: kworker/u24:1 Tainted: G W 6.18.0-rc6 #3 PREEMPT [ 1.791649] Tainted: [W]=WARN [ 1.791650] Hardware name: MediaTek Genio-510 EVK (DT) [ 1.791653] Workqueue: events_unbound deferred_probe_work_func [ 1.791658] Call trace: [ 1.791659] show_stack+0x18/0x30 (C) [ 1.791664] dump_stack_lvl+0x68/0x94 [ 1.791668] dump_stack+0x18/0x24 [ 1.791672] spin_dump+0x78/0x88 [ 1.791678] do_raw_spin_lock+0x110/0x140 [ 1.791684] _raw_spin_lock_irqsave+0x58/0x6c [ 1.791690] of_get_parent+0x28/0x74 [ 1.791694] of_fwnode_get_parent+0x38/0x7c [ 1.791700] fwnode_count_parents+0x34/0xf0 [ 1.791705] fwnode_full_name_string+0x28/0x120 [ 1.791710] device_node_string+0x3e4/0x50c [ 1.791715] pointer+0x294/0x430 [ 1.791718] vsnprintf+0x21c/0x5bc [ 1.791722] vprintk_store+0x108/0x47c [ 1.791728] vprintk_emit+0xc4/0x350 [ 1.791732] vprintk_default+0x34/0x40 [ 1.791736] vprintk+0x24/0x30 [ 1.791740] _printk+0x60/0x8c [ 1.791744] of_node_release+0x154/0x194 [ 1.791749] kobject_put+0xa0/0x120 [ 1.791753] of_node_put+0x18/0x28 [ 1.791756] of_find_node_with_property+0x74/0x100 [ 1.791761] scpsys_probe+0x338/0x5e0 [ 1.791765] platform_probe+0x5c/0xa4 [ 1.791770] really_probe+0xbc/0x2ac [ 1.791774] __driver_probe_device+0x78/0x118 [ 1.791779] driver_probe_device+0x3c/0x170 [ 1.791783] __device_attach_driver+0xb8/0x150 [ 1.791788] bus_for_each_drv+0x88/0xe8 [ 1.791792] __device_attach+0x9c/0x1a0 [ 1.791796] device_initial_probe+0x14/0x20 [ 1.791801] bus_probe_device+0xa0/0xa4 [ 1.791805] deferred_probe_work_func+0x88/0xd0 [ 1.791809] process_one_work+0x1e8/0x448 [ 1.791813] worker_thread+0x1ac/0x340 [ 1.791816] kthread+0x138/0x220 [ 1.791821] ret_from_fork+0x10/0x20 Fixes: c29345f ("pmdomain: mediatek: Refactor bus protection regmaps retrieval") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Tested-by: Macpaul Lin <macpaul.lin@mediatek.com> Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Avenger-285714
pushed a commit
that referenced
this pull request
Dec 1, 2025
The U-Blox EVK-M101 enumerates as 1546:0506 [1] with four FTDI interfaces: - EVK-M101 current sensors - EVK-M101 I2C - EVK-M101 UART - EVK-M101 port D Only the third USB interface is a UART. This change lets ftdi_sio probe the VID/PID and registers only interface #3 as a TTY, leaving the rest available for other drivers. [1] usb 5-1.3: new high-speed USB device number 11 using xhci_hcd usb 5-1.3: New USB device found, idVendor=1546, idProduct=0506, bcdDevice= 8.00 usb 5-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 5-1.3: Product: EVK-M101 usb 5-1.3: Manufacturer: u-blox AG Datasheet: https://content.u-blox.com/sites/default/files/documents/EVK-M10_UserGuide_UBX-21003949.pdf Signed-off-by: Oleksandr Suvorov <cryosay@gmail.com> Link: https://lore.kernel.org/20250926060235.3442748-1-cryosay@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
Avenger-285714
force-pushed
the
master
branch
8 times, most recently
from
b44219d to
483ad00
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updates the requirements on jinja2 to permit the latest version.
Updates
jinja2to 3.1.6Release notes
Sourced from jinja2's releases.
Changelog
Sourced from jinja2's changelog.
... (truncated)
Commits
1520688release version 3.1.690457bbMerge commit from fork065334dattr filter uses env.getattr033c200start version 3.1.6bc68d4euse global contributing guide (#2070)247de5euse global contributing guideab8218cuse project advisory link instead of globalb4ffc8frelease version 3.1.5 (#2066)877f6e5release version 3.1.58d58859remove test pypiDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditionsYou can disable automated security fix PRs for this repo from the Security Alerts page.