April 2025 - Linux-stable-mirror

[PATCH 07/16] drm/amd/display: Add HP Probook 445 and 465 to the quirk list for eDP on DP1

by Roman.Li＠amd.com

From: Mario Limonciello <mario.limonciello(a)amd.com> [Why] HP Probook 445 and 465 has DP0 and DP1 swapped. [How] Add HP Probook 445 and 465 to DP0/DP1 swap quirk list. Cc: stable(a)vger.kernel.org Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3995 Reviewed-by: Alex Hung <alex.hung(a)amd.com> Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Roman Li <roman.li(a)amd.com> Tested-by: Anson Tsao <anson.tsao(a)amd.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 7cfb6fb89fca..b2bb2f92db00 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1767,6 +1767,20 @@ static const struct dmi_system_id dmi_quirk_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 665 16 inch G11 Notebook PC"), }, }, + { + .callback = edp0_on_dp1_callback, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "HP"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook 445 14 inch G11 Notebook PC"), + }, + }, + { + .callback = edp0_on_dp1_callback, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "HP"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook 465 16 inch G11 Notebook PC"), + }, + }, {} /* TODO: refactor this from a fixed table to a dynamic option */ }; -- 2.34.1

18 hours, 38 minutes

1
0
0 0

[PATCH 1/1] virtio_console: fix missing byte order handling for cols and rows

by Halil Pasic

As per virtio spec the fields cols and rows are specified as little endian. Although there is no legacy interface requirement that would state that cols and rows need to be handled as native endian when legacy interface is used, unlike for the fields of the adjacent struct virtio_console_control, I decided to err on the side of caution based on some non-conclusive virtio spec repo archaeology and opt for using virtio16_to_cpu() much like for virtio_console_control.event. Strictly by the letter of the spec virtio_le_to_cpu() would have been sufficient. But when the legacy interface is not used, it boils down to the same. And when using the legacy interface, the device formatting these as little endian when the guest is big endian would surprise me more than it using guest native byte order (which would make it compatible with the current implementation). Nevertheless somebody trying to implement the spec following it to the letter could end up forcing little endian byte order when the legacy interface is in use. So IMHO this ultimately needs a judgement call by the maintainers. Fixes: 8345adbf96fc1 ("virtio: console: Accept console size along with resize control message") Signed-off-by: Halil Pasic <pasic(a)linux.ibm.com> Cc: stable(a)vger.kernel.org # v2.6.35+ --- @Michael: I think it would be nice to add a clarification on the byte order to be used for cols and rows when the legacy interface is used to the spec, regardless of what we decide the right byte order is. If it is native endian that shall be stated much like it is stated for virtio_console_control. If it is little endian, I would like to add a sentence that states that unlike for the fields of virtio_console_control the byte order of the fields of struct virtio_console_resize is little endian also when the legacy interface is used. @Maximilian: Would you mind giving this a spin with your implementation on the device side of things in QEMU? --- drivers/char/virtio_console.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 18f92dd44d45..fc698e2b1da1 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1579,8 +1579,8 @@ static void handle_control_message(struct virtio_device *vdev, break; case VIRTIO_CONSOLE_RESIZE: { struct { - __u16 rows; - __u16 cols; + __virtio16 rows; + __virtio16 cols; } size; if (!is_console_port(port)) @@ -1588,7 +1588,8 @@ static void handle_control_message(struct virtio_device *vdev, memcpy(&size, buf->buf + buf->offset + sizeof(*cpkt), sizeof(size)); - set_console_size(port, size.rows, size.cols); + set_console_size(port, virtio16_to_cpu(vdev, size.rows), + virtio16_to_cpu(vdev, size.cols)); port->cons.hvc->irq_requested = 1; resize_console(port); base-commit: b3ee1e4609512dfff642a96b34d7e5dfcdc92d05 -- 2.45.2

19 hours, 11 minutes

3
3
0 0

[PATCH v6 0/4] samsung: pinctrl: Add support for eint_fltcon_offset and filter selection on gs101

by Peter Griffin

Hi folks, This series fixes support for correctly saving and restoring fltcon0 and fltcon1 registers on gs101 for non-alive banks where the fltcon register offset is not at a fixed offset (unlike previous SoCs). This is done by adding a eint_fltcon_offset and providing GS101 specific pin macros that take an additional parameter (similar to how exynosautov920 handles it's eint_con_offset). Additionally the SoC specific suspend and resume callbacks are re-factored so that each SoC variant has it's own callback containing the peculiarities for that SoC. Finally support for filter selection on alive banks is added, this is currently only enabled for gs101. The code path can be excercised using `echo mem > /sys/power/state` regards, Peter To: Krzysztof Kozlowski <krzk(a)kernel.org> To: Sylwester Nawrocki <s.nawrocki(a)samsung.com> To: Alim Akhtar <alim.akhtar(a)samsung.com> To: Linus Walleij <linus.walleij(a)linaro.org> Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-samsung-soc(a)vger.kernel.org Cc: linux-gpio(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: andre.draszik(a)linaro.org Cc: tudor.ambarus(a)linaro.org Cc: willmcvicker(a)google.com Cc: semen.protsenko(a)linaro.org Cc: kernel-team(a)android.com Cc: jaewon02.kim(a)samsung.com Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org> --- Changes in v6: - Make drvdata->suspend/resume symmetrically reversed (Krzysztof) - rebase on linux-next - Link to v5: https://lore.kernel.org/r/20250312-pinctrl-fltcon-suspend-v5-0-d98d5b271242… Changes in v5: - Split drvdata suspend & resume callbacks into a dedicated patch (Krzysztof) - Add comment about stable dependency (Krzysztof) - Add back in {} braces (Krzysztof) - Link to v4: https://lore.kernel.org/r/20250307-pinctrl-fltcon-suspend-v4-0-2d775e486036… Changes in v4: - save->eint_fltcon1 is an argument to pr_debug(), not readl() change alignment accordingly (Andre) - Link to v3: https://lore.kernel.org/r/20250306-pinctrl-fltcon-suspend-v3-0-f9ab4ff6a24e… Changes in v3: - Ensure EXYNOS_FLTCON_DIGITAL bit is cleared (Andre) - Make it obvious that exynos_eint_set_filter() is conditional on bank type (Andre) - Make it obvious exynos_set_wakeup() is conditional on bank type (Andre) - Align style where the '+' is placed first (Andre) - Remove unnecessary braces (Andre) - Link to v2: https://lore.kernel.org/r/20250301-pinctrl-fltcon-suspend-v2-0-a7eef9bb443b… Changes in v2: - Remove eint_flt_selectable bool as it can be deduced from EINT_TYPE_WKUP (Peter) - Move filter config register comment to header file (Andre) - Rename EXYNOS_FLTCON_DELAY to EXYNOS_FLTCON_ANALOG (Andre) - Remove misleading old comment (Andre) - Refactor exynos_eint_update_flt_reg() into a loop (Andre) - Split refactor of suspend/resume callbacks & gs101 parts into separate patches (Andre) - Link to v1: https://lore.kernel.org/r/20250120-pinctrl-fltcon-suspend-v1-0-e77900b2a854… --- Peter Griffin (4): pinctrl: samsung: refactor drvdata suspend & resume callbacks pinctrl: samsung: add dedicated SoC eint suspend/resume callbacks pinctrl: samsung: add gs101 specific eint suspend/resume callbacks pinctrl: samsung: Add filter selection support for alive bank on gs101 drivers/pinctrl/samsung/pinctrl-exynos-arm64.c | 52 ++--- drivers/pinctrl/samsung/pinctrl-exynos.c | 294 +++++++++++++++---------- drivers/pinctrl/samsung/pinctrl-exynos.h | 28 ++- drivers/pinctrl/samsung/pinctrl-samsung.c | 21 +- drivers/pinctrl/samsung/pinctrl-samsung.h | 8 +- 5 files changed, 252 insertions(+), 151 deletions(-) --- base-commit: cd37a617b4bfb43f84dbbf8058317b487f5203ae change-id: 20250120-pinctrl-fltcon-suspend-2333a137c4d4 Best regards, -- Peter Griffin <peter.griffin(a)linaro.org>

19 hours, 33 minutes

1
1
0 0

[PATCH v6 4/4] ring-buffer: Use flush_kernel_vmap_range() over flush_dcache_folio()

by Steven Rostedt

From: Steven Rostedt <rostedt(a)goodmis.org> Some architectures do not have data cache coherency between user and kernel space. For these architectures, the cache needs to be flushed on both the kernel and user addresses so that user space can see the updates the kernel has made. Instead of using flush_dcache_folio() and playing with virt_to_folio() within the call to that function, use flush_kernel_vmap_range() which takes the virtual address and does the work for those architectures that need it. This also fixes a bug where the flush of the reader page only flushed one page. If the sub-buffer order is 1 or more, where the sub-buffer size would be greater than a page, it would miss the rest of the sub-buffer content, as the "reader page" is not just a page, but the size of a sub-buffer. Link: https://lore.kernel.org/all/CAG48ez3w0my4Rwttbc5tEbNsme6tc0mrSN95thjXUFaJ3a… Cc: stable(a)vger.kernel.org Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functions"); Suggested-by: Jann Horn <jannh(a)google.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/ring_buffer.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index f25966b3a1fc..d4b0f7b55cce 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -6016,7 +6016,7 @@ static void rb_update_meta_page(struct ring_buffer_per_cpu *cpu_buffer) meta->read = cpu_buffer->read; /* Some archs do not have data cache coherency between kernel and user-space */ - flush_dcache_folio(virt_to_folio(cpu_buffer->meta_page)); + flush_kernel_vmap_range(cpu_buffer->meta_page, PAGE_SIZE); } static void @@ -7319,7 +7319,8 @@ int ring_buffer_map_get_reader(struct trace_buffer *buffer, int cpu) out: /* Some archs do not have data cache coherency between kernel and user-space */ - flush_dcache_folio(virt_to_folio(cpu_buffer->reader_page->page)); + flush_kernel_vmap_range(cpu_buffer->reader_page->page, + buffer->subbuf_size + BUF_PAGE_HDR_SIZE); rb_update_meta_page(cpu_buffer); -- 2.47.2

20 hours, 2 minutes

1
0
0 0

[PATCH] platform/x86: thinkpad-acpi: Add error handling for tpacpi_check_quirks

by Wentao Liang

In tpacpi_battery_init(), the return value of tpacpi_check_quirks() needs to be checked. The battery should not be hooked if there is no matched battery information in quirk table. Add an error check and return -ENODEV immediately if the device fail the check. Fixes: 1a32ebb26ba9 ("platform/x86: thinkpad_acpi: Support battery quirk") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/platform/x86/thinkpad_acpi.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index 2cfb2ac3f465..a3227f60aa43 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -9969,11 +9969,15 @@ static const struct tpacpi_quirk battery_quirk_table[] __initconst = { static int __init tpacpi_battery_init(struct ibm_init_struct *ibm) { + unsigned long r; + memset(&battery_info, 0, sizeof(battery_info)); - tp_features.battery_force_primary = tpacpi_check_quirks( + r = tp_features.battery_force_primary = tpacpi_check_quirks( battery_quirk_table, ARRAY_SIZE(battery_quirk_table)); + if (!r) + return -ENODEV; battery_hook_register(&battery_hook); return 0; -- 2.42.0.windows.2

20 hours, 13 minutes

1
0
0 0

[PATCH] bcachefs: Add error handling for zlib_deflateInit2()

by Wentao Liang

In attempt_compress(), the return value of zlib_deflateInit2() needs to be checked. A proper implementation can be found in pstore_compress(). Add an error check and return 0 immediately if the initialzation fails. Fixes: 986e9842fb68 ("bcachefs: Compression levels") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- fs/bcachefs/compress.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/bcachefs/compress.c b/fs/bcachefs/compress.c index f99ff1819597..5af37c40cef0 100644 --- a/fs/bcachefs/compress.c +++ b/fs/bcachefs/compress.c @@ -365,13 +365,14 @@ static int attempt_compress(struct bch_fs *c, }; zlib_set_workspace(&strm, workspace); - zlib_deflateInit2(&strm, + if (zlib_deflateInit2(&strm, compression.level ? clamp_t(unsigned, compression.level, Z_BEST_SPEED, Z_BEST_COMPRESSION) : Z_DEFAULT_COMPRESSION, Z_DEFLATED, -MAX_WBITS, DEF_MEM_LEVEL, - Z_DEFAULT_STRATEGY); + Z_DEFAULT_STRATEGY) != Z_OK) + return 0; if (zlib_deflate(&strm, Z_FINISH) != Z_STREAM_END) return 0; -- 2.42.0.windows.2

20 hours, 35 minutes

2
1
0 0

[PATCH v3] sched/rt: Fix race in push_rt_task

by Harshit Agarwal

Overview ======== When a CPU chooses to call push_rt_task and picks a task to push to another CPU's runqueue then it will call find_lock_lowest_rq method which would take a double lock on both CPUs' runqueues. If one of the locks aren't readily available, it may lead to dropping the current runqueue lock and reacquiring both the locks at once. During this window it is possible that the task is already migrated and is running on some other CPU. These cases are already handled. However, if the task is migrated and has already been executed and another CPU is now trying to wake it up (ttwu) such that it is queued again on the runqeue (on_rq is 1) and also if the task was run by the same CPU, then the current checks will pass even though the task was migrated out and is no longer in the pushable tasks list. Crashes ======= This bug resulted in quite a few flavors of crashes triggering kernel panics with various crash signatures such as assert failures, page faults, null pointer dereferences, and queue corruption errors all coming from scheduler itself. Some of the crashes: -> kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx >= MAX_RT_PRIO) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? pick_next_task_rt+0x6e/0x1d0 ? do_error_trap+0x64/0xa0 ? pick_next_task_rt+0x6e/0x1d0 ? exc_invalid_op+0x4c/0x60 ? pick_next_task_rt+0x6e/0x1d0 ? asm_exc_invalid_op+0x12/0x20 ? pick_next_task_rt+0x6e/0x1d0 __schedule+0x5cb/0x790 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb -> BUG: kernel NULL pointer dereference, address: 00000000000000c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? __warn+0x8a/0xe0 ? exc_page_fault+0x3d6/0x520 ? asm_exc_page_fault+0x1e/0x30 ? pick_next_task_rt+0xb5/0x1d0 ? pick_next_task_rt+0x8c/0x1d0 __schedule+0x583/0x7e0 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb -> BUG: unable to handle page fault for address: ffff9464daea5900 kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq->cpu != task_cpu(p)) -> kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq->nr_running) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? dequeue_top_rt_rq+0xa2/0xb0 ? do_error_trap+0x64/0xa0 ? dequeue_top_rt_rq+0xa2/0xb0 ? exc_invalid_op+0x4c/0x60 ? dequeue_top_rt_rq+0xa2/0xb0 ? asm_exc_invalid_op+0x12/0x20 ? dequeue_top_rt_rq+0xa2/0xb0 dequeue_rt_entity+0x1f/0x70 dequeue_task_rt+0x2d/0x70 __schedule+0x1a8/0x7e0 ? blk_finish_plug+0x25/0x40 schedule+0x3c/0xb0 futex_wait_queue_me+0xb6/0x120 futex_wait+0xd9/0x240 do_futex+0x344/0xa90 ? get_mm_exe_file+0x30/0x60 ? audit_exe_compare+0x58/0x70 ? audit_filter_rules.constprop.26+0x65e/0x1220 __x64_sys_futex+0x148/0x1f0 do_syscall_64+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x62/0xc7 -> BUG: unable to handle page fault for address: ffff8cf3608bc2c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? spurious_kernel_fault+0x171/0x1c0 ? exc_page_fault+0x3b6/0x520 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? asm_exc_page_fault+0x1e/0x30 ? _cond_resched+0x15/0x30 ? futex_wait_queue_me+0xc8/0x120 ? futex_wait+0xd9/0x240 ? try_to_wake_up+0x1b8/0x490 ? futex_wake+0x78/0x160 ? do_futex+0xcd/0xa90 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? plist_del+0x6a/0xd0 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? dequeue_pushable_task+0x20/0x70 ? __schedule+0x382/0x7e0 ? asm_sysvec_reschedule_ipi+0xa/0x20 ? schedule+0x3c/0xb0 ? exit_to_user_mode_prepare+0x9e/0x150 ? irqentry_exit_to_user_mode+0x5/0x30 ? asm_sysvec_reschedule_ipi+0x12/0x20 Above are some of the common examples of the crashes that were observed due to this issue. Details ======= Let's look at the following scenario to understand this race. 1) CPU A enters push_rt_task a) CPU A has chosen next_task = task p. b) CPU A calls find_lock_lowest_rq(Task p, CPU Z’s rq). c) CPU A identifies CPU X as a destination CPU (X < Z). d) CPU A enters double_lock_balance(CPU Z’s rq, CPU X’s rq). e) Since X is lower than Z, CPU A unlocks CPU Z’s rq. Someone else has locked CPU X’s rq, and thus, CPU A must wait. 2) At CPU Z a) Previous task has completed execution and thus, CPU Z enters schedule, locks its own rq after CPU A releases it. b) CPU Z dequeues previous task and begins executing task p. c) CPU Z unlocks its rq. d) Task p yields the CPU (ex. by doing IO or waiting to acquire a lock) which triggers the schedule function on CPU Z. e) CPU Z enters schedule again, locks its own rq, and dequeues task p. f) As part of dequeue, it sets p.on_rq = 0 and unlocks its rq. 3) At CPU B a) CPU B enters try_to_wake_up with input task p. b) Since CPU Z dequeued task p, p.on_rq = 0, and CPU B updates B.state = WAKING. c) CPU B via select_task_rq determines CPU Y as the target CPU. 4) The race a) CPU A acquires CPU X’s lock and relocks CPU Z. b) CPU A reads task p.cpu = Z and incorrectly concludes task p is still on CPU Z. c) CPU A failed to notice task p had been dequeued from CPU Z while CPU A was waiting for locks in double_lock_balance. If CPU A knew that task p had been dequeued, it would return NULL forcing push_rt_task to give up the task p's migration. d) CPU B updates task p.cpu = Y and calls ttwu_queue. e) CPU B locks Ys rq. CPU B enqueues task p onto Y and sets task p.on_rq = 1. f) CPU B unlocks CPU Y, triggering memory synchronization. g) CPU A reads task p.on_rq = 1, cementing its assumption that task p has not migrated. h) CPU A decides to migrate p to CPU X. This leads to A dequeuing p from Y's queue and various crashes down the line. Solution ======== The solution here is fairly simple. After obtaining the lock (at 4a), the check is enhanced to make sure that the task is still at the head of the pushable tasks list. If not, then it is anyway not suitable for being pushed out. Testing ======= The fix is tested on a cluster of 3 nodes, where the panics due to this are hit every couple of days. A fix similar to this was deployed on such cluster and was stable for more than 30 days. Co-developed-by: Jon Kohler <jon(a)nutanix.com> Signed-off-by: Jon Kohler <jon(a)nutanix.com> Co-developed-by: Gauri Patwardhan <gauri.patwardhan(a)nutanix.com> Signed-off-by: Gauri Patwardhan <gauri.patwardhan(a)nutanix.com> Co-developed-by: Rahul Chunduru <rahul.chunduru(a)nutanix.com> Signed-off-by: Rahul Chunduru <rahul.chunduru(a)nutanix.com> Signed-off-by: Harshit Agarwal <harshit(a)nutanix.com> Tested-by: Will Ton <william.ton(a)nutanix.com> Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Cc: stable(a)vger.kernel.org --- Changes in v2: - As per Steve's suggestion, removed some checks that are done after obtaining the lock that are no longer needed with the addition of new check. - Moved up is_migration_disabled check. - Link to v1: https://lore.kernel.org/lkml/20250211054646.23987-1-harshit@nutanix.com/ Changes in v3: - Updated commit message to add stable maintainers and reviewed-by tag. - Link to v2: https://lore.kernel.org/lkml/20250214170844.201692-1-harshit@nutanix.com/ --- kernel/sched/rt.c | 54 +++++++++++++++++++++++------------------------ 1 file changed, 26 insertions(+), 28 deletions(-) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 4b8e33c615b1..4762dd3f50c5 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -1885,6 +1885,27 @@ static int find_lowest_rq(struct task_struct *task) return -1; } +static struct task_struct *pick_next_pushable_task(struct rq *rq) +{ + struct task_struct *p; + + if (!has_pushable_tasks(rq)) + return NULL; + + p = plist_first_entry(&rq->rt.pushable_tasks, + struct task_struct, pushable_tasks); + + BUG_ON(rq->cpu != task_cpu(p)); + BUG_ON(task_current(rq, p)); + BUG_ON(task_current_donor(rq, p)); + BUG_ON(p->nr_cpus_allowed <= 1); + + BUG_ON(!task_on_rq_queued(p)); + BUG_ON(!rt_task(p)); + + return p; +} + /* Will lock the rq it finds */ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) { @@ -1915,18 +1936,16 @@ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) /* * We had to unlock the run queue. In * the mean time, task could have - * migrated already or had its affinity changed. - * Also make sure that it wasn't scheduled on its rq. + * migrated already or had its affinity changed, + * therefore check if the task is still at the + * head of the pushable tasks list. * It is possible the task was scheduled, set * "migrate_disabled" and then got preempted, so we must * check the task migration disable flag here too. */ - if (unlikely(task_rq(task) != rq || + if (unlikely(is_migration_disabled(task) || !cpumask_test_cpu(lowest_rq->cpu, &task->cpus_mask) || - task_on_cpu(rq, task) || - !rt_task(task) || - is_migration_disabled(task) || - !task_on_rq_queued(task))) { + task != pick_next_pushable_task(rq))) { double_unlock_balance(rq, lowest_rq); lowest_rq = NULL; @@ -1946,27 +1965,6 @@ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) return lowest_rq; } -static struct task_struct *pick_next_pushable_task(struct rq *rq) -{ - struct task_struct *p; - - if (!has_pushable_tasks(rq)) - return NULL; - - p = plist_first_entry(&rq->rt.pushable_tasks, - struct task_struct, pushable_tasks); - - BUG_ON(rq->cpu != task_cpu(p)); - BUG_ON(task_current(rq, p)); - BUG_ON(task_current_donor(rq, p)); - BUG_ON(p->nr_cpus_allowed <= 1); - - BUG_ON(!task_on_rq_queued(p)); - BUG_ON(!rt_task(p)); - - return p; -} - /* * If the current CPU has more than one RT task, see if the non * running task can migrate over to a CPU that is running a task -- 2.22.3

22 hours, 4 minutes

5
10
0 0

[PATCH] usb: renesas_usbhs: Add error handling for usbhsf_fifo_select()

by Wentao Liang

In usbhsf_dcp_data_stage_prepare_pop(), the return value of usbhsf_fifo_select() needs to be checked. A proper implementation can be found in usbhsf_dma_try_pop_with_rx_irq(). Add an error check and jump to PIO pop when FIFO selection fails. Fixes: 9e74d601de8a ("usb: gadget: renesas_usbhs: add data/status stage handler") Cc: stable(a)vger.kernel.org # v3.2+ Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/usb/renesas_usbhs/fifo.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c index 10607e273879..6cc07ab4782d 100644 --- a/drivers/usb/renesas_usbhs/fifo.c +++ b/drivers/usb/renesas_usbhs/fifo.c @@ -466,6 +466,7 @@ static int usbhsf_dcp_data_stage_prepare_pop(struct usbhs_pkt *pkt, struct usbhs_pipe *pipe = pkt->pipe; struct usbhs_priv *priv = usbhs_pipe_to_priv(pipe); struct usbhs_fifo *fifo = usbhsf_get_cfifo(priv); + int ret; if (usbhs_pipe_is_busy(pipe)) return 0; @@ -480,10 +481,14 @@ static int usbhsf_dcp_data_stage_prepare_pop(struct usbhs_pkt *pkt, usbhs_pipe_sequence_data1(pipe); /* DATA1 */ - usbhsf_fifo_select(pipe, fifo, 0); + ret = usbhsf_fifo_select(pipe, fifo, 0); + if (ret < 0) + goto usbhsf_pio_prepare_pop; + usbhsf_fifo_clear(pipe, fifo); usbhsf_fifo_unselect(pipe, fifo); +usbhsf_pio_prepare_pop: /* * change handler to PIO pop */ -- 2.42.0.windows.2

22 hours, 6 minutes

1
0
0 0

[PATCH] nilfs2: Add pointer check for nilfs_direct_propagate()

by Wentao Liang

In nilfs_direct_propagate(), the printer get from nilfs_direct_get_ptr() need to be checked to ensure it is not an invalid pointer. A proper implementation can be found in nilfs_direct_delete(). Add a value check and return -ENOENT when it is an invalid pointer. Fixes: 10ff885ba6f5 ("nilfs2: get rid of nilfs_direct uses") Cc: stable(a)vger.kernel.org # v2.6+ Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- fs/nilfs2/direct.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/nilfs2/direct.c b/fs/nilfs2/direct.c index 893ab36824cc..ff1c9fe72bec 100644 --- a/fs/nilfs2/direct.c +++ b/fs/nilfs2/direct.c @@ -273,6 +273,9 @@ static int nilfs_direct_propagate(struct nilfs_bmap *bmap, dat = nilfs_bmap_get_dat(bmap); key = nilfs_bmap_data_get_key(bmap, bh); ptr = nilfs_direct_get_ptr(bmap, key); + if (ptr == NILFS_BMAP_INVALID_PTR) + return -ENOENT; + if (!buffer_nilfs_volatile(bh)) { oldreq.pr_entry_nr = ptr; newreq.pr_entry_nr = ptr; -- 2.42.0.windows.2

23 hours, 20 minutes

2
1
0 0

[PATCH net] gve: handle overflow when reporting TX consumed descriptors

by Harshitha Ramamurthy

From: Joshua Washington <joshwash(a)google.com> When the tx tail is less than the head (in cases of wraparound), the TX consumed descriptor statistic in DQ will be reported as UINT32_MAX - head + tail, which is incorrect. Mask the difference of head and tail according to the ring size when reporting the statistic. Cc: stable(a)vger.kernel.org Fixes: 2c9198356d56 ("gve: Add consumed counts to ethtool stats") Signed-off-by: Joshua Washington <joshwash(a)google.com> Signed-off-by: Harshitha Ramamurthy <hramamurthy(a)google.com> --- drivers/net/ethernet/google/gve/gve_ethtool.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/google/gve/gve_ethtool.c b/drivers/net/ethernet/google/gve/gve_ethtool.c index 31a21ccf4863..4dea1fdce748 100644 --- a/drivers/net/ethernet/google/gve/gve_ethtool.c +++ b/drivers/net/ethernet/google/gve/gve_ethtool.c @@ -392,7 +392,9 @@ gve_get_ethtool_stats(struct net_device *netdev, */ data[i++] = 0; data[i++] = 0; - data[i++] = tx->dqo_tx.tail - tx->dqo_tx.head; + data[i++] = + (tx->dqo_tx.tail - tx->dqo_tx.head) & + tx->mask; } do { start = -- 2.49.0.472.ge94155a9ec-goog

1 day

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2025