March 2021 - Linux-stable-mirror

[PATCH] MIPS: fix memory reservation for non-usermem setups

by Ilya Lipnitskiy

From: Tobias Wolf <dev-NTEO(a)vplace.de> Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is not. As the prerequisite of custom memory map has been removed, this results in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this platform. This patch adds the originally intended prerequisite again. This patch has been present in OpenWrt tree for over 2 years: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=93bfafb8dc209f153… Fixes: 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") Signed-off-by: Tobias Wolf <dev-NTEO(a)vplace.de> [Reword commit message] Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy(a)gmail.com> Cc: Marcin Nowakowski <marcin.nowakowski(a)mips.com> Cc: linux-mips(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org --- arch/mips/kernel/setup.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 279be0153f8b..97e3a0db651b 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -251,6 +251,8 @@ static unsigned long __init init_initrd(void) * Initialize the bootmem allocator. It also setup initrd related data * if needed. */ +static int usermem __initdata; + #if defined(CONFIG_SGI_IP27) || (defined(CONFIG_CPU_LOONGSON64) && defined(CONFIG_NUMA)) static void __init bootmem_init(void) @@ -290,7 +292,7 @@ static void __init bootmem_init(void) /* * Reserve any memory between the start of RAM and PHYS_OFFSET */ - if (ramstart > PHYS_OFFSET) + if (usermem && ramstart > PHYS_OFFSET) memblock_reserve(PHYS_OFFSET, ramstart - PHYS_OFFSET); if (PFN_UP(ramstart) > ARCH_PFN_OFFSET) { @@ -338,8 +340,6 @@ static void __init bootmem_init(void) #endif /* CONFIG_SGI_IP27 */ -static int usermem __initdata; - static int __init early_parse_mem(char *p) { phys_addr_t start, size; -- 2.30.1

3 years

3
8
0 0

[PATCH for-rc 4/4] IB/hfi1: Fix regressions in security fix

by dennis.dalessandro＠cornelisnetworks.com

From: Mike Marciniszyn <mike.marciniszyn(a)cornelisnetworks.com> The security code guards for non-current mm in all cases for updating the rb tree. That is ok for insert, but NOT ok for remove, since the insert has already guarded the node from being inserted and the remove can be called with a different mm because of a segfault other similar "close" issues where current-mm is NULL. Best case, is we leak pages. worst case we delete items for an lru_list more than once: [20945.911107] list_del corruption, ffffa0cd536bcac8->next is LIST_POISON1 (dead000000000100) Fix by removing the guard from any functions that remove nodes from the tree assuming the node was entered into the tree as valid since the insert is guarded. Fixes: 3d2a9d642512 ("IB/hfi1: Ensure correct mm is used at all times") Cc: <stable(a)vger.kernel.org> Signed-off-by: Mike Marciniszyn <mike.marciniszyn(a)cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)cornelisnetworks.com> --- drivers/infiniband/hw/hfi1/mmu_rb.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/drivers/infiniband/hw/hfi1/mmu_rb.c b/drivers/infiniband/hw/hfi1/mmu_rb.c index f3fb28e..375a881 100644 --- a/drivers/infiniband/hw/hfi1/mmu_rb.c +++ b/drivers/infiniband/hw/hfi1/mmu_rb.c @@ -210,9 +210,6 @@ bool hfi1_mmu_rb_remove_unless_exact(struct mmu_rb_handler *handler, unsigned long flags; bool ret = false; - if (current->mm != handler->mn.mm) - return ret; - spin_lock_irqsave(&handler->lock, flags); node = __mmu_rb_search(handler, addr, len); if (node) { @@ -235,9 +232,6 @@ void hfi1_mmu_rb_evict(struct mmu_rb_handler *handler, void *evict_arg) unsigned long flags; bool stop = false; - if (current->mm != handler->mn.mm) - return; - INIT_LIST_HEAD(&del_list); spin_lock_irqsave(&handler->lock, flags); @@ -271,9 +265,6 @@ void hfi1_mmu_rb_remove(struct mmu_rb_handler *handler, { unsigned long flags; - if (current->mm != handler->mn.mm) - return; - /* Validity of handler and node pointers has been checked by caller. */ trace_hfi1_mmu_rb_remove(node->addr, node->len); spin_lock_irqsave(&handler->lock, flags); -- 1.8.3.1

3 years

4
4
0 0

[PATCH] mpt3sas: only one vSES is handy even IOC has multi vSES

by Sreekanth Reddy

Whenever the driver is adding the vSES to virtual-phys list then the driver is reinitializing this list every time. Hence those vSES devices which were added earlier to this same list are lost. So, Even though multiple vSES devices are configured in IOC; but while scanning the vSES devices driver finds only one vSES device in the list and hence adds only that device to SML. So, don't reinitialize this list every time a new vSES device is added to it. Cc: stable(a)vger.kernel.org #v5.11.10+ Signed-off-by: Sreekanth Reddy <sreekanth.reddy(a)broadcom.com> --- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c index 6aa6de729187..ae1973878cc7 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -6483,6 +6483,9 @@ _scsih_alloc_vphy(struct MPT3SAS_ADAPTER *ioc, u8 port_id, u8 phy_num) if (!vphy) return NULL; + if (!port->vphys_mask) + INIT_LIST_HEAD(&port->vphys_list); + /* * Enable bit corresponding to HBA phy number on its * parent hba_port object's vphys_mask field. @@ -6490,7 +6493,6 @@ _scsih_alloc_vphy(struct MPT3SAS_ADAPTER *ioc, u8 port_id, u8 phy_num) port->vphys_mask |= (1 << phy_num); vphy->phy_mask |= (1 << phy_num); - INIT_LIST_HEAD(&port->vphys_list); list_add_tail(&vphy->list, &port->vphys_list); ioc_info(ioc, -- 2.27.0

3 years

2
1
0 0

[PATCH] mpt3sas: Block PCI cfg access from userspace during reset

by Sreekanth Reddy

While diag reset is in progress, there is short duration where all access to controller's PCI config space from the host needs to be blocked. This is due to a hardware limitation of IOC controllers. With this patch, driver will block all access to controller's config space from userland applications by calling pci_cfg_access_lock() while diag reset is in progress and unlocking after controller comes back to ready state. Cc: stable(a)vger.kernel.org #v5.4.108+ Signed-off-by: Sreekanth Reddy <sreekanth.reddy(a)broadcom.com> --- drivers/scsi/mpt3sas/mpt3sas_base.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c index ac0eef975f17..b6beacfd0f62 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.c +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c @@ -7252,6 +7252,8 @@ _base_diag_reset(struct MPT3SAS_ADAPTER *ioc) ioc_info(ioc, "sending diag reset !!\n"); + pci_cfg_access_lock(ioc->pdev); + drsprintk(ioc, ioc_info(ioc, "clear interrupts\n")); count = 0; @@ -7342,10 +7344,12 @@ _base_diag_reset(struct MPT3SAS_ADAPTER *ioc) goto out; } + pci_cfg_access_unlock(ioc->pdev); ioc_info(ioc, "diag reset: SUCCESS\n"); return 0; out: + pci_cfg_access_unlock(ioc->pdev); ioc_err(ioc, "diag reset: FAILED\n"); return -EFAULT; } -- 2.27.0

3 years

2
1
0 0

[PATCH v2] virtiofs: fix memory leak in virtio_fs_probe()

by Luis Henriques

When accidentally passing twice the same tag to qemu, kmemleak ended up reporting a memory leak in virtiofs. Also, looking at the log I saw the following error (that's when I realised the duplicated tag): virtiofs: probe of virtio5 failed with error -17 Here's the kmemleak log for reference: unreferenced object 0xffff888103d47800 (size 1024): comm "systemd-udevd", pid 118, jiffies 4294893780 (age 18.340s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 80 90 02 a0 ff ff ff ff ................ backtrace: [<000000000ebb87c1>] virtio_fs_probe+0x171/0x7ae [virtiofs] [<00000000f8aca419>] virtio_dev_probe+0x15f/0x210 [<000000004d6baf3c>] really_probe+0xea/0x430 [<00000000a6ceeac8>] device_driver_attach+0xa8/0xb0 [<00000000196f47a7>] __driver_attach+0x98/0x140 [<000000000b20601d>] bus_for_each_dev+0x7b/0xc0 [<00000000399c7b7f>] bus_add_driver+0x11b/0x1f0 [<0000000032b09ba7>] driver_register+0x8f/0xe0 [<00000000cdd55998>] 0xffffffffa002c013 [<000000000ea196a2>] do_one_initcall+0x64/0x2e0 [<0000000008f727ce>] do_init_module+0x5c/0x260 [<000000003cdedab6>] __do_sys_finit_module+0xb5/0x120 [<00000000ad2f48c6>] do_syscall_64+0x33/0x40 [<00000000809526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae Cc: stable(a)vger.kernel.org Signed-off-by: Luis Henriques <lhenriques(a)suse.de> --- Changes since v1: - Use kfree() to free fs->vqs instead of calling virtio_fs_put() fs/fuse/virtio_fs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index 8868ac31a3c0..989ef4f88636 100644 --- a/fs/fuse/virtio_fs.c +++ b/fs/fuse/virtio_fs.c @@ -896,6 +896,7 @@ static int virtio_fs_probe(struct virtio_device *vdev) out_vqs: vdev->config->reset(vdev); virtio_fs_cleanup_vqs(vdev, fs); + kfree(fs->vqs); out: vdev->priv = NULL;

3 years

4
3
0 0

FAILED: patch "[PATCH] counter: stm32-timer-cnt: fix ceiling miss-alignment with" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From b14d72ac731753708a7c1a6b3657b9312b6f0042 Mon Sep 17 00:00:00 2001 From: Fabrice Gasnier <fabrice.gasnier(a)foss.st.com> Date: Wed, 3 Mar 2021 18:49:49 +0100 Subject: [PATCH] counter: stm32-timer-cnt: fix ceiling miss-alignment with reload register Ceiling value may be miss-aligned with what's actually configured into the ARR register. This is seen after probe as currently the ARR value is zero, whereas ceiling value is set to the maximum. So: - reading ceiling reports zero - in case the counter gets enabled without any prior configuration, it won't count. - in case the function gets set by the user 1st, (priv->ceiling) is used. Fix it by getting rid of the cached "priv->ceiling" variable. Rather use the ARR register value directly by using regmap read or write when needed. There should be no drawback on performance as priv->ceiling isn't used in performance critical path. There's also no point in writing ARR while setting function (sms), so it can be safely removed. Fixes: ad29937e206f ("counter: Add STM32 Timer quadrature encoder") Suggested-by: William Breathitt Gray <vilhelm.gray(a)gmail.com> Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)foss.st.com> Acked-by: William Breathitt Gray <vilhelm.gray(a)gmail.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/1614793789-10346-1-git-send-email-fabrice.gasnier… Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c index 2295be3f309a..75bc401fdd18 100644 --- a/drivers/counter/stm32-timer-cnt.c +++ b/drivers/counter/stm32-timer-cnt.c @@ -31,7 +31,6 @@ struct stm32_timer_cnt { struct counter_device counter; struct regmap *regmap; struct clk *clk; - u32 ceiling; u32 max_arr; bool enabled; struct stm32_timer_regs bak; @@ -75,8 +74,10 @@ static int stm32_count_write(struct counter_device *counter, const unsigned long val) { struct stm32_timer_cnt *const priv = counter->priv; + u32 ceiling; - if (val > priv->ceiling) + regmap_read(priv->regmap, TIM_ARR, &ceiling); + if (val > ceiling) return -EINVAL; return regmap_write(priv->regmap, TIM_CNT, val); @@ -138,10 +139,6 @@ static int stm32_count_function_set(struct counter_device *counter, regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, 0); - /* TIMx_ARR register shouldn't be buffered (ARPE=0) */ - regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_ARPE, 0); - regmap_write(priv->regmap, TIM_ARR, priv->ceiling); - regmap_update_bits(priv->regmap, TIM_SMCR, TIM_SMCR_SMS, sms); /* Make sure that registers are updated */ @@ -199,7 +196,6 @@ static ssize_t stm32_count_ceiling_write(struct counter_device *counter, regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_ARPE, 0); regmap_write(priv->regmap, TIM_ARR, ceiling); - priv->ceiling = ceiling; return len; } @@ -374,7 +370,6 @@ static int stm32_timer_cnt_probe(struct platform_device *pdev) priv->regmap = ddata->regmap; priv->clk = ddata->clk; - priv->ceiling = ddata->max_arr; priv->max_arr = ddata->max_arr; priv->counter.name = dev_name(dev);

3 years

3
2
0 0

FAILED: patch "[PATCH] iio: hid-sensor-prox: Fix scale not correct issue" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-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>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From d68c592e02f6f49a88e705f13dfc1883432cf300 Mon Sep 17 00:00:00 2001 From: Ye Xiang <xiang.ye(a)intel.com> Date: Sat, 30 Jan 2021 18:25:30 +0800 Subject: [PATCH] iio: hid-sensor-prox: Fix scale not correct issue Currently, the proxy sensor scale is zero because it just return the exponent directly. To fix this issue, this patch use hid_sensor_format_scale to process the scale first then return the output. Fixes: 39a3a0138f61 ("iio: hid-sensors: Added Proximity Sensor Driver") Signed-off-by: Ye Xiang <xiang.ye(a)intel.com> Link: https://lore.kernel.org/r/20210130102530.31064-1-xiang.ye@intel.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/light/hid-sensor-prox.c b/drivers/iio/light/hid-sensor-prox.c index 330cf359e0b8..e9e00ce0c6d4 100644 --- a/drivers/iio/light/hid-sensor-prox.c +++ b/drivers/iio/light/hid-sensor-prox.c @@ -23,6 +23,9 @@ struct prox_state { struct hid_sensor_common common_attributes; struct hid_sensor_hub_attribute_info prox_attr; u32 human_presence; + int scale_pre_decml; + int scale_post_decml; + int scale_precision; }; /* Channel definitions */ @@ -93,8 +96,9 @@ static int prox_read_raw(struct iio_dev *indio_dev, ret_type = IIO_VAL_INT; break; case IIO_CHAN_INFO_SCALE: - *val = prox_state->prox_attr.units; - ret_type = IIO_VAL_INT; + *val = prox_state->scale_pre_decml; + *val2 = prox_state->scale_post_decml; + ret_type = prox_state->scale_precision; break; case IIO_CHAN_INFO_OFFSET: *val = hid_sensor_convert_exponent( @@ -234,6 +238,11 @@ static int prox_parse_report(struct platform_device *pdev, HID_USAGE_SENSOR_HUMAN_PRESENCE, &st->common_attributes.sensitivity); + st->scale_precision = hid_sensor_format_scale( + hsdev->usage, + &st->prox_attr, + &st->scale_pre_decml, &st->scale_post_decml); + return ret; }

3 years

3
2
0 0

[PATCH v2 1/2] media: staging/intel-ipu3: Fix memory leak in imu_fmt

by Ricardo Ribalda

We are losing the reference to an allocated memory if try. Change the order of the check to avoid that. 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 | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/ipu3/ipu3-v4l2.c b/drivers/staging/media/ipu3/ipu3-v4l2.c index 60aa02eb7d2a..35a74d99322f 100644 --- a/drivers/staging/media/ipu3/ipu3-v4l2.c +++ b/drivers/staging/media/ipu3/ipu3-v4l2.c @@ -693,6 +693,13 @@ static int imgu_fmt(struct imgu_device *imgu, unsigned int pipe, int node, if (inode == IMGU_NODE_STAT_3A || inode == IMGU_NODE_PARAMS) continue; + /* CSS expects some format on OUT queue */ + if (i != IPU3_CSS_QUEUE_OUT && + !imgu_pipe->nodes[inode].enabled) { + fmts[i] = NULL; + continue; + } + if (try) { fmts[i] = kmemdup(&imgu_pipe->nodes[inode].vdev_fmt.fmt.pix_mp, sizeof(struct v4l2_pix_format_mplane), @@ -705,10 +712,6 @@ static int imgu_fmt(struct imgu_device *imgu, unsigned int pipe, int node, fmts[i] = &imgu_pipe->nodes[inode].vdev_fmt.fmt.pix_mp; } - /* CSS expects some format on OUT queue */ - if (i != IPU3_CSS_QUEUE_OUT && - !imgu_pipe->nodes[inode].enabled) - fmts[i] = NULL; } if (!try) { -- 2.31.0.rc2.261.g7f71774620-goog

3 years

3
6
0 0

[PATCH for-rc 2/4] IB/hfi1: Call xa_destroy before unloading the module

by dennis.dalessandro＠cornelisnetworks.com

From: Kaike Wan <kaike.wan(a)intel.com> Call xa_destroy for hfi1_dev_table before unloading the module to avoid a potential memory leak. Fixes: 03b92789e5cf ("hfi1: Convert hfi1_unit_table to XArray") Cc: <stable(a)vger.kernel.org> Reviewed-by: Mike Marciniszyn <mike.marciniszyn(a)cornelisnetworks.com> Signed-off-by: Kaike Wan <kaike.wan(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)cornelisnetworks.com> --- drivers/infiniband/hw/hfi1/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/hfi1/init.c b/drivers/infiniband/hw/hfi1/init.c index 93237bf..e4f8db4 100644 --- a/drivers/infiniband/hw/hfi1/init.c +++ b/drivers/infiniband/hw/hfi1/init.c @@ -1507,7 +1507,7 @@ static void __exit hfi1_mod_cleanup(void) node_affinity_destroy_all(); hfi1_dbg_exit(); - WARN_ON(!xa_empty(&hfi1_dev_table)); + xa_destroy(&hfi1_dev_table); dispose_firmware(); /* asymmetric with obtain_firmware() */ dev_cleanup(); } -- 1.8.3.1

3 years

3
2
0 0

[PATCH v1] ovl: Fix leaked dentry

by Mickaël Salaün

From: Mickaël Salaün <mic(a)linux.microsoft.com> Since commit 6815f479ca90 ("ovl: use only uppermetacopy state in ovl_lookup()"), overlayfs doesn't put temporary dentry when there is a metacopy error, which leads to dentry leaks when shutting down the related superblock: overlayfs: refusing to follow metacopy origin for (/file0) ... BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay] ... WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1 ... RIP: 0010:umount_check.cold+0x107/0x14d ... Call Trace: d_walk+0x28c/0x950 ? dentry_lru_isolate+0x2b0/0x2b0 ? __kasan_slab_free+0x12/0x20 do_one_tree+0x33/0x60 shrink_dcache_for_umount+0x78/0x1d0 generic_shutdown_super+0x70/0x440 kill_anon_super+0x3e/0x70 deactivate_locked_super+0xc4/0x160 deactivate_super+0xfa/0x140 cleanup_mnt+0x22e/0x370 __cleanup_mnt+0x1a/0x30 task_work_run+0x139/0x210 do_exit+0xb0c/0x2820 ? __kasan_check_read+0x1d/0x30 ? find_held_lock+0x35/0x160 ? lock_release+0x1b6/0x660 ? mm_update_next_owner+0xa20/0xa20 ? reacquire_held_locks+0x3f0/0x3f0 ? __sanitizer_cov_trace_const_cmp4+0x22/0x30 do_group_exit+0x135/0x380 __do_sys_exit_group.isra.0+0x20/0x20 __x64_sys_exit_group+0x3c/0x50 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae ... VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day... This fix has been tested with a syzkaller reproducer. Cc: Amir Goldstein <amir73il(a)gmail.com> Cc: Miklos Szeredi <miklos(a)szeredi.hu> Cc: Vivek Goyal <vgoyal(a)redhat.com> Cc: <stable(a)vger.kernel.org> # v5.7+ Reported-by: syzbot <syzkaller(a)googlegroups.com> Fixes: 6815f479ca90 ("ovl: use only uppermetacopy state in ovl_lookup()") Signed-off-by: Mickaël Salaün <mic(a)linux.microsoft.com> Link: https://lore.kernel.org/r/20210329164907.2133175-1-mic@digikod.net --- fs/overlayfs/namei.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c index 3fe05fb5d145..424c594afd79 100644 --- a/fs/overlayfs/namei.c +++ b/fs/overlayfs/namei.c @@ -921,6 +921,7 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, if ((uppermetacopy || d.metacopy) && !ofs->config.metacopy) { err = -EPERM; pr_warn_ratelimited("refusing to follow metacopy origin for (%pd2)\n", dentry); + dput(this); goto out_put; } base-commit: a5e13c6df0e41702d2b2c77c8ad41677ebb065b3 -- 2.30.2

3 years

3
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2021