Currently the 'pispbe_schedule()' function does two things:
1) Tries to assemble a job by inspecting all the video node queues
to make sure all the required buffers are available
2) Submit the job to the hardware
The pispbe_schedule() function is called at:
- video device start_streaming() time
- video device qbuf() time
- irq handler
As assembling a job requires inspecting all queues, it is a rather
time consuming operation which is better not run in IRQ context.
To avoid executing the time consuming job creation in interrupt
context, split the job creation and job scheduling in two distinct
operations. When a well-formed job is created, append it to the
newly introduced 'pispbe->job_queue' where it will be dequeued from
by the scheduling routine.
At start_streaming() and qbuf() time immediately try to schedule a job
if one has been created as the irq handler routine is only called when
a job has completed, and we can't solely rely on it for scheduling new
jobs.
Signed-off-by: Jacopo Mondi <jacopo.mondi(a)ideasonboard.com>
---
Changes in v8:
- Use automatic release of *job in pispbe_prepare_job()
- Use temporary list to release jobs without holding the main driver
lock
- Collect tags
- Rebased on rpi-6.6.y: https://github.com/raspberrypi/linux/pull/6905
- Link to v7: https://lore.kernel.org/r/20250606-pispbe-mainline-split-jobs-handling-v6-v…
Changes in v7:
- Rebased on media-committers/next
- Fix lockdep warning by using the proper spinlock_irq() primitive in
pispbe_prepare_job() which can race with the IRQ handler
- Link to v6: https://lore.kernel.org/r/20240930-pispbe-mainline-split-jobs-handling-v6-v…
v5->v6:
- Make the driver depend on PM
- Simplify the probe() routine by using pm_runtime_
- Remove suspend call from remove()
v4->v5:
- Use appropriate locking constructs:
- spin_lock_irq() for pispbe_prepare_job() called from non irq context
- spin_lock_irqsave() for pispbe_schedule() called from irq context
- Remove hw_lock from ready_queue accesses in stop_streaming and
start_streaming
- Fix trivial indentation mistake in 4/4
v3->v4:
- Expand commit message in 2/4 to explain why removing validation in schedule()
is safe
- Drop ready_lock spinlock
- Use non _irqsave version of safe_guard(spinlock
- Support !CONFIG_PM in 4/4 by calling the enable/disable routines directly
and adjust pm_runtime usage as suggested by Laurent
v2->v3:
- Mark pispbe_runtime_resume() as __maybe_unused
- Add fixes tags where appropriate
v1->v2:
- Add two patches to address Laurent's comments separately
- use scoped_guard() when possible
- Add patch to fix runtime_pm imbalance
---
Jacopo Mondi (4):
media: pisp_be: Drop reference to non-existing function
media: pisp_be: Remove config validation from schedule()
media: pisp_be: Split jobs creation and scheduling
media: pisp_be: Fix pm_runtime underrun in probe
drivers/media/platform/raspberrypi/pisp_be/Kconfig | 1 +
.../media/platform/raspberrypi/pisp_be/pisp_be.c | 196 ++++++++++-----------
2 files changed, 98 insertions(+), 99 deletions(-)
---
base-commit: ce5cac69b2edac3e3246fee03e8f4c2a1075238b
change-id: 20240930-pispbe-mainline-split-jobs-handling-v6-15dc16e11e3a
Best regards,
--
Jacopo Mondi <jacopo.mondi(a)ideasonboard.com>
The patch below does not apply to the 5.10-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.10.y
git checkout FETCH_HEAD
git cherry-pick -x f4ecdc352646f7d23f348e5c544dbe3212c94fc8
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025061707-putt-mutable-5fb5@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From f4ecdc352646f7d23f348e5c544dbe3212c94fc8 Mon Sep 17 00:00:00 2001
From: Pawel Laszczak <pawell(a)cadence.com>
Date: Tue, 13 May 2025 05:30:09 +0000
Subject: [PATCH] usb: cdnsp: Fix issue with detecting command completion event
In some cases, there is a small-time gap in which CMD_RING_BUSY can be
cleared by controller but adding command completion event to event ring
will be delayed. As the result driver will return error code.
This behavior has been detected on usbtest driver (test 9) with
configuration including ep1in/ep1out bulk and ep2in/ep2out isoc
endpoint.
Probably this gap occurred because controller was busy with adding some
other events to event ring.
The CMD_RING_BUSY is cleared to '0' when the Command Descriptor has been
executed and not when command completion event has been added to event
ring.
To fix this issue for this test the small delay is sufficient less than
10us) but to make sure the problem doesn't happen again in the future
the patch introduces 10 retries to check with delay about 20us before
returning error code.
Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Pawel Laszczak <pawell(a)cadence.com>
Acked-by: Peter Chen <peter.chen(a)kernel.org>
Link: https://lore.kernel.org/r/PH7PR07MB9538AA45362ACCF1B94EE9B7DD96A@PH7PR07MB9…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/cdns3/cdnsp-gadget.c b/drivers/usb/cdns3/cdnsp-gadget.c
index cd1e00daf43f..55f95f41b3b4 100644
--- a/drivers/usb/cdns3/cdnsp-gadget.c
+++ b/drivers/usb/cdns3/cdnsp-gadget.c
@@ -548,6 +548,7 @@ int cdnsp_wait_for_cmd_compl(struct cdnsp_device *pdev)
dma_addr_t cmd_deq_dma;
union cdnsp_trb *event;
u32 cycle_state;
+ u32 retry = 10;
int ret, val;
u64 cmd_dma;
u32 flags;
@@ -579,8 +580,23 @@ int cdnsp_wait_for_cmd_compl(struct cdnsp_device *pdev)
flags = le32_to_cpu(event->event_cmd.flags);
/* Check the owner of the TRB. */
- if ((flags & TRB_CYCLE) != cycle_state)
+ if ((flags & TRB_CYCLE) != cycle_state) {
+ /*
+ * Give some extra time to get chance controller
+ * to finish command before returning error code.
+ * Checking CMD_RING_BUSY is not sufficient because
+ * this bit is cleared to '0' when the Command
+ * Descriptor has been executed by controller
+ * and not when command completion event has
+ * be added to event ring.
+ */
+ if (retry--) {
+ udelay(20);
+ continue;
+ }
+
return -EINVAL;
+ }
cmd_dma = le64_to_cpu(event->event_cmd.cmd_trb);
The patch below does not apply to the 5.10-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.10.y
git checkout FETCH_HEAD
git cherry-pick -x 1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025061733-scarring-crevice-7648@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4 Mon Sep 17 00:00:00 2001
From: Wupeng Ma <mawupeng1(a)huawei.com>
Date: Sat, 10 May 2025 11:30:40 +0800
Subject: [PATCH] VMCI: fix race between vmci_host_setup_notify and
vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio
as follow:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130
Modules linked in:
CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)
RIP: 0010:try_grab_folio+0x106/0x130
Call Trace:
<TASK>
follow_huge_pmd+0x240/0x8e0
follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0
follow_pud_mask.constprop.0.isra.0+0x14a/0x170
follow_page_mask+0x1c2/0x1f0
__get_user_pages+0x176/0x950
__gup_longterm_locked+0x15b/0x1060
? gup_fast+0x120/0x1f0
gup_fast_fallback+0x17e/0x230
get_user_pages_fast+0x5f/0x80
vmci_host_unlocked_ioctl+0x21c/0xf80
RIP: 0033:0x54d2cd
---[ end trace 0000000000000000 ]---
Digging into the source, context->notify_page may init by get_user_pages_fast
and can be seen in vmci_ctx_unset_notify which will try to put_page. However
get_user_pages_fast is not finished here and lead to following
try_grab_folio warning. The race condition is shown as follow:
cpu0 cpu1
vmci_host_do_set_notify
vmci_host_setup_notify
get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);
lockless_pages_from_mm
gup_pgd_range
gup_huge_pmd // update &context->notify_page
vmci_host_do_set_notify
vmci_ctx_unset_notify
notify_page = context->notify_page;
if (notify_page)
put_page(notify_page); // page is freed
__gup_longterm_locked
__get_user_pages
follow_trans_huge_pmd
try_grab_folio // warn here
To slove this, use local variable page to make notify_page can be seen
after finish get_user_pages_fast.
Fixes: a1d88436d53a ("VMCI: Fix two UVA mapping bugs")
Cc: stable <stable(a)kernel.org>
Closes: https://lore.kernel.org/all/e91da589-ad57-3969-d979-879bbd10dddd@huawei.com/
Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com>
Link: https://lore.kernel.org/r/20250510033040.901582-1-mawupeng1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/misc/vmw_vmci/vmci_host.c b/drivers/misc/vmw_vmci/vmci_host.c
index abe79f6fd2a7..b64944367ac5 100644
--- a/drivers/misc/vmw_vmci/vmci_host.c
+++ b/drivers/misc/vmw_vmci/vmci_host.c
@@ -227,6 +227,7 @@ static int drv_cp_harray_to_user(void __user *user_buf_uva,
static int vmci_host_setup_notify(struct vmci_ctx *context,
unsigned long uva)
{
+ struct page *page;
int retval;
if (context->notify_page) {
@@ -243,13 +244,11 @@ static int vmci_host_setup_notify(struct vmci_ctx *context,
/*
* Lock physical page backing a given user VA.
*/
- retval = get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);
- if (retval != 1) {
- context->notify_page = NULL;
+ retval = get_user_pages_fast(uva, 1, FOLL_WRITE, &page);
+ if (retval != 1)
return VMCI_ERROR_GENERIC;
- }
- if (context->notify_page == NULL)
- return VMCI_ERROR_UNAVAILABLE;
+
+ context->notify_page = page;
/*
* Map the locked page and set up notify pointer.
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 1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025061722-shaded-throwback-5dda@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4 Mon Sep 17 00:00:00 2001
From: Wupeng Ma <mawupeng1(a)huawei.com>
Date: Sat, 10 May 2025 11:30:40 +0800
Subject: [PATCH] VMCI: fix race between vmci_host_setup_notify and
vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio
as follow:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130
Modules linked in:
CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)
RIP: 0010:try_grab_folio+0x106/0x130
Call Trace:
<TASK>
follow_huge_pmd+0x240/0x8e0
follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0
follow_pud_mask.constprop.0.isra.0+0x14a/0x170
follow_page_mask+0x1c2/0x1f0
__get_user_pages+0x176/0x950
__gup_longterm_locked+0x15b/0x1060
? gup_fast+0x120/0x1f0
gup_fast_fallback+0x17e/0x230
get_user_pages_fast+0x5f/0x80
vmci_host_unlocked_ioctl+0x21c/0xf80
RIP: 0033:0x54d2cd
---[ end trace 0000000000000000 ]---
Digging into the source, context->notify_page may init by get_user_pages_fast
and can be seen in vmci_ctx_unset_notify which will try to put_page. However
get_user_pages_fast is not finished here and lead to following
try_grab_folio warning. The race condition is shown as follow:
cpu0 cpu1
vmci_host_do_set_notify
vmci_host_setup_notify
get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);
lockless_pages_from_mm
gup_pgd_range
gup_huge_pmd // update &context->notify_page
vmci_host_do_set_notify
vmci_ctx_unset_notify
notify_page = context->notify_page;
if (notify_page)
put_page(notify_page); // page is freed
__gup_longterm_locked
__get_user_pages
follow_trans_huge_pmd
try_grab_folio // warn here
To slove this, use local variable page to make notify_page can be seen
after finish get_user_pages_fast.
Fixes: a1d88436d53a ("VMCI: Fix two UVA mapping bugs")
Cc: stable <stable(a)kernel.org>
Closes: https://lore.kernel.org/all/e91da589-ad57-3969-d979-879bbd10dddd@huawei.com/
Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com>
Link: https://lore.kernel.org/r/20250510033040.901582-1-mawupeng1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/misc/vmw_vmci/vmci_host.c b/drivers/misc/vmw_vmci/vmci_host.c
index abe79f6fd2a7..b64944367ac5 100644
--- a/drivers/misc/vmw_vmci/vmci_host.c
+++ b/drivers/misc/vmw_vmci/vmci_host.c
@@ -227,6 +227,7 @@ static int drv_cp_harray_to_user(void __user *user_buf_uva,
static int vmci_host_setup_notify(struct vmci_ctx *context,
unsigned long uva)
{
+ struct page *page;
int retval;
if (context->notify_page) {
@@ -243,13 +244,11 @@ static int vmci_host_setup_notify(struct vmci_ctx *context,
/*
* Lock physical page backing a given user VA.
*/
- retval = get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);
- if (retval != 1) {
- context->notify_page = NULL;
+ retval = get_user_pages_fast(uva, 1, FOLL_WRITE, &page);
+ if (retval != 1)
return VMCI_ERROR_GENERIC;
- }
- if (context->notify_page == NULL)
- return VMCI_ERROR_UNAVAILABLE;
+
+ context->notify_page = page;
/*
* Map the locked page and set up notify pointer.
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 acb3dac2805d3342ded7dbbd164add32bbfdf21c
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025061708-chaperone-fantasy-02f0@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From acb3dac2805d3342ded7dbbd164add32bbfdf21c Mon Sep 17 00:00:00 2001
From: Dave Penkler <dpenkler(a)gmail.com>
Date: Wed, 21 May 2025 14:16:55 +0200
Subject: [PATCH] usb: usbtmc: Fix read_stb function and get_stb ioctl
The usbtmc488_ioctl_read_stb function relied on a positive return from
usbtmc_get_stb to reset the srq condition in the driver. The
USBTMC_IOCTL_GET_STB case tested for a positive return to return the stb
to the user.
Commit: <cac01bd178d6> ("usb: usbtmc: Fix erroneous get_stb ioctl
error returns") changed the return value of usbtmc_get_stb to 0 on
success instead of returning the value of usb_control_msg which is
positive in the normal case. This change caused the function
usbtmc488_ioctl_read_stb and the USBTMC_IOCTL_GET_STB ioctl to no
longer function correctly.
Change the test in usbtmc488_ioctl_read_stb to test for failure
first and return the failure code immediately.
Change the test for the USBTMC_IOCTL_GET_STB ioctl to test for 0
instead of a positive value.
Fixes: cac01bd178d6 ("usb: usbtmc: Fix erroneous get_stb ioctl error returns")
Cc: stable(a)vger.kernel.org
Signed-off-by: Dave Penkler <dpenkler(a)gmail.com>
Link: https://lore.kernel.org/r/20250521121656.18174-3-dpenkler@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 740d2d2b19fb..08511442a27f 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -563,14 +563,15 @@ static int usbtmc488_ioctl_read_stb(struct usbtmc_file_data *file_data,
rv = usbtmc_get_stb(file_data, &stb);
- if (rv > 0) {
- srq_asserted = atomic_xchg(&file_data->srq_asserted,
- srq_asserted);
- if (srq_asserted)
- stb |= 0x40; /* Set RQS bit */
+ if (rv < 0)
+ return rv;
+
+ srq_asserted = atomic_xchg(&file_data->srq_asserted, srq_asserted);
+ if (srq_asserted)
+ stb |= 0x40; /* Set RQS bit */
+
+ rv = put_user(stb, (__u8 __user *)arg);
- rv = put_user(stb, (__u8 __user *)arg);
- }
return rv;
}
@@ -2199,7 +2200,7 @@ static long usbtmc_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
case USBTMC_IOCTL_GET_STB:
retval = usbtmc_get_stb(file_data, &tmp_byte);
- if (retval > 0)
+ if (!retval)
retval = put_user(tmp_byte, (__u8 __user *)arg);
break;
The patch below does not apply to the 5.10-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.10.y
git checkout FETCH_HEAD
git cherry-pick -x acb3dac2805d3342ded7dbbd164add32bbfdf21c
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025061707-conceded-outwit-2f2f@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From acb3dac2805d3342ded7dbbd164add32bbfdf21c Mon Sep 17 00:00:00 2001
From: Dave Penkler <dpenkler(a)gmail.com>
Date: Wed, 21 May 2025 14:16:55 +0200
Subject: [PATCH] usb: usbtmc: Fix read_stb function and get_stb ioctl
The usbtmc488_ioctl_read_stb function relied on a positive return from
usbtmc_get_stb to reset the srq condition in the driver. The
USBTMC_IOCTL_GET_STB case tested for a positive return to return the stb
to the user.
Commit: <cac01bd178d6> ("usb: usbtmc: Fix erroneous get_stb ioctl
error returns") changed the return value of usbtmc_get_stb to 0 on
success instead of returning the value of usb_control_msg which is
positive in the normal case. This change caused the function
usbtmc488_ioctl_read_stb and the USBTMC_IOCTL_GET_STB ioctl to no
longer function correctly.
Change the test in usbtmc488_ioctl_read_stb to test for failure
first and return the failure code immediately.
Change the test for the USBTMC_IOCTL_GET_STB ioctl to test for 0
instead of a positive value.
Fixes: cac01bd178d6 ("usb: usbtmc: Fix erroneous get_stb ioctl error returns")
Cc: stable(a)vger.kernel.org
Signed-off-by: Dave Penkler <dpenkler(a)gmail.com>
Link: https://lore.kernel.org/r/20250521121656.18174-3-dpenkler@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 740d2d2b19fb..08511442a27f 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -563,14 +563,15 @@ static int usbtmc488_ioctl_read_stb(struct usbtmc_file_data *file_data,
rv = usbtmc_get_stb(file_data, &stb);
- if (rv > 0) {
- srq_asserted = atomic_xchg(&file_data->srq_asserted,
- srq_asserted);
- if (srq_asserted)
- stb |= 0x40; /* Set RQS bit */
+ if (rv < 0)
+ return rv;
+
+ srq_asserted = atomic_xchg(&file_data->srq_asserted, srq_asserted);
+ if (srq_asserted)
+ stb |= 0x40; /* Set RQS bit */
+
+ rv = put_user(stb, (__u8 __user *)arg);
- rv = put_user(stb, (__u8 __user *)arg);
- }
return rv;
}
@@ -2199,7 +2200,7 @@ static long usbtmc_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
case USBTMC_IOCTL_GET_STB:
retval = usbtmc_get_stb(file_data, &tmp_byte);
- if (retval > 0)
+ if (!retval)
retval = put_user(tmp_byte, (__u8 __user *)arg);
break;
Hi Greg and Sasha,
Please find attached backports of commit d0afcfeb9e38 ("kbuild: Disable
-Wdefault-const-init-unsafe") for 6.6 and older, which is needed for tip
of tree versions of LLVM. Please let me know if there are any questions.
Cheers,
Nathan
Sasha Levin <sashal(a)kernel.org> writes:
> This is a note to let you know that I've just added the patch titled
>
> net: sch_ets: Add a new Qdisc
>
> to the 5.4-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> net-sch_ets-add-a-new-qdisc.patch
> and it can be found in the queue-5.4 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
Not sure what the motivation is to include a pure added feature to a
stable tree. But if you truly want the patch, then there were a couple
follow up fixes over the years. At least the following look like patches
to code that would be problematic in 5.4.y as well:
cd9b50adc6bb ("net/sched: ets: fix crash when flipping from 'strict' to 'quantum'")
454d3e1ae057 ("net/sched: sch_ets: properly init all active DRR list handles")
de6d25924c2a ("net/sched: sch_ets: don't peek at classes beyond 'nbands'")
c062f2a0b04d ("net/sched: sch_ets: don't remove idle classes from the round-robin list")
d62b04fca434 ("net: sched: fix ets qdisc OOB Indexing")
1a6d0c00fa07 ("net_sched: ets: Fix double list add in class with netem as child qdisc")
On 10. 06. 25, 13:56, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> powerpc: do not build ppc_save_regs.o always
>
> to the 6.15-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
Please drop this from all trees. It was correctly broken. The whole if
was removed later by 93bd4a80efeb521314485a06d8c21157240497bb.
> The filename of the patch is:
> powerpc-do-not-build-ppc_save_regs.o-always.patch
> and it can be found in the queue-6.15 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
>
>
>
> commit 242c2ba3f16d92cd81c309725550f6c723833ae3
> Author: Jiri Slaby (SUSE) <jirislaby(a)kernel.org>
> Date: Thu Apr 17 12:53:05 2025 +0200
>
> powerpc: do not build ppc_save_regs.o always
>
> [ Upstream commit 497b7794aef03d525a5be05ae78dd7137c6861a5 ]
>
> The Fixes commit below tried to add CONFIG_PPC_BOOK3S to one of the
> conditions to enable the build of ppc_save_regs.o. But it failed to do
> so, in fact. The commit omitted to add a dollar sign.
>
> Therefore, ppc_save_regs.o is built always these days (as
> "(CONFIG_PPC_BOOK3S)" is never an empty string).
>
> Fix this by adding the missing dollar sign.
>
> Signed-off-by: Jiri Slaby (SUSE) <jirislaby(a)kernel.org>
> Fixes: fc2a5a6161a2 ("powerpc/64s: ppc_save_regs is now needed for all 64s builds")
> Acked-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
> Signed-off-by: Madhavan Srinivasan <maddy(a)linux.ibm.com>
> Link: https://patch.msgid.link/20250417105305.397128-1-jirislaby@kernel.org
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 6ac621155ec3c..0c26b2412d173 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -160,7 +160,7 @@ endif
>
> obj64-$(CONFIG_PPC_TRANSACTIONAL_MEM) += tm.o
>
> -ifneq ($(CONFIG_XMON)$(CONFIG_KEXEC_CORE)(CONFIG_PPC_BOOK3S),)
> +ifneq ($(CONFIG_XMON)$(CONFIG_KEXEC_CORE)$(CONFIG_PPC_BOOK3S),)
> obj-y += ppc_save_regs.o
> endif
>
--
js
suse labs
From: Sasha Levin <sashal(a)kernel.org>
>
> This is a note to let you know that I've just added the patch titled
>
> Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests
>
> to the 6.15-stable tree which can be found at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
>
> The filename of the patch is:
> drivers-hv-always-select-config_sysfb-for-hyper-v-gu.patch
> and it can be found in the queue-6.15 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
Please DO NOT backport this patch to ANY stable trees, at least
not at the moment. It is causing a config problem that we're trying
to work out. Once the resolution is decided upon, we can figure out
what to backport.
Thanks,
Michael Kelley
>
>
>
> commit 9766859ee9884c35dde0411df167a06452fee3ce
> Author: Michael Kelley <mhklinux(a)outlook.com>
> Date: Mon May 19 21:01:43 2025 -0700
>
> Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests
>
> [ Upstream commit 96959283a58d91ae20d025546f00e16f0a555208 ]
>
> The Hyper-V host provides guest VMs with a range of MMIO addresses
> that guest VMBus drivers can use. The VMBus driver in Linux manages
> that MMIO space, and allocates portions to drivers upon request. As
> part of managing that MMIO space in a Generation 2 VM, the VMBus
> driver must reserve the portion of the MMIO space that Hyper-V has
> designated for the synthetic frame buffer, and not allocate this
> space to VMBus drivers other than graphics framebuffer drivers. The
> synthetic frame buffer MMIO area is described by the screen_info data
> structure that is passed to the Linux kernel at boot time, so the
> VMBus driver must access screen_info for Generation 2 VMs. (In
> Generation 1 VMs, the framebuffer MMIO space is communicated to
> the guest via a PCI pseudo-device, and access to screen_info is
> not needed.)
>
> In commit a07b50d80ab6 ("hyperv: avoid dependency on screen_info")
> the VMBus driver's access to screen_info is restricted to when
> CONFIG_SYSFB is enabled. CONFIG_SYSFB is typically enabled in kernels
> built for Hyper-V by virtue of having at least one of CONFIG_FB_EFI,
> CONFIG_FB_VESA, or CONFIG_SYSFB_SIMPLEFB enabled, so the restriction
> doesn't usually affect anything. But it's valid to have none of these
> enabled, in which case CONFIG_SYSFB is not enabled, and the VMBus driver
> is unable to properly reserve the framebuffer MMIO space for graphics
> framebuffer drivers. The framebuffer MMIO space may be assigned to
> some other VMBus driver, with undefined results. As an example, if
> a VM is using a PCI pass-thru NVMe controller to host the OS disk,
> the PCI NVMe controller is probed before any graphics devices, and the
> NVMe controller is assigned a portion of the framebuffer MMIO space.
> Hyper-V reports an error to Linux during the probe, and the OS disk
> fails to get setup. Then Linux fails to boot in the VM.
>
> Fix this by having CONFIG_HYPERV always select SYSFB. Then the
> VMBus driver in a Gen 2 VM can always reserve the MMIO space for the
> graphics framebuffer driver, and prevent the undefined behavior. But
> don't select SYSFB when building for HYPERV_VTL_MODE as VTLs other
> than VTL 0 don't have a framebuffer and aren't subject to the issue.
> Adding SYSFB in such cases is harmless, but would increase the image
> size for no purpose.
>
> Fixes: a07b50d80ab6 ("hyperv: avoid dependency on screen_info")
> Signed-off-by: Michael Kelley <mhklinux(a)outlook.com>
> Reviewed-by: Saurabh Sengar <ssengar(a)linux.microsoft.com>
> Link:
> https://lore.kernel.org/st
> able%2F20250520040143.6964-1-
> mhklinux%2540outlook.com&data=05%7C02%7C%7C516ef64661c145eb315d08dda81861
> 51%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638851544842065319%7CUn
> known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa
> W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FZnrM9REMICWp
> JqW88gD7CxeTwcztS2y8%2B8GqHNtF3E%3D&reserved=0
> Link:
> https://lore.kernel.org/r%25
> 2F20250520040143.6964-1-
> mhklinux%40outlook.com&data=05%7C02%7C%7C516ef64661c145eb315d08dda8186151
> %7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638851544842081386%7CUnkn
> own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4
> zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=j%2F5AvOlxwTKfVUL
> vmNr%2FZliwRVrd9rSlVECyFGqFErE%3D&reserved=0
> Signed-off-by: Wei Liu <wei.liu(a)kernel.org>
> Message-ID: <20250520040143.6964-1-mhklinux(a)outlook.com>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 6c1416167bd2e..724fc08a73e70 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -9,6 +9,7 @@ config HYPERV
> select PARAVIRT
> select X86_HV_CALLBACK_VECTOR if X86
> select OF_EARLY_FLATTREE if OF
> + select SYSFB if !HYPERV_VTL_MODE
> help
> Select this option to run Linux as a Hyper-V client operating
> system.