Currently afunc_bind sets std_ac_if_desc.bNumEndpoints to 1 if
controls (mute/volume) are enabled. During next afunc_bind call,
bNumEndpoints would be unchanged and incorrectly set to 1 even
if the controls aren't enabled.
Fix this by resetting the value of bNumEndpoints to 0 on every
afunc_bind call.
Fixes: eaf6cbe09920 ("usb: gadget: f_uac2: add volume and mute support")
Cc: stable(a)vger.kernel.org
Signed-off-by: Prashanth K <quic_prashk(a)quicinc.com>
---
drivers/usb/gadget/function/f_uac2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/function/f_uac2.c b/drivers/usb/gadget/function/f_uac2.c
index ce5b77f89190..9b324821c93b 100644
--- a/drivers/usb/gadget/function/f_uac2.c
+++ b/drivers/usb/gadget/function/f_uac2.c
@@ -1185,6 +1185,7 @@ afunc_bind(struct usb_configuration *cfg, struct usb_function *fn)
uac2->as_in_alt = 0;
}
+ std_ac_if_desc.bNumEndpoints = 0;
if (FUOUT_EN(uac2_opts) || FUIN_EN(uac2_opts)) {
uac2->int_ep = usb_ep_autoconfig(gadget, &fs_ep_int_desc);
if (!uac2->int_ep) {
--
2.25.1
On Tue, 2024-12-10 at 15:41 -0500, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> drm/sched: memset() 'job' in drm_sched_job_init()
>
> to the 6.12-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:
> drm-sched-memset-job-in-drm_sched_job_init.patch
> and it can be found in the queue-6.12 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.
Hi,
you can add it, it does improve things a bit.
But I'd like to use this opportunity to understand by what criteria you
found and selected this patch? Stable was not on CC, neither does the
patch contain a Fixes tag.
Regards,
P.
>
>
>
> commit d0a6c893de0172427064e39be400a23b0ba5ffec
> Author: Philipp Stanner <pstanner(a)redhat.com>
> Date: Mon Oct 21 12:50:28 2024 +0200
>
> drm/sched: memset() 'job' in drm_sched_job_init()
>
> [ Upstream commit 2320c9e6a768d135c7b0039995182bb1a4e4fd22 ]
>
> drm_sched_job_init() has no control over how users allocate
> struct
> drm_sched_job. Unfortunately, the function can also not set some
> struct
> members such as job->sched.
>
> This could theoretically lead to UB by users dereferencing the
> struct's
> pointer members too early.
>
> It is easier to debug such issues if these pointers are
> initialized to
> NULL, so dereferencing them causes a NULL pointer exception.
> Accordingly, drm_sched_entity_init() does precisely that and
> initializes
> its struct with memset().
>
> Initialize parameter "job" to 0 in drm_sched_job_init().
>
> Signed-off-by: Philipp Stanner <pstanner(a)redhat.com>
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20241021105028.19794-2-pstann…
> Reviewed-by: Christian König <christian.koenig(a)amd.com>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index e97c6c60bc96e..416590ea0dc3d 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -803,6 +803,14 @@ int drm_sched_job_init(struct drm_sched_job
> *job,
> return -EINVAL;
> }
>
> + /*
> + * We don't know for sure how the user has allocated. Thus,
> zero the
> + * struct so that unallowed (i.e., too early) usage of
> pointers that
> + * this function does not set is guaranteed to lead to a
> NULL pointer
> + * exception instead of UB.
> + */
> + memset(job, 0, sizeof(*job));
> +
> job->entity = entity;
> job->credits = credits;
> job->s_fence = drm_sched_fence_alloc(entity, owner);
>
zram writeback is a costly operation, because every target slot
(unless ZRAM_HUGE) is decompressed before it gets written to a
backing device. The writeback to a backing device uses
submit_bio_wait() which may look like a rescheduling point.
However, if the backing device has BD_HAS_SUBMIT_BIO bit set
__submit_bio() calls directly disk->fops->submit_bio(bio) on
the backing device and so when submit_bio_wait() calls
blk_wait_io() the I/O is already done. On such systems we
effective end up in a loop
for_each (target slot) {
decompress(slot)
__submit_bio()
disk->fops->submit_bio(bio)
}
Which on PREEMPT_NONE systems triggers watchdogs (since there
are no explicit rescheduling points). Add cond_resched() to
the zram writeback loop.
Fixes: a939888ec38b ("zram: support idle/huge page writeback")
Cc: stable(a)vger.kernel.org
Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org>
---
drivers/block/zram/zram_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 0a924fae02a4..f5fa3db6b4f8 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -884,6 +884,8 @@ static ssize_t writeback_store(struct device *dev,
next:
zram_slot_unlock(zram, index);
release_pp_slot(zram, pps);
+
+ cond_resched();
}
if (blk_idx)
--
2.47.1.613.gc27f4b7a9f-goog