5.15.173-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 5.15.173-rc1 review
This is the start of the stable review cycle for the 5.15.173 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 17 Nov 2024 06:37:07 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.173-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.15.173-rc1
Linus Torvalds <[email protected]>
9p: fix slab cache name creation for real
Jan Kara <[email protected]>
udf: Avoid directory type conversion failure due to ENOMEM
Jan Kara <[email protected]>
udf: Allocate name buffer in directory iterator on heap
Yuanzheng Song <[email protected]>
mm/memory: add non-anonymous page check in the copy_present_page()
Qun-Wei Lin <[email protected]>
mm: krealloc: Fix MTE false alarm in __do_krealloc
Hagar Hemdan <[email protected]>
io_uring: fix possible deadlock in io_register_iowq_max_workers()
Li Nan <[email protected]>
md/raid10: improve code of mrdev in raid10_sync_request
Reinhard Speyerer <[email protected]>
net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition
Hans de Goede <[email protected]>
HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard
Kenneth Albanowski <[email protected]>
HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad
Alessandro Zanni <[email protected]>
fs: Fix uninitialized value issue in from_kuid and from_kgid
Yuan Can <[email protected]>
vDPA/ifcvf: Fix pci_read_config_byte() return code handling
Michael Ellerman <[email protected]>
powerpc/powernv: Free name on error in opal_event_init()
Ian Forbes <[email protected]>
drm/vmwgfx: Limit display layout ioctl array size to VMWGFX_NUM_DISPLAY_UNITS
Julian Vetter <[email protected]>
sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML
Herbert Xu <[email protected]>
crypto: marvell/cesa - Disable hash algorithms
Rik van Riel <[email protected]>
bpf: use kvzmalloc to allocate BPF verifier environment
WangYuli <[email protected]>
HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad
Stefan Blum <[email protected]>
HID: multitouch: Add support for B2402FVA track point
SurajSonawane2415 <[email protected]>
block: Fix elevator_get_default() checking for NULL q->tag_set
Sergey Matsievskiy <[email protected]>
irqchip/ocelot: Fix trigger register address
Pedro Falcato <[email protected]>
9p: Avoid creating multiple slab caches with the same name
-------------
Diffstat:
Makefile | 4 ++-- arch/powerpc/platforms/powernv/opal-irqchip.c | 1 + block/elevator.c | 4 ++-- drivers/crypto/marvell/cesa/hash.c | 12 ++++++------ drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +++- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 3 --- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-lenovo.c | 8 ++++++++ drivers/hid/hid-multitouch.c | 13 +++++++++++++ drivers/irqchip/irq-mscc-ocelot.c | 4 ++-- drivers/md/raid10.c | 23 ++++++++++++----------- drivers/net/usb/qmi_wwan.c | 1 + drivers/vdpa/ifcvf/ifcvf_base.c | 2 +- fs/ocfs2/file.c | 9 ++++++--- fs/udf/directory.c | 27 +++++++++++++++++++-------- fs/udf/udfdecl.h | 2 +- io_uring/io_uring.c | 5 +++++ kernel/bpf/verifier.c | 4 ++-- mm/memory.c | 11 +++++++++++ mm/slab_common.c | 2 +- net/9p/client.c | 12 +++++++++++- sound/Kconfig | 2 +- 23 files changed, 111 insertions(+), 47 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/22 9p: Avoid creating multiple slab caches with the same name
5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pedro Falcato <[email protected]>
[ Upstream commit 79efebae4afc2221fa814c3cae001bede66ab259 ]
In the spirit of [1], avoid creating multiple slab caches with the same name. Instead, add the dev_name into the mix.
[1]: https://lore.kernel.org/all/[email protected]/
Message-ID: <[email protected]>
--- net/9p/client.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
net/9p/client.c +9 -1
@@ -1005,6 +1005,7 @@ struct p9_client *p9_client_create(const char *dev_name, char *options)int err;struct p9_client *clnt;char *client_id; +char *cache_name; err =0 ; clnt =kmalloc (sizeof (*clnt),GFP_KERNEL );
@@ -1057,15 +1058,22 @@ struct p9_client *p9_client_create(const char *dev_name, char *options)if (err) goto close_trans; + cache_name =kasprintf (GFP_KERNEL ,"9p-fcall-cache-%s" , dev_name); +if (!cache_name) { + err = -ENOMEM ; + goto close_trans; + } +/* P9_HDRSZ + 4 is the smallest packet header we can have that is * followed by data accessed from userspace by read */ clnt->fcall_cache = -kmem_cache_create_usercopy ("9p-fcall-cache" , clnt->msize, +kmem_cache_create_usercopy (cache_name, clnt->msize,0 ,0 ,P9_HDRSZ +4 , clnt->msize - (P9_HDRSZ +4 ),NULL ); +kfree (cache_name);return clnt; close_trans:
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 2/22 irqchip/ocelot: Fix trigger register address
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Matsievskiy <[email protected]>
[ Upstream commit 9e9c4666abb5bb444dac37e2d7eb5250c8d52a45 ]
Controllers, supported by this driver, have two sets of registers:
* (main) interrupt registers control peripheral interrupt sources.
* device interrupt registers configure per-device (network interface) interrupts and act as an extra stage before the main interrupt registers.
In the driver unmask code, device trigger registers are used in the mask calculation of the main interrupt sticky register, mixing two kinds of registers.
Use the main interrupt trigger register instead.
--- drivers/irqchip/irq-mscc-ocelot.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/irqchip/irq-mscc-ocelot.c +2 -2
@@ -37,7 +37,7 @@ static struct chip_props ocelot_props = { .reg_off_ena_clr = 0x1c, .reg_off_ena_set = 0x20, .reg_off_ident = 0x38, - .reg_off_trigger = 0x5c, + .reg_off_trigger = 0x4, .n_irq = 24, };
@@ -70,7 +70,7 @@ static struct chip_props jaguar2_props = { .reg_off_ena_clr = 0x1c, .reg_off_ena_set = 0x20, .reg_off_ident = 0x38, - .reg_off_trigger = 0x5c, + .reg_off_trigger = 0x4, .n_irq = 29, };
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 3/22 block: Fix elevator_get_default() checking for NULL q->tag_set
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: SurajSonawane2415 <[email protected]>
[ Upstream commit b402328a24ee7193a8ab84277c0c90ae16768126 ]
elevator_get_default() and elv_support_iosched() both check for whether or not q->tag_set is non-NULL, however it's not possible for them to be NULL. This messes up some static checkers, as the checking of tag_set isn't consistent.
Remove the checks, which both simplifies the logic and avoids checker errors.
--- block/elevator.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
block/elevator.c +2 -2
@@ -620,7 +620,7 @@ int elevator_switch_mq(struct request_queue *q,static inline bool elv_support_iosched (struct request_queue *q) {if (!queue_is_mq (q) || - (q->tag_set && (q->tag_set->flags &BLK_MQ_F_NO_SCHED ))) + (q->tag_set->flags &BLK_MQ_F_NO_SCHED ))return false;return true; }
@@ -631,7 +631,7 @@ static inline bool elv_support_iosched(struct request_queue *q)*/ static struct elevator_type *elevator_get_default (struct request_queue *q) { -if (q->tag_set && q->tag_set->flags &BLK_MQ_F_NO_SCHED_BY_DEFAULT ) +if (q->tag_set->flags &BLK_MQ_F_NO_SCHED_BY_DEFAULT )return NULL ; if (q->nr_hw_queues != 1 &&
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 4/22 HID: multitouch: Add support for B2402FVA track point
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Blum <[email protected]>
[ Upstream commit 1a5cbb526ec4b885177d06a8bc04f38da7dbb1d9 ]
By default the track point does not work on the Asus Expertbook B2402FVA.
Quoted 1 line
From libinput record i got the ID of the track point device:
evdev:
# Name: ASUE1201:00 04F3:32AE
# ID: bus 0x18 vendor 0x4f3 product 0x32ae version 0x100I found that the track point is functional, when i set the MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU class for the reported device.
--- drivers/hid/hid-multitouch.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/hid/hid-multitouch.c +4 -0
@@ -2017,6 +2017,10 @@ static const struct hid_device_id mt_devices[] = {HID_DEVICE (BUS_I2C ,HID_GROUP_MULTITOUCH_WIN_8 , USB_VENDOR_ID_ELAN, 0x3148) }, + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU, +HID_DEVICE (BUS_I2C ,HID_GROUP_MULTITOUCH_WIN_8 , + USB_VENDOR_ID_ELAN, 0x32ae) }, + /* Elitegroup panel */ { .driver_data = MT_CLS_SERIAL, MT_USB_DEVICE(USB_VENDOR_ID_ELITEGROUP,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 5/22 HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: WangYuli <[email protected]>
[ Upstream commit 7a5ab8071114344f62a8b1e64ed3452a77257d76 ]
The behavior of HONOR MagicBook Art 14 touchpad is not consistent after reboots, as sometimes it reports itself as a touchpad, and sometimes as a mouse.
Similarly to GLO-GXXX it is possible to call MT_QUIRK_FORCE_GET_FEATURE as a workaround to force set feature in mt_set_input_mode() for such special touchpad device.
--- drivers/hid/hid-multitouch.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/hid/hid-multitouch.c +5 -0
@@ -2087,6 +2087,11 @@ static const struct hid_device_id mt_devices[] = { HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8, 0x347d, 0x7853) }, +/* HONOR MagicBook Art 14 touchpad */ + { .driver_data = MT_CLS_VTL, +HID_DEVICE (BUS_I2C ,HID_GROUP_MULTITOUCH_WIN_8 , + 0x35cc, 0x0104) }, + /* Ilitek dual touch panel */ { .driver_data = MT_CLS_NSMU, MT_USB_DEVICE(USB_VENDOR_ID_ILITEK,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 6/22 bpf: use kvzmalloc to allocate BPF verifier environment
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rik van Riel <[email protected]>
[ Upstream commit 434247637c66e1be2bc71a9987d4c3f0d8672387 ]
The kzmalloc call in bpf_check can fail when memory is very fragmented, which in turn can lead to an OOM kill.
Use kvzmalloc to fall back to vmalloc when memory is too fragmented to allocate an order 3 sized bpf verifier environment.
Admittedly this is not a very common case, and only happens on systems where memory has already been squeezed close to the limit, but this does not seem like much of a hot path, and it's a simple enough fix.
--- kernel/bpf/verifier.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/bpf/verifier.c +2 -2
@@ -14013,7 +14013,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr)/* 'struct bpf_verifier_env' can be global, but since it's not small, * allocate/free it every time bpf_check() is called */ - env =kzalloc (sizeof (struct bpf_verifier_env ),GFP_KERNEL ); + env =kvzalloc (sizeof (struct bpf_verifier_env ),GFP_KERNEL );if (!env)return -ENOMEM ; log = &env->log;
@@ -14228,6 +14228,6 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr)mutex_unlock (&bpf_verifier_lock);vfree (env->insn_aux_data); err_free_env: -kfree (env); +kvfree (env);return ret; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 7/22 crypto: marvell/cesa - Disable hash algorithms
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <[email protected]>
[ Upstream commit e845d2399a00f866f287e0cefbd4fc7d8ef0d2f7 ]
Disable cesa hash algorithms by lowering the priority because they appear to be broken when invoked in parallel. This allows them to still be tested for debugging purposes.
--- drivers/crypto/marvell/cesa/hash.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/crypto/marvell/cesa/hash.c +6 -6
@@ -947,7 +947,7 @@ struct ahash_alg mv_md5_alg = { .base = { .cra_name = "md5", .cra_driver_name = "mv-md5", - .cra_priority = 300, + .cra_priority = 0, .cra_flags =CRYPTO_ALG_ASYNC |CRYPTO_ALG_ALLOCATES_MEMORY | CRYPTO_ALG_KERN_DRIVER_ONLY,
@@ -1018,7 +1018,7 @@ struct ahash_alg mv_sha1_alg = { .base = { .cra_name = "sha1", .cra_driver_name = "mv-sha1", - .cra_priority = 300, + .cra_priority = 0, .cra_flags =CRYPTO_ALG_ASYNC |CRYPTO_ALG_ALLOCATES_MEMORY | CRYPTO_ALG_KERN_DRIVER_ONLY,
@@ -1092,7 +1092,7 @@ struct ahash_alg mv_sha256_alg = { .base = { .cra_name = "sha256", .cra_driver_name = "mv-sha256", - .cra_priority = 300, + .cra_priority = 0, .cra_flags =CRYPTO_ALG_ASYNC |CRYPTO_ALG_ALLOCATES_MEMORY | CRYPTO_ALG_KERN_DRIVER_ONLY,
@@ -1327,7 +1327,7 @@ struct ahash_alg mv_ahmac_md5_alg = { .base = { .cra_name = "hmac(md5)", .cra_driver_name = "mv-hmac-md5", - .cra_priority = 300, + .cra_priority = 0, .cra_flags =CRYPTO_ALG_ASYNC |CRYPTO_ALG_ALLOCATES_MEMORY | CRYPTO_ALG_KERN_DRIVER_ONLY,
@@ -1398,7 +1398,7 @@ struct ahash_alg mv_ahmac_sha1_alg = { .base = { .cra_name = "hmac(sha1)", .cra_driver_name = "mv-hmac-sha1", - .cra_priority = 300, + .cra_priority = 0, .cra_flags =CRYPTO_ALG_ASYNC |CRYPTO_ALG_ALLOCATES_MEMORY | CRYPTO_ALG_KERN_DRIVER_ONLY,
@@ -1469,7 +1469,7 @@ struct ahash_alg mv_ahmac_sha256_alg = { .base = { .cra_name = "hmac(sha256)", .cra_driver_name = "mv-hmac-sha256", - .cra_priority = 300, + .cra_priority = 0, .cra_flags =CRYPTO_ALG_ASYNC |CRYPTO_ALG_ALLOCATES_MEMORY | CRYPTO_ALG_KERN_DRIVER_ONLY,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 8/22 sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julian Vetter <[email protected]>
[ Upstream commit ad6639f143a0b42d7fb110ad14f5949f7c218890 ]
When building for the UM arch and neither INDIRECT_IOMEM=y, nor HAS_IOMEM=y is selected, it will fall back to the implementations from asm-generic/io.h for IO memcpy. But these fall-back functions just do a memcpy. So, instead of depending on UML, add dependency on 'HAS_IOMEM || INDIRECT_IOMEM'.
--- sound/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/Kconfig +1 -1
@@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only menuconfig SOUND tristate "Sound card support" - depends on HAS_IOMEM || UML + depends on HAS_IOMEM || INDIRECT_IOMEM help If you have a sound card in your computer, i.e. if it can say more than an occasional beep, say Y.
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 9/22 drm/vmwgfx: Limit display layout ioctl array size to VMWGFX_NUM_DISPLAY_UNITS
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Forbes <[email protected]>
[ Upstream commit 28a5dfd4f615539fb22fb6d5c219c199c14e6eb6 ]
Currently the array size is only limited by the largest kmalloc size which is incorrect. This change will also return a more specific error message than ENOMEM to userspace.
--- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +++- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 3 --- 3 files changed, 5 insertions(+), 6 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +2 -2
@@ -59,7 +59,7 @@#define VMWGFX_DRIVER_MINOR 19#define VMWGFX_DRIVER_PATCHLEVEL 0#define VMWGFX_FIFO_STATIC_SIZE (1024*1024) -#define VMWGFX_MAX_DISPLAYS 16 +#define VMWGFX_NUM_DISPLAY_UNITS 8#define VMWGFX_CMD_BOUNCE_INIT_SIZE 32768#define VMWGFX_PCI_ID_SVGA2 0x0405
@@ -71,7 +71,7 @@#define VMWGFX_NUM_GB_CONTEXT 256#define VMWGFX_NUM_GB_SHADER 20000#define VMWGFX_NUM_GB_SURFACE 32768 -#define VMWGFX_NUM_GB_SCREEN_TARGET VMWGFX_MAX_DISPLAYS +#define VMWGFX_NUM_GB_SCREEN_TARGET VMWGFX_NUM_DISPLAY_UNITS#define VMWGFX_NUM_DXCONTEXT 256#define VMWGFX_NUM_DXQUERY 512#define VMWGFX_NUM_MOB (VMWGFX_NUM_GB_CONTEXT +\
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +3 -1
@@ -2295,7 +2295,7 @@ int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data,struct drm_mode_config *mode_config = &dev->mode_config;struct drm_vmw_update_layout_arg *arg = (struct drm_vmw_update_layout_arg *)data; -void __user *user_rects; +const void __user *user_rects;struct drm_vmw_rect *rects;struct drm_rect *drm_rects;unsigned rects_size;
@@ -2308,6 +2308,8 @@ int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data, def_rect.x2, def_rect.y2);vmw_du_update_layout (dev_priv,1 , &def_rect);return 0 ; + }else if (arg->num_outputs >VMWGFX_NUM_DISPLAY_UNITS ) { +return -E2BIG ; } rects_size = arg->num_outputs *sizeof (struct drm_vmw_rect );
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h +0 -3
@@ -198,9 +198,6 @@ struct vmw_kms_dirty {s32 unit_y2; }; -#define VMWGFX_NUM_DISPLAY_UNITS 8 - -#define vmw_framebuffer_to_vfb (x) \ container_of(x, struct vmw_framebuffer, base)#define vmw_framebuffer_to_vfbs (x) \
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 10/22 powerpc/powernv: Free name on error in opal_event_init()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Ellerman <[email protected]>
[ Upstream commit cf8989d20d64ad702a6210c11a0347ebf3852aa7 ]
In opal_event_init() if request_irq() fails name is not freed, leading to a memory leak. The code only runs at boot time, there's no way for a user to trigger it, so there's no security impact.
Fix the leak by freeing name in the error path.
--- arch/powerpc/platforms/powernv/opal-irqchip.c | 1 + 1 file changed, 1 insertion(+)
arch/powerpc/platforms/powernv/opal-irqchip.c +1 -0
@@ -282,6 +282,7 @@ int __init opal_event_init(void) name, NULL);if (rc) {pr_warn ("Error %d requesting OPAL irq %d\n" , rc, (int )r->start); +kfree (name);continue ; } }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 11/22 vDPA/ifcvf: Fix pci_read_config_byte() return code handling
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yuan Can <[email protected]>
[ Upstream commit 7f8825b2a78ac392d3fbb3a2e65e56d9e39d75e9 ]
ifcvf_init_hw() uses pci_read_config_byte() that returns PCIBIOS_* codes. The error handling, however, assumes the codes are normal errnos because it checks for < 0.
Convert the error check to plain non-zero check.
Message-Id: <[email protected]>
--- drivers/vdpa/ifcvf/ifcvf_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/vdpa/ifcvf/ifcvf_base.c +1 -1
@@ -105,7 +105,7 @@ int ifcvf_init_hw(struct ifcvf_hw *hw, struct pci_dev *pdev)u32 i; ret =pci_read_config_byte (pdev,PCI_CAPABILITY_LIST , &pos); -if (ret <0 ) { +if (ret) {IFCVF_ERR (pdev,"Failed to read PCI capability list\n" );return -EIO ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 12/22 fs: Fix uninitialized value issue in from_kuid and from_kgid
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alessandro Zanni <[email protected]>
[ Upstream commit 15f34347481648a567db67fb473c23befb796af5 ]
ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set.
Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.
--- fs/ocfs2/file.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
fs/ocfs2/file.c +6 -3
@@ -1132,9 +1132,12 @@ int ocfs2_setattr(struct user_namespace *mnt_userns, struct dentry *dentry,trace_ocfs2_setattr (inode, dentry, (unsigned long long )OCFS2_I (inode)->ip_blkno, dentry->d_name.len, dentry->d_name.name, - attr->ia_valid, attr->ia_mode, -from_kuid (&init_user_ns, attr->ia_uid), -from_kgid (&init_user_ns, attr->ia_gid)); + attr->ia_valid, + attr->ia_valid &ATTR_MODE ? attr->ia_mode :0 , + attr->ia_valid &ATTR_UID ? +from_kuid (&init_user_ns, attr->ia_uid) :0 , + attr->ia_valid &ATTR_GID ? +from_kgid (&init_user_ns, attr->ia_gid) :0 );/* ensuring we don't even attempt to truncate a symlink */ if (S_ISLNK (inode->i_mode))
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 13/22 HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kenneth Albanowski <[email protected]>
[ Upstream commit 526748b925185e95f1415900ee13c2469d4b64cc ]
The Logitech Casa Touchpad does not reliably send touch release signals when communicating through the Logitech Bolt wireless-to-USB receiver.
Adjusting the device class to add MT_QUIRK_NOT_SEEN_MEANS_UP to make sure that no touches become stuck, MT_QUIRK_FORCE_MULTI_INPUT is not needed, but harmless.
Linux does not have information on which devices are connected to the Bolt receiver, so we have to enable this for the entire device.
--- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-multitouch.c | 4 ++++ 2 files changed, 5 insertions(+)
drivers/hid/hid-ids.h +1 -0
@@ -831,6 +831,7 @@#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1 0xc539#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_1 0xc53f#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_POWERPLAY 0xc53a +#define USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER 0xc548#define USB_DEVICE_ID_SPACETRAVELLER 0xc623#define USB_DEVICE_ID_SPACENAVIGATOR 0xc626#define USB_DEVICE_ID_DINOVO_DESKTOP 0xc704
drivers/hid/hid-multitouch.c +4 -0
@@ -2134,6 +2134,10 @@ static const struct hid_device_id mt_devices[] = {HID_DEVICE (BUS_BLUETOOTH ,HID_GROUP_MULTITOUCH_WIN_8 ,USB_VENDOR_ID_LOGITECH , USB_DEVICE_ID_LOGITECH_CASA_TOUCHPAD) }, + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU, +HID_DEVICE (BUS_USB ,HID_GROUP_MULTITOUCH_WIN_8 , +USB_VENDOR_ID_LOGITECH , + USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER) }, /* MosArt panels */ { .driver_data = MT_CLS_CONFIDENCE_MINUS_ONE,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 14/22 HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
[ Upstream commit 51268879eb2bfc563a91cdce69362d9dbf707e7e ]
The Thinkpad X1 Tablet Gen 3 keyboard has the same Lenovo specific quirks as the original Thinkpad X1 Tablet keyboard.
Add the PID for the "Thinkpad X1 Tablet Gen 3 keyboard" to the hid-lenovo driver to fix the FnLock, Mute and media buttons not working.
Closes https://bugzilla.redhat.com/show_bug.cgi?id=2315395
--- drivers/hid/hid-lenovo.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/hid/hid-lenovo.c +8 -0
@@ -343,6 +343,7 @@ static int lenovo_input_mapping(struct hid_device *hdev,return lenovo_input_mapping_tp10_ultrabook_kbd (hdev, hi, field, usage, bit, max);case USB_DEVICE_ID_LENOVO_X1_TAB : +case USB_DEVICE_ID_LENOVO_X1_TAB3 :return lenovo_input_mapping_x1_tab_kbd (hdev, hi, field, usage, bit, max);default :return 0 ;
@@ -431,6 +432,7 @@ static ssize_t attr_fn_lock_store(struct device *dev,break ;case USB_DEVICE_ID_LENOVO_TP10UBKBD :case USB_DEVICE_ID_LENOVO_X1_TAB : +case USB_DEVICE_ID_LENOVO_X1_TAB3 : ret =lenovo_led_set_tp10ubkbd (hdev,TP10UBKBD_FN_LOCK_LED , value);if (ret)return ret;
@@ -614,6 +616,7 @@ static int lenovo_event(struct hid_device *hdev, struct hid_field *field,return lenovo_event_cptkbd (hdev, field, usage, value);case USB_DEVICE_ID_LENOVO_TP10UBKBD :case USB_DEVICE_ID_LENOVO_X1_TAB : +case USB_DEVICE_ID_LENOVO_X1_TAB3 :return lenovo_event_tp10ubkbd (hdev, field, usage, value);default :return 0 ;
@@ -896,6 +899,7 @@ static int lenovo_led_brightness_set(struct led_classdev *led_cdev,break ;case USB_DEVICE_ID_LENOVO_TP10UBKBD :case USB_DEVICE_ID_LENOVO_X1_TAB : +case USB_DEVICE_ID_LENOVO_X1_TAB3 : ret =lenovo_led_set_tp10ubkbd (hdev, tp10ubkbd_led[led_nr], value);break ; }
@@ -1136,6 +1140,7 @@ static int lenovo_probe(struct hid_device *hdev,break ;case USB_DEVICE_ID_LENOVO_TP10UBKBD :case USB_DEVICE_ID_LENOVO_X1_TAB : +case USB_DEVICE_ID_LENOVO_X1_TAB3 : ret =lenovo_probe_tp10ubkbd (hdev);break ;default :
@@ -1202,6 +1207,7 @@ static void lenovo_remove(struct hid_device *hdev)break ;case USB_DEVICE_ID_LENOVO_TP10UBKBD :case USB_DEVICE_ID_LENOVO_X1_TAB : +case USB_DEVICE_ID_LENOVO_X1_TAB3 :lenovo_remove_tp10ubkbd (hdev);break ; }
@@ -1247,6 +1253,8 @@ static const struct hid_device_id lenovo_devices[] = {*/ {HID_DEVICE (BUS_USB ,HID_GROUP_GENERIC , USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_X1_TAB) }, + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, + USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_X1_TAB3) }, { } };
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 15/22 net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Reinhard Speyerer <[email protected]>
[ Upstream commit 64761c980cbf71fb7a532a8c7299907ea972a88c ]
Add Fibocom FG132 0x0112 composition:
T: Bus=03 Lev=02 Prnt=06 Port=01 Cnt=02 Dev#= 10 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2cb7 ProdID=0112 Rev= 5.15 S: Manufacturer=Fibocom Wireless Inc. S: Product=Fibocom Module S: SerialNumber=xxxxxxxx C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
--- drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/usb/qmi_wwan.c +1 -0
@@ -1421,6 +1421,7 @@ static const struct usb_device_id products[] = { {QMI_FIXED_INTF(0x2c7c, 0x0296, 4)}, /* Quectel BG96 */ {QMI_QUIRK_SET_DTR(0x2c7c, 0x030e, 4)}, /* Quectel EM05GV2 */ {QMI_QUIRK_SET_DTR(0x2cb7, 0x0104, 4)}, /* Fibocom NL678 series */ + {QMI_QUIRK_SET_DTR(0x2cb7, 0x0112, 0)}, /* Fibocom FG132 */ {QMI_FIXED_INTF(0x0489, 0xe0b4, 0)}, /* Foxconn T77W968 LTE */ {QMI_FIXED_INTF(0x0489, 0xe0b5, 0)}, /* Foxconn T77W968 LTE with eSIM support*/ {QMI_FIXED_INTF(0x2692, 0x9025, 4)}, /* Cellient MPL200 (rebranded Qualcomm 05c6:9025) */
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 16/22 md/raid10: improve code of mrdev in raid10_sync_request
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Nan <[email protected]>
commit 59f8f0b54c8ffb4521f6bbd1cb6f4dfa5022e75e upstream.
'need_recover' and 'mrdev' are equivalent in raid10_sync_request(), and inc mrdev->nr_pending is unreasonable if don't need recovery. Replace 'need_recover' with 'mrdev', and only inc nr_pending when needed.
--- drivers/md/raid10.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-)
drivers/md/raid10.c +12 -11
@@ -3443,7 +3443,6 @@ static sector_t raid10_sync_request(strusector_t sect;int must_sync;int any_working; -int need_recover =0 ;struct raid10_info *mirror = &conf->mirrors[i];struct md_rdev *mrdev, *mreplace;
@@ -3451,14 +3450,13 @@ static sector_t raid10_sync_request(stru mrdev =rcu_dereference (mirror->rdev); mreplace =rcu_dereference (mirror->replacement); -if (mrdev !=NULL && - !test_bit (Faulty, &mrdev->flags) && - !test_bit (In_sync, &mrdev->flags)) - need_recover =1 ; +if (mrdev && (test_bit (Faulty, &mrdev->flags) || +test_bit (In_sync, &mrdev->flags))) + mrdev =NULL ;if (mreplace &&test_bit (Faulty, &mreplace->flags)) mreplace =NULL ; -if (!need_recover && !mreplace) { +if (!mrdev && !mreplace) {rcu_read_unlock ();continue ; }
@@ -3492,7 +3490,8 @@ static sector_t raid10_sync_request(strurcu_read_unlock ();continue ; } -atomic_inc (&mrdev->nr_pending); +if (mrdev) +atomic_inc (&mrdev->nr_pending);if (mreplace)atomic_inc (&mreplace->nr_pending);rcu_read_unlock ();
@@ -3579,7 +3578,7 @@ static sector_t raid10_sync_request(stru r10_bio->devs[1 ].devnum = i; r10_bio->devs[1 ].addr = to_addr; -if (need_recover) { +if (mrdev) { bio = r10_bio->devs[1 ].bio; bio->bi_next = biolist; biolist = bio;
@@ -3624,7 +3623,7 @@ static sector_t raid10_sync_request(strufor (k =0 ; k < conf->copies; k++)if (r10_bio->devs[k].devnum == i)break ; -if (!test_bit (In_sync, +if (mrdev && !test_bit (In_sync, &mrdev->flags) && !rdev_set_badblocks( mrdev,
@@ -3650,12 +3649,14 @@ static sector_t raid10_sync_request(struif (rb2)atomic_dec (&rb2->remaining); r10_bio = rb2; -rdev_dec_pending (mrdev, mddev); +if (mrdev) +rdev_dec_pending (mrdev, mddev);if (mreplace)rdev_dec_pending (mreplace, mddev);break ; } -rdev_dec_pending (mrdev, mddev); +if (mrdev) +rdev_dec_pending (mrdev, mddev);if (mreplace)rdev_dec_pending (mreplace, mddev);if (r10_bio->devs[0 ].bio->bi_opf &MD_FAILFAST ) {
Greg Kroah-Hartman
maintainerPATCH 17/22 io_uring: fix possible deadlock in io_register_iowq_max_workers()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hagar Hemdan <[email protected]>
commit 73254a297c2dd094abec7c9efee32455ae875bdf upstream.
The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lock before acquiring sqd->lock"), this can lead to a potential deadlock situation.
To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call.
This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.
--- io_uring/io_uring.c | 5 +++++ 1 file changed, 5 insertions(+)
io_uring/io_uring.c +5 -0
@@ -10822,8 +10822,10 @@ static int io_register_iowq_max_workers( }if (sqd) { +mutex_unlock (&ctx->uring_lock);mutex_unlock (&sqd->lock);io_put_sq_data (sqd); +mutex_lock (&ctx->uring_lock); }if (copy_to_user (arg, new_count,sizeof (new_count)))
@@ -10848,8 +10850,11 @@ static int io_register_iowq_max_workers(return 0 ; err:if (sqd) { +mutex_unlock (&ctx->uring_lock);mutex_unlock (&sqd->lock);io_put_sq_data (sqd); +mutex_lock (&ctx->uring_lock); + }return ret; }
Greg Kroah-Hartman
maintainerPATCH 18/22 mm: krealloc: Fix MTE false alarm in __do_krealloc
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qun-Wei Lin <[email protected]>
commit 704573851b51808b45dae2d62059d1d8189138a2 upstream.
This patch addresses an issue introduced by commit 1a83a716ec233 ("mm:
krealloc: consider spare memory for __GFP_ZERO") which causes MTE (Memory Tagging Extension) to falsely report a slab-out-of-bounds error.
The problem occurs when zeroing out spare memory in __do_krealloc. The original code only considered software-based KASAN and did not account for MTE. It does not reset the KASAN tag before calling memset, leading to a mismatch between the pointer tag and the memory tag, resulting in a false positive.
Example of the error:
==================================================================
swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188 swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1 swapper/0: Pointer tag: [f4], memory tag: [fe] swapper/0:
swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12. swapper/0: Hardware name: MT6991(ENG) (DT) swapper/0: Call trace: swapper/0: dump_backtrace+0xfc/0x17c swapper/0: show_stack+0x18/0x28 swapper/0: dump_stack_lvl+0x40/0xa0 swapper/0: print_report+0x1b8/0x71c swapper/0: kasan_report+0xec/0x14c swapper/0: __do_kernel_fault+0x60/0x29c swapper/0: do_bad_area+0x30/0xdc swapper/0: do_tag_check_fault+0x20/0x34 swapper/0: do_mem_abort+0x58/0x104 swapper/0: el1_abort+0x3c/0x5c swapper/0: el1h_64_sync_handler+0x80/0xcc swapper/0: el1h_64_sync+0x68/0x6c swapper/0: __memset+0x84/0x188 swapper/0: btf_populate_kfunc_set+0x280/0x3d8 swapper/0: __register_btf_kfunc_id_set+0x43c/0x468 swapper/0: register_btf_kfunc_id_set+0x48/0x60 swapper/0: register_nf_nat_bpf+0x1c/0x40 swapper/0: nf_nat_init+0xc0/0x128 swapper/0: do_one_initcall+0x184/0x464 swapper/0: do_initcall_level+0xdc/0x1b0 swapper/0: do_initcalls+0x70/0xc0 swapper/0: do_basic_setup+0x1c/0x28 swapper/0: kernel_init_freeable+0x144/0x1b8 swapper/0: kernel_init+0x20/0x1a8 swapper/0: ret_from_fork+0x10/0x20
==================================================================
--- mm/slab_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/slab_common.c +1 -1
@@ -1213,7 +1213,7 @@ static __always_inline void *__do_kreall/* Zero out spare memory. */ if (want_init_on_alloc (flags)) {kasan_disable_current (); -memset ((void *)p + new_size,0 , ks - new_size); +memset (kasan_reset_tag (p) + new_size,0 , ks - new_size);kasan_enable_current (); }
Greg Kroah-Hartman
maintainerPATCH 19/22 mm/memory: add non-anonymous page check in the copy_present_page()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yuanzheng Song <[email protected]>
The vma->anon_vma of the child process may be NULL because the entire vma does not contain anonymous pages. In this case, a BUG will occur when the copy_present_page() passes a copy of a non-anonymous page of that vma to the page_add_new_anon_rmap() to set up new anonymous rmap.
------------[ cut here ]------------ kernel BUG at mm/rmap.c:1052! Internal error: Oops - BUG: 0 [#1] SMP Modules linked in: CPU: 4 PID: 4652 Comm: test Not tainted 5.15.75 #1 Hardware name: linux,dummy-virt (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __page_set_anon_rmap+0xc0/0xe8 lr : __page_set_anon_rmap+0xc0/0xe8
sp : ffff80000e773860
x29: ffff80000e773860 x28: fffffc13cf006ec0 x27: ffff04f3ccd68000
x26: ffff04f3c5c33248 x25: 0000000010100073 x24: ffff04f3c53c0a80
x23: 0000000020000000 x22: 0000000000000001 x21: 0000000020000000
x20: fffffc13cf006ec0 x19: 0000000000000000 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffdddc5581377c x8 : 0000000000000000 x7 : 0000000000000011 x6 : ffff2717a8433000 x5 : ffff80000e773810 x4 : ffffdddc55400000 x3 : 0000000000000000 x2 : ffffdddc56b20000 x1 : ffff04f3c9a48040 x0 : 0000000000000000
Call trace: __page_set_anon_rmap+0xc0/0xe8 page_add_new_anon_rmap+0x13c/0x200 copy_pte_range+0x6b8/0x1018 copy_page_range+0x3a8/0x5e0 dup_mmap+0x3a0/0x6e8 dup_mm+0x78/0x140 copy_process+0x1528/0x1b08 kernel_clone+0xac/0x610 __do_sys_clone+0x78/0xb0 __arm64_sys_clone+0x30/0x40 invoke_syscall+0x68/0x170 el0_svc_common.constprop.0+0x80/0x250 do_el0_svc+0x48/0xb8 el0_svc+0x48/0x1a8 el0t_64_sync_handler+0xb0/0xb8 el0t_64_sync+0x1a0/0x1a4 Code: 97f899f4 f9400273 17ffffeb 97f899f1 (d4210000) ---[ end trace dc65e5edd0f362fa ]--- Kernel panic - not syncing: Oops - BUG: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: 0x5ddc4d400000 from 0xffff800008000000PHYS_OFFSET: 0xfffffb0c80000000
CPU features: 0x44000cf1,00000806
Memory Limit: none
---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]---
This problem has been fixed by the commit <fb3d824d1a46> ("mm/rmap: split page_dup_rmap() into page_dup_file_rmap() and page_try_dup_anon_rmap()"), but still exists in the linux-5.15.y branch.
This patch is not applicable to this version because of the large version differences. Therefore, fix it by adding non-anonymous page check in the copy_present_page().
--- mm/memory.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
mm/memory.c +11 -0
@@ -903,6 +903,17 @@ copy_present_page(struct vm_area_structif (likely (!page_needs_cow_for_dma (src_vma, page)))return 1 ; +/* +* The vma->anon_vma of the child process may be NULL +* because the entire vma does not contain anonymous pages. +* A BUG will occur when the copy_present_page() passes +* a copy of a non-anonymous page of that vma to the +* page_add_new_anon_rmap() to set up new anonymous rmap. +* Return 1 if the page is not an anonymous page. +*/ +if (!PageAnon (page)) +return 1 ; + new_page = *prealloc;if (!new_page)return -EAGAIN ;
Greg Kroah-Hartman
maintainerPATCH 20/22 udf: Allocate name buffer in directory iterator on heap
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 0aba4860b0d0216a1a300484ff536171894d49d8 upstream.
Currently we allocate name buffer in directory iterators (struct udf_fileident_iter) on stack. These structures are relatively large (some 360 bytes on 64-bit architectures). For udf_rename() which needs to keep three of these structures in parallel the stack usage becomes rather heavy - 1536 bytes in total. Allocate the name buffer in the iterator from heap to avoid excessive stack usage.
--- fs/udf/directory.c | 24 ++++++++++++++++-------- fs/udf/udfdecl.h | 2 +- 2 files changed, 17 insertions(+), 9 deletions(-)
fs/udf/directory.c +16 -8
@@ -19,6 +19,7 @@#include <linux/bio.h> #include <linux/crc-itu-t.h> #include <linux/iversion.h> +#include <linux/slab.h> static int udf_verify_fi (struct udf_fileident_iter *iter) {
@@ -248,9 +249,14 @@ int udf_fiiter_init(struct udf_fileident iter->elen =0 ; iter->epos.bh =NULL ; iter->name =NULL ; + iter->namebuf =kmalloc (UDF_NAME_LEN_CS0 ,GFP_KERNEL ); +if (!iter->namebuf) +return -ENOMEM ; -if (iinfo->i_alloc_type ==ICBTAG_FLAG_AD_IN_ICB ) -return udf_copy_fi (iter); +if (iinfo->i_alloc_type ==ICBTAG_FLAG_AD_IN_ICB ) { + err =udf_copy_fi (iter); + goto out; + } if (inode_bmap(dir, iter->pos >> dir->i_blkbits, &iter->epos, &iter->eloc, &iter->elen, &iter->loffset) !=
@@ -260,17 +266,17 @@ int udf_fiiter_init(struct udf_fileidentudf_err (dir->i_sb,"position %llu not allocated in directory (ino %lu)\n" , (unsigned long long )pos, dir->i_ino); -return -EFSCORRUPTED ; + err = -EFSCORRUPTED ; + goto out; } err =udf_fiiter_load_bhs (iter);if (err <0 ) -return err; + goto out; err =udf_copy_fi (iter); -if (err <0 ) { +out: +if (err <0 )udf_fiiter_release (iter); -return err; - } -return 0 ; +return err; }int udf_fiiter_advance (struct udf_fileident_iter *iter)
@@ -307,6 +313,8 @@ void udf_fiiter_release(struct udf_fileibrelse (iter->bh[0 ]);brelse (iter->bh[1 ]); iter->bh[0 ] = iter->bh[1 ] =NULL ; +kfree (iter->namebuf); + iter->namebuf =NULL ; } static void udf_copy_to_bufs(void *buf1, int len1, void *buf2, int len2,
fs/udf/udfdecl.h +1 -1
@@ -99,7 +99,7 @@ struct udf_fileident_iter {struct extent_position epos;/* Position after the above extent */ struct fileIdentDesc fi;/* Copied directory entry */ uint8_t *name;/* Pointer to entry name */ -uint8_t namebuf[UDF_NAME_LEN_CS0 ];/* Storage for entry name in case +uint8_t *namebuf;/* Storage for entry name in case * the name is split between two blocks */ };
Greg Kroah-Hartman
maintainerPATCH 21/22 udf: Avoid directory type conversion failure due to ENOMEM
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit df97f64dfa317a5485daf247b6c043a584ef95f9 upstream.
When converting directory from in-ICB to normal format, the last iteration through the directory fixing up directory enteries can fail due to ENOMEM. We do not expect this iteration to fail since the directory is already verified to be correct and it is difficult to undo the conversion at this point. So just use GFP_NOFAIL to make sure the small allocation cannot fail.
--- fs/udf/directory.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
fs/udf/directory.c +6 -3
@@ -249,9 +249,12 @@ int udf_fiiter_init(struct udf_fileident iter->elen =0 ; iter->epos.bh =NULL ; iter->name =NULL ; - iter->namebuf =kmalloc (UDF_NAME_LEN_CS0 ,GFP_KERNEL ); -if (!iter->namebuf) -return -ENOMEM ; +/* +* When directory is verified, we don't expect directory iteration to +* fail and it can be difficult to undo without corrupting filesystem. +* So just do not allow memory allocation failures here. +*/ + iter->namebuf =kmalloc (UDF_NAME_LEN_CS0 ,GFP_KERNEL | __GFP_NOFAIL);if (iinfo->i_alloc_type ==ICBTAG_FLAG_AD_IN_ICB ) { err =udf_copy_fi (iter);
Greg Kroah-Hartman
maintainerPATCH 22/22 9p: fix slab cache name creation for real
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <[email protected]>
commit a360f311f57a36e96d88fa8086b749159714dcd2 upstream.
This was attempted by using the dev_name in the slab cache name, but as Omar Sandoval pointed out, that can be an arbitrary string, eg something like "/dev/root". Which in turn trips verify_dirent_name(), which fails if a filename contains a slash.
So just make it use a sequence counter, and make it an atomic_t to avoid any possible races or locking issues.
--- net/9p/client.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/9p/client.c +3 -1
@@ -1003,6 +1003,7 @@ error:struct p9_client *p9_client_create (const char *dev_name,char *options) {int err; +static atomic_t seqno =ATOMIC_INIT (0 );struct p9_client *clnt;char *client_id;char *cache_name;
@@ -1058,7 +1059,8 @@ struct p9_client *p9_client_create(constif (err) goto close_trans; - cache_name =kasprintf (GFP_KERNEL ,"9p-fcall-cache-%s" , dev_name); + cache_name =kasprintf (GFP_KERNEL , +"9p-fcall-cache-%u" ,atomic_inc_return (&seqno));if (!cache_name) { err = -ENOMEM ; goto close_trans;
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.173 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
No problems seen on x86_64 and aarch64 with our testing.
Thanks,
Harshit
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.173 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 17 Nov 2024 06:37:07 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.173-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
101 tests: 101 pass, 0 failLinux version: 5.15.173-rc1-g056657e11366
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Hello,
Quoted 7 lines · On Fri, 15 Nov 2024 07:38:46 +0100 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 5.15.173 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 17 Nov 2024 06:37:07 +0000. Anything received after that time might be too late.
This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].
[1] https://github.com/damonitor/damon-tests/tree/next/corr
[2] 056657e11366 ("Linux 5.15.173-rc1")
Thanks,
SJ
[...]
---
ok 1 selftests: damon: debugfs_attrs.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh # SKIP
ok 12 selftests: damon-tests: build_m68k.sh # SKIP
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.173 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 17 Nov 2024 06:37:07 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.173-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested with BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.173 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.173 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 17 Nov 2024 06:37:07 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.173-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.173 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 17 Nov 2024 06:37:07 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.173-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.15.173-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 056657e11366d6bca8c64eb4d70bca49608ba8a8
* git describe: v5.15.171-100-g056657e11366
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.171-100-g056657e11366
## Test Regressions (compared to v5.15.171-77-g0ef052d947fe)
## Metric Regressions (compared to v5.15.171-77-g0ef052d947fe)
## Test Fixes (compared to v5.15.171-77-g0ef052d947fe)
## Metric Fixes (compared to v5.15.171-77-g0ef052d947fe)
## Test result summary
total: 60279, pass: 44530, fail: 1869, skip: 13807, xfail: 73
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 101 total, 101 passed, 0 failed
* arm64: 28 total, 28 passed, 0 failed
* i386: 22 total, 22 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* parisc: 3 total, 3 passed, 0 failed
* powerpc: 22 total, 22 passed, 0 failed
* riscv: 8 total, 8 passed, 0 failed
* s390: 9 total, 9 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 24 total, 24 passed, 0 failed
## Test suites summary
* boot
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Thanks,
Hardik
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.173 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 17 Nov 2024 06:37:07 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.173-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah