March 2021 - Linux-stable-mirror

[PATCH v2 4.19 0/3] dm table: fix iterate_devices based device

by Jeffle Xu

Backport notes are detailed in the corresponding commit log. changes since v1: - fix build error of patch 1 - fix upstream commit id of patch 2 Jeffle Xu (3): dm table: fix iterate_devices based device capability checks dm table: fix DAX iterate_devices based device capability checks dm table: fix zoned iterate_devices based device capability checks drivers/md/dm-table.c | 174 ++++++++++++++++++------------------------ 1 file changed, 73 insertions(+), 101 deletions(-) -- 2.27.0

3 years, 7 months

2
4
0 0

few missing commits for 5.10-stable

by Sudip Mukherjee

Hi Greg, These were missing in 5.10-stable and 5.11-stable. dc22c1c058b5 ("nvme-pci: mark Kingston SKC2000 as not supporting the deepest power state") - Not marked for stable but looks like it should be there. 778e45d7720d ("parisc: Enable -mlong-calls gcc option with CONFIG_COMPILE_TEST") e9c6deee00e9 ("arm64: Make CPU_BIG_ENDIAN depend on ld.bfd or ld.lld 13.0.0+") - Not marked for stable, but 5.10-stable and 5.11-stable should have the same problem. 80e9baed722c ("btrfs: export and rename qgroup_reserve_meta") - only needed for the next patch. 4d14c5cde5c2 ("btrfs: don't flush from btrfs_delayed_inode_reserve_metadata") -- Regards Sudip

3 years, 7 months

2
1
0 0

[PATCH v2] ASoC: SOF: Intel: broadwell: fix mutual exclusion with catpt driver

by Pierre-Louis Bossart

In v5.10, the "haswell" driver was replaced by the "catpt" driver, but the mutual exclusion with the SOF driver was not updated. This leads to errors with card names and UCM profiles not being loaded by PulseAudio. This fix should only be applied on v5.10-stable, the mutual exclusion was removed in 5.11. Reported-by: David Ward <david.ward(a)ll.mit.edu> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211985 Fixes: 6cbfa11d2694 ("ASoC: Intel: Select catpt and deprecate haswell") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Cezary Rojewski <cezary.rojewski(a)intel.com> Acked-by: Mark Brown <broonie(a)kernel.org> Cc: <stable(a)vger.kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Sasha Levin <sashal(a)kernel.org> --- v2: added Mark and Cezary tags, fixed stable address, added maintainers sound/soc/sof/intel/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/intel/Kconfig b/sound/soc/sof/intel/Kconfig index de7ff2d097ab..6708a2c5a838 100644 --- a/sound/soc/sof/intel/Kconfig +++ b/sound/soc/sof/intel/Kconfig @@ -84,7 +84,7 @@ config SND_SOC_SOF_BAYTRAIL config SND_SOC_SOF_BROADWELL_SUPPORT bool "SOF support for Broadwell" - depends on SND_SOC_INTEL_HASWELL=n + depends on SND_SOC_INTEL_CATPT=n help This adds support for Sound Open Firmware for Intel(R) platforms using the Broadwell processors. -- 2.25.1

3 years, 7 months

2
1
0 0

[PATCH FOR stable v5.11] media: cedrus: Remove checking for required controls

by Hans Verkuil

From: Jernej Skrabec <jernej.skrabec(a)siol.net> [ Upstream commit 7072db89572135f28cad65f15877bf7e67cf2ff8 ] According to v4l2 request api specifications, it's allowed to skip control if its content isn't changed for performance reasons. Cedrus driver predates that, so it has implemented mechanism to check if all required controls are included in one request. Conform to specifications with removing that mechanism. Note that this mechanism with static required flag isn't very good anyway because need for control is usually signaled in other controls. Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Cc: stable(a)vger.kernel.org Signed-off-by: Jernej Skrabec <jernej.skrabec(a)siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> --- Without this patch the H264 cedrus support is non-compliant, and since 5.11 was the first kernel with a stable H264 stateless codec ABI it would be good to have this merged for 5.11 so the cedrus driver can be used with H264. --- drivers/staging/media/sunxi/cedrus/cedrus.c | 49 --------------------- drivers/staging/media/sunxi/cedrus/cedrus.h | 1 - 2 files changed, 50 deletions(-) diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c index ddad5d274ee8..7bd9291c8d5f 100644 --- a/drivers/staging/media/sunxi/cedrus/cedrus.c +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c @@ -34,56 +34,48 @@ static const struct cedrus_control cedrus_controls[] = { .id = V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS, }, .codec = CEDRUS_CODEC_MPEG2, - .required = true, }, { .cfg = { .id = V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION, }, .codec = CEDRUS_CODEC_MPEG2, - .required = false, }, { .cfg = { .id = V4L2_CID_STATELESS_H264_DECODE_PARAMS, }, .codec = CEDRUS_CODEC_H264, - .required = true, }, { .cfg = { .id = V4L2_CID_STATELESS_H264_SLICE_PARAMS, }, .codec = CEDRUS_CODEC_H264, - .required = true, }, { .cfg = { .id = V4L2_CID_STATELESS_H264_SPS, }, .codec = CEDRUS_CODEC_H264, - .required = true, }, { .cfg = { .id = V4L2_CID_STATELESS_H264_PPS, }, .codec = CEDRUS_CODEC_H264, - .required = true, }, { .cfg = { .id = V4L2_CID_STATELESS_H264_SCALING_MATRIX, }, .codec = CEDRUS_CODEC_H264, - .required = false, }, { .cfg = { .id = V4L2_CID_STATELESS_H264_PRED_WEIGHTS, }, .codec = CEDRUS_CODEC_H264, - .required = false, }, { .cfg = { @@ -92,7 +84,6 @@ static const struct cedrus_control cedrus_controls[] = { .def = V4L2_STATELESS_H264_DECODE_MODE_SLICE_BASED, }, .codec = CEDRUS_CODEC_H264, - .required = false, }, { .cfg = { @@ -101,7 +92,6 @@ static const struct cedrus_control cedrus_controls[] = { .def = V4L2_STATELESS_H264_START_CODE_NONE, }, .codec = CEDRUS_CODEC_H264, - .required = false, }, /* * We only expose supported profiles information, @@ -120,28 +110,24 @@ static const struct cedrus_control cedrus_controls[] = { BIT(V4L2_MPEG_VIDEO_H264_PROFILE_EXTENDED), }, .codec = CEDRUS_CODEC_H264, - .required = false, }, { .cfg = { .id = V4L2_CID_MPEG_VIDEO_HEVC_SPS, }, .codec = CEDRUS_CODEC_H265, - .required = true, }, { .cfg = { .id = V4L2_CID_MPEG_VIDEO_HEVC_PPS, }, .codec = CEDRUS_CODEC_H265, - .required = true, }, { .cfg = { .id = V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS, }, .codec = CEDRUS_CODEC_H265, - .required = true, }, { .cfg = { @@ -150,7 +136,6 @@ static const struct cedrus_control cedrus_controls[] = { .def = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_SLICE_BASED, }, .codec = CEDRUS_CODEC_H265, - .required = false, }, { .cfg = { @@ -159,14 +144,12 @@ static const struct cedrus_control cedrus_controls[] = { .def = V4L2_MPEG_VIDEO_HEVC_START_CODE_NONE, }, .codec = CEDRUS_CODEC_H265, - .required = false, }, { .cfg = { .id = V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER, }, .codec = CEDRUS_CODEC_VP8, - .required = true, }, }; @@ -227,12 +210,8 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct cedrus_ctx *ctx) static int cedrus_request_validate(struct media_request *req) { struct media_request_object *obj; - struct v4l2_ctrl_handler *parent_hdl, *hdl; struct cedrus_ctx *ctx = NULL; - struct v4l2_ctrl *ctrl_test; unsigned int count; - unsigned int i; - int ret = 0; list_for_each_entry(obj, &req->objects, list) { struct vb2_buffer *vb; @@ -259,34 +238,6 @@ static int cedrus_request_validate(struct media_request *req) return -EINVAL; } - parent_hdl = &ctx->hdl; - - hdl = v4l2_ctrl_request_hdl_find(req, parent_hdl); - if (!hdl) { - v4l2_info(&ctx->dev->v4l2_dev, "Missing codec control(s)\n"); - return -ENOENT; - } - - for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) { - if (cedrus_controls[i].codec != ctx->current_codec || - !cedrus_controls[i].required) - continue; - - ctrl_test = v4l2_ctrl_request_hdl_ctrl_find(hdl, - cedrus_controls[i].cfg.id); - if (!ctrl_test) { - v4l2_info(&ctx->dev->v4l2_dev, - "Missing required codec control\n"); - ret = -ENOENT; - break; - } - } - - v4l2_ctrl_request_hdl_put(hdl); - - if (ret) - return ret; - return vb2_request_validate(req); } diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h b/drivers/staging/media/sunxi/cedrus/cedrus.h index c96077aaef49..251a6a660351 100644 --- a/drivers/staging/media/sunxi/cedrus/cedrus.h +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h @@ -56,7 +56,6 @@ enum cedrus_h264_pic_type { struct cedrus_control { struct v4l2_ctrl_config cfg; enum cedrus_codec codec; - unsigned char required:1; }; struct cedrus_h264_run { -- 2.30.1

3 years, 7 months

2
1
0 0

[PATCH stable-5.11 0/9] stable-5.11 backports

by Pavel Begunkov

5-6/9 were forgotten to be marked for-stable. Others are 5 out of 6 failed to apply + dependencies. Jens Axboe (3): fs: provide locked helper variant of close_fd_get_file() io_uring: get rid of intermediate IORING_OP_CLOSE stage io_uring/io-wq: kill off now unused IO_WQ_WORK_NO_CANCEL Pavel Begunkov (6): io_uring: fix inconsistent lock state io_uring: deduplicate core cancellations sequence io_uring: unpark SQPOLL thread for cancelation io_uring: deduplicate failing task_work_add io_uring/io-wq: return 2-step work swap scheme io_uring: don't take uring_lock during iowq cancel fs/file.c | 36 +++++--- fs/internal.h | 1 + fs/io-wq.c | 17 ++-- fs/io-wq.h | 5 +- fs/io_uring.c | 241 +++++++++++++++++++++++--------------------------- 5 files changed, 145 insertions(+), 155 deletions(-) -- 2.24.0

3 years, 7 months

2
11
0 0

[PATCH net/net-next 2/4] FDDI: defxx: Make MMIO the configuration default except for EISA

by Maciej W. Rozycki

Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. The default kernel configuration choice for the defxx driver is the use of I/O ports rather than MMIO for PCI and EISA systems. It may have made sense as a conservative backwards compatible choice back when MMIO operation support was added to the driver as a part of TURBOchannel bus support. However nowadays this configuration choice makes the driver unusable with systems that do not implement I/O transactions for PCIe. Make DEFXX_MMIO the configuration default then, except where configured for EISA. This exception is because an EISA adapter can have its MMIO decoding disabled with ECU (EISA Configuration Utility) and therefore not available with the resource allocation infrastructure we implement, while port I/O is always readily available as it uses slot-specific addressing, directly mapped to the slot an option card has been placed in and handled with our EISA bus support core. Conversely a kernel that supports modern systems which may not have I/O transactions implemented for PCIe will usually not be expected to handle legacy EISA systems. The change of the default will make it easier for people, including but not limited to distribution packagers, to make a working choice for the driver. Update the option description accordingly and while at it replace the potentially ambiguous PIO acronym with IOP for "port I/O" vs "I/O ports" according to our nomenclature used elsewhere. Signed-off-by: Maciej W. Rozycki <macro(a)orcam.me.uk> Fixes: e89a2cfb7d7b ("[TC] defxx: TURBOchannel support") Cc: stable(a)vger.kernel.org # v2.6.21+ --- drivers/net/fddi/Kconfig | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) Index: linux-defxx/drivers/net/fddi/Kconfig =================================================================== --- linux-defxx.orig/drivers/net/fddi/Kconfig +++ linux-defxx/drivers/net/fddi/Kconfig @@ -40,17 +40,20 @@ config DEFXX config DEFXX_MMIO bool - prompt "Use MMIO instead of PIO" if PCI || EISA + prompt "Use MMIO instead of IOP" if PCI || EISA depends on DEFXX - default n if PCI || EISA + default n if EISA default y help This instructs the driver to use EISA or PCI memory-mapped I/O - (MMIO) as appropriate instead of programmed I/O ports (PIO). + (MMIO) as appropriate instead of programmed I/O ports (IOP). Enabling this gives an improvement in processing time in parts - of the driver, but it may cause problems with EISA (DEFEA) - adapters. TURBOchannel does not have the concept of I/O ports, - so MMIO is always used for these (DEFTA) adapters. + of the driver, but it requires a memory window to be configured + for EISA (DEFEA) adapters that may not always be available. + Conversely some PCIe host bridges do not support IOP, so MMIO + may be required to access PCI (DEFPA) adapters on downstream PCI + buses with some systems. TURBOchannel does not have the concept + of I/O ports, so MMIO is always used for these (DEFTA) adapters. If unsure, say N.

3 years, 7 months

1
0
0 0

[PATCH net/net-next 1/4] FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR

by Maciej W. Rozycki

Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. For those systems the PCI BARs that request a mapping in the I/O space have the length recorded in the corresponding PCI resource set to zero, which makes it unassigned: # lspci -s 0031:02:04.0 -v 0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02) Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA) Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8 Memory at 620c080020000 (32-bit, non-prefetchable) [size=128] I/O ports at <unassigned> [disabled] Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Kernel driver in use: defxx Kernel modules: defxx # Regardless the driver goes ahead and requests it (here observed with a Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry: # cat /proc/ioports 00000000-ffffffffffffffff : 0031:02:04.0 # Furthermore, the system gets confused as the driver actually continues and pokes at those locations, causing a flood of messages being output to the system console by the underlying system firmware, like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others defxx 0031:02:04.0: enabling device (0140 -> 0142) LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event and so on and so on (possibly intermixed actually, as there's no locking between the kernel and the firmware in console port access with this particular system, but cleaned up above for clarity), and once some 10k of such pairs of the latter two messages have been produced an interace eventually shows up in a useless state: 0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00 This was not expected to happen as resource handling was added to the driver a while ago, because it was not known at that time that a PCI system would be possible that cannot assign port I/O resources, and oddly enough `request_region' does not fail, which would have caught it. Correct the problem then by checking for the length of zero for the CSR resource and bail out gracefully refusing to register an interface if that turns out to be the case, producing messages like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 0031:02:04.0: Cannot use I/O, no address set, aborting 0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y" Keep the original check for the EISA MMIO resource as implemented, because in that case the length is hardwired to 0x400 as a consequence of how the compare/mask address decoding works in the ESIC chip and it is only the base address that is set to zero if MMIO has been disabled for the adapter in EISA configuration, which in turn could be a valid bus address in a legacy-free system implementing PCI, especially for port I/O. Where the EISA MMIO resource has been disabled for the adapter in EISA configuration this arrangement keeps producing messages like: eisa 00:05: EISA: slot 5: DEC3002 detected defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 00:05: Cannot use MMIO, no address set, aborting 00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n" 00:05: Or run ECU and set adapter's MMIO location with the last two lines now swapped for easier handling in the driver. There is no need to check for and catch the case of a port I/O resource not having been assigned for EISA as the adapter uses the slot-specific I/O space, which gets assigned by how EISA has been specified and maps directly to the particular slot an option card has been placed in. And the EISA variant of the adapter has additional registers that are only accessible via the port I/O space anyway. While at it factor out the error message calls into helpers and fix an argument order bug with the `pr_err' call now in `dfx_register_res_err'. Signed-off-by: Maciej W. Rozycki <macro(a)orcam.me.uk> Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management") Cc: stable(a)vger.kernel.org # v3.19+ --- drivers/net/fddi/defxx.c | 47 ++++++++++++++++++++++++++++++----------------- 1 file changed, 30 insertions(+), 17 deletions(-) Index: linux-defxx/drivers/net/fddi/defxx.c =================================================================== --- linux-defxx.orig/drivers/net/fddi/defxx.c +++ linux-defxx/drivers/net/fddi/defxx.c @@ -495,6 +495,25 @@ static const struct net_device_ops dfx_n .ndo_set_mac_address = dfx_ctl_set_mac_address, }; +static void dfx_register_res_alloc_err(const char *print_name, bool mmio, + bool eisa) +{ + pr_err("%s: Cannot use %s, no address set, aborting\n", + print_name, mmio ? "MMIO" : "I/O"); + pr_err("%s: Recompile driver with \"CONFIG_DEFXX_MMIO=%c\"\n", + print_name, mmio ? 'n' : 'y'); + if (eisa && mmio) + pr_err("%s: Or run ECU and set adapter's MMIO location\n", + print_name); +} + +static void dfx_register_res_err(const char *print_name, bool mmio, + unsigned long start, unsigned long len) +{ + pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, aborting\n", + print_name, mmio ? "MMIO" : "I/O", len, start); +} + /* * ================ * = dfx_register = @@ -568,15 +587,12 @@ static int dfx_register(struct device *b dev_set_drvdata(bdev, dev); dfx_get_bars(bdev, bar_start, bar_len); - if (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0) { - pr_err("%s: Cannot use MMIO, no address set, aborting\n", - print_name); - pr_err("%s: Run ECU and set adapter's MMIO location\n", - print_name); - pr_err("%s: Or recompile driver with \"CONFIG_DEFXX_MMIO=n\"" - "\n", print_name); + if (bar_len[0] == 0 || + (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0)) { + dfx_register_res_alloc_err(print_name, dfx_use_mmio, + dfx_bus_eisa); err = -ENXIO; - goto err_out; + goto err_out_disable; } if (dfx_use_mmio) @@ -585,18 +601,16 @@ static int dfx_register(struct device *b else region = request_region(bar_start[0], bar_len[0], print_name); if (!region) { - pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, " - "aborting\n", dfx_use_mmio ? "MMIO" : "I/O", print_name, - (long)bar_len[0], (long)bar_start[0]); + dfx_register_res_err(print_name, dfx_use_mmio, + bar_start[0], bar_len[0]); err = -EBUSY; goto err_out_disable; } if (bar_start[1] != 0) { region = request_region(bar_start[1], bar_len[1], print_name); if (!region) { - pr_err("%s: Cannot reserve I/O resource " - "0x%lx @ 0x%lx, aborting\n", print_name, - (long)bar_len[1], (long)bar_start[1]); + dfx_register_res_err(print_name, 0, + bar_start[1], bar_len[1]); err = -EBUSY; goto err_out_csr_region; } @@ -604,9 +618,8 @@ static int dfx_register(struct device *b if (bar_start[2] != 0) { region = request_region(bar_start[2], bar_len[2], print_name); if (!region) { - pr_err("%s: Cannot reserve I/O resource " - "0x%lx @ 0x%lx, aborting\n", print_name, - (long)bar_len[2], (long)bar_start[2]); + dfx_register_res_err(print_name, 0, + bar_start[2], bar_len[2]); err = -EBUSY; goto err_out_bh_region; }

3 years, 7 months

1
0
0 0

[PATCH] media: videobuf2: Fix integer overrun in allocation

by Ricardo Ribalda

The plane_length is an unsigned integer. So, if we have a size of 0xffffffff bytes we incorrectly allocate 0 bytes instead of 1 << 32. Cc: stable(a)vger.kernel.org Fixes: 7f8414594e47 ("[media] media: videobuf2: fix the length check for mmap") Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- drivers/media/common/videobuf2/videobuf2-core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c index 02281d13505f..543da515c761 100644 --- a/drivers/media/common/videobuf2/videobuf2-core.c +++ b/drivers/media/common/videobuf2/videobuf2-core.c @@ -223,8 +223,10 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb) * NOTE: mmapped areas should be page aligned */ for (plane = 0; plane < vb->num_planes; ++plane) { + unsigned long size = vb->planes[plane].length; + /* Memops alloc requires size to be page aligned. */ - unsigned long size = PAGE_ALIGN(vb->planes[plane].length); + size = PAGE_ALIGN(size); /* Did it wrap around? */ if (size < vb->planes[plane].length) -- 2.30.1.766.gb4fecdf3b7-goog

3 years, 7 months

3
7
0 0

[PATCH] media: videobuf2: Fix integer overrun in vb2_mmap

by Ricardo Ribalda

The plane_length is an unsigned integer. So, if we have a size of 0xffffffff bytes we incorrectly allocate 0 bytes instead of 1 << 32. Suggested-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: stable(a)vger.kernel.org Fixes: 7f8414594e47 ("[media] media: videobuf2: fix the length check for mmap") Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- drivers/media/common/videobuf2/videobuf2-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c index 543da515c761..876db5886867 100644 --- a/drivers/media/common/videobuf2/videobuf2-core.c +++ b/drivers/media/common/videobuf2/videobuf2-core.c @@ -2256,7 +2256,7 @@ int vb2_mmap(struct vb2_queue *q, struct vm_area_struct *vma) * The buffer length was page_aligned at __vb2_buf_mem_alloc(), * so, we need to do the same here. */ - length = PAGE_ALIGN(vb->planes[plane].length); + length = PAGE_ALIGN((unsigned int)vb->planes[plane].length); if (length < (vma->vm_end - vma->vm_start)) { dprintk(q, 1, "MMAP invalid, as it would overflow buffer length\n"); -- 2.30.1.766.gb4fecdf3b7-goog

3 years, 7 months

3
3
0 0

[PATCH] media: staging/intel-ipu3: Fix set_fmt error handling

by Ricardo Ribalda

If there in an error during a set_fmt, do not overwrite the previous sizes with the invalid config. Without this patch, v4l2-compliance ends up allocating 4GiB of RAM and causing the following OOPs [ 38.662975] ipu3-imgu 0000:00:05.0: swiotlb buffer is full (sz: 4096 bytes) [ 38.662980] DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:00:05.0 [ 38.663010] general protection fault: 0000 [#1] PREEMPT SMP Cc: stable(a)vger.kernel.org Fixes: 6d5f26f2e045 ("media: staging/intel-ipu3-v4l: reduce kernel stack usage") Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- drivers/staging/media/ipu3/ipu3-v4l2.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/staging/media/ipu3/ipu3-v4l2.c b/drivers/staging/media/ipu3/ipu3-v4l2.c index 60aa02eb7d2a..e8944e489c56 100644 --- a/drivers/staging/media/ipu3/ipu3-v4l2.c +++ b/drivers/staging/media/ipu3/ipu3-v4l2.c @@ -669,6 +669,7 @@ static int imgu_fmt(struct imgu_device *imgu, unsigned int pipe, int node, struct imgu_css_pipe *css_pipe = &imgu->css.pipes[pipe]; struct imgu_media_pipe *imgu_pipe = &imgu->imgu_pipe[pipe]; struct imgu_v4l2_subdev *imgu_sd = &imgu_pipe->imgu_sd; + struct v4l2_pix_format_mplane fmt_backup; dev_dbg(dev, "set fmt node [%u][%u](try = %u)", pipe, node, try); @@ -734,6 +735,7 @@ static int imgu_fmt(struct imgu_device *imgu, unsigned int pipe, int node, ret = -EINVAL; goto out; } + fmt_backup = *fmts[css_q]; *fmts[css_q] = f->fmt.pix_mp; if (try) @@ -741,6 +743,9 @@ static int imgu_fmt(struct imgu_device *imgu, unsigned int pipe, int node, else ret = imgu_css_fmt_set(&imgu->css, fmts, rects, pipe); + if (try || ret < 0) + *fmts[css_q] = fmt_backup; + /* ret is the binary number in the firmware blob */ if (ret < 0) goto out; -- 2.30.1.766.gb4fecdf3b7-goog

3 years, 7 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2021