October 2023 - Linux-stable-mirror

[PATCH v4.19.y 1/6] driver: platform: Add helper for safer setting of driver_override

by Lee Jones

From: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> commit 6c2f421174273de8f83cde4286d1c076d43a2d35 upstream. Several core drivers and buses expect that driver_override is a dynamically allocated memory thus later they can kfree() it. However such assumption is not documented, there were in the past and there are already users setting it to a string literal. This leads to kfree() of static memory during device release (e.g. in error paths or during unbind): kernel BUG at ../mm/slub.c:3960! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM ... (kfree) from [<c058da50>] (platform_device_release+0x88/0xb4) (platform_device_release) from [<c0585be0>] (device_release+0x2c/0x90) (device_release) from [<c0a69050>] (kobject_put+0xec/0x20c) (kobject_put) from [<c0f2f120>] (exynos5_clk_probe+0x154/0x18c) (exynos5_clk_probe) from [<c058de70>] (platform_drv_probe+0x6c/0xa4) (platform_drv_probe) from [<c058b7ac>] (really_probe+0x280/0x414) (really_probe) from [<c058baf4>] (driver_probe_device+0x78/0x1c4) (driver_probe_device) from [<c0589854>] (bus_for_each_drv+0x74/0xb8) (bus_for_each_drv) from [<c058b48c>] (__device_attach+0xd4/0x16c) (__device_attach) from [<c058a638>] (bus_probe_device+0x88/0x90) (bus_probe_device) from [<c05871fc>] (device_add+0x3dc/0x62c) (device_add) from [<c075ff10>] (of_platform_device_create_pdata+0x94/0xbc) (of_platform_device_create_pdata) from [<c07600ec>] (of_platform_bus_create+0x1a8/0x4fc) (of_platform_bus_create) from [<c0760150>] (of_platform_bus_create+0x20c/0x4fc) (of_platform_bus_create) from [<c07605f0>] (of_platform_populate+0x84/0x118) (of_platform_populate) from [<c0f3c964>] (of_platform_default_populate_init+0xa0/0xb8) (of_platform_default_populate_init) from [<c01031f8>] (do_one_initcall+0x8c/0x404) Provide a helper which clearly documents the usage of driver_override. This will allow later to reuse the helper and reduce the amount of duplicated code. Convert the platform driver to use a new helper and make the driver_override field const char (it is not modified by the core). Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Link: https://lore.kernel.org/r/20220419113435.246203-2-krzysztof.kozlowski@linar… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lee Jones <lee(a)kernel.org> Change-Id: I2f59769cfb99d8359d14e2cb7345ce3428593afc --- drivers/base/driver.c | 69 +++++++++++++++++++++++++++++++++ drivers/base/platform.c | 28 ++----------- include/linux/device.h | 2 + include/linux/platform_device.h | 6 ++- 4 files changed, 80 insertions(+), 25 deletions(-) diff --git a/drivers/base/driver.c b/drivers/base/driver.c index 857c8f1b876e5..668c6c8c22f1f 100644 --- a/drivers/base/driver.c +++ b/drivers/base/driver.c @@ -29,6 +29,75 @@ static struct device *next_device(struct klist_iter *i) return dev; } +/** + * driver_set_override() - Helper to set or clear driver override. + * @dev: Device to change + * @override: Address of string to change (e.g. &device->driver_override); + * The contents will be freed and hold newly allocated override. + * @s: NUL-terminated string, new driver name to force a match, pass empty + * string to clear it ("" or "\n", where the latter is only for sysfs + * interface). + * @len: length of @s + * + * Helper to set or clear driver override in a device, intended for the cases + * when the driver_override field is allocated by driver/bus code. + * + * Returns: 0 on success or a negative error code on failure. + */ +int driver_set_override(struct device *dev, const char **override, + const char *s, size_t len) +{ + const char *new, *old; + char *cp; + + if (!override || !s) + return -EINVAL; + + /* + * The stored value will be used in sysfs show callback (sysfs_emit()), + * which has a length limit of PAGE_SIZE and adds a trailing newline. + * Thus we can store one character less to avoid truncation during sysfs + * show. + */ + if (len >= (PAGE_SIZE - 1)) + return -EINVAL; + + if (!len) { + /* Empty string passed - clear override */ + device_lock(dev); + old = *override; + *override = NULL; + device_unlock(dev); + kfree(old); + + return 0; + } + + cp = strnchr(s, len, '\n'); + if (cp) + len = cp - s; + + new = kstrndup(s, len, GFP_KERNEL); + if (!new) + return -ENOMEM; + + device_lock(dev); + old = *override; + if (cp != s) { + *override = new; + } else { + /* "\n" passed - clear override */ + kfree(new); + *override = NULL; + } + device_unlock(dev); + + kfree(old); + + return 0; +} +EXPORT_SYMBOL_GPL(driver_set_override); + /** * driver_for_each_device - Iterator for devices bound to a driver. * @drv: Driver we're iterating. diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 2f89e618b142c..a09e7a681f7a7 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -891,31 +891,11 @@ static ssize_t driver_override_store(struct device *dev, const char *buf, size_t count) { struct platform_device *pdev = to_platform_device(dev); - char *driver_override, *old, *cp; - - /* We need to keep extra room for a newline */ - if (count >= (PAGE_SIZE - 1)) - return -EINVAL; - - driver_override = kstrndup(buf, count, GFP_KERNEL); - if (!driver_override) - return -ENOMEM; - - cp = strchr(driver_override, '\n'); - if (cp) - *cp = '\0'; - - device_lock(dev); - old = pdev->driver_override; - if (strlen(driver_override)) { - pdev->driver_override = driver_override; - } else { - kfree(driver_override); - pdev->driver_override = NULL; - } - device_unlock(dev); + int ret; - kfree(old); + ret = driver_set_override(dev, &pdev->driver_override, buf, count); + if (ret) + return ret; return count; } diff --git a/include/linux/device.h b/include/linux/device.h index 37e359d81a86f..bccd367c11de5 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -330,6 +330,8 @@ extern int __must_check driver_create_file(struct device_driver *driver, extern void driver_remove_file(struct device_driver *driver, const struct driver_attribute *attr); +int driver_set_override(struct device *dev, const char **override, + const char *s, size_t len); extern int __must_check driver_for_each_device(struct device_driver *drv, struct device *start, void *data, diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index 9e5c98fcea8c6..8268439975b21 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -29,7 +29,11 @@ struct platform_device { struct resource *resource; const struct platform_device_id *id_entry; - char *driver_override; /* Driver name to force a match */ + /* + * Driver name to force a match. Do not set directly, because core + * frees it. Use driver_set_override() to set or clear it. + */ + const char *driver_override; /* MFD cell pointer */ struct mfd_cell *mfd_cell; -- 2.42.0.820.g83a721a137-goog

2 years

1
6
0 0

[PATCH stable 5.15 0/7] can: isotp: upgrade to latest 6.1 LTS code base

by Oliver Hartkopp

The backport of commit 9c5df2f14ee3 ("can: isotp: isotp_ops: fix poll() to not report false EPOLLOUT events") introduced a new regression where the fix could potentially introduce new side effects. To reduce the risk of other unmet dependencies and missing fixes and checks the latest 6.1 LTS code base is ported back to the 5.15 LTS tree. Lukas Magel (1): can: isotp: isotp_sendmsg(): fix TX state detection and wait behavior Oliver Hartkopp (6): can: isotp: set max PDU size to 64 kByte can: isotp: isotp_bind(): return -EINVAL on incorrect CAN ID formatting can: isotp: check CAN address family in isotp_bind() can: isotp: handle wait_event_interruptible() return values can: isotp: add local echo tx processing and tx without FC can: isotp: isotp_bind(): do not validate unused address information include/uapi/linux/can/isotp.h | 25 +- net/can/isotp.c | 426 +++++++++++++++++++++------------ 2 files changed, 288 insertions(+), 163 deletions(-) -- 2.34.1

2 years

1
7
0 0

[PATCH v2 3/3] media: mtk-jpeg: Fix timeout schedule error in mtk_jpegdec_worker.

by Zheng Wang

In mtk_jpegdec_worker, if error occurs in mtk_jpeg_set_dec_dst, it will start the timeout worker and invoke v4l2_m2m_job_finish at the same time. This will break the logic of design for there should be only one function to call v4l2_m2m_job_finish. But now the timeout handler and mtk_jpegdec_worker will both invoke it. Fix it by start the worker only if mtk_jpeg_set_dec_dst successfully finished. Fixes: da4ede4b7fd6 ("media: mtk-jpeg: move data/code inside CONFIG_OF blocks") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Cc: stable(a)vger.kernel.org --- v2: - put the patches into a single series suggested by Dmitry --- drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c index a39acde2724a..c3456c700c07 100644 --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c @@ -1749,9 +1749,6 @@ static void mtk_jpegdec_worker(struct work_struct *work) v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx); v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx); - schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work, - msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); - mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs); if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, @@ -1761,6 +1758,9 @@ static void mtk_jpegdec_worker(struct work_struct *work) goto setdst_end; } + schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work, + msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); + spin_lock_irqsave(&comp_jpeg[hw_id]->hw_lock, flags); ctx->total_frame_num++; mtk_jpeg_dec_reset(comp_jpeg[hw_id]->reg_base); -- 2.25.1

2 years

1
0
0 0

[PATCH v2 2/3] media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run

by Zheng Wang

In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. In mtk_jpeg_dec_device_run, if error happens in mtk_jpeg_set_dec_dst, it will finally start the worker while mark the job as finished by invoking v4l2_m2m_job_finish. There are two methods to trigger the bug. If we remove the module, it which will call mtk_jpeg_remove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug. CPU0 CPU1 mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use If we close the file descriptor, which will call mtk_jpeg_release, it will have a similar sequence. Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2_m2m_job_finish will only be called in either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run. Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Cc: stable(a)vger.kernel.org --- v2: - put the patches into a single series suggested by Dmitry --- drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c index 60425c99a2b8..a39acde2724a 100644 --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c @@ -1021,13 +1021,13 @@ static void mtk_jpeg_dec_device_run(void *priv) if (ret < 0) goto dec_end; - schedule_delayed_work(&jpeg->job_timeout_work, - msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); - mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs); if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, &dst_buf->vb2_buf, &fb)) goto dec_end; + schedule_delayed_work(&jpeg->job_timeout_work, + msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); + spin_lock_irqsave(&jpeg->hw_lock, flags); mtk_jpeg_dec_reset(jpeg->reg_base); mtk_jpeg_dec_set_config(jpeg->reg_base, -- 2.25.1

2 years

1
0
0 0

[PATCH v2 3/3] media: mtk-jpeg: Fix timeout schedule error in

by Zheng Wang

In mtk_jpegdec_worker, if error occurs in mtk_jpeg_set_dec_dst, it will start the timeout worker and invoke v4l2_m2m_job_finish at the same time. This will break the logic of design for there should be only one function to call v4l2_m2m_job_finish. But now the timeout handler and mtk_jpegdec_worker will both invoke it. Fix it by start the worker only if mtk_jpeg_set_dec_dst successfully finished. Fixes: da4ede4b7fd6 ("media: mtk-jpeg: move data/code inside CONFIG_OF blocks") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Cc: stable(a)vger.kernel.org --- v2: - put the patches into a single series suggested by Dmitry --- drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c index a39acde2724a..c3456c700c07 100644 --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c @@ -1749,9 +1749,6 @@ static void mtk_jpegdec_worker(struct work_struct *work) v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx); v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx); - schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work, - msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); - mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs); if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, @@ -1761,6 +1758,9 @@ static void mtk_jpegdec_worker(struct work_struct *work) goto setdst_end; } + schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work, + msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); + spin_lock_irqsave(&comp_jpeg[hw_id]->hw_lock, flags); ctx->total_frame_num++; mtk_jpeg_dec_reset(comp_jpeg[hw_id]->reg_base); -- 2.25.1

2 years

1
0
0 0

[PATCH v2 2/3] media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run

by Zheng Wang

In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. In mtk_jpeg_dec_device_run, if error happens in mtk_jpeg_set_dec_dst, it will finally start the worker while mark the job as finished by invoking v4l2_m2m_job_finish. There are two methods to trigger the bug. If we remove the module, it which will call mtk_jpeg_remove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug. CPU0 CPU1 mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use If we close the file descriptor, which will call mtk_jpeg_release, it will have a similar sequence. Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2_m2m_job_finish will only be called in either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run. Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Cc: stable(a)vger.kernel.org --- v2: - put the patches into a single series suggested by Dmitry --- drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c index 60425c99a2b8..a39acde2724a 100644 --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c @@ -1021,13 +1021,13 @@ static void mtk_jpeg_dec_device_run(void *priv) if (ret < 0) goto dec_end; - schedule_delayed_work(&jpeg->job_timeout_work, - msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); - mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs); if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, &dst_buf->vb2_buf, &fb)) goto dec_end; + schedule_delayed_work(&jpeg->job_timeout_work, + msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); + spin_lock_irqsave(&jpeg->hw_lock, flags); mtk_jpeg_dec_reset(jpeg->reg_base); mtk_jpeg_dec_set_config(jpeg->reg_base, -- 2.25.1

2 years

1
0
0 0

[PATCH v2 3/3] media: mtk-jpeg: Fix timeout schedule error in

by Zheng Wang

In mtk_jpegdec_worker, if error occurs in mtk_jpeg_set_dec_dst, it will start the timeout worker and invoke v4l2_m2m_job_finish at the same time. This will break the logic of design for there should be only one function to call v4l2_m2m_job_finish. But now the timeout handler and mtk_jpegdec_worker will both invoke it. Fix it by start the worker only if mtk_jpeg_set_dec_dst successfully finished. Fixes: da4ede4b7fd6 ("media: mtk-jpeg: move data/code inside CONFIG_OF blocks") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Cc: stable(a)vger.kernel.org --- v2: - put the patches into a single series suggested by Dmitry --- drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c index a39acde2724a..c3456c700c07 100644 --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c @@ -1749,9 +1749,6 @@ static void mtk_jpegdec_worker(struct work_struct *work) v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx); v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx); - schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work, - msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); - mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs); if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, @@ -1761,6 +1758,9 @@ static void mtk_jpegdec_worker(struct work_struct *work) goto setdst_end; } + schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work, + msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); + spin_lock_irqsave(&comp_jpeg[hw_id]->hw_lock, flags); ctx->total_frame_num++; mtk_jpeg_dec_reset(comp_jpeg[hw_id]->reg_base); -- 2.25.1

2 years

1
0
0 0

[PATCH v2 2/3] media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run

by Zheng Wang

In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. In mtk_jpeg_dec_device_run, if error happens in mtk_jpeg_set_dec_dst, it will finally start the worker while mark the job as finished by invoking v4l2_m2m_job_finish. There are two methods to trigger the bug. If we remove the module, it which will call mtk_jpeg_remove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug. CPU0 CPU1 mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use If we close the file descriptor, which will call mtk_jpeg_release, it will have a similar sequence. Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2_m2m_job_finish will only be called in either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run. Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Cc: stable(a)vger.kernel.org --- v2: - put the patches into a single series suggested by Dmitry --- drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c index 60425c99a2b8..a39acde2724a 100644 --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c @@ -1021,13 +1021,13 @@ static void mtk_jpeg_dec_device_run(void *priv) if (ret < 0) goto dec_end; - schedule_delayed_work(&jpeg->job_timeout_work, - msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); - mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs); if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, &dst_buf->vb2_buf, &fb)) goto dec_end; + schedule_delayed_work(&jpeg->job_timeout_work, + msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); + spin_lock_irqsave(&jpeg->hw_lock, flags); mtk_jpeg_dec_reset(jpeg->reg_base); mtk_jpeg_dec_set_config(jpeg->reg_base, -- 2.25.1

2 years

1
0
0 0

Re: [PATCH v1] perf evlist: Avoid frequency mode for the dummy event

by Mingwei Zhang

On Mon, Oct 30, 2023 at 12:04 PM Mingwei Zhang <mizhang(a)google.com> wrote: > > On Fri, Sep 15, 2023 at 9:10 PM Ian Rogers <irogers(a)google.com> wrote: > > > > Dummy events are created with an attribute where the period and freq > > are zero. evsel__config will then see the uninitialized values and > > initialize them in evsel__default_freq_period. As fequency mode is > > used by default the dummy event would be set to use frequency > > mode. However, this has no effect on the dummy event but does cause > > unnecessary timers/interrupts. Avoid this overhead by setting the > > period to 1 for dummy events. > > > > evlist__add_aux_dummy calls evlist__add_dummy then sets freq=0 and > > period=1. This isn't necessary after this change and so the setting is > > removed. > > > > From Stephane: > > > > The dummy event is not counting anything. It is used to collect mmap > > records and avoid a race condition during the synthesize mmap phase of > > perf record. As such, it should not cause any overhead during active > > profiling. Yet, it did. Because of a bug the dummy event was > > programmed as a sampling event in frequency mode. Events in that mode > > incur more kernel overheads because on timer tick, the kernel has to > > look at the number of samples for each event and potentially adjust > > the sampling period to achieve the desired frequency. The dummy event > > was therefore adding a frequency event to task and ctx contexts we may > > otherwise not have any, e.g., perf record -a -e > > cpu/event=0x3c,period=10000000/. On each timer tick the > > perf_adjust_freq_unthr_context() is invoked and if ctx->nr_freq is > > non-zero, then the kernel will loop over ALL the events of the context > > looking for frequency mode ones. In doing, so it locks the context, > > and enable/disable the PMU of each hw event. If all the events of the > > context are in period mode, the kernel will have to traverse the list for > > nothing incurring overhead. The overhead is multiplied by a very large > > factor when this happens in a guest kernel. There is no need for the > > dummy event to be in frequency mode, it does not count anything and > > therefore should not cause extra overhead for no reason. > > > > Fixes: 5bae0250237f ("perf evlist: Introduce perf_evlist__new_dummy constructor") > > Reported-by: Stephane Eranian <eranian(a)google.com> > > Signed-off-by: Ian Rogers <irogers(a)google.com> > > --- > > tools/perf/util/evlist.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c > > index 25c3ebe2c2f5..e36da58522ef 100644 > > --- a/tools/perf/util/evlist.c > > +++ b/tools/perf/util/evlist.c > > @@ -251,6 +251,9 @@ static struct evsel *evlist__dummy_event(struct evlist *evlist) > > .type = PERF_TYPE_SOFTWARE, > > .config = PERF_COUNT_SW_DUMMY, > > .size = sizeof(attr), /* to capture ABI version */ > > + /* Avoid frequency mode for dummy events to avoid associated timers. */ > > + .freq = 0, > > + .sample_period = 1, > > }; > > > > return evsel__new_idx(&attr, evlist->core.nr_entries); > > @@ -277,8 +280,6 @@ struct evsel *evlist__add_aux_dummy(struct evlist *evlist, bool system_wide) > > evsel->core.attr.exclude_kernel = 1; > > evsel->core.attr.exclude_guest = 1; > > evsel->core.attr.exclude_hv = 1; > > - evsel->core.attr.freq = 0; > > - evsel->core.attr.sample_period = 1; > > evsel->core.system_wide = system_wide; > > evsel->no_aux_samples = true; > > evsel->name = strdup("dummy:u"); > > -- > > 2.42.0.459.ge4e396fd5e-goog > > > > Hi Greg, > > This patch is a critical performance fix for perf and vPMU. Can you > help us dispatch the commit to all stable kernel versions? > > Appreciate your help. Thanks. > -Mingwei Oops... Update target email to: stable(a)vger.kernel.org

2 years

2
1
0 0

Re: Security Fix Backport: Intel RDMA driver

by Greg KH

On Mon, Oct 30, 2023 at 04:47:01PM +0000, Saleem, Shiraz wrote: > Hi, > > There was a security bug fix recently made to the Intel RDMA driver (irdma) that has made to mainline. > > https://github.com/torvalds/linux/commit/bb6d73d9add68ad270888db327514384df… > subject: RDMA/irdma: Prevent zero-length STAG registration > commit-id: bb6d73d9add68ad270888db327514384dfa44958 > > This problem in theory is possible in i40iw as well. i40iw is replaced with irdma upstream since 5.14. > > However, i40iw is still part of LTS 4.14.x, 4.19.x, 5.4.x, and 5.10. Since it is a security fix, I am thinking its reasonable we backport it to i40iw too for these kernels. The patch would need some adjustments and I can do this if required. If you feel it is needed, yes, please do the needed backport and submit it here. thanks, greg k-h

2 years

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023