April 2024 - Linux-stable-mirror

[PATCH] drm/xe: Unmap userptr in MMU invalidation notifier

by Matthew Brost

To be secure, when a userptr is invalidated the pages should be dma unmapped ensuring the device can no longer touch the invalidated pages. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Fixes: 12f4b58a37f4 ("drm/xe: Use hmm_range_fault to populate user pages") Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: stable(a)vger.kernel.org # 6.8 Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> --- drivers/gpu/drm/xe/xe_vm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index dfd31b346021..964a5b4d47d8 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -637,6 +637,9 @@ static bool vma_userptr_invalidate(struct mmu_interval_notifier *mni, XE_WARN_ON(err); } + if (userptr->sg) + xe_hmm_userptr_free_sg(uvma); + trace_xe_vma_userptr_invalidate_complete(vma); return true; -- 2.34.1

7 months, 4 weeks

3
7
0 0

[PATCH] crypto: arm64: use simd_skcipher_create() when registering aes internal algs

by Liam Kearney

The arm64 crypto drivers duplicate driver names when adding simd variants, which after backported commit 27016f75f5ed ("crypto: api - Disallow identical driver names"), causes an error that leads to the aes algs not being installed. On weaker processors this results in hangs due to falling back to SW crypto. Use simd_skcipher_create() as it will properly namespace the new algs. This issue does not exist in mainline/latest (and stable v6.1+) as the driver has been refactored to remove the simd algs from this code path. Fixes: 27016f75f5ed ("crypto: api - Disallow identical driver names") Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Liam Kearney <liam.kearney(a)canonical.com> --- arch/arm64/crypto/aes-glue.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c index aa13344a3a5e..af862e52a36b 100644 --- a/arch/arm64/crypto/aes-glue.c +++ b/arch/arm64/crypto/aes-glue.c @@ -1028,7 +1028,6 @@ static int __init aes_init(void) struct simd_skcipher_alg *simd; const char *basename; const char *algname; - const char *drvname; int err; int i; @@ -1045,9 +1044,8 @@ static int __init aes_init(void) continue; algname = aes_algs[i].base.cra_name + 2; - drvname = aes_algs[i].base.cra_driver_name + 2; basename = aes_algs[i].base.cra_driver_name; - simd = simd_skcipher_create_compat(algname, drvname, basename); + simd = simd_skcipher_create(algname, basename); err = PTR_ERR(simd); if (IS_ERR(simd)) goto unregister_simds; -- 2.40.1

7 months, 4 weeks

1
0
0 0

[PATCH v2] usb: dwc3: Wait unconditionally after issuing EndXfer command

by Prashanth K

Currently all controller IP/revisions except DWC3_usb3 >= 310a wait 1ms unconditionally for ENDXFER completion when IOC is not set. This is because DWC_usb3 controller revisions >= 3.10a supports GUCTL2[14: Rst_actbitlater] bit which allows polling CMDACT bit to know whether ENDXFER command is completed. Consider a case where an IN request was queued, and parallelly soft_disconnect was called (due to ffs_epfile_release). This eventually calls stop_active_transfer with IOC cleared, hence send_gadget_ep_cmd() skips waiting for CMDACT cleared during EndXfer. For DWC3 controllers with revisions >= 310a, we don't forcefully wait for 1ms either, and we proceed by unmapping the requests. If ENDXFER didn't complete by this time, it leads to SMMU faults since the controller would still be accessing those requests. Fix this by ensuring ENDXFER completion by adding 1ms delay in __dwc3_stop_active_transfer() unconditionally. Cc: <stable(a)vger.kernel.org> Fixes: b353eb6dc285 ("usb: dwc3: gadget: Skip waiting for CMDACT cleared during endxfer") Signed-off-by: Prashanth K <quic_prashk(a)quicinc.com> --- Changes in v2: Changed the patch logic from CMDACT polling to 1ms mdelay. Updated subject and commit accordingly. Link to v1: https://lore.kernel.org/all/20240422090539.3986723-1-quic_prashk@quicinc.co… drivers/usb/dwc3/gadget.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 4df2661f6675..666eae94524f 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1724,8 +1724,7 @@ static int __dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force, bool int dep->resource_index = 0; if (!interrupt) { - if (!DWC3_IP_IS(DWC3) || DWC3_VER_IS_PRIOR(DWC3, 310A)) - mdelay(1); + mdelay(1); dep->flags &= ~DWC3_EP_TRANSFER_STARTED; } else if (!ret) { dep->flags |= DWC3_EP_END_TRANSFER_PENDING; -- 2.25.1

7 months, 4 weeks

3
3
0 0

[PATCH v3 1/2] cxl/core: correct length of DPA field masks

by Shiyang Ruan

The length of Physical Address in General Media Event Record/DRAM Event Record is 64-bit, so the field mask should be defined as such length. Otherwise, this causes cxl_general_media and cxl_dram tracepoints to mask off the upper-32-bits of DPA addresses. The cxl_poison event is unaffected. If userspace was doing its own DPA-to-HPA translation this could lead to incorrect page retirement decisions, but there is no known consumer (like rasdaemon) of this event today. Fixes: d54a531a430b ("cxl/mem: Trace General Media Event Record") Cc: <stable(a)vger.kernel.org> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Cc: Ira Weiny <ira.weiny(a)intel.com> Signed-off-by: Shiyang Ruan <ruansy.fnst(a)fujitsu.com> --- drivers/cxl/core/trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cxl/core/trace.h b/drivers/cxl/core/trace.h index e5f13260fc52..cdfce932d5b1 100644 --- a/drivers/cxl/core/trace.h +++ b/drivers/cxl/core/trace.h @@ -253,7 +253,7 @@ TRACE_EVENT(cxl_generic_event, * DRAM Event Record * CXL rev 3.0 section 8.2.9.2.1.2; Table 8-44 */ -#define CXL_DPA_FLAGS_MASK 0x3F +#define CXL_DPA_FLAGS_MASK 0x3FULL #define CXL_DPA_MASK (~CXL_DPA_FLAGS_MASK) #define CXL_DPA_VOLATILE BIT(0) -- 2.34.1

7 months, 4 weeks

4
7
0 0

FAILED: patch "[PATCH] ACPI: CPPC: Fix access width used for PCC registers" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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.15.y git checkout FETCH_HEAD git cherry-pick -x f489c948028b69cea235d9c0de1cc10eeb26a172 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024042905-puppy-heritage-e422@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: f489c948028b ("ACPI: CPPC: Fix access width used for PCC registers") 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses") 0651ab90e4ad ("ACPI: CPPC: Check _OSC for flexible address space") c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not supported by firmware") 2ca8e6285250 ("Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag"") f684b1075128 ("ACPI: CPPC: Drop redundant local variable from cpc_read()") 5f51c7ce1dc3 ("ACPI: CPPC: Fix up I/O port access in cpc_read()") a2c8f92bea5f ("ACPI: CPPC: Implement support for SystemIO registers") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f489c948028b69cea235d9c0de1cc10eeb26a172 Mon Sep 17 00:00:00 2001 From: Vanshidhar Konda <vanshikonda(a)os.amperecomputing.com> Date: Thu, 11 Apr 2024 16:18:44 -0700 Subject: [PATCH] ACPI: CPPC: Fix access width used for PCC registers commit 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses") modified cpc_read()/cpc_write() to use access_width to read CPC registers. However, for PCC registers the access width field in the ACPI register macro specifies the PCC subspace ID. For non-zero PCC subspace ID it is incorrectly treated as access width. This causes errors when reading from PCC registers in the CPPC driver. For PCC registers, base the size of read/write on the bit width field. The debug message in cpc_read()/cpc_write() is updated to print relevant information for the address space type used to read the register. Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses") Signed-off-by: Vanshidhar Konda <vanshikonda(a)os.amperecomputing.com> Tested-by: Jarred White <jarredwhite(a)linux.microsoft.com> Reviewed-by: Jarred White <jarredwhite(a)linux.microsoft.com> Reviewed-by: Easwar Hariharan <eahariha(a)linux.microsoft.com> Cc: 5.15+ <stable(a)vger.kernel.org> # 5.15+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 00a30ca35e78..a40b6f3946ef 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -1002,14 +1002,14 @@ static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) } *val = 0; + size = GET_BIT_WIDTH(reg); if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) { - u32 width = GET_BIT_WIDTH(reg); u32 val_u32; acpi_status status; status = acpi_os_read_port((acpi_io_address)reg->address, - &val_u32, width); + &val_u32, size); if (ACPI_FAILURE(status)) { pr_debug("Error: Failed to read SystemIO port %llx\n", reg->address); @@ -1018,17 +1018,22 @@ static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) *val = val_u32; return 0; - } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM && pcc_ss_id >= 0) + } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM && pcc_ss_id >= 0) { + /* + * For registers in PCC space, the register size is determined + * by the bit width field; the access size is used to indicate + * the PCC subspace id. + */ + size = reg->bit_width; vaddr = GET_PCC_VADDR(reg->address, pcc_ss_id); + } else if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) vaddr = reg_res->sys_mem_vaddr; else if (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) return cpc_read_ffh(cpu, reg, val); else return acpi_os_read_memory((acpi_physical_address)reg->address, - val, reg->bit_width); - - size = GET_BIT_WIDTH(reg); + val, size); switch (size) { case 8: @@ -1044,8 +1049,13 @@ static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) *val = readq_relaxed(vaddr); break; default: - pr_debug("Error: Cannot read %u bit width from PCC for ss: %d\n", - reg->bit_width, pcc_ss_id); + if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { + pr_debug("Error: Cannot read %u bit width from system memory: 0x%llx\n", + size, reg->address); + } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM) { + pr_debug("Error: Cannot read %u bit width from PCC for ss: %d\n", + size, pcc_ss_id); + } return -EFAULT; } @@ -1063,12 +1073,13 @@ static int cpc_write(int cpu, struct cpc_register_resource *reg_res, u64 val) int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu); struct cpc_reg *reg = &reg_res->cpc_entry.reg; + size = GET_BIT_WIDTH(reg); + if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) { - u32 width = GET_BIT_WIDTH(reg); acpi_status status; status = acpi_os_write_port((acpi_io_address)reg->address, - (u32)val, width); + (u32)val, size); if (ACPI_FAILURE(status)) { pr_debug("Error: Failed to write SystemIO port %llx\n", reg->address); @@ -1076,17 +1087,22 @@ static int cpc_write(int cpu, struct cpc_register_resource *reg_res, u64 val) } return 0; - } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM && pcc_ss_id >= 0) + } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM && pcc_ss_id >= 0) { + /* + * For registers in PCC space, the register size is determined + * by the bit width field; the access size is used to indicate + * the PCC subspace id. + */ + size = reg->bit_width; vaddr = GET_PCC_VADDR(reg->address, pcc_ss_id); + } else if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) vaddr = reg_res->sys_mem_vaddr; else if (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) return cpc_write_ffh(cpu, reg, val); else return acpi_os_write_memory((acpi_physical_address)reg->address, - val, reg->bit_width); - - size = GET_BIT_WIDTH(reg); + val, size); if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) val = MASK_VAL(reg, val); @@ -1105,8 +1121,13 @@ static int cpc_write(int cpu, struct cpc_register_resource *reg_res, u64 val) writeq_relaxed(val, vaddr); break; default: - pr_debug("Error: Cannot write %u bit width to PCC for ss: %d\n", - reg->bit_width, pcc_ss_id); + if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { + pr_debug("Error: Cannot write %u bit width to system memory: 0x%llx\n", + size, reg->address); + } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM) { + pr_debug("Error: Cannot write %u bit width to PCC for ss: %d\n", + size, pcc_ss_id); + } ret_val = -EFAULT; break; }

7 months, 4 weeks

3
7
0 0

[PATCH v2 2/3] Bluetooth: qca: fix NVM configuration parsing

by Johan Hovold

The NVM configuration files used by WCN3988 and WCN3990/1/8 have two sets of configuration tags that are enclosed by a type-length header of type four which the current parser fails to account for. Instead the driver happily parses random data as if it were valid tags, something which can lead to the configuration data being corrupted if it ever encounters the words 0x0011 or 0x001b. As is clear from commit b63882549b2b ("Bluetooth: btqca: Fix the NVM baudrate tag offcet for wcn3991") the intention has always been to process the configuration data also for WCN3991 and WCN3998 which encodes the baud rate at a different offset. Fix the parser so that it can handle the WCN3xxx configuration files, which has an enclosing type-length header of type four and two sets of TLV tags enclosed by a type-length header of type two and three, respectively. Note that only the first set, which contains the tags the driver is currently looking for, will be parsed for now. With the parser fixed, the software in-band sleep bit will now be set for WCN3991 and WCN3998 (as it is for later controllers) and the default baud rate 3200000 may be updated by the driver also for WCN3xxx controllers. Notably the deep-sleep feature bit is already set by default in all configuration files in linux-firmware. Fixes: 4219d4686875 ("Bluetooth: btqca: Add wcn3990 firmware download support.") Cc: stable(a)vger.kernel.org # 4.19 Cc: Matthias Kaehlcke <mka(a)chromium.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/bluetooth/btqca.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c index 6743b0a79d7a..f6c9f89a6311 100644 --- a/drivers/bluetooth/btqca.c +++ b/drivers/bluetooth/btqca.c @@ -281,6 +281,7 @@ static int qca_tlv_check_data(struct hci_dev *hdev, struct tlv_type_patch *tlv_patch; struct tlv_type_nvm *tlv_nvm; uint8_t nvm_baud_rate = config->user_baud_rate; + u8 type; config->dnld_mode = QCA_SKIP_EVT_NONE; config->dnld_type = QCA_SKIP_EVT_NONE; @@ -346,11 +347,30 @@ static int qca_tlv_check_data(struct hci_dev *hdev, tlv = (struct tlv_type_hdr *)fw_data; type_len = le32_to_cpu(tlv->type_len); - length = (type_len >> 8) & 0x00ffffff; + length = type_len >> 8; + type = type_len & 0xff; - BT_DBG("TLV Type\t\t : 0x%x", type_len & 0x000000ff); + /* Some NVM files have more than one set of tags, only parse + * the first set when it has type 2 for now. When there is + * more than one set there is an enclosing header of type 4. + */ + if (type == 4) { + if (fw_size < 2 * sizeof(struct tlv_type_hdr)) + return -EINVAL; + + tlv++; + + type_len = le32_to_cpu(tlv->type_len); + length = type_len >> 8; + type = type_len & 0xff; + } + + BT_DBG("TLV Type\t\t : 0x%x", type); BT_DBG("Length\t\t : %d bytes", length); + if (type != 2) + break; + if (fw_size < length + (tlv->data - fw_data)) return -EINVAL; -- 2.43.2

7 months, 4 weeks

1
0
0 0

Re: Patch "arm64: dts: mediatek: mt7622: drop "reset-names" from thermal block" has been added to the 4.19-stable tree

by Matthias Brugger

On 4/28/24 13:24, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > arm64: dts: mediatek: mt7622: drop "reset-names" from thermal block > > to the 4.19-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: > arm64-dts-mediatek-mt7622-drop-reset-names-from-ther.patch > and it can be found in the queue-4.19 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 9628765c4a0eefa9474ef4a0698691a10395a469 > Author: Rafał Miłecki <rafal(a)milecki.pl> > Date: Sun Mar 17 23:10:50 2024 +0100 > > arm64: dts: mediatek: mt7622: drop "reset-names" from thermal block > > [ Upstream commit ecb5b0034f5bcc35003b4b965cf50c6e98316e79 ] > > Binding doesn't specify "reset-names" property and Linux driver also > doesn't use it. > I think that's an open discussion item if fixes to DTS checks are valid stable backports. From my point of view there is no bug so it shouldn't be in stable. Regards, Matthias > Fix following validation error: > arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: thermal@1100b000: Unevaluated properties are not allowed ('reset-names' was unexpected) > from schema $id: http://devicetree.org/schemas/thermal/mediatek,thermal.yaml# > > Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related device nodes") > Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> > Link: https://lore.kernel.org/r/20240317221050.18595-5-zajec5@gmail.com > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi > index 76297dac2d459..f8df34ac1e64d 100644 > --- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi > @@ -459,7 +459,6 @@ thermal: thermal@1100b000 { > <&pericfg CLK_PERI_AUXADC_PD>; > clock-names = "therm", "auxadc"; > resets = <&pericfg MT7622_PERI_THERM_SW_RST>; > - reset-names = "therm"; > mediatek,auxadc = <&auxadc>; > mediatek,apmixedsys = <&apmixedsys>; > nvmem-cells = <&thermal_calibration>;

7 months, 4 weeks

2
1
0 0

Re: Patch "arm64: dts: mediatek: mt7622: fix ethernet controller "compatible"" has been added to the 4.19-stable tree

by Matthias Brugger

On 4/28/24 13:24, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > arm64: dts: mediatek: mt7622: fix ethernet controller "compatible" > > to the 4.19-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: > arm64-dts-mediatek-mt7622-fix-ethernet-controller-co.patch > and it can be found in the queue-4.19 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 b6f34784d92ba280c8a4f42e22fee3c41cd09c3f > Author: Rafał Miłecki <rafal(a)milecki.pl> > Date: Sun Mar 17 23:10:49 2024 +0100 > > arm64: dts: mediatek: mt7622: fix ethernet controller "compatible" > > [ Upstream commit 208add29ce5b7291f6c466e4dfd9cbf61c72888e ] > > Fix following validation error: > arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: ethernet@1b100000: compatible: ['mediatek,mt7622-eth', 'mediatek,mt2701-eth', 'syscon'] is too long > from schema $id: http://devicetree.org/schemas/net/mediatek,net.yaml# > (and other complains about wrong clocks). > DTS validation fix, not a real bug. From my point of view it shouldn't be in stable. I won't go on in the list, I would like to hear from others how serious they see it. With my distro hat on, this kind of stable fixes are not helpfull to make a code base stable (as there is no stability issue). Matthias > Fixes: 5f599b3a0bb8 ("arm64: dts: mt7622: add ethernet device nodes") > Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> > Link: https://lore.kernel.org/r/20240317221050.18595-4-zajec5@gmail.com > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi > index 5c12e9dad9167..76297dac2d459 100644 > --- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi > @@ -846,9 +846,7 @@ hsdma: dma-controller@1b007000 { > }; > > eth: ethernet@1b100000 { > - compatible = "mediatek,mt7622-eth", > - "mediatek,mt2701-eth", > - "syscon"; > + compatible = "mediatek,mt7622-eth"; > reg = <0 0x1b100000 0 0x20000>; > interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_LOW>, > <GIC_SPI 224 IRQ_TYPE_LEVEL_LOW>,

7 months, 4 weeks

1
0
0 0

[STABLE 6.6.y] ovl: fix memory leak in ovl_parse_param()

by Jingbo Xu

From: Amir Goldstein <amir73il(a)gmail.com> commit 37f32f52643869131ec01bb69bdf9f404f6109fb upstream. On failure to parse parameters in ovl_parse_param_lowerdir(), it is necessary to update ctx->nr with the correct nr before using ovl_reset_lowerdirs() to release l->name. Reported-and-tested-by: syzbot+26eedf3631650972f17c(a)syzkaller.appspotmail.com Fixes: c835110b588a ("ovl: remove unused code in lowerdir param parsing") Co-authored-by: Edward Adam Davis <eadavis(a)qq.com> Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> Signed-off-by: Jingbo Xu <jefflexu(a)linux.alibaba.com> --- Commit c835110b588a ("ovl: remove unused code in lowerdir param parsing") was back ported to 6.6.y as a "Stable-dep-of" of commit 2824083db76c ("ovl: Always reject mounting over case-insensitive directories"), while omitting the fix for commit c835110b588a itself. Maybe that is because by the time commit 37f32f526438 (the fix) is merged into master branch, commit c835110b588a has not been back ported to 6.6.y yet. This causes ltp test warning on vfat (EBUSY when umounting) [1]: tst_test.c:1701: TINFO: === Testing on vfat === tst_test.c:1117: TINFO: Formatting /dev/loop0 with vfat opts='' extra opts='' tst_test.c:1131: TINFO: Mounting /dev/loop0 to /tmp/ltp-XeGbUgDq5N/LTP_fankzf5WQ/mntpoint fstyp=vfat flags=0 fanotify13.c:152: TINFO: Test #0.1: FAN_REPORT_FID with mark flag: FAN_MARK_INODE fanotify13.c:157: TCONF: overlayfs not supported on vfat fanotify13.c:152: TINFO: Test #1.1: FAN_REPORT_FID with mark flag: FAN_MARK_INODE fanotify13.c:157: TCONF: overlayfs not supported on vfat fanotify13.c:152: TINFO: Test #2.1: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT fanotify13.c:157: TCONF: overlayfs not supported on vfat fanotify13.c:152: TINFO: Test #3.1: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT fanotify13.c:157: TCONF: overlayfs not supported on vfat fanotify13.c:152: TINFO: Test #4.1: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM fanotify13.c:157: TCONF: overlayfs not supported on vfat fanotify13.c:152: TINFO: Test #5.1: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM fanotify13.c:157: TCONF: overlayfs not supported on vfat tst_device.c:408: TINFO: umount('mntpoint') failed with EBUSY, try 1... tst_device.c:412: TINFO: Likely gvfsd-trash is probing newly mounted fs, kill it to speed up tests. tst_device.c:408: TINFO: umount('mntpoint') failed with EBUSY, try 2... tst_device.c:408: TINFO: umount('mntpoint') failed with EBUSY, try 3... tst_device.c:408: TINFO: umount('mntpoint') failed with EBUSY, try 4... Reproduce: /opt/ltp/runltp -f syscalls -s fanotify13 The original fix is applied to 6.6.y without conflict. [1] https://lists.linux.it/pipermail/ltp/2023-November/036189.html --- fs/overlayfs/params.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c index ad3593a41fb5..488f920f79d2 100644 --- a/fs/overlayfs/params.c +++ b/fs/overlayfs/params.c @@ -438,7 +438,7 @@ static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc) struct ovl_fs_context *ctx = fc->fs_private; struct ovl_fs_context_layer *l; char *dup = NULL, *iter; - ssize_t nr_lower = 0, nr = 0, nr_data = 0; + ssize_t nr_lower, nr; bool data_layer = false; /* @@ -490,6 +490,7 @@ static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc) iter = dup; l = ctx->lower; for (nr = 0; nr < nr_lower; nr++, l++) { + ctx->nr++; memset(l, 0, sizeof(*l)); err = ovl_mount_dir(iter, &l->path); @@ -506,10 +507,10 @@ static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc) goto out_put; if (data_layer) - nr_data++; + ctx->nr_data++; /* Calling strchr() again would overrun. */ - if ((nr + 1) == nr_lower) + if (ctx->nr == nr_lower) break; err = -EINVAL; @@ -519,7 +520,7 @@ static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc) * This is a regular layer so we require that * there are no data layers. */ - if ((ctx->nr_data + nr_data) > 0) { + if (ctx->nr_data > 0) { pr_err("regular lower layers cannot follow data lower layers"); goto out_put; } @@ -532,8 +533,6 @@ static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc) data_layer = true; iter++; } - ctx->nr = nr_lower; - ctx->nr_data += nr_data; kfree(dup); return 0; -- 2.19.1.6.gb485710b

7 months, 4 weeks

3
2
0 0

[PATCH 08/17] net: lan966x: remove debugfs directory in probe() error path

by Herve Codina

A debugfs directory entry is create early during probe(). This entry is not removed on error path leading to some "already present" issues in case of EPROBE_DEFER. Create this entry later in the probe() code to avoid the need to change many 'return' in 'goto' and add the removal in the already present error path. Fixes: 942814840127 ("net: lan966x: Add VCAP debugFS support") Cc: <stable(a)vger.kernel.org> Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- drivers/net/ethernet/microchip/lan966x/lan966x_main.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c index 2635ef8958c8..61d88207eed4 100644 --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c @@ -1087,8 +1087,6 @@ static int lan966x_probe(struct platform_device *pdev) platform_set_drvdata(pdev, lan966x); lan966x->dev = &pdev->dev; - lan966x->debugfs_root = debugfs_create_dir("lan966x", NULL); - if (!device_get_mac_address(&pdev->dev, mac_addr)) { ether_addr_copy(lan966x->base_mac, mac_addr); } else { @@ -1179,6 +1177,8 @@ static int lan966x_probe(struct platform_device *pdev) return dev_err_probe(&pdev->dev, -ENODEV, "no ethernet-ports child found\n"); + lan966x->debugfs_root = debugfs_create_dir("lan966x", NULL); + /* init switch */ lan966x_init(lan966x); lan966x_stats_init(lan966x); @@ -1257,6 +1257,8 @@ static int lan966x_probe(struct platform_device *pdev) destroy_workqueue(lan966x->stats_queue); mutex_destroy(&lan966x->stats_lock); + debugfs_remove_recursive(lan966x->debugfs_root); + return err; } -- 2.44.0

7 months, 4 weeks

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024