August 2023 - Linux-stable-mirror

[PATCH 5.10 1/1] udf: Handle error when adding extent to a file

by Vladislav Efanov

From: Jan Kara <jack(a)suse.cz> commit 19fd80de0a8b5170ef34704c8984cca920dffa59 upstream When adding extent to a file fails, so far we've silently squelshed the error. Make sure to propagate it up properly. Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Vladislav Efanov <VEfanov(a)ispras.ru> --- Syzkaller reports this problem in 5.10 stable release. The problem has been fixed by the following patch which can be cleanly applied to the 5.10 branch. fs/udf/inode.c | 41 +++++++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 14 deletions(-) diff --git a/fs/udf/inode.c b/fs/udf/inode.c index d114774ecdea..3e11190b7118 100644 --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -57,15 +57,15 @@ static int udf_update_inode(struct inode *, int); static int udf_sync_inode(struct inode *inode); static int udf_alloc_i_data(struct inode *inode, size_t size); static sector_t inode_getblk(struct inode *, sector_t, int *, int *); -static int8_t udf_insert_aext(struct inode *, struct extent_position, - struct kernel_lb_addr, uint32_t); +static int udf_insert_aext(struct inode *, struct extent_position, + struct kernel_lb_addr, uint32_t); static void udf_split_extents(struct inode *, int *, int, udf_pblk_t, struct kernel_long_ad *, int *); static void udf_prealloc_extents(struct inode *, int, int, struct kernel_long_ad *, int *); static void udf_merge_extents(struct inode *, struct kernel_long_ad *, int *); -static void udf_update_extents(struct inode *, struct kernel_long_ad *, int, - int, struct extent_position *); +static int udf_update_extents(struct inode *, struct kernel_long_ad *, int, + int, struct extent_position *); static int udf_get_block(struct inode *, sector_t, struct buffer_head *, int); static void __udf_clear_extent_cache(struct inode *inode) @@ -887,7 +887,9 @@ static sector_t inode_getblk(struct inode *inode, sector_t block, /* write back the new extents, inserting new extents if the new number * of extents is greater than the old number, and deleting extents if * the new number of extents is less than the old number */ - udf_update_extents(inode, laarr, startnum, endnum, &prev_epos); + *err = udf_update_extents(inode, laarr, startnum, endnum, &prev_epos); + if (*err < 0) + goto out_free; newblock = udf_get_pblock(inode->i_sb, newblocknum, iinfo->i_location.partitionReferenceNum, 0); @@ -1155,21 +1157,30 @@ static void udf_merge_extents(struct inode *inode, struct kernel_long_ad *laarr, } } -static void udf_update_extents(struct inode *inode, struct kernel_long_ad *laarr, - int startnum, int endnum, - struct extent_position *epos) +static int udf_update_extents(struct inode *inode, struct kernel_long_ad *laarr, + int startnum, int endnum, + struct extent_position *epos) { int start = 0, i; struct kernel_lb_addr tmploc; uint32_t tmplen; + int err; if (startnum > endnum) { for (i = 0; i < (startnum - endnum); i++) udf_delete_aext(inode, *epos); } else if (startnum < endnum) { for (i = 0; i < (endnum - startnum); i++) { - udf_insert_aext(inode, *epos, laarr[i].extLocation, - laarr[i].extLength); + err = udf_insert_aext(inode, *epos, + laarr[i].extLocation, + laarr[i].extLength); + /* + * If we fail here, we are likely corrupting the extent + * list and leaking blocks. At least stop early to + * limit the damage. + */ + if (err < 0) + return err; udf_next_aext(inode, epos, &laarr[i].extLocation, &laarr[i].extLength, 1); start++; @@ -1181,6 +1192,7 @@ static void udf_update_extents(struct inode *inode, struct kernel_long_ad *laarr udf_write_aext(inode, epos, &laarr[i].extLocation, laarr[i].extLength, 1); } + return 0; } struct buffer_head *udf_bread(struct inode *inode, udf_pblk_t block, @@ -2215,12 +2227,13 @@ int8_t udf_current_aext(struct inode *inode, struct extent_position *epos, return etype; } -static int8_t udf_insert_aext(struct inode *inode, struct extent_position epos, - struct kernel_lb_addr neloc, uint32_t nelen) +static int udf_insert_aext(struct inode *inode, struct extent_position epos, + struct kernel_lb_addr neloc, uint32_t nelen) { struct kernel_lb_addr oeloc; uint32_t oelen; int8_t etype; + int err; if (epos.bh) get_bh(epos.bh); @@ -2230,10 +2243,10 @@ static int8_t udf_insert_aext(struct inode *inode, struct extent_position epos, neloc = oeloc; nelen = (etype << 30) | oelen; } - udf_add_aext(inode, &epos, &neloc, nelen, 1); + err = udf_add_aext(inode, &epos, &neloc, nelen, 1); brelse(epos.bh); - return (nelen >> 30); + return err; } int8_t udf_delete_aext(struct inode *inode, struct extent_position epos) -- 2.34.1

1 year, 3 months

3
5
0 0

[PATCH AUTOSEL 6.4 01/54] ksmbd: Fix unsigned expression compared with zero

by Sasha Levin

From: Wang Ming <machel(a)vivo.com> [ Upstream commit 0266a2f791294e0b4ba36f4a1d89b8615ea3cac0 ] The return value of the ksmbd_vfs_getcasexattr() is signed. However, the return value is being assigned to an unsigned variable and subsequently recasted, causing warnings. Use a signed type. Signed-off-by: Wang Ming <machel(a)vivo.com> Acked-by: Tom Talpey <tom(a)talpey.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- fs/smb/server/vfs.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/smb/server/vfs.c b/fs/smb/server/vfs.c index 81489fdedd8e0..525fda90ed686 100644 --- a/fs/smb/server/vfs.c +++ b/fs/smb/server/vfs.c @@ -416,7 +416,8 @@ static int ksmbd_vfs_stream_write(struct ksmbd_file *fp, char *buf, loff_t *pos, { char *stream_buf = NULL, *wbuf; struct mnt_idmap *idmap = file_mnt_idmap(fp->filp); - size_t size, v_len; + size_t size; + ssize_t v_len; int err = 0; ksmbd_debug(VFS, "write stream data pos : %llu, count : %zd\n", @@ -433,9 +434,9 @@ static int ksmbd_vfs_stream_write(struct ksmbd_file *fp, char *buf, loff_t *pos, fp->stream.name, fp->stream.size, &stream_buf); - if ((int)v_len < 0) { + if (v_len < 0) { pr_err("not found stream in xattr : %zd\n", v_len); - err = (int)v_len; + err = v_len; goto out; } -- 2.40.1

1 year, 3 months

5
58
0 0

[PATCH] tpm: Don't make vendor check required for probe

by Mario Limonciello

The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") doesn't work properly on Intel fTPM. The TPM doesn't reply at bootup and returns back the command code. As this isn't crucial for anything but AMD fTPM and AMD fTPM works, throw away the error code to let Intel fTPM continue to work. Cc: stable(a)vger.kernel.org Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") Reported-by: Todd Brandt <todd.e.brandt(a)intel.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804 Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> --- drivers/char/tpm/tpm_crb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index 9eb1a18590123..b0e9931fe436c 100644 --- a/drivers/char/tpm/tpm_crb.c +++ b/drivers/char/tpm/tpm_crb.c @@ -472,8 +472,7 @@ static int crb_check_flags(struct tpm_chip *chip) if (ret) return ret; - ret = tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL); - if (ret) + if (tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL)) goto release; if (val == 0x414D4400U /* AMD */) -- 2.34.1

1 year, 3 months

5
8
0 0

[PATCH] iio: afe: rescale: Fix logic bug

by Linus Walleij

When introducing support for processed channels I needed to invert the expression: if (!iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) || !iio_channel_has_info(schan, IIO_CHAN_INFO_SCALE)) dev_err(dev, "source channel does not support raw/scale\n"); To the inverse, meaning detect when we can usse raw+scale rather than when we can not. This was the result: if (iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) || iio_channel_has_info(schan, IIO_CHAN_INFO_SCALE)) dev_info(dev, "using raw+scale source channel\n"); Ooops. Spot the error. Yep old George Boole came up and bit me. That should be an &&. The current code "mostly works" because we have not run into systems supporting only raw but not scale or only scale but not raw, and I doubt there are few using the rescaler on anything such, but let's fix the logic. Cc: Liam Beguin <liambeguin(a)gmail.com> Cc: stable(a)vger.kernel.org Fixes: 53ebee949980 ("iio: afe: iio-rescale: Support processed channels") Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/iio/afe/iio-rescale.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c index 7e511293d6d1..dc426e1484f0 100644 --- a/drivers/iio/afe/iio-rescale.c +++ b/drivers/iio/afe/iio-rescale.c @@ -278,7 +278,7 @@ static int rescale_configure_channel(struct device *dev, chan->ext_info = rescale->ext_info; chan->type = rescale->cfg->type; - if (iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) || + if (iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) && iio_channel_has_info(schan, IIO_CHAN_INFO_SCALE)) { dev_info(dev, "using raw+scale source channel\n"); } else if (iio_channel_has_info(schan, IIO_CHAN_INFO_PROCESSED)) { -- 2.35.3

1 year, 3 months

6
17
0 0

[PATCH v2] arm: marvell: Fix maxium->maxim typo in brownstone dts

by Duje Mihanović

Fix an obvious spelling error in the PMIC compatible in the MMP2 Brownstone DTS file. Without this, the PMIC would never probe. Fixes: 58f1193e6210 ("mfd: max8925: Add dts") Cc: stable(a)vger.kernel.org Signed-off-by: Duje Mihanović <duje.mihanovic(a)skole.hr> --- Changes in v2: - Address maintainer comments: - Add Fixes: and Cc: tags - Change "for" to "in" in subject - Emphasize PMIC's inability to probe without patch - Link to v1: https://lore.kernel.org/r/20230804-brownstone-typo-fix-v1-1-4832d84c0509@sk… --- arch/arm/boot/dts/marvell/mmp2-brownstone.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/marvell/mmp2-brownstone.dts b/arch/arm/boot/dts/marvell/mmp2-brownstone.dts index 04f1ae1382e7..bc64348b8218 100644 --- a/arch/arm/boot/dts/marvell/mmp2-brownstone.dts +++ b/arch/arm/boot/dts/marvell/mmp2-brownstone.dts @@ -28,7 +28,7 @@ &uart3 { &twsi1 { status = "okay"; pmic: max8925@3c { - compatible = "maxium,max8925"; + compatible = "maxim,max8925"; reg = <0x3c>; interrupts = <1>; interrupt-parent = <&intcmux4>; --- base-commit: 2ccdd1b13c591d306f0401d98dedc4bdcd02b421 change-id: 20230804-brownstone-typo-fix-f5b16c47d865 Best regards, -- Duje Mihanović <duje.mihanovic(a)skole.hr>

1 year, 3 months

2
1
0 0

[PATCH AUTOSEL 6.1 01/10] idmaengine: make FSL_EDMA and INTEL_IDMA64 depends on HAS_IOMEM

by Sasha Levin

From: Baoquan He <bhe(a)redhat.com> [ Upstream commit b1e213a9e31c20206f111ec664afcf31cbfe0dbb ] On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let FSL_EDMA and INTEL_IDMA64 depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset. -------- ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! -------- Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/ Signed-off-by: Baoquan He <bhe(a)redhat.com> Cc: Vinod Koul <vkoul(a)kernel.org> Cc: dmaengine(a)vger.kernel.org Link: https://lore.kernel.org/r/20230707135852.24292-2-bhe@redhat.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index b64ae02c26f8c..81de833ccd041 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -210,6 +210,7 @@ config FSL_DMA config FSL_EDMA tristate "Freescale eDMA engine support" depends on OF + depends on HAS_IOMEM select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help @@ -279,6 +280,7 @@ config IMX_SDMA config INTEL_IDMA64 tristate "Intel integrated DMA 64-bit support" + depends on HAS_IOMEM select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help -- 2.40.1

1 year, 3 months

2
13
0 0

[PATCH AUTOSEL 5.10 1/7] netlabel: fix shift wrapping bug in netlbl_catmap_setlong()

by Sasha Levin

From: Dmitry Mastykin <dmastykin(a)astralinux.ru> [ Upstream commit b403643d154d15176b060b82f7fc605210033edd ] There is a shift wrapping bug in this code on 32-bit architectures. NETLBL_CATMAP_MAPTYPE is u64, bitmap is unsigned long. Every second 32-bit word of catmap becomes corrupted. Signed-off-by: Dmitry Mastykin <dmastykin(a)astralinux.ru> Acked-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/netlabel/netlabel_kapi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c index 91b35b7c80d82..96059c99b915e 100644 --- a/net/netlabel/netlabel_kapi.c +++ b/net/netlabel/netlabel_kapi.c @@ -857,7 +857,8 @@ int netlbl_catmap_setlong(struct netlbl_lsm_catmap **catmap, offset -= iter->startbit; idx = offset / NETLBL_CATMAP_MAPSIZE; - iter->bitmap[idx] |= bitmap << (offset % NETLBL_CATMAP_MAPSIZE); + iter->bitmap[idx] |= (NETLBL_CATMAP_MAPTYPE)bitmap + << (offset % NETLBL_CATMAP_MAPSIZE); return 0; } -- 2.40.1

1 year, 3 months

2
8
0 0

[STABLE] stable backport request for 6.1 for io_uring

by Helge Deller

Hello Greg, Hello Jens, Hello stable team, would you please accept some backports to v6.1-stable for io_uring()? io_uring() fails on parisc because of some missing upstream patches. Since 6.1 is currently used in debian and gentoo as main kernel we face some build errors due to the missing patches. Here are the 3 steps I'm asking for (for kernel 6.1-stable only, the others are OK): 1) cherry-pick this upstream commit: commit 567b35159e76997e95b643b9a8a5d9d2198f2522 Author: John David Anglin <dave(a)parisc-linux.org> Date: Sun Feb 26 18:03:33 2023 +0000 parisc: Cleanup mmap implementation regarding color alignment 2) cherry-pick this upstream commit: commit b5d89408b9fb21258f7c371d6d48a674f60f7181 Author: Helge Deller <deller(a)gmx.de> Date: Fri Jun 30 12:36:09 2023 +0200 parisc: sys_parisc: parisc_personality() is called from asm code 3) apply the patch below as manual backport: I think this is the least invasive change and I wasn't able to otherwise simply pull in the upstream patches without touching code I don't want to touch (and keep life easier for Jens if he wants to backport other patches later). Thanks! Helge From: Helge Deller <deller(a)gmx.de> Date: Mon, 28 Aug 2023 23:07:49 +0200 Subject: [PATCH] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc Vidra Jonas reported issues on parisc with libuv which then triggers build errors with cmake. Debugging shows that those issues stem from io_uring(). I was not able to easily pull in upstream commits directly, so here is IMHO the least invasive manual backport of the following upstream commits to fix the cache aliasing issues on parisc on kernel 6.1 with io_uring: 56675f8b9f9b ("io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc") 32832a407a71 ("io_uring: Fix io_uring mmap() by using architecture-provided get_unmapped_area()") d808459b2e31 ("io_uring: Adjust mapping wrt architecture aliasing requirements") With this patch kernel 6.1 has all relevant mmap changes and is identical to kernel 6.5 with regard to mmap() in io_uring. Signed-off-by: Helge Deller <deller(a)gmx.de> Reported-by: Vidra.Jonas(a)seznam.cz Link: https://lore.kernel.org/linux-parisc/520.NvTX.6mXZpmfh4Ju.1awpAS@seznam.cz/ Cc: Sam James <sam(a)gentoo.org> Cc: John David Anglin <dave.anglin(a)bell.net> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c index ed8e9deae284..b0e47fe1eb4b 100644 --- a/io_uring/io_uring.c +++ b/io_uring/io_uring.c @@ -72,6 +72,7 @@ #include <linux/io_uring.h> #include <linux/audit.h> #include <linux/security.h> +#include <asm/shmparam.h> #define CREATE_TRACE_POINTS #include <trace/events/io_uring.h> @@ -3110,6 +3111,49 @@ static __cold int io_uring_mmap(struct file *file, struct vm_area_struct *vma) return remap_pfn_range(vma, vma->vm_start, pfn, sz, vma->vm_page_prot); } +static unsigned long io_uring_mmu_get_unmapped_area(struct file *filp, + unsigned long addr, unsigned long len, + unsigned long pgoff, unsigned long flags) +{ + void *ptr; + + /* + * Do not allow to map to user-provided address to avoid breaking the + * aliasing rules. Userspace is not able to guess the offset address of + * kernel kmalloc()ed memory area. + */ + if (addr) + return -EINVAL; + + ptr = io_uring_validate_mmap_request(filp, pgoff, len); + if (IS_ERR(ptr)) + return -ENOMEM; + + /* + * Some architectures have strong cache aliasing requirements. + * For such architectures we need a coherent mapping which aliases + * kernel memory *and* userspace memory. To achieve that: + * - use a NULL file pointer to reference physical memory, and + * - use the kernel virtual address of the shared io_uring context + * (instead of the userspace-provided address, which has to be 0UL + * anyway). + * - use the same pgoff which the get_unmapped_area() uses to + * calculate the page colouring. + * For architectures without such aliasing requirements, the + * architecture will return any suitable mapping because addr is 0. + */ + filp = NULL; + flags |= MAP_SHARED; + pgoff = 0; /* has been translated to ptr above */ +#ifdef SHM_COLOUR + addr = (uintptr_t) ptr; + pgoff = addr >> PAGE_SHIFT; +#else + addr = 0UL; +#endif + return current->mm->get_unmapped_area(filp, addr, len, pgoff, flags); +} + #else /* !CONFIG_MMU */ static int io_uring_mmap(struct file *file, struct vm_area_struct *vma) @@ -3324,6 +3368,8 @@ static const struct file_operations io_uring_fops = { #ifndef CONFIG_MMU .get_unmapped_area = io_uring_nommu_get_unmapped_area, .mmap_capabilities = io_uring_nommu_mmap_capabilities, +#else + .get_unmapped_area = io_uring_mmu_get_unmapped_area, #endif .poll = io_uring_poll, #ifdef CONFIG_PROC_FS

1 year, 3 months

4
7
0 0

[PATCH 6.5.y] erofs: ensure that the post-EOF tails are all zeroed

by Gao Xiang

commit e4c1cf523d820730a86cae2c6d55924833b6f7ac upstream. This was accidentally fixed up in commit e4c1cf523d82 but we can't take the full change due to other dependancy issues, so here is just the actual bugfix that is needed. [Background] keltargw reported an issue [1] that with mmaped I/Os, sometimes the tail of the last page (after file ends) is not filled with zeroes. The root cause is that such tail page could be wrongly selected for inplace I/Os so the zeroed part will then be filled with compressed data instead of zeroes. A simple fix is to avoid doing inplace I/Os for such tail parts, actually that was already fixed upstream in commit e4c1cf523d82 ("erofs: tidy up z_erofs_do_read_page()") by accident. [1] https://lore.kernel.org/r/3ad8b469-25db-a297-21f9-75db2d6ad224@linux.alibab… Reported-by: keltargw <keltar.gw(a)gmail.com> Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support") Signed-off-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> --- fs/erofs/zdata.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c index de4f12152b62..9c9350eb1704 100644 --- a/fs/erofs/zdata.c +++ b/fs/erofs/zdata.c @@ -1038,6 +1038,8 @@ static int z_erofs_do_read_page(struct z_erofs_decompress_frontend *fe, cur = end - min_t(erofs_off_t, offset + end - map->m_la, end); if (!(map->m_flags & EROFS_MAP_MAPPED)) { zero_user_segment(page, cur, end); + ++spiltted; + tight = false; goto next_part; } if (map->m_flags & EROFS_MAP_FRAGMENT) { -- 2.24.4

1 year, 3 months

2
7
0 0

amdgpu segfault on 6.5 while playing VP9

by Mario Limonciello

Hi, A segfault is reported while using hardware offload for playing VP9 videos on kernel 6.5. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2822 This is fixed by this commit: 6f38bdb86a05 ("drm/amdgpu: correct vmhub index in GMC v10/11") Can you please backport it to 6.5.y? Thanks,

1 year, 3 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2023