December 2024 - Linux-stable-mirror

patch "iio: gyro: fxas21002c: Fix missing data update in trigger handler" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: gyro: fxas21002c: Fix missing data update in trigger handler to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. From fa13ac6cdf9b6c358e7d77c29fb60145c7a87965 Mon Sep 17 00:00:00 2001 From: Carlos Song <carlos.song(a)nxp.com> Date: Sat, 16 Nov 2024 10:29:45 -0500 Subject: iio: gyro: fxas21002c: Fix missing data update in trigger handler The fxas21002c_trigger_handler() may fail to acquire sample data because the runtime PM enters the autosuspend state and sensor can not return sample data in standby mode.. Resume the sensor before reading the sample data into the buffer within the trigger handler. After the data is read, place the sensor back into the autosuspend state. Fixes: a0701b6263ae ("iio: gyro: add core driver for fxas21002c") Signed-off-by: Carlos Song <carlos.song(a)nxp.com> Signed-off-by: Frank Li <Frank.Li(a)nxp.com> Link: https://patch.msgid.link/20241116152945.4006374-1-Frank.Li@nxp.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/gyro/fxas21002c_core.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/iio/gyro/fxas21002c_core.c b/drivers/iio/gyro/fxas21002c_core.c index 0391c78c2f18..754c8a564ba4 100644 --- a/drivers/iio/gyro/fxas21002c_core.c +++ b/drivers/iio/gyro/fxas21002c_core.c @@ -730,14 +730,21 @@ static irqreturn_t fxas21002c_trigger_handler(int irq, void *p) int ret; mutex_lock(&data->lock); - ret = regmap_bulk_read(data->regmap, FXAS21002C_REG_OUT_X_MSB, - data->buffer, CHANNEL_SCAN_MAX * sizeof(s16)); + ret = fxas21002c_pm_get(data); if (ret < 0) goto out_unlock; + ret = regmap_bulk_read(data->regmap, FXAS21002C_REG_OUT_X_MSB, + data->buffer, CHANNEL_SCAN_MAX * sizeof(s16)); + if (ret < 0) + goto out_pm_put; + iio_push_to_buffers_with_timestamp(indio_dev, data->buffer, data->timestamp); +out_pm_put: + fxas21002c_pm_put(data); + out_unlock: mutex_unlock(&data->lock); -- 2.47.1

6 months, 1 week

1
0
0 0

patch "iio: adc: ad7124: Disable all channels at probe time" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: ad7124: Disable all channels at probe time to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. From 4be339af334c283a1a1af3cb28e7e448a0aa8a7c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig(a)baylibre.com> Date: Mon, 4 Nov 2024 11:19:04 +0100 Subject: iio: adc: ad7124: Disable all channels at probe time MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When during a measurement two channels are enabled, two measurements are done that are reported sequencially in the DATA register. As the code triggered by reading one of the sysfs properties expects that only one channel is enabled it only reads the first data set which might or might not belong to the intended channel. To prevent this situation disable all channels during probe. This fixes a problem in practise because the reset default for channel 0 is enabled. So all measurements before the first measurement on channel 0 (which disables channel 0 at the end) might report wrong values. Fixes: 7b8d045e497a ("iio: adc: ad7124: allow more than 8 channels") Reviewed-by: Nuno Sa <nuno.sa(a)analog.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)baylibre.com> Link: https://patch.msgid.link/20241104101905.845737-2-u.kleine-koenig@baylibre.c… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7124.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/adc/ad7124.c b/drivers/iio/adc/ad7124.c index 7314fb32bdec..3d678c420cbf 100644 --- a/drivers/iio/adc/ad7124.c +++ b/drivers/iio/adc/ad7124.c @@ -917,6 +917,9 @@ static int ad7124_setup(struct ad7124_state *st) * set all channels to this default value. */ ad7124_set_channel_odr(st, i, 10); + + /* Disable all channels to prevent unintended conversions. */ + ad_sd_write_reg(&st->sd, AD7124_CHANNEL(i), 2, 0); } ret = ad_sd_write_reg(&st->sd, AD7124_ADC_CONTROL, 2, st->adc_control); -- 2.47.1

6 months, 1 week

1
0
0 0

[PATCH] arm64/sme: Move storage of reg_smidr to __cpuinfo_store_cpu()

by Mark Brown

In commit 892f7237b3ff ("arm64: Delay initialisation of cpuinfo_arm64::reg_{zcr,smcr}") we moved access to ZCR, SMCR and SMIDR later in the boot process in order to ensure that we don't attempt to interact with them if SVE or SME is disabled on the command line. Unfortunately when initialising the boot CPU in init_cpu_features() we work on a copy of the struct cpuinfo_arm64 for the boot CPU used only during boot, not the percpu copy used by the sysfs code. Fix this by moving the handling for SMIDR_EL1 for the boot CPU to cpuinfo_store_boot_cpu() so it can operate on the percpu copy of the data. This reduces the potential for error that could come from having both the percpu and boot CPU copies in init_cpu_features(). This issue wasn't apparent when testing on emulated platforms that do not report values in this ID register. Fixes: 892f7237b3ff ("arm64: Delay initialisation of cpuinfo_arm64::reg_{zcr,smcr}") Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- arch/arm64/kernel/cpufeature.c | 6 ------ arch/arm64/kernel/cpuinfo.c | 11 +++++++++++ 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 6ce71f444ed84f9056196bb21bbfac61c9687e30..b88102fd2c20f77e25af6df513fda09a484e882e 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -1167,12 +1167,6 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info) id_aa64pfr1_sme(read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1))) { unsigned long cpacr = cpacr_save_enable_kernel_sme(); - /* - * We mask out SMPS since even if the hardware - * supports priorities the kernel does not at present - * and we block access to them. - */ - info->reg_smidr = read_cpuid(SMIDR_EL1) & ~SMIDR_EL1_SMPS; vec_init_vq_map(ARM64_VEC_SME); cpacr_restore(cpacr); diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c index d79e88fccdfce427507e7a34c5959ce6309cbd12..b7d403da71e5a01ed3943eb37e7a00af238771a2 100644 --- a/arch/arm64/kernel/cpuinfo.c +++ b/arch/arm64/kernel/cpuinfo.c @@ -499,4 +499,15 @@ void __init cpuinfo_store_boot_cpu(void) boot_cpu_data = *info; init_cpu_features(&boot_cpu_data); + + /* SMIDR_EL1 needs to be stored in the percpu data for sysfs */ + if (IS_ENABLED(CONFIG_ARM64_SME) && + id_aa64pfr1_sme(read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1))) { + /* + * We mask out SMPS since even if the hardware + * supports priorities the kernel does not at present + * and we block access to them. + */ + info->reg_smidr = read_cpuid(SMIDR_EL1) & ~SMIDR_EL1_SMPS; + } } --- base-commit: fac04efc5c793dccbd07e2d59af9f90b7fc0dca4 change-id: 20241213-arm64-fix-boot-cpu-smidr-386b8db292b2 Best regards, -- Mark Brown <broonie(a)kernel.org>

6 months, 1 week

3
13
0 0

[PATCH v6.12] KVM: arm64: Disable MPAM visibility by default and ignore VMM writes

by Marc Zyngier

From: James Morse <james.morse(a)arm.com> commit 6685f5d572c22e1003e7c0d089afe1c64340ab1f upstream. commit 011e5f5bf529f ("arm64/cpufeature: Add remaining feature bits in ID_AA64PFR0 register") exposed the MPAM field of AA64PFR0_EL1 to guests, but didn't add trap handling. A previous patch supplied the missing trap handling. Existing VMs that have the MPAM field of ID_AA64PFR0_EL1 set need to be migratable, but there is little point enabling the MPAM CPU interface on new VMs until there is something a guest can do with it. Clear the MPAM field from the guest's ID_AA64PFR0_EL1 and on hardware that supports MPAM, politely ignore the VMMs attempts to set this bit. Guests exposed to this bug have the sanitised value of the MPAM field, so only the correct value needs to be ignored. This means the field can continue to be used to block migration to incompatible hardware (between MPAM=1 and MPAM=5), and the VMM can't rely on the field being ignored. Signed-off-by: James Morse <james.morse(a)arm.com> Co-developed-by: Joey Gouly <joey.gouly(a)arm.com> Signed-off-by: Joey Gouly <joey.gouly(a)arm.com> Reviewed-by: Gavin Shan <gshan(a)redhat.com> Tested-by: Shameer Kolothum <shameerali.kolothum.thodi(a)huawei.com> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20241030160317.2528209-7-joey.gouly@arm.com Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> [maz: adapted to lack of ID_FILTERED()] Signed-off-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org --- arch/arm64/kvm/sys_regs.c | 55 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 52 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index ff8c4e1b847ed..fbed433283c9b 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1535,6 +1535,7 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu, val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTEX); val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_DF2); val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_PFAR); + val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MPAM_frac); break; case SYS_ID_AA64PFR2_EL1: /* We only expose FPMR */ @@ -1724,6 +1725,13 @@ static u64 read_sanitised_id_aa64pfr0_el1(struct kvm_vcpu *vcpu, val &= ~ID_AA64PFR0_EL1_AMU_MASK; + /* + * MPAM is disabled by default as KVM also needs a set of PARTID to + * program the MPAMVPMx_EL2 PARTID remapping registers with. But some + * older kernels let the guest see the ID bit. + */ + val &= ~ID_AA64PFR0_EL1_MPAM_MASK; + return val; } @@ -1834,6 +1842,42 @@ static int set_id_dfr0_el1(struct kvm_vcpu *vcpu, return set_id_reg(vcpu, rd, val); } +static int set_id_aa64pfr0_el1(struct kvm_vcpu *vcpu, + const struct sys_reg_desc *rd, u64 user_val) +{ + u64 hw_val = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1); + u64 mpam_mask = ID_AA64PFR0_EL1_MPAM_MASK; + + /* + * Commit 011e5f5bf529f ("arm64/cpufeature: Add remaining feature bits + * in ID_AA64PFR0 register") exposed the MPAM field of AA64PFR0_EL1 to + * guests, but didn't add trap handling. KVM doesn't support MPAM and + * always returns an UNDEF for these registers. The guest must see 0 + * for this field. + * + * But KVM must also accept values from user-space that were provided + * by KVM. On CPUs that support MPAM, permit user-space to write + * the sanitizied value to ID_AA64PFR0_EL1.MPAM, but ignore this field. + */ + if ((hw_val & mpam_mask) == (user_val & mpam_mask)) + user_val &= ~ID_AA64PFR0_EL1_MPAM_MASK; + + return set_id_reg(vcpu, rd, user_val); +} + +static int set_id_aa64pfr1_el1(struct kvm_vcpu *vcpu, + const struct sys_reg_desc *rd, u64 user_val) +{ + u64 hw_val = read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1); + u64 mpam_mask = ID_AA64PFR1_EL1_MPAM_frac_MASK; + + /* See set_id_aa64pfr0_el1 for comment about MPAM */ + if ((hw_val & mpam_mask) == (user_val & mpam_mask)) + user_val &= ~ID_AA64PFR1_EL1_MPAM_frac_MASK; + + return set_id_reg(vcpu, rd, user_val); +} + /* * cpufeature ID register user accessors * @@ -2377,7 +2421,7 @@ static const struct sys_reg_desc sys_reg_descs[] = { { SYS_DESC(SYS_ID_AA64PFR0_EL1), .access = access_id_reg, .get_user = get_id_reg, - .set_user = set_id_reg, + .set_user = set_id_aa64pfr0_el1, .reset = read_sanitised_id_aa64pfr0_el1, .val = ~(ID_AA64PFR0_EL1_AMU | ID_AA64PFR0_EL1_MPAM | @@ -2385,7 +2429,12 @@ static const struct sys_reg_desc sys_reg_descs[] = { ID_AA64PFR0_EL1_RAS | ID_AA64PFR0_EL1_AdvSIMD | ID_AA64PFR0_EL1_FP), }, - ID_WRITABLE(ID_AA64PFR1_EL1, ~(ID_AA64PFR1_EL1_PFAR | + { SYS_DESC(SYS_ID_AA64PFR1_EL1), + .access = access_id_reg, + .get_user = get_id_reg, + .set_user = set_id_aa64pfr1_el1, + .reset = kvm_read_sanitised_id_reg, + .val = ~(ID_AA64PFR1_EL1_PFAR | ID_AA64PFR1_EL1_DF2 | ID_AA64PFR1_EL1_MTEX | ID_AA64PFR1_EL1_THE | @@ -2397,7 +2446,7 @@ static const struct sys_reg_desc sys_reg_descs[] = { ID_AA64PFR1_EL1_RES0 | ID_AA64PFR1_EL1_MPAM_frac | ID_AA64PFR1_EL1_RAS_frac | - ID_AA64PFR1_EL1_MTE)), + ID_AA64PFR1_EL1_MTE), }, ID_WRITABLE(ID_AA64PFR2_EL1, ID_AA64PFR2_EL1_FPMR), ID_UNALLOCATED(4,3), ID_WRITABLE(ID_AA64ZFR0_EL1, ~ID_AA64ZFR0_EL1_RES0), -- 2.39.2

6 months, 1 week

2
1
0 0

[PATCH v2 5.4 5.15 6.6] tracing/kprobes: Skip symbol counting logic for module symbols in create_local_trace_kprobe()

by Nikolay Kuratov

commit b022f0c7e404 ("tracing/kprobes: Return EADDRNOTAVAIL when func matches several symbols") avoids checking number_of_same_symbols() for module symbol in __trace_kprobe_create(), but create_local_trace_kprobe() should avoid this check too. Doing this check leads to ENOENT for module_name:symbol_name constructions passed over perf_event_open. No bug in newer kernels as it was fixed more generally by commit 9d8616034f16 ("tracing/kprobes: Add symbol counting check when module loads") Link: https://lore.kernel.org/linux-trace-kernel/20240705161030.b3ddb33a8167013b9… Fixes: b022f0c7e404 ("tracing/kprobes: Return EADDRNOTAVAIL when func matches several symbols") Signed-off-by: Nikolay Kuratov <kniv(a)yandex-team.ru> --- v1 -> v2: * Reword commit title and message * Send for stable instead of mainline kernel/trace/trace_kprobe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c index 12d997bb3e78..94cb09d44115 100644 --- a/kernel/trace/trace_kprobe.c +++ b/kernel/trace/trace_kprobe.c @@ -1814,7 +1814,7 @@ create_local_trace_kprobe(char *func, void *addr, unsigned long offs, int ret; char *event; - if (func) { + if (func && !strchr(func, ':')) { unsigned int count; count = number_of_same_symbols(func); -- 2.34.1

6 months, 1 week

2
1
0 0

[PATCH] usb: phy-tahvo: fix call balance for tu->ick handling routines

by Vitalii Mordan

If the clock tu->ick was not enabled in tahvo_usb_probe, it may still hold a non-error pointer, potentially causing the clock to be incorrectly disabled later in the function. Use the devm_clk_get_enabled helper function to ensure proper call balance for tu->ick. Found by Linux Verification Center (linuxtesting.org) with Klever. Fixes: 9ba96ae5074c ("usb: omap1: Tahvo USB transceiver driver") Cc: stable(a)vger.kernel.org Signed-off-by: Vitalii Mordan <mordan(a)ispras.ru> --- v2: Corrected a typo in the error handling of the devm_clk_get_enabled call. This issue was reported by Dan Carpenter <dan.carpenter(a)linaro.org>. drivers/usb/phy/phy-tahvo.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c index ae7bf3ff89ee..4182e86dc450 100644 --- a/drivers/usb/phy/phy-tahvo.c +++ b/drivers/usb/phy/phy-tahvo.c @@ -341,9 +341,11 @@ static int tahvo_usb_probe(struct platform_device *pdev) mutex_init(&tu->serialize); - tu->ick = devm_clk_get(&pdev->dev, "usb_l4_ick"); - if (!IS_ERR(tu->ick)) - clk_enable(tu->ick); + tu->ick = devm_clk_get_enabled(&pdev->dev, "usb_l4_ick"); + if (IS_ERR(tu->ick)) { + dev_err(&pdev->dev, "failed to get and enable clock\n"); + return PTR_ERR(tu->ick); + } /* * Set initial state, so that we generate kevents only on state changes. @@ -353,15 +355,14 @@ static int tahvo_usb_probe(struct platform_device *pdev) tu->extcon = devm_extcon_dev_allocate(&pdev->dev, tahvo_cable); if (IS_ERR(tu->extcon)) { dev_err(&pdev->dev, "failed to allocate memory for extcon\n"); - ret = PTR_ERR(tu->extcon); - goto err_disable_clk; + return PTR_ERR(tu->extcon); } ret = devm_extcon_dev_register(&pdev->dev, tu->extcon); if (ret) { dev_err(&pdev->dev, "could not register extcon device: %d\n", ret); - goto err_disable_clk; + return ret; } /* Set the initial cable state. */ @@ -384,7 +385,7 @@ static int tahvo_usb_probe(struct platform_device *pdev) if (ret < 0) { dev_err(&pdev->dev, "cannot register USB transceiver: %d\n", ret); - goto err_disable_clk; + return ret; } dev_set_drvdata(&pdev->dev, tu); @@ -405,9 +406,6 @@ static int tahvo_usb_probe(struct platform_device *pdev) err_remove_phy: usb_remove_phy(&tu->phy); -err_disable_clk: - if (!IS_ERR(tu->ick)) - clk_disable(tu->ick); return ret; } @@ -418,8 +416,6 @@ static void tahvo_usb_remove(struct platform_device *pdev) free_irq(tu->irq, tu); usb_remove_phy(&tu->phy); - if (!IS_ERR(tu->ick)) - clk_disable(tu->ick); } static struct platform_driver tahvo_usb_driver = { -- 2.25.1

6 months, 1 week

1
0
0 0

[PATCH] usb: phy-tahvo: fix call balance for tu->ick handling routines

by Vitalii Mordan

If the clock tu->ick was not enabled in tahvo_usb_probe, it may still hold a non-error pointer, potentially causing the clock to be incorrectly disabled later in the function. Use the devm_clk_get_enabled helper function to ensure proper call balance for tu->ick. Found by Linux Verification Center (linuxtesting.org) with Klever. Fixes: 9ba96ae5074c ("usb: omap1: Tahvo USB transceiver driver") Cc: stable(a)vger.kernel.org Signed-off-by: Vitalii Mordan <mordan(a)ispras.ru> --- drivers/usb/phy/phy-tahvo.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c index ae7bf3ff89ee..d393308d23d4 100644 --- a/drivers/usb/phy/phy-tahvo.c +++ b/drivers/usb/phy/phy-tahvo.c @@ -341,9 +341,11 @@ static int tahvo_usb_probe(struct platform_device *pdev) mutex_init(&tu->serialize); - tu->ick = devm_clk_get(&pdev->dev, "usb_l4_ick"); - if (!IS_ERR(tu->ick)) - clk_enable(tu->ick); + tu->ick = devm_clk_get_enabled(&pdev->dev, "usb_l4_ick"); + if (!IS_ERR(tu->ick)) { + dev_err(&pdev->dev, "failed to get and enable clock\n"); + return PTR_ERR(tu->ick); + } /* * Set initial state, so that we generate kevents only on state changes. @@ -353,15 +355,14 @@ static int tahvo_usb_probe(struct platform_device *pdev) tu->extcon = devm_extcon_dev_allocate(&pdev->dev, tahvo_cable); if (IS_ERR(tu->extcon)) { dev_err(&pdev->dev, "failed to allocate memory for extcon\n"); - ret = PTR_ERR(tu->extcon); - goto err_disable_clk; + return PTR_ERR(tu->extcon); } ret = devm_extcon_dev_register(&pdev->dev, tu->extcon); if (ret) { dev_err(&pdev->dev, "could not register extcon device: %d\n", ret); - goto err_disable_clk; + return ret; } /* Set the initial cable state. */ @@ -384,7 +385,7 @@ static int tahvo_usb_probe(struct platform_device *pdev) if (ret < 0) { dev_err(&pdev->dev, "cannot register USB transceiver: %d\n", ret); - goto err_disable_clk; + return ret; } dev_set_drvdata(&pdev->dev, tu); @@ -405,9 +406,6 @@ static int tahvo_usb_probe(struct platform_device *pdev) err_remove_phy: usb_remove_phy(&tu->phy); -err_disable_clk: - if (!IS_ERR(tu->ick)) - clk_disable(tu->ick); return ret; } @@ -418,8 +416,6 @@ static void tahvo_usb_remove(struct platform_device *pdev) free_irq(tu->irq, tu); usb_remove_phy(&tu->phy); - if (!IS_ERR(tu->ick)) - clk_disable(tu->ick); } static struct platform_driver tahvo_usb_driver = { -- 2.25.1

6 months, 1 week

3
2
0 0

[PATCH v5 1/5] libfs: Return ENOSPC when the directory offset range is exhausted

by cel＠kernel.org

From: Chuck Lever <chuck.lever(a)oracle.com> Testing shows that the EBUSY error return from mtree_alloc_cyclic() leaks into user space. The ERRORS section of "man creat(2)" says: > EBUSY O_EXCL was specified in flags and pathname refers > to a block device that is in use by the system > (e.g., it is mounted). ENOSPC is closer to what applications expect in this situation. Note that the normal range of simple directory offset values is 2..2^63, so hitting this error is going to be rare to impossible. Fixes: 6faddda69f62 ("libfs: Add directory operations for stable offsets") Cc: <stable(a)vger.kernel.org> # v6.9+ Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Reviewed-by: Yang Erkun <yangerkun(a)huawei.com> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> --- fs/libfs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/libfs.c b/fs/libfs.c index 748ac5923154..f6d04c69f195 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -292,7 +292,9 @@ int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry) ret = mtree_alloc_cyclic(&octx->mt, &offset, dentry, DIR_OFFSET_MIN, LONG_MAX, &octx->next_offset, GFP_KERNEL); - if (ret < 0) + if (unlikely(ret == -EBUSY)) + return -ENOSPC; + if (unlikely(ret < 0)) return ret; offset_set(dentry, offset); -- 2.47.0

6 months, 1 week

4
3
0 0

[PATCH v1 v1] drm/nouveau: Fix memory leak in nvbios_iccsense_parse

by Zhanxin Qi

The nvbios_iccsense_parse function allocates memory for sensor data but fails to free it when the function exits, leading to a memory leak. Add proper cleanup to free the allocated memory. Fixes: 39b7e6e547ff ("drm/nouveau/nvbios/iccsense: add parsing of the SENSE table") Signed-off-by: Zhanxin Qi <zhanxin(a)nfschina.com> Signed-off-by: Duanjun Li <duanjun(a)nfschina.com> Signed-off-by: Danilo Krummrich <dakr(a)redhat.com> --- .../include/nvkm/subdev/bios/iccsense.h | 2 ++ .../drm/nouveau/nvkm/subdev/bios/iccsense.c | 20 +++++++++++++++++++ .../drm/nouveau/nvkm/subdev/iccsense/base.c | 3 +++ 3 files changed, 25 insertions(+) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/iccsense.h b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/iccsense.h index 4c108fd2c805..8bfc28c3f7a7 100644 --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/iccsense.h +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/iccsense.h @@ -20,4 +20,6 @@ struct nvbios_iccsense { }; int nvbios_iccsense_parse(struct nvkm_bios *, struct nvbios_iccsense *); + +void nvbios_iccsense_cleanup(struct nvbios_iccsense *iccsense); #endif diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c index dea444d48f94..38fcc91ffea6 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c @@ -56,6 +56,19 @@ nvbios_iccsense_table(struct nvkm_bios *bios, u8 *ver, u8 *hdr, u8 *cnt, return 0; } +/** + * nvbios_iccsense_parse - Parse ICCSENSE table from VBIOS + * @bios: VBIOS base pointer + * @iccsense: ICCSENSE table structure to fill + * + * Parses the ICCSENSE table from VBIOS and fills the provided structure. + * The caller must invoke nvbios_iccsense_cleanup() after successful parsing + * to free the allocated rail resources. + * + * Returns: + * 0 - Success + * -ENODEV - Table not found + */ int nvbios_iccsense_parse(struct nvkm_bios *bios, struct nvbios_iccsense *iccsense) { @@ -127,3 +140,10 @@ nvbios_iccsense_parse(struct nvkm_bios *bios, struct nvbios_iccsense *iccsense) return 0; } + +void +nvbios_iccsense_cleanup(struct nvbios_iccsense *iccsense) +{ + kfree(iccsense->rail); + iccsense->rail = NULL; +} diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c index 8f0ccd3664eb..4c1759ecce38 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c @@ -291,6 +291,9 @@ nvkm_iccsense_oneinit(struct nvkm_subdev *subdev) list_add_tail(&rail->head, &iccsense->rails); } } + + nvbios_iccsense_cleanup(&stbl); + return 0; } -- 2.30.2

6 months, 1 week

2
1
0 0

FAILED: patch "[PATCH] bpf,perf: Fix invalid prog_array access in" 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 978c4486cca5c7b9253d3ab98a88c8e769cb9bbd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024121506-pancreas-mosaic-0ae0@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 978c4486cca5c7b9253d3ab98a88c8e769cb9bbd Mon Sep 17 00:00:00 2001 From: Jiri Olsa <jolsa(a)kernel.org> Date: Sun, 8 Dec 2024 15:25:07 +0100 Subject: [PATCH] bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog Syzbot reported [1] crash that happens for following tracing scenario: - create tracepoint perf event with attr.inherit=1, attach it to the process and set bpf program to it - attached process forks -> chid creates inherited event the new child event shares the parent's bpf program and tp_event (hence prog_array) which is global for tracepoint - exit both process and its child -> release both events - first perf_event_detach_bpf_prog call will release tp_event->prog_array and second perf_event_detach_bpf_prog will crash, because tp_event->prog_array is NULL The fix makes sure the perf_event_detach_bpf_prog checks prog_array is valid before it tries to remove the bpf program from it. [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc9… Fixes: 0ee288e69d03 ("bpf,perf: Fix perf_event_detach_bpf_prog error handling") Reported-by: syzbot+2e0d2840414ce817aaac(a)syzkaller.appspotmail.com Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20241208142507.1207698-1-jolsa@kernel.org diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index a403b05a7091..1b8db5aee9d3 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -2250,6 +2250,9 @@ void perf_event_detach_bpf_prog(struct perf_event *event) goto unlock; old_array = bpf_event_rcu_dereference(event->tp_event->prog_array); + if (!old_array) + goto put; + ret = bpf_prog_array_copy(old_array, event->prog, NULL, 0, &new_array); if (ret < 0) { bpf_prog_array_delete_safe(old_array, event->prog); @@ -2258,6 +2261,7 @@ void perf_event_detach_bpf_prog(struct perf_event *event) bpf_prog_array_free_sleepable(old_array); } +put: /* * It could be that the bpf_prog is not sleepable (and will be freed * via normal RCU), but is called from a point that supports sleepable

6 months, 1 week

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024