* Re: [PATCH v2 1/2] cgroup/cpuset: Avoid unnecessary cpus & mems update in cpuset_hotplug_update_tasks()
From: Manuel Ebner @ 2026-06-24 8:40 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Ridong Chen, Jonathan Corbet, Shuah Khan
Cc: cgroups, linux-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260623230413.1984188-2-longman@redhat.com>
On Tue, 2026-06-23 at 19:04 -0400, Waiman Long wrote:
> As reported by sashiko [1], cpuset_hotplug_update_tasks() may perform
> unnecessary task iteration and updating of tasks' CPU and node masks
> when mems_allowed and/or cpus_allowed are not set in cpuset v2. It is
> due to the fact that the temporary new_cpus and new_mems masks do not
> inherit parent's effective_cpus/mems when they are empty which is the
> expected behavior for cpuset v2 since commit 4ec22e9c5a90 ("cpuset:
> Enable cpuset controller in default hierarchy").
>
> Fix that and avoid unnecessay work by enhancing
> compute_effective_cpumask() to add the empty cpumask check
> and inheriting the parent's versions if empty when in v2. A new
> compute_effective_nodemask() helper is also added to perform similar
> function for new effective_mems.
perform a similar function
or
perform similar functions
> [...]
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index aff86acea701..044ddbf66f8e 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -1094,12 +1094,35 @@ void cpuset_update_tasks_cpumask(struct cpuset *cs, struct
> cpumask *new_cpus)
> * @cs: the cpuset the need to recompute the new effective_cpus mask
> * @parent: the parent cpuset
> *
> + * For v2, the parent's effective_cpus is inherited if cpumask empty.
+ * For v2, the parent's effective_cpus is inherited if cpumask is empty.
Thanks
Manuel
^ permalink raw reply
* [PATCH bpf 2/2] selftests/bpf: Cover fastcall helper stack reads
From: Nuoqi Gui @ 2026-06-24 8:39 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi
Cc: John Fastabend, Martin KaFai Lau, Shuah Khan, bpf,
linux-kselftest, linux-kernel, Nuoqi Gui
In-Reply-To: <20260624-f01-12-fastcall-helper-stack-read-v1-0-e0a86085ef77@mails.tsinghua.edu.cn>
Add verifier_bpf_fastcall test where a spill/fill pair initializes a stack
slot. bpf_csum_diff() later reads it through ARG_PTR_TO_MEM | MEM_RDONLY.
The translated program must keep the spill and fill materialized. Otherwise
the helper reads stack bytes that no longer match the verifier model.
Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
---
.../selftests/bpf/progs/verifier_bpf_fastcall.c | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/tools/testing/selftests/bpf/progs/verifier_bpf_fastcall.c b/tools/testing/selftests/bpf/progs/verifier_bpf_fastcall.c
index fb4fa465d67c6..aab92e69673d2 100644
--- a/tools/testing/selftests/bpf/progs/verifier_bpf_fastcall.c
+++ b/tools/testing/selftests/bpf/progs/verifier_bpf_fastcall.c
@@ -500,6 +500,38 @@ __naked void bad_helper_write(void)
: __clobber_all);
}
+SEC("tc")
+__arch_x86_64
+__xlated("1: *(u64 *)(r10 -8) = r1")
+__xlated("...")
+__xlated("3: r0 = &(void __percpu *)(r0)")
+__xlated("...")
+__xlated("5: r1 = *(u64 *)(r10 -8)")
+__success
+__naked void bad_helper_read(void)
+{
+ asm volatile (
+ "r1 = 1;"
+ /* bpf_fastcall pattern with stack offset -8 */
+ "*(u64 *)(r10 - 8) = r1;"
+ "call %[bpf_get_smp_processor_id];"
+ "r1 = *(u64 *)(r10 - 8);"
+ /* bpf_csum_diff() reads fp[-8], so keep the spill materialized */
+ "r1 = r10;"
+ "r1 += -8;"
+ "r2 = 8;"
+ "r3 = 0;"
+ "r4 = 0;"
+ "r5 = 0;"
+ "call %[bpf_csum_diff];"
+ "r0 = 0;"
+ "exit;"
+ :
+ : __imm(bpf_get_smp_processor_id),
+ __imm(bpf_csum_diff)
+ : __clobber_all);
+}
+
SEC("raw_tp")
__arch_x86_64
/* main, not patched */
--
2.34.1
^ permalink raw reply related
* [PATCH bpf 0/2] bpf: Keep fastcall stack slots for helper stack reads
From: Nuoqi Gui @ 2026-06-24 8:39 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi
Cc: John Fastabend, Martin KaFai Lau, Shuah Khan, bpf,
linux-kselftest, linux-kernel, Nuoqi Gui
Fastcall spill/fill elision is guarded by a stack contract: stack slots in
the pattern may only be accessed by the pattern itself. Direct stack loads
and stores enforce that contract, but helper and kfunc memory arguments can
read from PTR_TO_STACK through check_stack_range_initialized() without
disabling the post-verification elision.
Make helper/kfunc stack memory checks enforce the fastcall contract after
resolving the range. Add a verifier selftest for a read-only helper access
through bpf_csum_diff().
Fixes: 5b5f51bff1b66 ("bpf: no_caller_saved_registers attribute for helper calls")
Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
---
Nuoqi Gui (2):
bpf: Keep fastcall spills for helper stack reads
selftests/bpf: Cover fastcall helper stack reads
kernel/bpf/verifier.c | 4 +++
.../selftests/bpf/progs/verifier_bpf_fastcall.c | 32 ++++++++++++++++++++++
2 files changed, 36 insertions(+)
---
base-commit: 76f62d237538b456354a44e796a541cde03c6e28
change-id: 20260624-f01-12-fastcall-helper-stack-read-6d4dc1ffb513
Best regards,
--
Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
^ permalink raw reply
* [PATCH bpf 1/2] bpf: Keep fastcall spills for helper stack reads
From: Nuoqi Gui @ 2026-06-24 8:39 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi
Cc: John Fastabend, Martin KaFai Lau, Shuah Khan, bpf,
linux-kselftest, linux-kernel, Nuoqi Gui
In-Reply-To: <20260624-f01-12-fastcall-helper-stack-read-v1-0-e0a86085ef77@mails.tsinghua.edu.cn>
The fastcall spill/fill rewrite is only sound while the stack slots used by
the pattern are not accessed outside the pattern. Direct stack loads and
stores already call check_fastcall_stack_contract() to enforce this.
Helper and kfunc memory-argument checks can validate PTR_TO_STACK reads
through check_stack_range_initialized() without applying the same contract.
When such a read overlaps a fastcall spill slot,
bpf_remove_fastcall_spills_fills() can still remove the spill/fill pair.
It can then shrink the subprogram stack depth even though a helper or kfunc
reads that stack address.
Apply check_fastcall_stack_contract() from check_stack_range_initialized()
after the concrete stack range is known. Zero-sized accesses do not read or
write memory, so leave the fastcall optimization unchanged for those.
Fixes: 5b5f51bff1b66 ("bpf: no_caller_saved_registers attribute for helper calls")
Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
---
kernel/bpf/verifier.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index ff9b1f68ceca4..d77332eeab359 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -6873,6 +6873,10 @@ static int check_stack_range_initialized(
max_off = reg->smax_value + off;
}
+ if (access_size)
+ check_fastcall_stack_contract(env, state, env->insn_idx,
+ min_off);
+
if (meta && meta->raw_mode) {
/* Ensure we won't be overwriting dynptrs when simulating byte
* by byte access in check_helper_call using meta.access_size.
--
2.34.1
^ permalink raw reply related
* [PATCH] platform/chrome: cros_ec_typec: reject out-of-bounds PD cap count
From: Maoyi Xie @ 2026-06-24 8:39 UTC (permalink / raw)
To: Benson Leung, Tzung-Bi Shih
Cc: Abhishek Pandit-Subedi, Jameson Thies, Andrei Kuchynski,
Guenter Roeck, Kaixuan Li, chrome-platform, linux-kernel
cros_typec_register_partner_pdos() copies the partner PDOs from the EC
TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array.
memcpy(caps_desc.pdo, resp->source_cap_pdos,
sizeof(u32) * resp->source_cap_count);
...
memcpy(caps_desc.pdo, resp->sink_cap_pdos,
sizeof(u32) * resp->sink_cap_count);
PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields
from the EC, and the only check is that they are not both zero. If either
is larger than 7, the memcpy writes past the end of the array on the stack.
A count of 255 overflows it by about 1 KB.
The ChromeOS EC firmware caps these counts today, so a compliant setup
does not hit this. The kernel should still validate the values from the EC
rather than trust them.
Validate the counts in cros_typec_handle_status() right after the
EC_CMD_TYPEC_STATUS command returns, and return early if either one is
above PDO_MAX_OBJECTS.
Fixes: 348a2e8c93d3 ("platform/chrome: cros_ec_typec: Register partner PDOs")
Suggested-by: Tzung-Bi Shih <tzungbi@kernel.org>
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
drivers/platform/chrome/cros_ec_typec.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
index c0806c562bb9..3ae9b35b7d85 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -1158,6 +1158,12 @@ static void cros_typec_handle_status(struct cros_typec_data *typec, int port_num
return;
}
+ if (resp.source_cap_count > PDO_MAX_OBJECTS ||
+ resp.sink_cap_count > PDO_MAX_OBJECTS) {
+ dev_warn(typec->dev, "Invalid PDO count from EC, port: %d\n", port_num);
+ return;
+ }
+
/* If we got a hard reset, unregister everything and return. */
if (resp.events & PD_STATUS_EVENT_HARD_RESET) {
cros_typec_remove_partner(typec, port_num);
^ permalink raw reply related
* RE: [PATCH v4 7/7] test/bpf: check that bpf_convert can be JIT'd
From: Marat Khalili @ 2026-06-24 8:39 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org; +Cc: Konstantin Ananyev
In-Reply-To: <20260623232522.257208-8-stephen@networkplumber.org>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Wednesday 24 June 2026 00:23
> To: dev@dpdk.org
> Cc: Stephen Hemminger <stephen@networkplumber.org>; Konstantin Ananyev <konstantin.ananyev@huawei.com>;
> Marat Khalili <marat.khalili@huawei.com>
> Subject: [PATCH v4 7/7] test/bpf: check that bpf_convert can be JIT'd
>
> Run each converted filter through both the interpreter and the JIT and
> check they agree, catching JIT miscompiles.
>
> test_bpf_filter and test_bpf_match did nearly the same thing: compile,
> load and run a filter against the dummy packet. Combine them into
> test_bpf_match, which now builds the packet itself and returns whether
> the filter matched. Callers run it for both load methods.
>
> The dummy packet is a UDP packet to a fixed destination MAC, source
> and destination ports, so the filter results are deterministic. None
> of the sample filters should match it, so assert that; a convert or
> JIT bug that flips a result is then caught. The destination MAC and
> source port are chosen so the negative ethernet and port filters do
> not match, and "port not 53 and not arp" is dropped as it matches
> any non-ARP packet that lacks port 53.
>
> Reduce log output to make it easier to match which expression might be
> causing issues.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Marat Khalili <marat.khalili@huawei.com>
^ permalink raw reply
* [PATCH] ptest-packagelists.inc: disable glib-2.0 for RISCV64
From: João Marcos Costa @ 2026-06-24 8:38 UTC (permalink / raw)
To: openembedded-core
Cc: thomas.petazzoni, mathieu.dubois-briand, João Marcos Costa
Timeouts and other intermittent failures have been observed in the
autobuilder, and they are tracked in different entries at Bugzilla:
- https://bugzilla.yoctoproject.org/show_bug.cgi?id=15891
- https://bugzilla.yoctoproject.org/show_bug.cgi?id=16230
They also happen when musl is enabled, but not only.
Signed-off-by: João Marcos Costa <joaomarcos.costa@bootlin.com>
---
meta/conf/distro/include/ptest-packagelists.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/conf/distro/include/ptest-packagelists.inc b/meta/conf/distro/include/ptest-packagelists.inc
index f0950bcc99..de64a80ec3 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -157,8 +157,8 @@ PTESTS_PROBLEMS:append:riscv32 = " lttng-tools strace"
PTESTS_SLOW:append:libc-musl = " libc-test"
# These tests don't yet pass for riscv64
-PTESTS_SLOW:remove:riscv64 = "tcl tcl8 python3-cffi strace lttng-tools python3-numpy perl"
-PTESTS_PROBLEMS:append:riscv64 = " tcl tcl8 python3-cffi strace lttng-tools python3-numpy perl"
+PTESTS_SLOW:remove:riscv64 = "tcl tcl8 python3-cffi strace lttng-tools python3-numpy perl glib-2.0"
+PTESTS_PROBLEMS:append:riscv64 = " tcl tcl8 python3-cffi strace lttng-tools python3-numpy perl glib-2.0"
# These tests don't yet pass for musl qemuarm64
PTESTS_SLOW:remove:libc-musl:qemuarm64 = "strace perl gnutls glib-2.0"
--
2.47.0
^ permalink raw reply related
* Re: [PATCH] RDMA/core: Fix memory leak in __ib_create_cq() on invalid cqe
From: Kalesh Anakkur Purayil @ 2026-06-24 8:38 UTC (permalink / raw)
To: Chenguang Zhao
Cc: jgg, leon, edwards, mbloch, michaelgur, msanalla, ohartoov, jiri,
linux-rdma
In-Reply-To: <20260624025949.306783-1-zhaochenguang@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
On Wed, Jun 24, 2026 at 8:30 AM Chenguang Zhao <zhaochenguang@kylinos.cn> wrote:
>
> Free the allocated CQ object when cqe is zero before returning
> -EINVAL.
>
> Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
> ---
> drivers/infiniband/core/verbs.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
> index 3b613b57e269..d6b2eb820061 100644
> --- a/drivers/infiniband/core/verbs.c
> +++ b/drivers/infiniband/core/verbs.c
> @@ -2200,8 +2200,10 @@ struct ib_cq *__ib_create_cq(struct ib_device *device,
> if (!cq)
> return ERR_PTR(-ENOMEM);
>
> - if (WARN_ON_ONCE(!cq_attr->cqe))
> + if (WARN_ON_ONCE(!cq_attr->cqe)) {
> + kfree(cq);
> return ERR_PTR(-EINVAL);
> + }
[Kalesh] I think you can move this check to the beginning of the function.
Also, please add a Fixes tag.
>
> cq->device = device;
> cq->comp_handler = comp_handler;
> --
> 2.25.1
>
>
--
Regards,
Kalesh AP
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5509 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] virtio-gpu-virgl: replace fprintf(stderr) with qemu_log_mask and trace events
From: Akihiko Odaki @ 2026-06-24 8:38 UTC (permalink / raw)
To: Bin Guo, alex.bennee; +Cc: mst, dmitry.osipenko, qemu-devel
In-Reply-To: <c6641369b55274965251a16bb420f9744445cfa2.1782270919.git.guobin@linux.alibaba.com>
On 2026/06/24 14:55, Bin Guo wrote:
> Three places in virtio-gpu-virgl.c used fprintf(stderr) directly,
> bypassing QEMU's logging and tracing infrastructure:
>
> 1. Command error reporting in virgl_cmd_process() — replace with
> qemu_log_mask(LOG_GUEST_ERROR, ...) so the message is filtered
> via -d guest_errors, consistent with virtio-gpu.c.
>
> 2. Statistics output in virtio_gpu_print_stats() — replace with
> trace_virtio_gpu_virgl_stats() so the data is captured by the
> tracing subsystem instead of unconditionally hitting stderr.
Requiring both stats=on and the -trace option is inconvenient. Using
trace_event_get_state() instead of keeping the stats property may be a
good idea.
Regards,
Akihiko Odaki
>
> 3. Idle statistics message — replace with
> trace_virtio_gpu_virgl_stats_idle() to preserve the existing
> "idle" indication without stderr pollution.
>
> Add the two new trace events to hw/display/trace-events.
>
> Signed-off-by: Bin Guo <guobin@linux.alibaba.com>
> ---
> hw/display/trace-events | 2 ++
> hw/display/virtio-gpu-virgl.c | 15 +++++++--------
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/hw/display/trace-events b/hw/display/trace-events
> index 4bfc457fba..cf1e852b45 100644
> --- a/hw/display/trace-events
> +++ b/hw/display/trace-events
> @@ -58,6 +58,8 @@ virtio_gpu_fence_resp(uint64_t fence) "fence 0x%" PRIx64
> virtio_gpu_inc_inflight_fences(uint32_t inflight) "in-flight+ %u"
> virtio_gpu_dec_inflight_fences(uint32_t inflight) "in-flight- %u"
> virtio_gpu_cmd_suspended(uint32_t cmd) "cmd 0x%x"
> +virtio_gpu_virgl_stats(int requests, int max_inflight, int req_3d, int bytes_3d) "stats: vq req %d, max_inflight %d -- 3D %d (%d bytes)"
> +virtio_gpu_virgl_stats_idle(void) "stats: idle"
>
> # qxl.c
> disable qxl_io_write_vga(int qid, const char *mode, uint32_t addr, uint32_t val) "%d %s addr=%u val=%u"
> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> index b992ffc44e..afb0d0984a 100644
> --- a/hw/display/virtio-gpu-virgl.c
> +++ b/hw/display/virtio-gpu-virgl.c
> @@ -1129,8 +1129,8 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
> return;
> }
> if (cmd->error) {
> - fprintf(stderr, "%s: ctrl 0x%x, error 0x%x\n", __func__,
> - cmd->cmd_hdr.type, cmd->error);
> + qemu_log_mask(LOG_GUEST_ERROR, "%s: ctrl 0x%x, error 0x%x\n",
> + __func__, cmd->cmd_hdr.type, cmd->error);
> virtio_gpu_ctrl_response_nodata(g, cmd, cmd->error);
> return;
> }
> @@ -1370,17 +1370,16 @@ static void virtio_gpu_print_stats(void *opaque)
> VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
>
> if (g->stats.requests) {
> - fprintf(stderr, "stats: vq req %4d, %3d -- 3D %4d (%5d)\n",
> - g->stats.requests,
> - g->stats.max_inflight,
> - g->stats.req_3d,
> - g->stats.bytes_3d);
> + trace_virtio_gpu_virgl_stats(g->stats.requests,
> + g->stats.max_inflight,
> + g->stats.req_3d,
> + g->stats.bytes_3d);
> g->stats.requests = 0;
> g->stats.max_inflight = 0;
> g->stats.req_3d = 0;
> g->stats.bytes_3d = 0;
> } else {
> - fprintf(stderr, "stats: idle\r");
> + trace_virtio_gpu_virgl_stats_idle();
> }
> timer_mod(gl->print_stats, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 1000);
> }
^ permalink raw reply
* Re: [PATCH 1/2] bug: Provide WARN_ON.*DEFERRED() macros for console deferred output
From: Breno Leitao @ 2026-06-24 8:37 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-arch, linux-kernel, sched-ext, netdev, David S . Miller,
Andrea Righi, Andrew Morton, Arnd Bergmann, Ben Segall,
Changwoo Min, David Vernet, Dietmar Eggemann, Eric Dumazet,
Ingo Molnar, Jakub Kicinski, John Ogness, Juri Lelli,
K Prateek Nayak, Paolo Abeni, Peter Zijlstra, Petr Mladek,
Sergey Senozhatsky, Simon Horman, Steven Rostedt, Tejun Heo,
Vincent Guittot, Vlad Poenaru
In-Reply-To: <20260623142650.265721-2-bigeasy@linutronix.de>
Hello Sebastian,
First of all thanks for working on it.
On Tue, Jun 23, 2026 at 04:26:49PM +0200, Sebastian Andrzej Siewior wrote:
> Provide a deferred version of the WARN_ON() macro. It will delay
> flushing the console until a later context. It is needed in a context
> where the caller holds locks which can lead to a deadlock content is
> flushed to the console driver.
> An example would from a warning from within the scheduler resulting in a
> wake-up of a task.
>
> Deferring the output works by using printk_deferred_enter/ exit() around
> the printing output. This must be used in a context where the task can't
> migrate to another CPU. This should be the case usually, since the
> scheduler would acquire the rq lock whith disabled interrupts, but to be
> safe preemption is disabled to guarantee this.
>
> In order not to bloat the code on architectures which provide an
> optimized __WARN_FLAGS() define BUGFLAG_DEFERRED which is handled by
> __report_bug() and does not increase the code size.
>
> Provide the DEFERRED macros based on __WARN_FLAGS and __WARN_FLAGS
> macros. Extend __report_bug() to handle the deferred case.
Have you considered an approach similar to printk_deferred_enter(),
where you mark the code region that needs deferral and all WARN() calls
within that region are automatically deferred?
The current proposal requires changing individual WARN() call sites,
but whether they need deferral might depend on the calling context. This
means you'd need to convert many call sites and ensure all nested
warnings are also converted to the deferred variant.
Thanks,
--breno
^ permalink raw reply
* [PATCH v1] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-24 8:37 UTC (permalink / raw)
To: Nicolas Frattaroli, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai
Cc: Heiko Stuebner, linux-rockchip, linux-sound, linux-arm-kernel,
linux-kernel
Currently that header is only included via:
<sound/dmaengine_pcm.h> ->
<sound/soc.h> ->
<linux/platform_device.h>
which doesn't look reliable, still more in the presence of the comment:
/* For the current users of sound/soc.h to avoid build issues */
in <sound/soc.h>.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
sound/soc/rockchip/rockchip_sai.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
index a195e96fed0a..37e81d56bc16 100644
--- a/sound/soc/rockchip/rockchip_sai.c
+++ b/sound/soc/rockchip/rockchip_sai.c
@@ -11,6 +11,7 @@
#include <linux/delay.h>
#include <linux/of_device.h>
#include <linux/clk.h>
+#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/regmap.h>
#include <linux/reset.h>
base-commit: ef0c9f75a19532d7675384708fc8621e10850104
--
2.47.3
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* [PATCH v1] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-24 8:37 UTC (permalink / raw)
To: Nicolas Frattaroli, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai
Cc: Heiko Stuebner, linux-rockchip, linux-sound, linux-arm-kernel,
linux-kernel
Currently that header is only included via:
<sound/dmaengine_pcm.h> ->
<sound/soc.h> ->
<linux/platform_device.h>
which doesn't look reliable, still more in the presence of the comment:
/* For the current users of sound/soc.h to avoid build issues */
in <sound/soc.h>.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
sound/soc/rockchip/rockchip_sai.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
index a195e96fed0a..37e81d56bc16 100644
--- a/sound/soc/rockchip/rockchip_sai.c
+++ b/sound/soc/rockchip/rockchip_sai.c
@@ -11,6 +11,7 @@
#include <linux/delay.h>
#include <linux/of_device.h>
#include <linux/clk.h>
+#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/regmap.h>
#include <linux/reset.h>
base-commit: ef0c9f75a19532d7675384708fc8621e10850104
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v10 23/31] dax/bus: Factor out dev dax resize logic
From: Anisa Su @ 2026-06-24 8:36 UTC (permalink / raw)
To: Anisa Su
Cc: linux-cxl, linux-kernel, nvdimm, Dan Williams, Jonathan Cameron,
Davidlohr Bueso, Dave Jiang, Vishal Verma, Ira Weiny,
Alison Schofield, John Groves, Gregory Price, Ira Weiny,
Jonathan Cameron
In-Reply-To: <29393afa419cdffdd5d299cdc323262f5c20c036.1779528761.git.anisa.su@samsung.com>
On Sat, May 23, 2026 at 02:43:17AM -0700, Anisa Su wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> Dynamic Capacity (DC) DAX regions back their dax devices with per-extent
> resource children of the region, rather than carving from a single
> contiguous dax_region->res. Allocating space for a DC dax device — on
> initial uuid claim of its backing extents and on shrink-to-0 during
> destroy — needs the same allocator the static case uses, but pointed at
> a different parent resource.
>
> Factor the body of dev_dax_resize() into __dev_dax_resize(parent, ...)
> and add a dev_dax_resize_static() wrapper that passes dax_region->res
> for static (non-DC) regions. alloc_dev_dax_range() gains the same
> parent parameter so it can operate under either kind of parent.
>
Stale commit message :( __dev_dax_resize is introduced in a subsequent
commit. Updated commit message to reflect actual state.
> No functional change.
>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
[snip]
> +
> +static ssize_t dev_dax_resize(struct dax_region *dax_region,
> + struct dev_dax *dev_dax, resource_size_t size)
> +{
> + resource_size_t avail = dax_region_avail_size(dax_region);
> + resource_size_t dev_size = dev_dax_size(dev_dax);
> + struct device *dev = &dev_dax->dev;
> + resource_size_t to_alloc;
> + resource_size_t alloc;
> +
> + if (dev->driver)
> + return -EBUSY;
> + if (size == dev_size)
> + return 0;
> + if (size > dev_size && size - dev_size > avail)
> + return -ENOSPC;
> + if (size < dev_size)
> + return dev_dax_shrink(dev_dax, size);
> +
> + to_alloc = size - dev_size;
> + if (dev_WARN_ONCE(dev, !alloc_is_aligned(dev_dax, to_alloc),
> + "resize of %pa misaligned\n", &to_alloc))
> + return -ENXIO;
> +
> +retry:
> + alloc = dev_dax_resize_static(&dax_region->res, dev_dax, to_alloc);
From Sashiko: https://sashiko.dev/#/patchset/cover.1779528761.git.anisa.su%40samsung.com?part=23
alloc is declared as unsigned resource_size_t. A negative errno isn't
returned correctly. Instead, the below line to_alloc -= alloc underflows
and the goto retry loops forever.
Fix: declare ssize_t alloc.
> + if (alloc <= 0)
> + return alloc;
> to_alloc -= alloc;
> if (to_alloc)
> goto retry;
> @@ -1367,7 +1396,8 @@ static ssize_t mapping_store(struct device *dev, struct device_attribute *attr,
>
> to_alloc = range_len(&r);
> if (alloc_is_aligned(dev_dax, to_alloc))
> - rc = alloc_dev_dax_range(dev_dax, r.start, to_alloc, NULL);
> + rc = alloc_dev_dax_range(&dax_region->res, dev_dax, r.start,
> + to_alloc, NULL);
> up_write(&dax_dev_rwsem);
> up_write(&dax_region_rwsem);
>
> @@ -1659,7 +1689,8 @@ static struct dev_dax *__devm_create_dev_dax(struct dev_dax_data *data)
> device_initialize(dev);
> dev_set_name(dev, "dax%d.%d", dax_region->id, dev_dax->id);
>
> - rc = alloc_dev_dax_range(dev_dax, dax_region->res.start, data->size, NULL);
> + rc = alloc_dev_dax_range(&dax_region->res, dev_dax, dax_region->res.start,
> + data->size, NULL);
> if (rc)
> goto err_range;
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 3/3] virtio-gpu: use unsigned shift for scanout bitmask operations
From: Akihiko Odaki @ 2026-06-24 8:34 UTC (permalink / raw)
To: Bin Guo, alex.bennee; +Cc: mst, dmitry.osipenko, qemu-devel
In-Reply-To: <22d21cfbe4466c27e33e979717957f48673d4647.1782270919.git.guobin@linux.alibaba.com>
On 2026/06/24 14:55, Bin Guo wrote:
> The scanout_bitmask field is uint32_t, but all six bit operations used
> the signed literal `1 << shift`. When the shift count reaches 31 this
> is undefined behavior (signed integer overflow). Replace every
> occurrence with `1U << shift` to perform an unsigned shift, which is
> well-defined for all bit positions 0-31.
I think we can make use of the BIT() macro.
Regards,
Akihiko Odaki
>
> No functional change; the result is already stored in a uint32_t, so
> the generated code is identical on most platforms.
>
> Signed-off-by: Bin Guo <guobin@linux.alibaba.com>
> ---
> hw/display/virtio-gpu.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> index 88526051a9..9dfffa270a 100644
> --- a/hw/display/virtio-gpu.c
> +++ b/hw/display/virtio-gpu.c
> @@ -387,7 +387,7 @@ void virtio_gpu_disable_scanout(VirtIOGPU *g, int scanout_id)
>
> res = virtio_gpu_find_resource(g, scanout->resource_id);
> if (res) {
> - res->scanout_bitmask &= ~(1 << scanout_id);
> + res->scanout_bitmask &= ~(1U << scanout_id);
> }
>
> qemu_console_set_surface(scanout->con, NULL);
> @@ -405,7 +405,7 @@ static void virtio_gpu_resource_destroy(VirtIOGPU *g,
>
> if (res->scanout_bitmask) {
> for (i = 0; i < g->parent_obj.conf.max_outputs; i++) {
> - if (res->scanout_bitmask & (1 << i)) {
> + if (res->scanout_bitmask & (1U << i)) {
> virtio_gpu_disable_scanout(g, i);
> }
> }
> @@ -571,7 +571,7 @@ static void virtio_gpu_resource_flush(VirtIOGPU *g,
> for (i = 0; i < g->parent_obj.conf.max_outputs; i++) {
> QemuRect rect;
>
> - if (!(res->scanout_bitmask & (1 << i))) {
> + if (!(res->scanout_bitmask & (1U << i))) {
> continue;
> }
> scanout = &g->parent_obj.scanout[i];
> @@ -605,10 +605,10 @@ void virtio_gpu_update_scanout(VirtIOGPU *g,
> scanout = &g->parent_obj.scanout[scanout_id];
> ores = virtio_gpu_find_resource(g, scanout->resource_id);
> if (ores) {
> - ores->scanout_bitmask &= ~(1 << scanout_id);
> + ores->scanout_bitmask &= ~(1U << scanout_id);
> }
>
> - res->scanout_bitmask |= (1 << scanout_id);
> + res->scanout_bitmask |= (1U << scanout_id);
> scanout->resource_id = res->resource_id;
> scanout->x = r->x;
> scanout->y = r->y;
> @@ -1490,7 +1490,7 @@ static int virtio_gpu_post_load(void *opaque, int version_id)
> if (scanout->cursor.resource_id) {
> update_cursor(g, &scanout->cursor);
> }
> - res->scanout_bitmask |= (1 << i);
> + res->scanout_bitmask |= (1U << i);
> }
>
> return 0;
^ permalink raw reply
* Re: [PATCH b4 0/5] shazam: stop --resolve from silently dropping commits
From: Christian Brauner @ 2026-06-24 8:35 UTC (permalink / raw)
To: Christian Brauner; +Cc: Kernel.org Tools, Konstantin Ryabitsev
In-Reply-To: <20260624-shazam-resolve-native-am-v1-0-91f5e5678998@kernel.org>
On 2026-06-24 01:41 +0200, Christian Brauner wrote:
> b4 shazam --resolve exists to help land a series that doesn't apply
> cleanly. The problem that motivated this series is that, while resolving,
> it can silently drop whole commits from the merge it produces: you end up
> with a merge that is quietly missing changes, and nothing in the output
> points at what went missing.
>
> Why they vanish
>
> When git am can't apply the series, the old --resolve path merged the
> patches that did apply, then replayed each remaining patch with
> "git apply --3way" and staged the result with "git add -u".
>
> git apply --3way can only do its three-way merge if the blob IDs recorded
> in the patch's "index <old>..<new>" lines are present in your object
> store. For patches that arrived over email those blobs usually aren't
> there -- which is frequently the very reason git am -3 failed to begin
> with. In that case git apply --3way falls back to a plain apply, fails
> with "patch does not apply", and exits non-zero having written nothing at
> all: no conflict markers, no unmerged index entries.
>
> The replay loop assumed any non-zero exit meant "conflict markers are in
> the tree." It advanced past the patch and asked you to resolve conflicts
> that did not exist, so b4 shazam --continue happily resumed at the next
> patch. The skipped patch's changes never entered the merge -- they were
> simply gone, with no warning. A patch that only adds a new file can
> disappear the same way when it rides along with a change that can't be
> applied.
>
> How this fixes it
>
> Stop replaying patches with git apply entirely. On a conflict, b4 already
> leaves the in-progress git am parked in a throwaway worktree; keep it
> there and finish it natively:
>
> cd <worktree printed by b4>
> # resolve the conflicted files
> git am --continue # or: git am --skip
>
> git am drives the whole remaining series through git's own machinery,
> which stops on every patch it cannot apply and never silently skips one.
> Once it is done, b4 shazam --continue fetches the fully-applied series and
> merges it exactly once -- the same merge a clean b4 shazam makes. Because
> every patch now goes through git am, nothing can vanish. This also brings
> --resolve in line with how the review TUI already resolves conflicts.
>
> Since both now resolve am conflicts the same way, the series starts by
> lifting the worktree plumbing the TUI already had -- detecting an
> in-progress git am, and fetching the finished result out of the worktree
> before dropping it -- into b4 core, and shazam reuses it rather than
> growing its own copy.
>
> Resolving conflicts in subdirectory files
>
> One gap hid behind that guarantee. The series is applied in a sparse
> worktree where only root-level files are materialized, and git's 3-way
> merge refuses to touch skip-worktree paths. So a conflict in a
> subdirectory file -- the common case for real series -- still made
> git am -3 abort with a clean index: no markers, nothing to resolve. The
> user was pointed at a conflict that was not there, git am --continue
> dead-ended, and git am --skip silently dropped the patch. Only root-file
> conflicts, which the tests happened to use, ever worked.
>
> git_fetch_am_into_repo now rebuilds a full worktree on a conflict before
> handing it back -- abort the partial am, disable sparse-checkout, replay --
> so the conflict is recorded with real markers to resolve. b4 shazam
> --resolve and the review TUI both apply through this one function, so both
> are fixed, and a regression test drives a subdirectory conflict end to end.
>
> The same commit hardens the rest of the flow: b4 shazam --abort no longer
> crashes on a corrupt state file, --continue refuses up front on a dirty
> working tree (keeping its state so it stays re-runnable), a failed
> worktree fetch leaves the resolved am in place to retry, and the docs now
> note that --continue merges with -M and leaves FETCH_HEAD with -H.
>
> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
> ---
v2 will be coming shortly.
^ permalink raw reply
* Re: [PATCH v3 RESEND 4/5] RISC-V: KVM: Split huge pages during KVM_CLEAR_DIRTY_LOG
From: sashiko-bot @ 2026-06-24 8:35 UTC (permalink / raw)
To: wang.yechao255; +Cc: kvm
In-Reply-To: <20260624161128723A8RgX9GQcthwS3so76Ou2@zte.com.cn>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Eager huge page splitting during KVM_CLEAR_DIRTY_LOG silently fails for most ranges due to incorrect address alignment in mmu_split_huge_pages().
Pre-existing issues:
- [High] Write-protecting guest page table entries (SPTEs) clobbers concurrent hardware Access/Dirty bit updates.
--
commit 00cb697f813eca012a08732046a12ddb66d6af56
Author: Wang Yechao <wang.yechao255@zte.com.cn>
RISC-V: KVM: Split huge pages during KVM_CLEAR_DIRTY_LOG
This commit splits huge pages on the range specified by KVM_CLEAR_DIRTY_LOG.
It also avoids splitting when enabling dirty logging if
KVM_DIRTY_LOG_INITIALLY_SET is set.
> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index bc3bad67d507b..cbda927dd24e3 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c
> @@ -164,6 +164,9 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
> kvm_riscv_gstage_init(&gstage, kvm);
>
> kvm_riscv_gstage_wp_range(&gstage, start, end);
[Severity: High]
This is a pre-existing issue, but does calling kvm_riscv_gstage_wp_range()
clobber concurrent hardware Access/Dirty bit updates?
Looking at arch/riscv/kvm/gstage.c, kvm_riscv_gstage_op_pte() uses a
non-atomic read-modify-write when write-protecting:
kvm_riscv_gstage_op_pte() {
...
else if (op == GSTAGE_OP_WP)
set_pte(ptep, __pte(pte_val(ptep_get(ptep)) & ~_PAGE_WRITE));
...
}
If the hardware page-table walker sets the Accessed or Dirty bit between the
read and the write, it seems the bit is permanently lost.
> +
> + if (kvm_dirty_log_manual_protect_and_init_set(kvm))
> + mmu_split_huge_pages(&gstage, start, end);
[Severity: High]
Does mmu_split_huge_pages() fail to split overlapping huge pages for small
or unaligned ranges?
Looking at mmu_split_huge_pages() in arch/riscv/kvm/mmu.c, it initializes
the address using ALIGN():
phys_addr_t addr = ALIGN(start, PMD_SIZE);
If KVM_CLEAR_DIRTY_LOG passes an unaligned start address (e.g., clearing a
small mask), ALIGN() rounds the start address up. This could cause addr to
be greater than or equal to end, resulting in the while (addr < end) loop
terminating immediately and skipping the huge page that overlaps the
beginning of the target range. Should this use ALIGN_DOWN() instead?
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624160054463wcDvJaMoydSggcNOWgcfB@zte.com.cn?part=4
^ permalink raw reply
* Re: [PATCH v22 04/13] firmware: psci: Introduce command-based resets
From: Shivendra Pratap @ 2026-06-24 8:34 UTC (permalink / raw)
To: Lorenzo Pieralisi, Arnd Bergmann, Sebastian Reichel, Mark Rutland,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Souvik Chakravarty, Bartosz Golaszewski, Sudeep Holla
Cc: krzk+dt, conor+dt, devicetree, robh, sashiko-reviews
In-Reply-To: <20260514212353.881AFC2BCB8@smtp.kernel.org>
On 15-05-2026 02:53, sashiko-bot@kernel.org wrote:
> - [High] The API illegally truncates the 64-bit PSCI SYSTEM_RESET2 cookie parameter to 32 bits, violating the ARM PSCI specification.
Hi Lorenzo,
Was going through this comment. The patch currently uses a 32 bit
cookie. The spec also talks about "SMC64 - uint64 - cookie". Can you
please suggest if we should add support for 64 bit cookie here?
This will require a re-design for supporting about up-to three 32-bit
numbers in reboot-mode framework.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v3 RESEND 2/5] RISC-V: KVM: Split huge pages when dirty logging is enabled
From: sashiko-bot @ 2026-06-24 8:35 UTC (permalink / raw)
To: wang.yechao255; +Cc: kvm
In-Reply-To: <20260624160756348x7b5SnXSw0CoFU0bMR692@zte.com.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] `need_topup_split_caches_or_resched` fails to check `rwlock_needbreak(&kvm->mmu_lock)`, causing lock starvation and latency spikes.
--
commit 10d6c81f6c350e7e0a1eeeb75389a0fa2b8dc5f8
Author: Wang Yechao <wang.yechao255@zte.com.cn>
RISC-V: KVM: Split huge pages when dirty logging is enabled
Eagerly split huge pages when enabling dirty logging to avoid faulting on
write-protected pages. This mirrors the approach taken on x86 and arm64
to improve guest performance.
> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index 9cf69bc28b9c5..95e83c50addf5 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c
[ ... ]
> +static bool need_topup_split_caches_or_resched(struct kvm_mmu_memory_cache *cache,
> + int count)
> +{
> + if (need_resched())
> + return true;
> +
> + return kvm_mmu_memory_cache_nr_free_objects(cache) < count;
> +}
> +
> +static bool mmu_split_huge_pages(struct kvm_gstage *gstage,
> + phys_addr_t start, phys_addr_t end)
> +{
> + struct kvm *kvm = gstage->kvm;
> + struct kvm_mmu_memory_cache *pcache = &kvm->arch.pgd_split_page_cache;
> + phys_addr_t addr = ALIGN(start, PMD_SIZE);
> + phys_addr_t last_flush_gfn = addr >> PAGE_SHIFT;
> + int count = gstage->pgd_levels;
> + bool flush = false;
> + int ret;
> +
> + lockdep_assert_held_write(&kvm->mmu_lock);
> +
> + while (addr < end) {
> + if (need_topup_split_caches_or_resched(pcache, count)) {
[Severity: High]
Does this code need to check rwlock_needbreak() to avoid lock starvation?
When mmu_split_huge_pages() iterates over a memslot with kvm->mmu_lock held
in write mode, preemption is disabled. The need_resched() check alone might
not capture lock contention on kvm->mmu_lock.
If there are no huge pages to split in the memslot, the memory cache will
never deplete. This means the loop could run over large amounts of memory
without ever yielding the lock.
Could this starve other vCPUs waiting to acquire kvm->mmu_lock in read mode?
Perhaps need_topup_split_caches_or_resched() should check
rwlock_needbreak(&kvm->mmu_lock) like other architectures do during eager
page splitting?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624160054463wcDvJaMoydSggcNOWgcfB@zte.com.cn?part=2
^ permalink raw reply
* [PATCH v1] media: ti: vpe: #include <linux/platform_device.h> explicitly
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-24 8:34 UTC (permalink / raw)
To: Yemike Abhilash Chandra, Mauro Carvalho Chehab; +Cc: linux-media, linux-kernel
The driver uses several symbols and structs defined in that header. The
header is currently included transitively via
"vip.h" ->
<media/v4l2-ctrls.h> ->
<media/media-request.h> ->
<media/media-device.h> ->
<linux/platform_device.h>
which seems to be on the lower end of the scale between random and
reliable.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/media/platform/ti/vpe/vip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/ti/vpe/vip.c b/drivers/media/platform/ti/vpe/vip.c
index cb0a5a07a3d4..e56a95f53ea9 100644
--- a/drivers/media/platform/ti/vpe/vip.c
+++ b/drivers/media/platform/ti/vpe/vip.c
@@ -16,6 +16,7 @@
#include <linux/interrupt.h>
#include <linux/module.h>
#include <linux/workqueue.h>
+#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/sched.h>
#include <linux/mfd/syscon.h>
base-commit: ef0c9f75a19532d7675384708fc8621e10850104
prerequisite-patch-id: 9fe9c8859b763130453036a4748307de6005c1ba
--
2.47.3
^ permalink raw reply related
* [scarthgap][PATCH v2] curl: fix CVE-2026-5773 - wrong reuse of SMB connection
From: Jaipaul Cheernam @ 2026-06-24 8:34 UTC (permalink / raw)
To: openembedded-core; +Cc: Jaipaul Cheernam
In-Reply-To: <20260623074847.3424-1-jaipaul.cheernam@est.tech>
libcurl's SMB handler marks connections for reuse (connkeep) without
verifying that subsequent requests target the same share. This allows
a second SMB request to the same host to reuse a connection
authenticated for a different share, potentially accessing data
without proper authorization.
The upstream fix removes connection reuse for SMB entirely in
lib/protocol.c, a file introduced in curl 8.20.0. For 8.7.1, the
equivalent fix is changing connkeep() to connclose() in lib/smb.c,
which prevents the connection from being returned to the pool.
Tested with SMBv1 server (Docker dperson/samba):
Without patch: "Re-using existing connection" for different shares
With patch: New connection per request, no reuse
Binary verified: Curl_conncontrol arg changes from 0 (KEEP) to 1 (CLOSE)
Reference: https://curl.se/docs/CVE-2026-5773.html
Signed-off-by: Jaipaul Cheernam <jaipaul.cheernam@est.tech>
---
.../curl/curl/CVE-2026-5773.patch | 41 +++++++++++++++++++
meta/recipes-support/curl/curl_8.7.1.bb | 1 +
2 files changed, 42 insertions(+)
create mode 100644 meta/recipes-support/curl/curl/CVE-2026-5773.patch
diff --git a/meta/recipes-support/curl/curl/CVE-2026-5773.patch b/meta/recipes-support/curl/curl/CVE-2026-5773.patch
new file mode 100644
index 0000000000..0a5fa588fe
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2026-5773.patch
@@ -0,0 +1,41 @@
+From 74a169575d6412dc0ff532acdf94de35a6c2a571 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg <daniel@haxx.se>
+Date: Sun, 5 Apr 2026 18:23:35 +0200
+Subject: [PATCH] protocol: disable connection reuse for SMB(S)
+
+Connections should only be reused when using the same "share" (and
+perhaps some additional conditions), but instead of fixing this flaw,
+this change completely disables connection reuse for SMB. This protocol
+is about to get dropped soon anyway.
+
+Reported-by: Osama Hamad
+Closes #21238
+Signed-off-by: Daniel Stenberg <daniel@haxx.se>
+
+CVE: CVE-2026-5773
+Upstream-Status: Backport [https://github.com/curl/curl/commit/74a169575d6412dc0ff532acdf94de35a6c2a571]
+
+Note: The upstream fix targets lib/protocol.c which was introduced in
+curl 8.20.0. In 8.7.1 the equivalent is changing connkeep() to
+connclose() in lib/smb.c, which prevents the connection from being
+returned to the pool. The effect is identical.
+
+Signed-off-by: Jaipaul Cheernam <jaipaul.cheernam@est.tech>
+---
+ lib/smb.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/lib/smb.c b/lib/smb.c
+index 7c73cbcec..a1f5c9b31 100644
+--- a/lib/smb.c
++++ b/lib/smb.c
+@@ -461,8 +461,7 @@ static CURLcode smb_connect(struct Curl_easy *data, bool *done)
+ if(!smbc->send_buf)
+ return CURLE_OUT_OF_MEMORY;
+
+- /* Multiple requests are allowed with this connection */
+- connkeep(conn, "SMB default");
++ connclose(conn, "SMB default");
+
+ /* Parse the username, domain, and password */
+ slash = strchr(conn->user, '/');
diff --git a/meta/recipes-support/curl/curl_8.7.1.bb b/meta/recipes-support/curl/curl_8.7.1.bb
index 14d63d6373..d026731751 100644
--- a/meta/recipes-support/curl/curl_8.7.1.bb
+++ b/meta/recipes-support/curl/curl_8.7.1.bb
@@ -36,6 +36,7 @@ SRC_URI = " \
file://CVE-2026-1965-2.patch \
file://CVE-2026-3783.patch \
file://CVE-2026-3784.patch \
+ file://CVE-2026-5773.patch \
"
SRC_URI:append:class-nativesdk = " \
--
2.34.1
^ permalink raw reply related
* ✓ Xe.CI.FULL: success for tests/intel/xe_exec_fault_mode: Revive atomic tests
From: Patchwork @ 2026-06-24 8:34 UTC (permalink / raw)
To: Gajendra Uttamchand; +Cc: igt-dev
In-Reply-To: <20260624062022.34659-2-gajendra.uttamchand@intel.com>
[-- Attachment #1: Type: text/plain, Size: 46139 bytes --]
== Series Details ==
Series: tests/intel/xe_exec_fault_mode: Revive atomic tests
URL : https://patchwork.freedesktop.org/series/169064/
State : success
== Summary ==
CI Bug Log - changes from XEIGT_8982_FULL -> XEIGTPW_15436_FULL
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Participating hosts (2 -> 2)
------------------------------
No changes in participating hosts
New tests
---------
New tests have been introduced between XEIGT_8982_FULL and XEIGTPW_15436_FULL:
### New IGT tests (4) ###
* igt@xe_exec_fault_mode@atomic-many:
- Statuses : 2 pass(s)
- Exec time: [0.03, 0.06] s
* igt@xe_exec_fault_mode@atomic-many-wait:
- Statuses : 2 pass(s)
- Exec time: [0.03, 0.04] s
* igt@xe_exec_fault_mode@atomic-once:
- Statuses : 2 pass(s)
- Exec time: [0.03] s
* igt@xe_exec_fault_mode@atomic-once-wait:
- Statuses : 2 pass(s)
- Exec time: [0.02] s
Known issues
------------
Here are the changes found in XEIGTPW_15436_FULL that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@asahi/asahi_get_params@get-params-1:
- shard-bmg: NOTRUN -> [SKIP][1] ([Intel XE#8416])
[1]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-6/igt@asahi/asahi_get_params@get-params-1.html
- shard-lnl: NOTRUN -> [SKIP][2] ([Intel XE#8416])
[2]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-7/igt@asahi/asahi_get_params@get-params-1.html
* igt@intel_hwmon@hwmon-write:
- shard-bmg: NOTRUN -> [FAIL][3] ([Intel XE#7445])
[3]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-1/igt@intel_hwmon@hwmon-write.html
- shard-lnl: NOTRUN -> [SKIP][4] ([Intel XE#1125] / [Intel XE#7312])
[4]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-5/igt@intel_hwmon@hwmon-write.html
* igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- shard-bmg: NOTRUN -> [SKIP][5] ([Intel XE#2233])
[5]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-2/igt@kms_addfb_basic@addfb25-y-tiled-small-legacy.html
* igt@kms_atomic_transition@plane-all-transition-nonblocking:
- shard-bmg: [PASS][6] -> [INCOMPLETE][7] ([Intel XE#8174]) +1 other test incomplete
[6]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-6/igt@kms_atomic_transition@plane-all-transition-nonblocking.html
[7]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-3/igt@kms_atomic_transition@plane-all-transition-nonblocking.html
* igt@kms_big_fb@4-tiled-64bpp-rotate-270:
- shard-lnl: NOTRUN -> [SKIP][8] ([Intel XE#1407])
[8]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-4/igt@kms_big_fb@4-tiled-64bpp-rotate-270.html
* igt@kms_big_fb@linear-32bpp-rotate-90:
- shard-bmg: NOTRUN -> [SKIP][9] ([Intel XE#2327]) +2 other tests skip
[9]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-2/igt@kms_big_fb@linear-32bpp-rotate-90.html
* igt@kms_big_fb@yf-tiled-32bpp-rotate-0:
- shard-bmg: NOTRUN -> [SKIP][10] ([Intel XE#1124]) +5 other tests skip
[10]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-7/igt@kms_big_fb@yf-tiled-32bpp-rotate-0.html
* igt@kms_big_fb@yf-tiled-8bpp-rotate-270:
- shard-lnl: NOTRUN -> [SKIP][11] ([Intel XE#1124]) +2 other tests skip
[11]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-5/igt@kms_big_fb@yf-tiled-8bpp-rotate-270.html
* igt@kms_big_fb@yf-tiled-addfb-size-overflow:
- shard-bmg: NOTRUN -> [SKIP][12] ([Intel XE#610] / [Intel XE#7387])
[12]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-10/igt@kms_big_fb@yf-tiled-addfb-size-overflow.html
- shard-lnl: NOTRUN -> [SKIP][13] ([Intel XE#1428] / [Intel XE#7387])
[13]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-1/igt@kms_big_fb@yf-tiled-addfb-size-overflow.html
* igt@kms_bw@connected-linear-tiling-2-displays-target-2560x1440p:
- shard-lnl: NOTRUN -> [SKIP][14] ([Intel XE#7679])
[14]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-7/igt@kms_bw@connected-linear-tiling-2-displays-target-2560x1440p.html
* igt@kms_bw@connected-linear-tiling-3-displays-target-2160x1440p:
- shard-bmg: NOTRUN -> [SKIP][15] ([Intel XE#7679])
[15]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-7/igt@kms_bw@connected-linear-tiling-3-displays-target-2160x1440p.html
* igt@kms_ccs@bad-pixel-format-4-tiled-dg2-mc-ccs:
- shard-bmg: NOTRUN -> [SKIP][16] ([Intel XE#2887]) +7 other tests skip
[16]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-5/igt@kms_ccs@bad-pixel-format-4-tiled-dg2-mc-ccs.html
* igt@kms_ccs@bad-pixel-format-y-tiled-gen12-mc-ccs:
- shard-lnl: NOTRUN -> [SKIP][17] ([Intel XE#2887]) +3 other tests skip
[17]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@kms_ccs@bad-pixel-format-y-tiled-gen12-mc-ccs.html
* igt@kms_cdclk@mode-transition:
- shard-bmg: NOTRUN -> [SKIP][18] ([Intel XE#2724] / [Intel XE#7449])
[18]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-7/igt@kms_cdclk@mode-transition.html
* igt@kms_cdclk@mode-transition@pipe-b-edp-1:
- shard-lnl: NOTRUN -> [SKIP][19] ([Intel XE#4417] / [Intel XE#5447]) +3 other tests skip
[19]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-2/igt@kms_cdclk@mode-transition@pipe-b-edp-1.html
* igt@kms_chamelium_color@ctm-blue-to-red:
- shard-bmg: NOTRUN -> [SKIP][20] ([Intel XE#2325] / [Intel XE#7358])
[20]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-4/igt@kms_chamelium_color@ctm-blue-to-red.html
* igt@kms_chamelium_color_pipeline@plane-lut3d-green-only:
- shard-bmg: NOTRUN -> [SKIP][21] ([Intel XE#7358])
[21]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-5/igt@kms_chamelium_color_pipeline@plane-lut3d-green-only.html
- shard-lnl: NOTRUN -> [SKIP][22] ([Intel XE#7358])
[22]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-5/igt@kms_chamelium_color_pipeline@plane-lut3d-green-only.html
* igt@kms_chamelium_edid@dp-edid-stress-resolution-4k:
- shard-bmg: NOTRUN -> [SKIP][23] ([Intel XE#2252]) +2 other tests skip
[23]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-3/igt@kms_chamelium_edid@dp-edid-stress-resolution-4k.html
* igt@kms_chamelium_hpd@dp-hpd-after-hibernate:
- shard-lnl: NOTRUN -> [SKIP][24] ([Intel XE#373]) +1 other test skip
[24]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-1/igt@kms_chamelium_hpd@dp-hpd-after-hibernate.html
* igt@kms_content_protection@lic-type-1:
- shard-bmg: NOTRUN -> [SKIP][25] ([Intel XE#7642])
[25]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-7/igt@kms_content_protection@lic-type-1.html
* igt@kms_content_protection@srm:
- shard-bmg: NOTRUN -> [FAIL][26] ([Intel XE#1178] / [Intel XE#3304] / [Intel XE#7374]) +1 other test fail
[26]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-5/igt@kms_content_protection@srm.html
- shard-lnl: NOTRUN -> [SKIP][27] ([Intel XE#7642])
[27]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-6/igt@kms_content_protection@srm.html
* igt@kms_cursor_crc@cursor-rapid-movement-512x170:
- shard-lnl: NOTRUN -> [SKIP][28] ([Intel XE#2321] / [Intel XE#7355])
[28]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@kms_cursor_crc@cursor-rapid-movement-512x170.html
- shard-bmg: NOTRUN -> [SKIP][29] ([Intel XE#2321] / [Intel XE#7355])
[29]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-5/igt@kms_cursor_crc@cursor-rapid-movement-512x170.html
* igt@kms_cursor_crc@cursor-rapid-movement-max-size:
- shard-bmg: NOTRUN -> [SKIP][30] ([Intel XE#2320]) +2 other tests skip
[30]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-1/igt@kms_cursor_crc@cursor-rapid-movement-max-size.html
- shard-lnl: NOTRUN -> [SKIP][31] ([Intel XE#1424]) +1 other test skip
[31]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-5/igt@kms_cursor_crc@cursor-rapid-movement-max-size.html
* igt@kms_cursor_legacy@2x-cursor-vs-flip-legacy:
- shard-lnl: NOTRUN -> [SKIP][32] ([Intel XE#309] / [Intel XE#7343]) +2 other tests skip
[32]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@kms_cursor_legacy@2x-cursor-vs-flip-legacy.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic:
- shard-bmg: [PASS][33] -> [FAIL][34] ([Intel XE#7571])
[33]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-7/igt@kms_cursor_legacy@flip-vs-cursor-atomic.html
[34]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-9/igt@kms_cursor_legacy@flip-vs-cursor-atomic.html
* igt@kms_cursor_legacy@short-busy-flip-before-cursor-toggle:
- shard-bmg: NOTRUN -> [SKIP][35] ([Intel XE#2286] / [Intel XE#6035])
[35]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-1/igt@kms_cursor_legacy@short-busy-flip-before-cursor-toggle.html
* igt@kms_dsc@dsc-with-formats-bigjoiner:
- shard-bmg: NOTRUN -> [SKIP][36] ([Intel XE#8265]) +1 other test skip
[36]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-1/igt@kms_dsc@dsc-with-formats-bigjoiner.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-bmg: NOTRUN -> [SKIP][37] ([Intel XE#4156] / [Intel XE#7425])
[37]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-3/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-dp2-hdmi-a3:
- shard-bmg: [PASS][38] -> [FAIL][39] ([Intel XE#3321]) +1 other test fail
[38]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-5/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-dp2-hdmi-a3.html
[39]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-6/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-dp2-hdmi-a3.html
* igt@kms_flip@2x-nonexisting-fb:
- shard-lnl: NOTRUN -> [SKIP][40] ([Intel XE#1421])
[40]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-4/igt@kms_flip@2x-nonexisting-fb.html
* igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-lnl: [PASS][41] -> [FAIL][42] ([Intel XE#301]) +1 other test fail
[41]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-lnl-1/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
[42]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
* igt@kms_flip@flip-vs-expired-vblank@c-edp1:
- shard-lnl: [PASS][43] -> [FAIL][44] ([Intel XE#301] / [Intel XE#3149]) +1 other test fail
[43]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-lnl-1/igt@kms_flip@flip-vs-expired-vblank@c-edp1.html
[44]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@kms_flip@flip-vs-expired-vblank@c-edp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscaling:
- shard-bmg: NOTRUN -> [SKIP][45] ([Intel XE#7178] / [Intel XE#7351])
[45]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-7/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscaling.html
* igt@kms_frontbuffer_tracking@drrshdr-2p-primscrn-pri-shrfb-draw-blt:
- shard-lnl: NOTRUN -> [SKIP][46] ([Intel XE#7905]) +6 other tests skip
[46]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-1/igt@kms_frontbuffer_tracking@drrshdr-2p-primscrn-pri-shrfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscreen-pri-shrfb-draw-blt:
- shard-bmg: NOTRUN -> [SKIP][47] ([Intel XE#4141]) +9 other tests skip
[47]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-4/igt@kms_frontbuffer_tracking@fbc-1p-offscreen-pri-shrfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbcdrrs-1p-primscrn-pri-indfb-draw-render:
- shard-lnl: NOTRUN -> [SKIP][48] ([Intel XE#6312] / [Intel XE#651]) +1 other test skip
[48]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-3/igt@kms_frontbuffer_tracking@fbcdrrs-1p-primscrn-pri-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbcdrrs-2p-scndscrn-pri-indfb-draw-render:
- shard-lnl: NOTRUN -> [SKIP][49] ([Intel XE#656] / [Intel XE#7905]) +6 other tests skip
[49]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@kms_frontbuffer_tracking@fbcdrrs-2p-scndscrn-pri-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbcdrrshdr-1p-primscrn-spr-indfb-onoff:
- shard-lnl: NOTRUN -> [SKIP][50] ([Intel XE#6312]) +3 other tests skip
[50]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-6/igt@kms_frontbuffer_tracking@fbcdrrshdr-1p-primscrn-spr-indfb-onoff.html
* igt@kms_frontbuffer_tracking@fbcdrrshdr-rgb565-draw-blt:
- shard-bmg: NOTRUN -> [SKIP][51] ([Intel XE#2311]) +31 other tests skip
[51]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-6/igt@kms_frontbuffer_tracking@fbcdrrshdr-rgb565-draw-blt.html
* igt@kms_frontbuffer_tracking@fbchdr-1p-primscrn-shrfb-pgflip-blt:
- shard-lnl: NOTRUN -> [SKIP][52] ([Intel XE#7865]) +3 other tests skip
[52]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-4/igt@kms_frontbuffer_tracking@fbchdr-1p-primscrn-shrfb-pgflip-blt.html
* igt@kms_frontbuffer_tracking@fbchdr-argb161616f-draw-mmap-wc:
- shard-lnl: NOTRUN -> [SKIP][53] ([Intel XE#7061])
[53]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-3/igt@kms_frontbuffer_tracking@fbchdr-argb161616f-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt:
- shard-bmg: NOTRUN -> [SKIP][54] ([Intel XE#2313]) +31 other tests skip
[54]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-abgr161616f-draw-blt:
- shard-bmg: NOTRUN -> [SKIP][55] ([Intel XE#7061] / [Intel XE#7356])
[55]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-10/igt@kms_frontbuffer_tracking@fbcpsr-abgr161616f-draw-blt.html
* igt@kms_hdr@invalid-hdr:
- shard-bmg: [PASS][56] -> [SKIP][57] ([Intel XE#1503])
[56]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-8/igt@kms_hdr@invalid-hdr.html
[57]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-10/igt@kms_hdr@invalid-hdr.html
* igt@kms_pipe_stress@stress-xrgb8888-yftiled:
- shard-bmg: NOTRUN -> [SKIP][58] ([Intel XE#6912] / [Intel XE#7375])
[58]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-9/igt@kms_pipe_stress@stress-xrgb8888-yftiled.html
* igt@kms_plane@pixel-format-4-tiled-bmg-ccs-modifier@pipe-a-plane-5:
- shard-bmg: NOTRUN -> [SKIP][59] ([Intel XE#8303]) +1 other test skip
[59]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-3/igt@kms_plane@pixel-format-4-tiled-bmg-ccs-modifier@pipe-a-plane-5.html
* igt@kms_plane@pixel-format-yf-tiled-ccs-modifier-source-clamping:
- shard-bmg: NOTRUN -> [SKIP][60] ([Intel XE#7283]) +3 other tests skip
[60]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-7/igt@kms_plane@pixel-format-yf-tiled-ccs-modifier-source-clamping.html
- shard-lnl: NOTRUN -> [SKIP][61] ([Intel XE#7283]) +2 other tests skip
[61]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-2/igt@kms_plane@pixel-format-yf-tiled-ccs-modifier-source-clamping.html
* igt@kms_plane_scaling@planes-downscale-factor-0-5:
- shard-lnl: NOTRUN -> [SKIP][62] ([Intel XE#2763] / [Intel XE#6886]) +7 other tests skip
[62]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-4/igt@kms_plane_scaling@planes-downscale-factor-0-5.html
* igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-a:
- shard-bmg: NOTRUN -> [SKIP][63] ([Intel XE#2763] / [Intel XE#6886]) +9 other tests skip
[63]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-9/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-a.html
* igt@kms_pm_backlight@fade-with-dpms:
- shard-bmg: NOTRUN -> [SKIP][64] ([Intel XE#7376] / [Intel XE#7760] / [Intel XE#870])
[64]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-4/igt@kms_pm_backlight@fade-with-dpms.html
* igt@kms_pm_dc@dc3co-after-dc6:
- shard-bmg: NOTRUN -> [SKIP][65] ([Intel XE#8395]) +1 other test skip
[65]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-6/igt@kms_pm_dc@dc3co-after-dc6.html
* igt@kms_pm_dc@dc3co-after-dc6@psr2:
- shard-bmg: NOTRUN -> [SKIP][66] ([Intel XE#8396])
[66]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-6/igt@kms_pm_dc@dc3co-after-dc6@psr2.html
* igt@kms_pm_dc@dc6-psr:
- shard-lnl: [PASS][67] -> [FAIL][68] ([Intel XE#8399])
[67]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-lnl-7/igt@kms_pm_dc@dc6-psr.html
[68]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-1/igt@kms_pm_dc@dc6-psr.html
* igt@kms_pm_rpm@modeset-non-lpsp-stress-no-wait:
- shard-lnl: NOTRUN -> [SKIP][69] ([Intel XE#1439] / [Intel XE#3141] / [Intel XE#7383])
[69]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-5/igt@kms_pm_rpm@modeset-non-lpsp-stress-no-wait.html
* igt@kms_psr2_sf@fbc-pr-overlay-plane-update-continuous-sf:
- shard-bmg: NOTRUN -> [SKIP][70] ([Intel XE#1489]) +4 other tests skip
[70]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-9/igt@kms_psr2_sf@fbc-pr-overlay-plane-update-continuous-sf.html
- shard-lnl: NOTRUN -> [SKIP][71] ([Intel XE#2893] / [Intel XE#7304]) +1 other test skip
[71]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@kms_psr2_sf@fbc-pr-overlay-plane-update-continuous-sf.html
* igt@kms_psr2_sf@fbc-psr2-overlay-plane-update-sf-dmg-area:
- shard-lnl: NOTRUN -> [SKIP][72] ([Intel XE#2893] / [Intel XE#4608] / [Intel XE#7304])
[72]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-3/igt@kms_psr2_sf@fbc-psr2-overlay-plane-update-sf-dmg-area.html
* igt@kms_psr2_sf@fbc-psr2-overlay-plane-update-sf-dmg-area@pipe-a-edp-1:
- shard-lnl: NOTRUN -> [SKIP][73] ([Intel XE#4608])
[73]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-3/igt@kms_psr2_sf@fbc-psr2-overlay-plane-update-sf-dmg-area@pipe-a-edp-1.html
* igt@kms_psr2_sf@fbc-psr2-overlay-plane-update-sf-dmg-area@pipe-b-edp-1:
- shard-lnl: NOTRUN -> [SKIP][74] ([Intel XE#4608] / [Intel XE#7304])
[74]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-3/igt@kms_psr2_sf@fbc-psr2-overlay-plane-update-sf-dmg-area@pipe-b-edp-1.html
* igt@kms_psr@fbc-psr2-basic:
- shard-bmg: NOTRUN -> [SKIP][75] ([Intel XE#2234] / [Intel XE#2850]) +4 other tests skip
[75]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-3/igt@kms_psr@fbc-psr2-basic.html
- shard-lnl: NOTRUN -> [SKIP][76] ([Intel XE#1406] / [Intel XE#7345])
[76]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-6/igt@kms_psr@fbc-psr2-basic.html
* igt@kms_psr@fbc-psr2-basic@edp-1:
- shard-lnl: NOTRUN -> [SKIP][77] ([Intel XE#1406] / [Intel XE#4609])
[77]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-6/igt@kms_psr@fbc-psr2-basic@edp-1.html
* igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180:
- shard-lnl: NOTRUN -> [SKIP][78] ([Intel XE#1127] / [Intel XE#5813])
[78]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-3/igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180.html
* igt@kms_sharpness_filter@invalid-plane-with-filter:
- shard-bmg: NOTRUN -> [SKIP][79] ([Intel XE#6503])
[79]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-5/igt@kms_sharpness_filter@invalid-plane-with-filter.html
* igt@kms_tiled_display@basic-test-pattern:
- shard-bmg: NOTRUN -> [FAIL][80] ([Intel XE#1729] / [Intel XE#7424])
[80]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-10/igt@kms_tiled_display@basic-test-pattern.html
* igt@kms_vrr@flipline:
- shard-lnl: [PASS][81] -> [FAIL][82] ([Intel XE#4227] / [Intel XE#7397]) +1 other test fail
[81]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-lnl-1/igt@kms_vrr@flipline.html
[82]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@kms_vrr@flipline.html
* igt@kms_vrr@lobf-dc3co:
- shard-bmg: NOTRUN -> [SKIP][83] ([Intel XE#8397])
[83]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-7/igt@kms_vrr@lobf-dc3co.html
- shard-lnl: NOTRUN -> [SKIP][84] ([Intel XE#8397])
[84]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-1/igt@kms_vrr@lobf-dc3co.html
* igt@xe_eudebug@basic-vm-bind-ufence:
- shard-bmg: NOTRUN -> [SKIP][85] ([Intel XE#7636]) +7 other tests skip
[85]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-8/igt@xe_eudebug@basic-vm-bind-ufence.html
* igt@xe_eudebug_online@resume-one:
- shard-lnl: NOTRUN -> [SKIP][86] ([Intel XE#7636]) +2 other tests skip
[86]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-1/igt@xe_eudebug_online@resume-one.html
* igt@xe_evict_ccs@evict-overcommit-standalone-nofree-reopen:
- shard-lnl: NOTRUN -> [SKIP][87] ([Intel XE#6540] / [Intel XE#688]) +3 other tests skip
[87]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-5/igt@xe_evict_ccs@evict-overcommit-standalone-nofree-reopen.html
* igt@xe_exec_balancer@once-parallel-userptr-rebind:
- shard-lnl: NOTRUN -> [SKIP][88] ([Intel XE#7482]) +3 other tests skip
[88]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-4/igt@xe_exec_balancer@once-parallel-userptr-rebind.html
* igt@xe_exec_basic@multigpu-no-exec-bindexecqueue-rebind:
- shard-bmg: NOTRUN -> [SKIP][89] ([Intel XE#2322] / [Intel XE#7372]) +2 other tests skip
[89]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-8/igt@xe_exec_basic@multigpu-no-exec-bindexecqueue-rebind.html
- shard-lnl: NOTRUN -> [SKIP][90] ([Intel XE#1392])
[90]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@xe_exec_basic@multigpu-no-exec-bindexecqueue-rebind.html
* igt@xe_exec_fault_mode@many-multi-queue-rebind-prefetch:
- shard-bmg: NOTRUN -> [SKIP][91] ([Intel XE#8374]) +9 other tests skip
[91]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-10/igt@xe_exec_fault_mode@many-multi-queue-rebind-prefetch.html
- shard-lnl: NOTRUN -> [SKIP][92] ([Intel XE#8374]) +4 other tests skip
[92]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-1/igt@xe_exec_fault_mode@many-multi-queue-rebind-prefetch.html
* igt@xe_exec_multi_queue@few-execs-preempt-mode-fault-close-fd-smem:
- shard-lnl: NOTRUN -> [SKIP][93] ([Intel XE#8364]) +6 other tests skip
[93]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-3/igt@xe_exec_multi_queue@few-execs-preempt-mode-fault-close-fd-smem.html
* igt@xe_exec_multi_queue@two-queues-preempt-mode-fault-priority:
- shard-bmg: NOTRUN -> [SKIP][94] ([Intel XE#8364]) +16 other tests skip
[94]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-1/igt@xe_exec_multi_queue@two-queues-preempt-mode-fault-priority.html
* igt@xe_exec_reset@cm-multi-queue-close-fd:
- shard-lnl: NOTRUN -> [SKIP][95] ([Intel XE#8369])
[95]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-7/igt@xe_exec_reset@cm-multi-queue-close-fd.html
* igt@xe_exec_reset@multi-queue-cancel-on-secondary:
- shard-bmg: NOTRUN -> [SKIP][96] ([Intel XE#8369]) +1 other test skip
[96]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-4/igt@xe_exec_reset@multi-queue-cancel-on-secondary.html
* igt@xe_exec_threads@threads-multi-queue-cm-basic:
- shard-lnl: NOTRUN -> [SKIP][97] ([Intel XE#8378]) +1 other test skip
[97]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-4/igt@xe_exec_threads@threads-multi-queue-cm-basic.html
* igt@xe_exec_threads@threads-multi-queue-hang-fd-userptr-invalidate-race:
- shard-bmg: NOTRUN -> [SKIP][98] ([Intel XE#8378]) +4 other tests skip
[98]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-4/igt@xe_exec_threads@threads-multi-queue-hang-fd-userptr-invalidate-race.html
* igt@xe_multigpu_svm@mgpu-coherency-prefetch:
- shard-bmg: NOTRUN -> [SKIP][99] ([Intel XE#6964]) +1 other test skip
[99]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-5/igt@xe_multigpu_svm@mgpu-coherency-prefetch.html
* igt@xe_multigpu_svm@mgpu-latency-prefetch:
- shard-lnl: NOTRUN -> [SKIP][100] ([Intel XE#6964])
[100]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@xe_multigpu_svm@mgpu-latency-prefetch.html
* igt@xe_non_msix@walker-interrupt-notification-non-msix:
- shard-bmg: NOTRUN -> [SKIP][101] ([Intel XE#7622])
[101]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-10/igt@xe_non_msix@walker-interrupt-notification-non-msix.html
- shard-lnl: NOTRUN -> [SKIP][102] ([Intel XE#7622])
[102]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-1/igt@xe_non_msix@walker-interrupt-notification-non-msix.html
* igt@xe_page_reclaim@binds-large-split:
- shard-lnl: NOTRUN -> [SKIP][103] ([Intel XE#7793])
[103]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@xe_page_reclaim@binds-large-split.html
- shard-bmg: NOTRUN -> [SKIP][104] ([Intel XE#7793])
[104]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-9/igt@xe_page_reclaim@binds-large-split.html
* igt@xe_pat@pat-index-xelp:
- shard-lnl: NOTRUN -> [SKIP][105] ([Intel XE#7590] / [Intel XE#977])
[105]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@xe_pat@pat-index-xelp.html
- shard-bmg: NOTRUN -> [SKIP][106] ([Intel XE#2245] / [Intel XE#7590])
[106]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-8/igt@xe_pat@pat-index-xelp.html
* igt@xe_pat@pt-caching-update-pat-and-pte:
- shard-bmg: [PASS][107] -> [ABORT][108] ([Intel XE#7893] / [Intel XE#8300])
[107]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-2/igt@xe_pat@pt-caching-update-pat-and-pte.html
[108]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-1/igt@xe_pat@pt-caching-update-pat-and-pte.html
* igt@xe_peer2peer@write:
- shard-bmg: NOTRUN -> [SKIP][109] ([Intel XE#2427] / [Intel XE#6953] / [Intel XE#7326] / [Intel XE#7353])
[109]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-2/igt@xe_peer2peer@write.html
- shard-lnl: NOTRUN -> [SKIP][110] ([Intel XE#1061] / [Intel XE#7326] / [Intel XE#7353])
[110]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-7/igt@xe_peer2peer@write.html
* igt@xe_pm@s3-vm-bind-unbind-all:
- shard-lnl: NOTRUN -> [SKIP][111] ([Intel XE#584] / [Intel XE#7369])
[111]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@xe_pm@s3-vm-bind-unbind-all.html
* igt@xe_pm_residency@aspm_link_residency:
- shard-lnl: NOTRUN -> [SKIP][112] ([Intel XE#7271])
[112]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-3/igt@xe_pm_residency@aspm_link_residency.html
* igt@xe_pxp@pxp-stale-bo-exec-post-termination-irq:
- shard-bmg: NOTRUN -> [SKIP][113] ([Intel XE#4733] / [Intel XE#7417])
[113]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-4/igt@xe_pxp@pxp-stale-bo-exec-post-termination-irq.html
* igt@xe_query@multigpu-query-invalid-size:
- shard-bmg: NOTRUN -> [SKIP][114] ([Intel XE#944])
[114]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-6/igt@xe_query@multigpu-query-invalid-size.html
* igt@xe_sriov_flr@flr-twice:
- shard-bmg: [PASS][115] -> [FAIL][116] ([Intel XE#6569])
[115]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-3/igt@xe_sriov_flr@flr-twice.html
[116]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-6/igt@xe_sriov_flr@flr-twice.html
* igt@xe_wedged@wedged-at-any-timeout:
- shard-bmg: NOTRUN -> [DMESG-WARN][117] ([Intel XE#5545])
[117]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-3/igt@xe_wedged@wedged-at-any-timeout.html
#### Possible fixes ####
* igt@kms_ccs@crc-primary-suspend-4-tiled-bmg-ccs:
- shard-bmg: [INCOMPLETE][118] ([Intel XE#7084] / [Intel XE#8150]) -> [PASS][119] +1 other test pass
[118]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-9/igt@kms_ccs@crc-primary-suspend-4-tiled-bmg-ccs.html
[119]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-4/igt@kms_ccs@crc-primary-suspend-4-tiled-bmg-ccs.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-lnl: [INCOMPLETE][120] ([Intel XE#8430]) -> [PASS][121]
[120]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-lnl-3/igt@kms_fbcon_fbt@fbc-suspend.html
[121]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-4/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-absolute-wf_vblank@c-hdmi-a3:
- shard-bmg: [FAIL][122] ([Intel XE#3098]) -> [PASS][123] +1 other test pass
[122]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-10/igt@kms_flip@flip-vs-absolute-wf_vblank@c-hdmi-a3.html
[123]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-7/igt@kms_flip@flip-vs-absolute-wf_vblank@c-hdmi-a3.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1:
- shard-lnl: [FAIL][124] ([Intel XE#301] / [Intel XE#3149]) -> [PASS][125] +1 other test pass
[124]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-lnl-7/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
[125]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-3/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
* igt@kms_hdmi_inject@inject-audio:
- shard-bmg: [SKIP][126] ([Intel XE#7308]) -> [PASS][127]
[126]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-7/igt@kms_hdmi_inject@inject-audio.html
[127]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-6/igt@kms_hdmi_inject@inject-audio.html
* igt@kms_plane_scaling@intel-max-src-size:
- shard-bmg: [SKIP][128] ([Intel XE#2685] / [Intel XE#3307]) -> [PASS][129]
[128]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-8/igt@kms_plane_scaling@intel-max-src-size.html
[129]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-6/igt@kms_plane_scaling@intel-max-src-size.html
* igt@sriov_basic@enable-vfs-autoprobe-off@numvfs-7:
- shard-bmg: [FAIL][130] ([Intel XE#7992]) -> [PASS][131] +27 other tests pass
[130]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-2/igt@sriov_basic@enable-vfs-autoprobe-off@numvfs-7.html
[131]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-1/igt@sriov_basic@enable-vfs-autoprobe-off@numvfs-7.html
* igt@xe_sriov_flr@flr-vf1-clear:
- shard-bmg: [FAIL][132] ([Intel XE#6569]) -> [PASS][133]
[132]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-5/igt@xe_sriov_flr@flr-vf1-clear.html
[133]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-1/igt@xe_sriov_flr@flr-vf1-clear.html
* igt@xe_wedged@wedged-mode-toggle:
- shard-bmg: [ABORT][134] ([Intel XE#8007]) -> [PASS][135]
[134]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-9/igt@xe_wedged@wedged-mode-toggle.html
[135]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-2/igt@xe_wedged@wedged-mode-toggle.html
#### Warnings ####
* igt@kms_bw@linear-tiling-3-displays-target-2560x1440p:
- shard-lnl: [SKIP][136] ([Intel XE#367]) -> [ABORT][137] ([Intel XE#8007])
[136]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-lnl-1/igt@kms_bw@linear-tiling-3-displays-target-2560x1440p.html
[137]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-8/igt@kms_bw@linear-tiling-3-displays-target-2560x1440p.html
- shard-bmg: [SKIP][138] ([Intel XE#367]) -> [ABORT][139] ([Intel XE#8007])
[138]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-7/igt@kms_bw@linear-tiling-3-displays-target-2560x1440p.html
[139]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-2/igt@kms_bw@linear-tiling-3-displays-target-2560x1440p.html
* igt@kms_cursor_legacy@cursorb-vs-flipb-atomic-transitions:
- shard-lnl: [SKIP][140] ([Intel XE#309] / [Intel XE#7343] / [Intel XE#7935]) -> [SKIP][141] ([Intel XE#309] / [Intel XE#7343])
[140]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-lnl-8/igt@kms_cursor_legacy@cursorb-vs-flipb-atomic-transitions.html
[141]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-2/igt@kms_cursor_legacy@cursorb-vs-flipb-atomic-transitions.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt:
- shard-lnl: [ABORT][142] ([Intel XE#8007]) -> [SKIP][143] ([Intel XE#656] / [Intel XE#7905])
[142]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-lnl-5/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt.html
[143]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-2/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt.html
* igt@kms_hdr@brightness-with-hdr:
- shard-bmg: [SKIP][144] ([Intel XE#3374] / [Intel XE#3544]) -> [SKIP][145] ([Intel XE#3544])
[144]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-bmg-2/igt@kms_hdr@brightness-with-hdr.html
[145]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-bmg-1/igt@kms_hdr@brightness-with-hdr.html
* igt@xe_configfs@survivability-mode:
- shard-lnl: [SKIP][146] ([Intel XE#8415]) -> [SKIP][147] ([Intel XE#8428])
[146]: https://intel-gfx-ci.01.org/tree/intel-xe/IGT_8982/shard-lnl-7/igt@xe_configfs@survivability-mode.html
[147]: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/shard-lnl-1/igt@xe_configfs@survivability-mode.html
[Intel XE#1061]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1061
[Intel XE#1124]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1124
[Intel XE#1125]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1125
[Intel XE#1127]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1127
[Intel XE#1178]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1178
[Intel XE#1392]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1392
[Intel XE#1406]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1406
[Intel XE#1407]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1407
[Intel XE#1421]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1421
[Intel XE#1424]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1424
[Intel XE#1428]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1428
[Intel XE#1439]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1439
[Intel XE#1489]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1489
[Intel XE#1503]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1503
[Intel XE#1729]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1729
[Intel XE#2233]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2233
[Intel XE#2234]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2234
[Intel XE#2245]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2245
[Intel XE#2252]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2252
[Intel XE#2286]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2286
[Intel XE#2311]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2311
[Intel XE#2313]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2313
[Intel XE#2320]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2320
[Intel XE#2321]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2321
[Intel XE#2322]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2322
[Intel XE#2325]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2325
[Intel XE#2327]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2327
[Intel XE#2427]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2427
[Intel XE#2685]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2685
[Intel XE#2724]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2724
[Intel XE#2763]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2763
[Intel XE#2850]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2850
[Intel XE#2887]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2887
[Intel XE#2893]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2893
[Intel XE#301]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/301
[Intel XE#309]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/309
[Intel XE#3098]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3098
[Intel XE#3141]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3141
[Intel XE#3149]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3149
[Intel XE#3304]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3304
[Intel XE#3307]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3307
[Intel XE#3321]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3321
[Intel XE#3374]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3374
[Intel XE#3544]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3544
[Intel XE#367]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/367
[Intel XE#373]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/373
[Intel XE#4141]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4141
[Intel XE#4156]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4156
[Intel XE#4227]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4227
[Intel XE#4417]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4417
[Intel XE#4608]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4608
[Intel XE#4609]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4609
[Intel XE#4733]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4733
[Intel XE#5447]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5447
[Intel XE#5545]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5545
[Intel XE#5813]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5813
[Intel XE#584]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/584
[Intel XE#6035]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6035
[Intel XE#610]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/610
[Intel XE#6312]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6312
[Intel XE#6503]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6503
[Intel XE#651]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/651
[Intel XE#6540]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6540
[Intel XE#656]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/656
[Intel XE#6569]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6569
[Intel XE#688]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/688
[Intel XE#6886]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6886
[Intel XE#6912]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6912
[Intel XE#6953]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6953
[Intel XE#6964]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6964
[Intel XE#7061]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7061
[Intel XE#7084]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7084
[Intel XE#7178]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7178
[Intel XE#7271]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7271
[Intel XE#7283]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7283
[Intel XE#7304]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7304
[Intel XE#7308]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7308
[Intel XE#7312]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7312
[Intel XE#7326]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7326
[Intel XE#7343]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7343
[Intel XE#7345]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7345
[Intel XE#7351]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7351
[Intel XE#7353]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7353
[Intel XE#7355]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7355
[Intel XE#7356]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7356
[Intel XE#7358]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7358
[Intel XE#7369]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7369
[Intel XE#7372]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7372
[Intel XE#7374]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7374
[Intel XE#7375]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7375
[Intel XE#7376]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7376
[Intel XE#7383]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7383
[Intel XE#7387]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7387
[Intel XE#7397]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7397
[Intel XE#7417]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7417
[Intel XE#7424]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7424
[Intel XE#7425]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7425
[Intel XE#7445]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7445
[Intel XE#7449]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7449
[Intel XE#7482]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7482
[Intel XE#7571]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7571
[Intel XE#7590]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7590
[Intel XE#7622]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7622
[Intel XE#7636]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7636
[Intel XE#7642]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7642
[Intel XE#7679]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7679
[Intel XE#7760]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7760
[Intel XE#7793]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7793
[Intel XE#7865]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7865
[Intel XE#7893]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7893
[Intel XE#7905]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7905
[Intel XE#7935]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7935
[Intel XE#7992]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7992
[Intel XE#8007]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8007
[Intel XE#8150]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8150
[Intel XE#8174]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8174
[Intel XE#8265]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8265
[Intel XE#8300]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8300
[Intel XE#8303]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8303
[Intel XE#8364]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8364
[Intel XE#8369]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8369
[Intel XE#8374]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8374
[Intel XE#8378]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8378
[Intel XE#8395]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8395
[Intel XE#8396]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8396
[Intel XE#8397]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8397
[Intel XE#8399]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8399
[Intel XE#8415]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8415
[Intel XE#8416]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8416
[Intel XE#8428]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8428
[Intel XE#8430]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/8430
[Intel XE#870]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/870
[Intel XE#944]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/944
[Intel XE#977]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/977
Build changes
-------------
* IGT: IGT_8982 -> IGTPW_15436
* Linux: xe-5292-e7cd62086ec5a70cefb8b8b00964096692bfab36 -> xe-5293-640edd13412b0be5556c337d1dfc2439ba45d4d0
IGTPW_15436: 15436
IGT_8982: 48befce9e6b0c0d371c4812bfff34a61319f68f1 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
xe-5292-e7cd62086ec5a70cefb8b8b00964096692bfab36: e7cd62086ec5a70cefb8b8b00964096692bfab36
xe-5293-640edd13412b0be5556c337d1dfc2439ba45d4d0: 640edd13412b0be5556c337d1dfc2439ba45d4d0
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15436/index.html
[-- Attachment #2: Type: text/html, Size: 52292 bytes --]
^ permalink raw reply
* RE: [PATCH v2 16/28] drm/i915/dp_link_caps: Add helper to get the number of supported link rates
From: Kahola, Mika @ 2026-06-24 8:34 UTC (permalink / raw)
To: Deak, Imre, intel-gfx@lists.freedesktop.org,
intel-xe@lists.freedesktop.org
In-Reply-To: <20260616200849.3534628-17-imre.deak@intel.com>
> -----Original Message-----
> From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of Imre Deak
> Sent: Tuesday, 16 June 2026 23.09
> To: intel-gfx@lists.freedesktop.org; intel-xe@lists.freedesktop.org
> Subject: [PATCH v2 16/28] drm/i915/dp_link_caps: Add helper to get the number of supported link rates
>
> Add intel_dp_link_caps_num_common_rates() to return the number of
> supported link rates tracked by the link_caps module. This prepares for
> tracking these capabilities internally within the link caps module.
>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
> Signed-off-by: Imre Deak <imre.deak@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_dp_link_caps.c | 5 +++++
> drivers/gpu/drm/i915/display/intel_dp_link_caps.h | 1 +
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index f9c3d3561c417..84640c8394534 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1766,7 +1766,7 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
> int link_bpp_x16 =
> intel_dp_output_format_link_bpp_x16(pipe_config->output_format, bpp);
>
> - for (i = 0; i < intel_dp->num_common_rates; i++) {
> + for (i = 0; i < intel_dp_link_caps_num_common_rates(intel_dp->link.caps); i++) {
> link_rate = intel_dp_common_rate(intel_dp, i);
> if (link_rate < limits->min_rate ||
> link_rate > limits->max_rate)
> @@ -1995,7 +1995,7 @@ static int dsc_compute_link_config(struct intel_dp *intel_dp,
> int link_rate, lane_count;
> int i;
>
> - for (i = 0; i < intel_dp->num_common_rates; i++) {
> + for (i = 0; i < intel_dp_link_caps_num_common_rates(intel_dp->link.caps); i++) {
> link_rate = intel_dp_common_rate(intel_dp, i);
> if (link_rate < limits->min_rate || link_rate > limits->max_rate)
> continue;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_caps.c b/drivers/gpu/drm/i915/display/intel_dp_link_caps.c
> index 13f9bfd5d7bad..09b60a0cd6fbb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_caps.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_caps.c
> @@ -67,6 +67,11 @@ int intel_dp_max_common_rate(struct intel_dp *intel_dp)
> return intel_dp_common_rate(intel_dp, intel_dp->num_common_rates - 1);
> }
>
> +int intel_dp_link_caps_num_common_rates(struct intel_dp_link_caps *link_caps)
> +{
> + return link_caps->dp->num_common_rates;
> +}
> +
> void intel_dp_link_caps_print_common_rates(struct intel_dp_link_caps *link_caps)
> {
> struct intel_dp *intel_dp = link_caps->dp;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_caps.h b/drivers/gpu/drm/i915/display/intel_dp_link_caps.h
> index 7333df6b82f97..3413f6f760453 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_caps.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_caps.h
> @@ -15,6 +15,7 @@ int intel_dp_common_len_rate_limit(const struct intel_dp *intel_dp,
> int max_rate);
> int intel_dp_common_rate(struct intel_dp *intel_dp, int index);
> int intel_dp_max_common_rate(struct intel_dp *intel_dp);
> +int intel_dp_link_caps_num_common_rates(struct intel_dp_link_caps *link_caps);
>
> void intel_dp_link_caps_print_common_rates(struct intel_dp_link_caps *link_caps);
>
> --
> 2.49.1
^ permalink raw reply
* [PATCH] fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()
From: w15303746062 @ 2026-06-24 8:33 UTC (permalink / raw)
To: deller, tzimmermann, simona
Cc: syoshida, dri-devel, linux-fbdev, linux-kernel, Mingyu Wang,
stable
From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
When fbcon_do_set_font() fails (e.g., due to a memory allocation failure
inside vc_resize() under heavy memory pressure), it jumps to the `err_out`
label to roll back the console state. However, the current rollback logic
forgets to restore the `hi_font` state, leading to a severe state machine
corruption.
Earlier in the function, `set_vc_hi_font()` might be called to change
`vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()`
subsequently fails, the `err_out` path restores `vc_font.charcount`
but entirely skips rolling back the `vc_hi_font_mask` and the screen
buffer.
This mismatch leaves the terminal in a desynchronized state. Because
`vc_hi_font_mask` remains set, the VT subsystem will still accept
character indices greater than 255 from userspace and write them to the
screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will
then use these inflated indices to access the reverted, 256-character
font array, leading to a deterministic out-of-bounds read and potential
kernel memory disclosure.
Fix this by adding the missing rollback logic for the `hi_font` mask
and screen buffer in the error path.
Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed")
Cc: stable@vger.kernel.org
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
---
drivers/video/fbdev/core/fbcon.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 9077d3b99357..5880ab9f3cde 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2405,6 +2405,7 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
int resize, ret, old_width, old_height, old_charcount;
font_data_t *old_fontdata = p->fontdata;
const u8 *old_data = vc->vc_font.data;
+ int old_hi_font_mask = vc->vc_hi_font_mask;
font_data_get(data);
@@ -2451,6 +2452,12 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
vc->vc_font.height = old_height;
vc->vc_font.charcount = old_charcount;
+ /* Restore the hi_font state and screen buffer */
+ if (old_hi_font_mask && !vc->vc_hi_font_mask)
+ set_vc_hi_font(vc, true);
+ else if (!old_hi_font_mask && vc->vc_hi_font_mask)
+ set_vc_hi_font(vc, false);
+
font_data_put(data);
return ret;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH ath-next] wifi: ath12k: use %u for unsigned variables in QMI debug logs
From: Rameshkumar Sundaram @ 2026-06-24 8:33 UTC (permalink / raw)
To: Raj Kumar Bhagat, Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260623-qmi-debug-log-v1-1-79471aa8b898@oss.qualcomm.com>
On 6/23/2026 9:34 AM, Raj Kumar Bhagat wrote:
> Replace incorrect %d format specifiers with %u for unsigned variables
> in qmi.c debug messages. Also add missing trailing '\n' in log messages
> to ensure proper termination. No functional change intended.
>
> Tested-on: Compile tested only.
>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] iio: imu: inv_icm45600: Use I2C match data
From: Jean-Baptiste Maneyrol @ 2026-06-24 8:33 UTC (permalink / raw)
To: Pengpeng Hou, Remi Buisson, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260624053823.73969-1-pengpeng@iscas.ac.cn>
>From: Pengpeng Hou <pengpeng@iscas.ac.cn>
>Sent: Wednesday, June 24, 2026 07:38
>To: Remi Buisson; Jonathan Cameron; David Lechner; Nuno Sá; Andy Shevchenko
>Cc: linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org; Pengpeng Hou
>Subject: [PATCH] iio: imu: inv_icm45600: Use I2C match data
>
>The I2C driver provides chip_info through both the OF match table and the I2C id table, but probe reads it with device_get_match_data(). That misses id-table driver_data for non-firmware I2C matches and can reject a supported device with -ENODEV.
>ZjQcmQRYFpfptBannerStart
>This Message Is From an Untrusted Sender
>You have not previously corresponded with this sender.
>
>ZjQcmQRYFpfptBannerEnd
>
>The I2C driver provides chip_info through both the OF match table and
>the I2C id table, but probe reads it with device_get_match_data(). That
>misses id-table driver_data for non-firmware I2C matches and can reject
>a supported device with -ENODEV.
>
>Use i2c_get_match_data() so the id-table chip_info is used when firmware
>match data is not present.
>
>Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
>---
> drivers/iio/imu/inv_icm45600/inv_icm45600_i2c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/iio/imu/inv_icm45600/inv_icm45600_i2c.c b/drivers/iio/imu/inv_icm45600/inv_icm45600_i2c.c
>index 5ebc18121a11..c65e5501eee7 100644
>--- a/drivers/iio/imu/inv_icm45600/inv_icm45600_i2c.c
>+++ b/drivers/iio/imu/inv_icm45600/inv_icm45600_i2c.c
>@@ -23,7 +23,7 @@ static int inv_icm45600_probe(struct i2c_client *client)
> if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_I2C_BLOCK))
> return -ENODEV;
>
>- chip_info = device_get_match_data(&client->dev);
>+ chip_info = i2c_get_match_data(client);
> if (!chip_info)
> return -ENODEV;
>
>--
>2.50.1 (Apple Git-155)
>
Hello Pengpeng,
good stuff, thanks for your patch.
Reviewed-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Thanks,
JB
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.