March 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] arm64: efi: Make efi_rt_lock a raw_spinlock" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 0e68b5517d3767562889f1d83fdb828c26adb24f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '167818210919025(a)kroah.com' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 0e68b5517d37 ("arm64: efi: Make efi_rt_lock a raw_spinlock") ff7a167961d1 ("arm64: efi: Execute runtime services from a dedicated stack") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0e68b5517d3767562889f1d83fdb828c26adb24f Mon Sep 17 00:00:00 2001 From: Pierre Gondois <pierre.gondois(a)arm.com> Date: Wed, 15 Feb 2023 17:10:47 +0100 Subject: [PATCH] arm64: efi: Make efi_rt_lock a raw_spinlock Running a rt-kernel base on 6.2.0-rc3-rt1 on an Ampere Altra outputs the following: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: kworker/u320:0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by kworker/u320:0/9: #0: ffff3fff8c27d128 ((wq_completion)efi_rts_wq){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #1: ffff80000861bdd0 ((work_completion)(&efi_rts_work.work)){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #2: ffffdf7e1ed3e460 (efi_rt_lock){+.+.}-{3:3}, at: efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) Preemption disabled at: efi_virtmap_load (./arch/arm64/include/asm/mmu_context.h:248) CPU: 0 PID: 9 Comm: kworker/u320:0 Tainted: G W 6.2.0-rc3-rt1 Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18 Workqueue: efi_rts_wq efi_call_rts Call trace: dump_backtrace (arch/arm64/kernel/stacktrace.c:158) show_stack (arch/arm64/kernel/stacktrace.c:165) dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) dump_stack (lib/dump_stack.c:114) __might_resched (kernel/sched/core.c:10134) rt_spin_lock (kernel/locking/rtmutex.c:1769 (discriminator 4)) efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) [...] This seems to come from commit ff7a167961d1 ("arm64: efi: Execute runtime services from a dedicated stack") which adds a spinlock. This spinlock is taken through: efi_call_rts() \-efi_call_virt() \-efi_call_virt_pointer() \-arch_efi_call_virt_setup() Make 'efi_rt_lock' a raw_spinlock to avoid being preempted. [ardb: The EFI runtime services are called with a different set of translation tables, and are permitted to use the SIMD registers. The context switch code preserves/restores neither, and so EFI calls must be made with preemption disabled, rather than only disabling migration.] Fixes: ff7a167961d1 ("arm64: efi: Execute runtime services from a dedicated stack") Signed-off-by: Pierre Gondois <pierre.gondois(a)arm.com> Cc: <stable(a)vger.kernel.org> # v6.1+ Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h index 5d47d429672b..1b81dd5554cb 100644 --- a/arch/arm64/include/asm/efi.h +++ b/arch/arm64/include/asm/efi.h @@ -34,7 +34,7 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md, ({ \ efi_virtmap_load(); \ __efi_fpsimd_begin(); \ - spin_lock(&efi_rt_lock); \ + raw_spin_lock(&efi_rt_lock); \ }) #undef arch_efi_call_virt @@ -43,12 +43,12 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md, #define arch_efi_call_virt_teardown() \ ({ \ - spin_unlock(&efi_rt_lock); \ + raw_spin_unlock(&efi_rt_lock); \ __efi_fpsimd_end(); \ efi_virtmap_unload(); \ }) -extern spinlock_t efi_rt_lock; +extern raw_spinlock_t efi_rt_lock; efi_status_t __efi_rt_asm_wrapper(void *, const char *, ...); #define ARCH_EFI_IRQ_FLAGS_MASK (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT) diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c index db9007cae93d..b8108d56ca2d 100644 --- a/arch/arm64/kernel/efi.c +++ b/arch/arm64/kernel/efi.c @@ -157,7 +157,7 @@ asmlinkage efi_status_t efi_handle_corrupted_x18(efi_status_t s, const char *f) return s; } -DEFINE_SPINLOCK(efi_rt_lock); +DEFINE_RAW_SPINLOCK(efi_rt_lock); asmlinkage u64 *efi_rt_stack_top __ro_after_init;

2 years, 1 month

3
2
0 0

Please apply commit 06e472acf964 ("scsi: mpt3sas: Remove usage of dma_get_required_mask() API") to stable series

by Salvatore Bonaccorso

Dear stable maintainers, Please backport the aboove commit to the stable series. Note, though as a first step it just applies cleanly to 6.1.y. Due to 9df650963bf6 ("scsi: mpt3sas: Don't change DMA mask while reallocating pools") it does not apply cleanly to earlier series. For context: There were several reports in Debian about regression in 5.10.y already: https://bugs.debian.org/1022268 https://bugs.debian.org/1023183 https://bugs.debian.org/1025747 https://bugs.debian.org/1022126 https://lore.kernel.org/linux-scsi/Y1JkuKTjVYrOWbvm@eldamar.lan/ is the initial reporting to upstream and later on brought as well to the regression list: https://lore.kernel.org/regressions/754b030c-ba14-167c-e2d0-2f4f5bf55e99@le… Thorsten suggested to first get the patch applied at least in 6.1.y but for further steps down we need help. Sreekanth and Martin is this still on your radar? Help with getting this back to 5.10.y would be welcome, and I'm sure with a tentative patch I can get some of the reporting users to report a Tested-by. While people are "unhappy" why it is not fixed yet in Debian, I'm not willing to diverge and appy a patch which is not approved and aimed to go upstream into the respective stable series. But I have too less knowledge here to see which is the correct change to apply to back to 5.10.y alone in case we need to diverge, as 9df650963bf6 picking as well is not an option. Input from you experts on that would be more the appreciated. Regards, Salvatore

2 years, 1 month

4
10
0 0

[PATCH 3/3] arm64: efi: Set NX compat flag in PE/COFF header

by Ard Biesheuvel

The PE/COFF header has a NX compat flag which informs the firmware that the application does not rely on memory regions being mapped with both executable and writable permissions at the same time. This is typically used by the firmware to decide whether it can set the NX attribute on all allocations it returns, but going forward, it may be used to enforce a policy that only permits applications with the NX flag set to be loaded to begin wiht in some configurations, e.g., when Secure Boot is in effect. Even though the arm64 version of the EFI stub may relocate the kernel before executing it, it always did so after disabling the MMU, and so we were always in line with what the NX compat flag conveys, we just never bothered to set it. So let's set the flag now. Cc: <stable(a)vger.kernel.org> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> --- arch/arm64/kernel/efi-header.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/efi-header.S b/arch/arm64/kernel/efi-header.S index 28d8a5dca5f12978..d731b4655df8eb27 100644 --- a/arch/arm64/kernel/efi-header.S +++ b/arch/arm64/kernel/efi-header.S @@ -66,7 +66,7 @@ .long .Lefi_header_end - .L_head // SizeOfHeaders .long 0 // CheckSum .short IMAGE_SUBSYSTEM_EFI_APPLICATION // Subsystem - .short 0 // DllCharacteristics + .short IMAGE_DLL_CHARACTERISTICS_NX_COMPAT // DllCharacteristics .quad 0 // SizeOfStackReserve .quad 0 // SizeOfStackCommit .quad 0 // SizeOfHeapReserve -- 2.39.2

2 years, 1 month

1
0
0 0

[PATCH 1/3] efi/libstub: zboot: Mark zboot EFI application as NX compatible

by Ard Biesheuvel

Now that the zboot loader will invoke the EFI memory attributes protocol to remap the decompressed code and rodata as read-only/executable, we can set the PE/COFF header flag that indicates to the firmware that the application does not rely on writable memory being executable at the same time. Cc: <stable(a)vger.kernel.org> # v6.2+ Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> --- drivers/firmware/efi/libstub/zboot-header.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/efi/libstub/zboot-header.S b/drivers/firmware/efi/libstub/zboot-header.S index ec4525d40e0cf6d6..445cb646eaaaf1c6 100644 --- a/drivers/firmware/efi/libstub/zboot-header.S +++ b/drivers/firmware/efi/libstub/zboot-header.S @@ -63,7 +63,7 @@ __efistub_efi_zboot_header: .long .Lefi_header_end - .Ldoshdr .long 0 .short IMAGE_SUBSYSTEM_EFI_APPLICATION - .short 0 + .short IMAGE_DLL_CHARACTERISTICS_NX_COMPAT #ifdef CONFIG_64BIT .quad 0, 0, 0, 0 #else -- 2.39.2

2 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] media: uvcvideo: Fix race condition with usb_kill_urb" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 619d9b710cf06f7a00a17120ca92333684ac45a8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '167845046617959(a)kroah.com' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 619d9b710cf0 ("media: uvcvideo: Fix race condition with usb_kill_urb") 40140eda661e ("media: uvcvideo: Implement mask for V4L2_CTRL_TYPE_MENU") adfd3910c27f ("media: uvcvideo: Remove void casting for the status endpoint") 382075604a68 ("media: uvcvideo: Limit power line control for Quanta UVC Webcam") 710871163510 ("media: uvcvideo: Add missing value for power_line_frequency") 70fa906d6fce ("media: uvcvideo: Use control names from framework") 9b31ea808a44 ("media: uvcvideo: Add support for V4L2_CTRL_TYPE_CTRL_CLASS") 866c6bdd5663 ("media: uvcvideo: refactor __uvc_ctrl_add_mapping") 9e56380ae625 ("media: uvcvideo: Rename debug functions") ed4c5fa4d804 ("media: uvcvideo: use dev_printk() for uvc_trace()") 59e92bf62771 ("media: uvcvideo: New macro uvc_trace_cont") 69df09547e7a ("media: uvcvideo: Use dev_ printk aliases") 6f6a87eb8266 ("media: uvcvideo: Add Privacy control based on EXT_GPIO") 2886477ff987 ("media: uvcvideo: Implement UVC_EXT_GPIO_UNIT") d9c8763e6129 ("media: uvcvideo: Provide sync and async uvc_ctrl_status_event") 351509c604dc ("media: uvcvideo: Move guid to entity") dc9455ffae02 ("media: uvcvideo: Accept invalid bFormatIndex and bFrameIndex values") b400b6f28af0 ("media: uvcvideo: Force UVC version to 1.0a for 1bcf:0b40") 8a652a17e3c0 ("media: uvcvideo: Ensure all probed info is returned to v4l2") f875bcc375c7 ("media: uvcvideo: Fix dereference of out-of-bound list iterator") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 619d9b710cf06f7a00a17120ca92333684ac45a8 Mon Sep 17 00:00:00 2001 From: Ricardo Ribalda <ribalda(a)chromium.org> Date: Thu, 5 Jan 2023 15:31:29 +0100 Subject: [PATCH] media: uvcvideo: Fix race condition with usb_kill_urb usb_kill_urb warranties that all the handlers are finished when it returns, but does not protect against threads that might be handling asynchronously the urb. For UVC, the function uvc_ctrl_status_event_async() takes care of control changes asynchronously. If the code is executed in the following order: CPU 0 CPU 1 ===== ===== uvc_status_complete() uvc_status_stop() uvc_ctrl_status_event_work() uvc_status_start() -> FAIL Then uvc_status_start will keep failing and this error will be shown: <4>[ 5.540139] URB 0000000000000000 submitted while active drivers/usb/core/urb.c:378 usb_submit_urb+0x4c3/0x528 Let's improve the current situation, by not re-submiting the urb if we are stopping the status event. Also process the queued work (if any) during stop. CPU 0 CPU 1 ===== ===== uvc_status_complete() uvc_status_stop() uvc_status_start() uvc_ctrl_status_event_work() -> FAIL Hopefully, with the usb layer protection this should be enough to cover all the cases. Cc: stable(a)vger.kernel.org Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives") Reviewed-by: Yunke Cao <yunkec(a)chromium.org> Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c index ee58f0db2763..c3aeba3fe31b 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -6,6 +6,7 @@ * Laurent Pinchart (laurent.pinchart(a)ideasonboard.com) */ +#include <asm/barrier.h> #include <linux/bitops.h> #include <linux/kernel.h> #include <linux/list.h> @@ -1571,6 +1572,10 @@ static void uvc_ctrl_status_event_work(struct work_struct *work) uvc_ctrl_status_event(w->chain, w->ctrl, w->data); + /* The barrier is needed to synchronize with uvc_status_stop(). */ + if (smp_load_acquire(&dev->flush_status)) + return; + /* Resubmit the URB. */ w->urb->interval = dev->int_ep->desc.bInterval; ret = usb_submit_urb(w->urb, GFP_KERNEL); diff --git a/drivers/media/usb/uvc/uvc_status.c b/drivers/media/usb/uvc/uvc_status.c index 602830a8023e..a78a88c710e2 100644 --- a/drivers/media/usb/uvc/uvc_status.c +++ b/drivers/media/usb/uvc/uvc_status.c @@ -6,6 +6,7 @@ * Laurent Pinchart (laurent.pinchart(a)ideasonboard.com) */ +#include <asm/barrier.h> #include <linux/kernel.h> #include <linux/input.h> #include <linux/slab.h> @@ -311,5 +312,41 @@ int uvc_status_start(struct uvc_device *dev, gfp_t flags) void uvc_status_stop(struct uvc_device *dev) { + struct uvc_ctrl_work *w = &dev->async_ctrl; + + /* + * Prevent the asynchronous control handler from requeing the URB. The + * barrier is needed so the flush_status change is visible to other + * CPUs running the asynchronous handler before usb_kill_urb() is + * called below. + */ + smp_store_release(&dev->flush_status, true); + + /* + * Cancel any pending asynchronous work. If any status event was queued, + * process it synchronously. + */ + if (cancel_work_sync(&w->work)) + uvc_ctrl_status_event(w->chain, w->ctrl, w->data); + + /* Kill the urb. */ usb_kill_urb(dev->int_urb); + + /* + * The URB completion handler may have queued asynchronous work. This + * won't resubmit the URB as flush_status is set, but it needs to be + * cancelled before returning or it could then race with a future + * uvc_status_start() call. + */ + if (cancel_work_sync(&w->work)) + uvc_ctrl_status_event(w->chain, w->ctrl, w->data); + + /* + * From this point, there are no events on the queue and the status URB + * is dead. No events will be queued until uvc_status_start() is called. + * The barrier is needed to make sure that flush_status is visible to + * uvc_ctrl_status_event_work() when uvc_status_start() will be called + * again. + */ + smp_store_release(&dev->flush_status, false); } diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index e85df8deb965..c0e706fcd2cb 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -577,6 +577,7 @@ struct uvc_device { struct usb_host_endpoint *int_ep; struct urb *int_urb; struct uvc_status *status; + bool flush_status; struct input_dev *input; char input_phys[64];

2 years, 1 month

2
2
0 0

FAILED: patch "[PATCH] media: uvcvideo: Fix race condition with usb_kill_urb" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 619d9b710cf06f7a00a17120ca92333684ac45a8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '167845046715250(a)kroah.com' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 619d9b710cf0 ("media: uvcvideo: Fix race condition with usb_kill_urb") 40140eda661e ("media: uvcvideo: Implement mask for V4L2_CTRL_TYPE_MENU") adfd3910c27f ("media: uvcvideo: Remove void casting for the status endpoint") 382075604a68 ("media: uvcvideo: Limit power line control for Quanta UVC Webcam") 710871163510 ("media: uvcvideo: Add missing value for power_line_frequency") 70fa906d6fce ("media: uvcvideo: Use control names from framework") 9b31ea808a44 ("media: uvcvideo: Add support for V4L2_CTRL_TYPE_CTRL_CLASS") 866c6bdd5663 ("media: uvcvideo: refactor __uvc_ctrl_add_mapping") 9e56380ae625 ("media: uvcvideo: Rename debug functions") ed4c5fa4d804 ("media: uvcvideo: use dev_printk() for uvc_trace()") 59e92bf62771 ("media: uvcvideo: New macro uvc_trace_cont") 69df09547e7a ("media: uvcvideo: Use dev_ printk aliases") 6f6a87eb8266 ("media: uvcvideo: Add Privacy control based on EXT_GPIO") 2886477ff987 ("media: uvcvideo: Implement UVC_EXT_GPIO_UNIT") d9c8763e6129 ("media: uvcvideo: Provide sync and async uvc_ctrl_status_event") 351509c604dc ("media: uvcvideo: Move guid to entity") dc9455ffae02 ("media: uvcvideo: Accept invalid bFormatIndex and bFrameIndex values") b400b6f28af0 ("media: uvcvideo: Force UVC version to 1.0a for 1bcf:0b40") 8a652a17e3c0 ("media: uvcvideo: Ensure all probed info is returned to v4l2") f875bcc375c7 ("media: uvcvideo: Fix dereference of out-of-bound list iterator") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 619d9b710cf06f7a00a17120ca92333684ac45a8 Mon Sep 17 00:00:00 2001 From: Ricardo Ribalda <ribalda(a)chromium.org> Date: Thu, 5 Jan 2023 15:31:29 +0100 Subject: [PATCH] media: uvcvideo: Fix race condition with usb_kill_urb usb_kill_urb warranties that all the handlers are finished when it returns, but does not protect against threads that might be handling asynchronously the urb. For UVC, the function uvc_ctrl_status_event_async() takes care of control changes asynchronously. If the code is executed in the following order: CPU 0 CPU 1 ===== ===== uvc_status_complete() uvc_status_stop() uvc_ctrl_status_event_work() uvc_status_start() -> FAIL Then uvc_status_start will keep failing and this error will be shown: <4>[ 5.540139] URB 0000000000000000 submitted while active drivers/usb/core/urb.c:378 usb_submit_urb+0x4c3/0x528 Let's improve the current situation, by not re-submiting the urb if we are stopping the status event. Also process the queued work (if any) during stop. CPU 0 CPU 1 ===== ===== uvc_status_complete() uvc_status_stop() uvc_status_start() uvc_ctrl_status_event_work() -> FAIL Hopefully, with the usb layer protection this should be enough to cover all the cases. Cc: stable(a)vger.kernel.org Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives") Reviewed-by: Yunke Cao <yunkec(a)chromium.org> Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c index ee58f0db2763..c3aeba3fe31b 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -6,6 +6,7 @@ * Laurent Pinchart (laurent.pinchart(a)ideasonboard.com) */ +#include <asm/barrier.h> #include <linux/bitops.h> #include <linux/kernel.h> #include <linux/list.h> @@ -1571,6 +1572,10 @@ static void uvc_ctrl_status_event_work(struct work_struct *work) uvc_ctrl_status_event(w->chain, w->ctrl, w->data); + /* The barrier is needed to synchronize with uvc_status_stop(). */ + if (smp_load_acquire(&dev->flush_status)) + return; + /* Resubmit the URB. */ w->urb->interval = dev->int_ep->desc.bInterval; ret = usb_submit_urb(w->urb, GFP_KERNEL); diff --git a/drivers/media/usb/uvc/uvc_status.c b/drivers/media/usb/uvc/uvc_status.c index 602830a8023e..a78a88c710e2 100644 --- a/drivers/media/usb/uvc/uvc_status.c +++ b/drivers/media/usb/uvc/uvc_status.c @@ -6,6 +6,7 @@ * Laurent Pinchart (laurent.pinchart(a)ideasonboard.com) */ +#include <asm/barrier.h> #include <linux/kernel.h> #include <linux/input.h> #include <linux/slab.h> @@ -311,5 +312,41 @@ int uvc_status_start(struct uvc_device *dev, gfp_t flags) void uvc_status_stop(struct uvc_device *dev) { + struct uvc_ctrl_work *w = &dev->async_ctrl; + + /* + * Prevent the asynchronous control handler from requeing the URB. The + * barrier is needed so the flush_status change is visible to other + * CPUs running the asynchronous handler before usb_kill_urb() is + * called below. + */ + smp_store_release(&dev->flush_status, true); + + /* + * Cancel any pending asynchronous work. If any status event was queued, + * process it synchronously. + */ + if (cancel_work_sync(&w->work)) + uvc_ctrl_status_event(w->chain, w->ctrl, w->data); + + /* Kill the urb. */ usb_kill_urb(dev->int_urb); + + /* + * The URB completion handler may have queued asynchronous work. This + * won't resubmit the URB as flush_status is set, but it needs to be + * cancelled before returning or it could then race with a future + * uvc_status_start() call. + */ + if (cancel_work_sync(&w->work)) + uvc_ctrl_status_event(w->chain, w->ctrl, w->data); + + /* + * From this point, there are no events on the queue and the status URB + * is dead. No events will be queued until uvc_status_start() is called. + * The barrier is needed to make sure that flush_status is visible to + * uvc_ctrl_status_event_work() when uvc_status_start() will be called + * again. + */ + smp_store_release(&dev->flush_status, false); } diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index e85df8deb965..c0e706fcd2cb 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -577,6 +577,7 @@ struct uvc_device { struct usb_host_endpoint *int_ep; struct urb *int_urb; struct uvc_status *status; + bool flush_status; struct input_dev *input; char input_phys[64];

2 years, 1 month

2
2
0 0

FAILED: patch "[PATCH] media: uvcvideo: Fix race condition with usb_kill_urb" failed to apply to 6.2-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.2-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.2.y git checkout FETCH_HEAD git cherry-pick -x 619d9b710cf06f7a00a17120ca92333684ac45a8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '16781002113959(a)kroah.com' --subject-prefix 'PATCH 6.2.y' HEAD^.. Possible dependencies: 619d9b710cf0 ("media: uvcvideo: Fix race condition with usb_kill_urb") 40140eda661e ("media: uvcvideo: Implement mask for V4L2_CTRL_TYPE_MENU") adfd3910c27f ("media: uvcvideo: Remove void casting for the status endpoint") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 619d9b710cf06f7a00a17120ca92333684ac45a8 Mon Sep 17 00:00:00 2001 From: Ricardo Ribalda <ribalda(a)chromium.org> Date: Thu, 5 Jan 2023 15:31:29 +0100 Subject: [PATCH] media: uvcvideo: Fix race condition with usb_kill_urb usb_kill_urb warranties that all the handlers are finished when it returns, but does not protect against threads that might be handling asynchronously the urb. For UVC, the function uvc_ctrl_status_event_async() takes care of control changes asynchronously. If the code is executed in the following order: CPU 0 CPU 1 ===== ===== uvc_status_complete() uvc_status_stop() uvc_ctrl_status_event_work() uvc_status_start() -> FAIL Then uvc_status_start will keep failing and this error will be shown: <4>[ 5.540139] URB 0000000000000000 submitted while active drivers/usb/core/urb.c:378 usb_submit_urb+0x4c3/0x528 Let's improve the current situation, by not re-submiting the urb if we are stopping the status event. Also process the queued work (if any) during stop. CPU 0 CPU 1 ===== ===== uvc_status_complete() uvc_status_stop() uvc_status_start() uvc_ctrl_status_event_work() -> FAIL Hopefully, with the usb layer protection this should be enough to cover all the cases. Cc: stable(a)vger.kernel.org Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives") Reviewed-by: Yunke Cao <yunkec(a)chromium.org> Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c index ee58f0db2763..c3aeba3fe31b 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -6,6 +6,7 @@ * Laurent Pinchart (laurent.pinchart(a)ideasonboard.com) */ +#include <asm/barrier.h> #include <linux/bitops.h> #include <linux/kernel.h> #include <linux/list.h> @@ -1571,6 +1572,10 @@ static void uvc_ctrl_status_event_work(struct work_struct *work) uvc_ctrl_status_event(w->chain, w->ctrl, w->data); + /* The barrier is needed to synchronize with uvc_status_stop(). */ + if (smp_load_acquire(&dev->flush_status)) + return; + /* Resubmit the URB. */ w->urb->interval = dev->int_ep->desc.bInterval; ret = usb_submit_urb(w->urb, GFP_KERNEL); diff --git a/drivers/media/usb/uvc/uvc_status.c b/drivers/media/usb/uvc/uvc_status.c index 602830a8023e..a78a88c710e2 100644 --- a/drivers/media/usb/uvc/uvc_status.c +++ b/drivers/media/usb/uvc/uvc_status.c @@ -6,6 +6,7 @@ * Laurent Pinchart (laurent.pinchart(a)ideasonboard.com) */ +#include <asm/barrier.h> #include <linux/kernel.h> #include <linux/input.h> #include <linux/slab.h> @@ -311,5 +312,41 @@ int uvc_status_start(struct uvc_device *dev, gfp_t flags) void uvc_status_stop(struct uvc_device *dev) { + struct uvc_ctrl_work *w = &dev->async_ctrl; + + /* + * Prevent the asynchronous control handler from requeing the URB. The + * barrier is needed so the flush_status change is visible to other + * CPUs running the asynchronous handler before usb_kill_urb() is + * called below. + */ + smp_store_release(&dev->flush_status, true); + + /* + * Cancel any pending asynchronous work. If any status event was queued, + * process it synchronously. + */ + if (cancel_work_sync(&w->work)) + uvc_ctrl_status_event(w->chain, w->ctrl, w->data); + + /* Kill the urb. */ usb_kill_urb(dev->int_urb); + + /* + * The URB completion handler may have queued asynchronous work. This + * won't resubmit the URB as flush_status is set, but it needs to be + * cancelled before returning or it could then race with a future + * uvc_status_start() call. + */ + if (cancel_work_sync(&w->work)) + uvc_ctrl_status_event(w->chain, w->ctrl, w->data); + + /* + * From this point, there are no events on the queue and the status URB + * is dead. No events will be queued until uvc_status_start() is called. + * The barrier is needed to make sure that flush_status is visible to + * uvc_ctrl_status_event_work() when uvc_status_start() will be called + * again. + */ + smp_store_release(&dev->flush_status, false); } diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index e85df8deb965..c0e706fcd2cb 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -577,6 +577,7 @@ struct uvc_device { struct usb_host_endpoint *int_ep; struct urb *int_urb; struct uvc_status *status; + bool flush_status; struct input_dev *input; char input_phys[64];

2 years, 1 month

3
5
0 0

[PATCH 5.15.y] drm/virtio: Fix error code in virtio_gpu_object_shmem_init()

by Harshit Mogalapalli

In virtio_gpu_object_shmem_init() we are passing NULL to PTR_ERR, which is returning 0/success. Fix this by storing error value in 'ret' variable before assigning shmem->pages to NULL. Found using static analysis with Smatch. Fixes: 64b88afbd92f ("drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- Only compile tested. Upstream commit b5c9ed70d1a9 ("drm/virtio: Improve DMA API usage for shmem BOs") deleted this code, so this patch is not necessary in linux-6.1.y and linux-6.2.y. --- drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index 7e75fb0fc7bd..25d399b00404 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -169,8 +169,9 @@ static int virtio_gpu_object_shmem_init(struct virtio_gpu_device *vgdev, shmem->pages = drm_gem_shmem_get_sg_table(&bo->base); if (IS_ERR(shmem->pages)) { drm_gem_shmem_unpin(&bo->base); + ret = PTR_ERR(shmem->pages); shmem->pages = NULL; - return PTR_ERR(shmem->pages); + return ret; } if (use_dma_api) { -- 2.31.1

2 years, 1 month

3
2
0 0

FAILED: patch "[PATCH] io_uring/poll: allow some retries for poll triggering" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x c16bda37594f83147b167d381d54c010024efecf # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '167809981810941(a)kroah.com' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: c16bda37594f ("io_uring/poll: allow some retries for poll triggering spuriously") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From c16bda37594f83147b167d381d54c010024efecf Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Sat, 25 Feb 2023 12:53:53 -0700 Subject: [PATCH] io_uring/poll: allow some retries for poll triggering spuriously If we get woken spuriously when polling and fail the operation with -EAGAIN again, then we generally only allow polling again if data had been transferred at some point. This is indicated with REQ_F_PARTIAL_IO. However, if the spurious poll triggers when the socket was originally empty, then we haven't transferred data yet and we will fail the poll re-arm. This either punts the socket to io-wq if it's blocking, or it fails the request with -EAGAIN if not. Neither condition is desirable, as the former will slow things down, while the latter will make the application confused. We want to ensure that a repeated poll trigger doesn't lead to infinite work making no progress, that's what the REQ_F_PARTIAL_IO check was for. But it doesn't protect against a loop post the first receive, and it's unnecessarily strict if we started out with an empty socket. Add a somewhat random retry count, just to put an upper limit on the potential number of retries that will be done. This should be high enough that we won't really hit it in practice, unless something needs to be aborted anyway. Cc: stable(a)vger.kernel.org # v5.10+ Link: https://github.com/axboe/liburing/issues/364 Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/poll.c b/io_uring/poll.c index 8339a92b4510..a82d6830bdfd 100644 --- a/io_uring/poll.c +++ b/io_uring/poll.c @@ -650,6 +650,14 @@ static void io_async_queue_proc(struct file *file, struct wait_queue_head *head, __io_queue_proc(&apoll->poll, pt, head, &apoll->double_poll); } +/* + * We can't reliably detect loops in repeated poll triggers and issue + * subsequently failing. But rather than fail these immediately, allow a + * certain amount of retries before we give up. Given that this condition + * should _rarely_ trigger even once, we should be fine with a larger value. + */ +#define APOLL_MAX_RETRY 128 + static struct async_poll *io_req_alloc_apoll(struct io_kiocb *req, unsigned issue_flags) { @@ -665,14 +673,18 @@ static struct async_poll *io_req_alloc_apoll(struct io_kiocb *req, if (entry == NULL) goto alloc_apoll; apoll = container_of(entry, struct async_poll, cache); + apoll->poll.retries = APOLL_MAX_RETRY; } else { alloc_apoll: apoll = kmalloc(sizeof(*apoll), GFP_ATOMIC); if (unlikely(!apoll)) return NULL; + apoll->poll.retries = APOLL_MAX_RETRY; } apoll->double_poll = NULL; req->apoll = apoll; + if (unlikely(!--apoll->poll.retries)) + return NULL; return apoll; } @@ -694,8 +706,6 @@ int io_arm_poll_handler(struct io_kiocb *req, unsigned issue_flags) return IO_APOLL_ABORTED; if (!file_can_poll(req->file)) return IO_APOLL_ABORTED; - if ((req->flags & (REQ_F_POLLED|REQ_F_PARTIAL_IO)) == REQ_F_POLLED) - return IO_APOLL_ABORTED; if (!(req->flags & REQ_F_APOLL_MULTISHOT)) mask |= EPOLLONESHOT; diff --git a/io_uring/poll.h b/io_uring/poll.h index 5f3bae50fc81..b2393b403a2c 100644 --- a/io_uring/poll.h +++ b/io_uring/poll.h @@ -12,6 +12,7 @@ struct io_poll { struct file *file; struct wait_queue_head *head; __poll_t events; + int retries; struct wait_queue_entry wait; };

2 years, 1 month

3
2
0 0

[4.19/5.4/5.10] Please backport fdaf88531cfd.

by Kuniyuki Iwashima

Hi, On 4.14, 4.19, 5.4, and 5.10, listen() does not return -EADDRINUSE when it fails to reserve a port. The same issue happend on 5.15.88 and fdaf88531cfd ("tcp: Fix listen() regression in 5.15.88.") in the 5.15.y branch fixed it. The commit can be applied cleanly to 4.19, 5.4, and 5.10. Could you backport the commit to these branch ? For 4.14.y, I'll post another patch. Thanks, Kuniyuki

2 years, 1 month

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2023