Skip to contentSkip to conversation

5.14.10-rc1 review

PATCH In review Greg Kroah-Hartman 7 participants 184 messages Oct 4, 2021 – Oct 5, 2021 Page 2 of 2

Subsystems (2)
lore
Share & tools
lore
author maintainer
#145 lore raw

PATCH 145/172 elf: dont use MAP_FIXED_NOREPLACE for elf interpreter mappings

In reply to Greg Kroah-Hartman

From: Chen Jingwen <[email protected]>

commit 9b2f72cc0aa4bb444541bb87581c35b7508b37d3 upstream.

In commit b212921b13bd ("elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings") we still leave MAP_FIXED_NOREPLACE in place for load_elf_interp.

Unfortunately, this will cause kernel to fail to start with:

1 (init): Uhuuh, elf segment at 00003ffff7ffd000 requested but the memory is mapped already Failed to execute /init (error -17)

The reason is that the elf interpreter (ld.so) has overlapping segments.

readelf -l ld-2.31.so
Program Headers:

    Type           Offset             VirtAddr           PhysAddr
                   FileSiz            MemSiz              Flags  Align
    LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                   0x000000000002c94c 0x000000000002c94c  R E    0x10000
    LOAD           0x000000000002dae0 0x000000000003dae0 0x000000000003dae0
                   0x00000000000021e8 0x0000000000002320  RW     0x10000
    LOAD           0x000000000002fe00 0x000000000003fe00 0x000000000003fe00
                   0x00000000000011ac 0x0000000000001328  RW     0x10000

The reason for this problem is the same as described in commit ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments").

Not only executable binaries, elf interpreters (e.g. ld.so) can have overlapping elf segments, so we better drop MAP_FIXED_NOREPLACE and go back to MAP_FIXED in load_elf_interp.

Fixes 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map")
Cc <[email protected]> # v4.19
Cc Andrew Morton <[email protected]>
Cc Michal Hocko <[email protected]>
---
 fs/binfmt_elf.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/binfmt_elf.c +1 -1
@@ -630,7 +630,7 @@ static unsigned long load_elf_interp(str
 
 			vaddr = eppnt->p_vaddr;
 			if (interp_elf_ex->e_type == ET_EXEC || load_addr_set)
-				elf_type |= MAP_FIXED_NOREPLACE;
+				elf_type |= MAP_FIXED;
 			else if (no_base && interp_elf_ex->e_type == ET_DYN)
 				load_addr = -vaddr;
 
author maintainer
#146 lore raw

PATCH 146/172 driver core: fw_devlink: Improve handling of cyclic dependencies

In reply to Greg Kroah-Hartman

From: Saravana Kannan <[email protected]>

commit 2de9d8e0d2fe3a1eb632def2245529067cb35db5 upstream.

When we have a dependency of the form:

Device-A -> Device-C
Device-B

Device-C -> Device-B

Where,
* Indentation denotes "child of" parent in previous line.
* X -> Y denotes X is consumer of Y based on firmware (Eg: DT).

We have cyclic dependency: device-A -> device-C -> device-B -> device-A

fw_devlink current treats device-C -> device-B dependency as an invalid dependency and doesn't enforce it but leaves the rest of the dependencies as is.

While the current behavior is necessary, it is not sufficient if the false dependency in this example is actually device-A -> device-C. When this is the case, device-C will correctly probe defer waiting for device-B to be added, but device-A will be incorrectly probe deferred by fw_devlink waiting on device-C to probe successfully. Due to this, none of the devices in the cycle will end up probing.

To fix this, we need to go relax all the dependencies in the cycle like we already do in the other instances where fw_devlink detects cycles. A real world example of this was reported[1] and analyzed[2].

[1] - https://lore.kernel.org/lkml/[email protected]/
[2] - https://lore.kernel.org/lkml/CAGETcx8peaew90SWiux=TyvuGgvTQOmO4BFALz7aj0Za5QdNFQ@mail.gmail.com/

---
 drivers/base/core.c |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)
drivers/base/core.c +12 -5
@@ -1790,14 +1790,21 @@ static int fw_devlink_create_devlink(str
 	 * be broken by applying logic. Check for these types of cycles and
 	 * break them so that devices in the cycle probe properly.
 	 *
-	 * If the supplier's parent is dependent on the consumer, then
-	 * the consumer-supplier dependency is a false dependency. So,
-	 * treat it as an invalid link.
+	 * If the supplier's parent is dependent on the consumer, then the
+	 * consumer and supplier have a cyclic dependency. Since fw_devlink
+	 * can't tell which of the inferred dependencies are incorrect, don't
+	 * enforce probe ordering between any of the devices in this cyclic
+	 * dependency. Do this by relaxing all the fw_devlink device links in
+	 * this cycle and by treating the fwnode link between the consumer and
+	 * the supplier as an invalid dependency.
 	 */
 	sup_dev = fwnode_get_next_parent_dev(sup_handle);
 	if (sup_dev && device_is_dependent(con, sup_dev)) {
-		dev_dbg(con, "Not linking to %pfwP - False link\n",
-			sup_handle);
+		dev_info(con, "Fixing up cyclic dependency with %pfwP (%s)\n",
+			 sup_handle, dev_name(sup_dev));
+		device_links_write_lock();
+		fw_devlink_relax_cycle(con, sup_dev);
+		device_links_write_unlock();
 		ret = -EINVAL;
 	} else {
 		/*
author maintainer
#147 lore raw

PATCH 147/172 debugfs: debugfs_create_file_size(): use IS_ERR to check for error

In reply to Greg Kroah-Hartman

From: Nirmoy Das <[email protected]>

commit af505cad9567f7a500d34bf183696d570d7f6810 upstream.

debugfs_create_file() returns encoded error so use IS_ERR for checking return value.

Fixes ff9fb72bc077 ("debugfs: return error values, not NULL")
Cc stable <[email protected]>
---
 fs/debugfs/inode.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/debugfs/inode.c +1 -1
@@ -528,7 +528,7 @@ void debugfs_create_file_size(const char
 {
 	struct dentry *de = debugfs_create_file(name, mode, parent, data, fops);
 
-	if (de)
+	if (!IS_ERR(de))
 		d_inode(de)->i_size = file_size;
 }
 EXPORT_SYMBOL_GPL(debugfs_create_file_size);
author maintainer
#148 lore raw

PATCH 148/172 ipack: ipoctal: fix stack information leak

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

commit a89936cce87d60766a75732a9e7e25c51164f47c upstream.

The tty driver name is used also after registering the driver and must specifically not be allocated on the stack to avoid leaking information to user space (or triggering an oops).

Drivers should not try to encode topology information in the tty device name but this one snuck in through staging without anyone noticing and another driver has since copied this malpractice.

Fixing the ABI is a separate issue, but this at least plugs the security hole.

Fixes ba4dc61fe8c5 ("Staging: ipack: add support for IP-OCTAL mezzanine board")
---
 drivers/ipack/devices/ipoctal.c |   19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)
drivers/ipack/devices/ipoctal.c +14 -5
@@ -264,7 +264,6 @@ static int ipoctal_inst_slot(struct ipoc
 	int res;
 	int i;
 	struct tty_driver *tty;
-	char name[20];
 	struct ipoctal_channel *channel;
 	struct ipack_region *region;
 	void __iomem *addr;
@@ -355,8 +354,11 @@ static int ipoctal_inst_slot(struct ipoc
 	/* Fill struct tty_driver with ipoctal data */
 	tty->owner = THIS_MODULE;
 	tty->driver_name = KBUILD_MODNAME;
-	sprintf(name, KBUILD_MODNAME ".%d.%d.", bus_nr, slot);
-	tty->name = name;
+	tty->name = kasprintf(GFP_KERNEL, KBUILD_MODNAME ".%d.%d.", bus_nr, slot);
+	if (!tty->name) {
+		res = -ENOMEM;
+		goto err_put_driver;
+	}
 	tty->major = 0;
 
 	tty->minor_start = 0;
@@ -372,8 +374,7 @@ static int ipoctal_inst_slot(struct ipoc
 	res = tty_register_driver(tty);
 	if (res) {
 		dev_err(&ipoctal->dev->dev, "Can't register tty driver.\n");
-		put_tty_driver(tty);
-		return res;
+		goto err_free_name;
 	}
 
 	/* Save struct tty_driver for use it when uninstalling the device */
@@ -410,6 +411,13 @@ static int ipoctal_inst_slot(struct ipoc
 				       ipoctal_irq_handler, ipoctal);
 
 	return 0;
+
+err_free_name:
+	kfree(tty->name);
+err_put_driver:
+	put_tty_driver(tty);
+
+	return res;
 }
 
 static inline int ipoctal_copy_write_buffer(struct ipoctal_channel *channel,
@@ -697,6 +705,7 @@ static void __ipoctal_remove(struct ipoc
 	}
 
 	tty_unregister_driver(ipoctal->tty_drv);
+	kfree(ipoctal->tty_drv->name);
 	put_tty_driver(ipoctal->tty_drv);
 	kfree(ipoctal);
 }
author maintainer
#149 lore raw

PATCH 149/172 ipack: ipoctal: fix tty registration race

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

commit 65c001df517a7bf9be8621b53d43c89f426ce8d6 upstream.

Make sure to set the tty class-device driver data before registering the tty to avoid having a racing open() dereference a NULL pointer.

Fixes 9c1d784afc6f ("Staging: ipack/devices/ipoctal: Get rid of ipoctal_list.")
---
 drivers/ipack/devices/ipoctal.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ipack/devices/ipoctal.c +2 -2
@@ -393,13 +393,13 @@ static int ipoctal_inst_slot(struct ipoc
 		spin_lock_init(&channel->lock);
 		channel->pointer_read = 0;
 		channel->pointer_write = 0;
-		tty_dev = tty_port_register_device(&channel->tty_port, tty, i, NULL);
+		tty_dev = tty_port_register_device_attr(&channel->tty_port, tty,
+							i, NULL, channel, NULL);
 		if (IS_ERR(tty_dev)) {
 			dev_err(&ipoctal->dev->dev, "Failed to register tty device.\n");
 			tty_port_destroy(&channel->tty_port);
 			continue;
 		}
-		dev_set_drvdata(tty_dev, channel);
 	}
 
 	/*
author maintainer
#150 lore raw

PATCH 150/172 ipack: ipoctal: fix tty-registration error handling

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

commit cd20d59291d1790dc74248476e928f57fc455189 upstream.

Registration of the ipoctal tty devices is unlikely to fail, but if it ever does, make sure not to deregister a never registered tty device (and dereference a NULL pointer) when the driver is later unbound.

Fixes 2afb41d9d30d ("Staging: ipack/devices/ipoctal: Check tty_register_device return value.")
---
 drivers/ipack/devices/ipoctal.c |    7 +++++++
 1 file changed, 7 insertions(+)
drivers/ipack/devices/ipoctal.c +7 -0
@@ -33,6 +33,7 @@ struct ipoctal_channel {
 	unsigned int			pointer_read;
 	unsigned int			pointer_write;
 	struct tty_port			tty_port;
+	bool				tty_registered;
 	union scc2698_channel __iomem	*regs;
 	union scc2698_block __iomem	*block_regs;
 	unsigned int			board_id;
@@ -397,9 +398,11 @@ static int ipoctal_inst_slot(struct ipoc
 							i, NULL, channel, NULL);
 		if (IS_ERR(tty_dev)) {
 			dev_err(&ipoctal->dev->dev, "Failed to register tty device.\n");
+			tty_port_free_xmit_buf(&channel->tty_port);
 			tty_port_destroy(&channel->tty_port);
 			continue;
 		}
+		channel->tty_registered = true;
 	}
 
 	/*
@@ -699,6 +702,10 @@ static void __ipoctal_remove(struct ipoc
 
 	for (i = 0; i < NR_CHANNELS; i++) {
 		struct ipoctal_channel *channel = &ipoctal->channel[i];
+
+		if (!channel->tty_registered)
+			continue;
+
 		tty_unregister_device(ipoctal->tty_drv, i);
 		tty_port_free_xmit_buf(&channel->tty_port);
 		tty_port_destroy(&channel->tty_port);
author maintainer
#151 lore raw

PATCH 151/172 ipack: ipoctal: fix missing allocation-failure check

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

commit 445c8132727728dc297492a7d9fc074af3e94ba3 upstream.

Add the missing error handling when allocating the transmit buffer to avoid dereferencing a NULL pointer in write() should the allocation ever fail.

Fixes ba4dc61fe8c5 ("Staging: ipack: add support for IP-OCTAL mezzanine board")
---
 drivers/ipack/devices/ipoctal.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/ipack/devices/ipoctal.c +3 -1
@@ -386,7 +386,9 @@ static int ipoctal_inst_slot(struct ipoc
 
 		channel = &ipoctal->channel[i];
 		tty_port_init(&channel->tty_port);
-		tty_port_alloc_xmit_buf(&channel->tty_port);
+		res = tty_port_alloc_xmit_buf(&channel->tty_port);
+		if (res)
+			continue;
 		channel->tty_port.ops = &ipoctal_tty_port_ops;
 
 		ipoctal_reset_stats(&channel->stats);
author maintainer
#152 lore raw

PATCH 152/172 ipack: ipoctal: fix module reference leak

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

commit bb8a4fcb2136508224c596a7e665bdba1d7c3c27 upstream.

A reference to the carrier module was taken on every open but was only released once when the final reference to the tty struct was dropped.

Fix this by taking the module reference and initialising the tty driver data when installing the tty.

---
 drivers/ipack/devices/ipoctal.c |   29 +++++++++++++++++++++--------
 1 file changed, 21 insertions(+), 8 deletions(-)
drivers/ipack/devices/ipoctal.c +21 -8
@@ -82,22 +82,34 @@ static int ipoctal_port_activate(struct
 	return 0;
 }
 
-static int ipoctal_open(struct tty_struct *tty, struct file *file)
+static int ipoctal_install(struct tty_driver *driver, struct tty_struct *tty)
 {
 	struct ipoctal_channel *channel = dev_get_drvdata(tty->dev);
 	struct ipoctal *ipoctal = chan_to_ipoctal(channel, tty->index);
-	int err;
-
-	tty->driver_data = channel;
+	int res;
 
 	if (!ipack_get_carrier(ipoctal->dev))
 		return -EBUSY;
 
-	err = tty_port_open(&channel->tty_port, tty, file);
-	if (err)
-		ipack_put_carrier(ipoctal->dev);
+	res = tty_standard_install(driver, tty);
+	if (res)
+		goto err_put_carrier;
+
+	tty->driver_data = channel;
+
+	return 0;
+
+err_put_carrier:
+	ipack_put_carrier(ipoctal->dev);
+
+	return res;
+}
+
+static int ipoctal_open(struct tty_struct *tty, struct file *file)
+{
+	struct ipoctal_channel *channel = tty->driver_data;
 
-	return err;
+	return tty_port_open(&channel->tty_port, tty, file);
 }
 
 static void ipoctal_reset_stats(struct ipoctal_stats *stats)
@@ -662,6 +674,7 @@ static void ipoctal_cleanup(struct tty_s
 
 static const struct tty_operations ipoctal_fops = {
 	.ioctl =		NULL,
+	.install =		ipoctal_install,
 	.open =			ipoctal_open,
 	.close =		ipoctal_close,
 	.write =		ipoctal_write_tty,
author maintainer
#153 lore raw

PATCH 153/172 ext4: fix loff_t overflow in ext4_max_bitmap_size()

In reply to Greg Kroah-Hartman

From: Ritesh Harjani <[email protected]>

commit 75ca6ad408f459f00b09a64f04c774559848c097 upstream.

We should use unsigned long long rather than loff_t to avoid overflow in ext4_max_bitmap_size() for comparison before returning. w/o this patch sbi->s_bitmap_maxbytes was becoming a negative value due to overflow of upper_limit (with has_huge_files as true)

Below is a quick test to trigger it on a 64KB pagesize system.

sudo mkfs.ext4 -b 65536 -O ^has_extents,^64bit /dev/loop2 sudo mount /dev/loop2 /mnt
sudo echo "hello" > /mnt/hello -> This will error out with
"echo: write error: File too large"

---
 fs/ext4/super.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
fs/ext4/super.c +5 -5
@@ -3185,17 +3185,17 @@ static loff_t ext4_max_size(int blkbits,
  */
 static loff_t ext4_max_bitmap_size(int bits, int has_huge_files)
 {
-	loff_t res = EXT4_NDIR_BLOCKS;
+	unsigned long long upper_limit, res = EXT4_NDIR_BLOCKS;
 	int meta_blocks;
-	loff_t upper_limit;
-	/* This is calculated to be the largest file size for a dense, block
+
+	/*
+	 * This is calculated to be the largest file size for a dense, block
 	 * mapped file such that the file's total number of 512-byte sectors,
 	 * including data and all indirect blocks, does not exceed (2^48 - 1).
 	 *
 	 * __u32 i_blocks_lo and _u16 i_blocks_high represent the total
 	 * number of 512-byte sectors of the file.
 	 */
-
 	if (!has_huge_files) {
 		/*
 		 * !has_huge_files or implies that the inode i_block field
@@ -3238,7 +3238,7 @@ static loff_t ext4_max_bitmap_size(int b
 	if (res > MAX_LFS_FILESIZE)
 		res = MAX_LFS_FILESIZE;
 
-	return res;
+	return (loff_t)res;
 }
 
 static ext4_fsblk_t descriptor_loc(struct super_block *sb,
author maintainer
#154 lore raw

PATCH 154/172 ext4: limit the number of blocks in one ADD_RANGE TLV

In reply to Greg Kroah-Hartman

From: Hou Tao <[email protected]>

commit a2c2f0826e2b75560b31daf1cd9a755ab93cf4c6 upstream.

Now EXT4_FC_TAG_ADD_RANGE uses ext4_extent to track the newly-added blocks, but the limit on the max value of ee_len field is ignored, and it can lead to BUG_ON as shown below when running command "fallocate -l 128M file" on a fast_commit-enabled fs:

kernel BUG at fs/ext4/ext4_extents.h:199! invalid opcode: 0000 [#1] SMP PTI

  CPU: 3 PID: 624 Comm: fallocate Not tainted 5.14.0-rc6+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
  RIP: 0010:ext4_fc_write_inode_data+0x1f3/0x200
  Call Trace:
   ? ext4_fc_write_inode+0xf2/0x150
   ext4_fc_commit+0x93b/0xa00
   ? ext4_fallocate+0x1ad/0x10d0
   ext4_sync_file+0x157/0x340
   ? ext4_sync_file+0x157/0x340
   vfs_fsync_range+0x49/0x80
   do_fsync+0x3d/0x70
   __x64_sys_fsync+0x14/0x20
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae

Simply fixing it by limiting the number of blocks in one EXT4_FC_TAG_ADD_RANGE TLV.

---
 fs/ext4/fast_commit.c |    6 ++++++
 1 file changed, 6 insertions(+)
fs/ext4/fast_commit.c +6 -0
@@ -893,6 +893,12 @@ static int ext4_fc_write_inode_data(stru
 					    sizeof(lrange), (u8 *)&lrange, crc))
 				return -ENOSPC;
 		} else {
+			unsigned int max = (map.m_flags & EXT4_MAP_UNWRITTEN) ?
+				EXT_UNWRITTEN_MAX_LEN : EXT_INIT_MAX_LEN;
+
+			/* Limit the number of blocks in one extent */
+			map.m_len = min(max, map.m_len);
+
 			fc_ext.fc_ino = cpu_to_le32(inode->i_ino);
 			ex = (struct ext4_extent *)&fc_ext.fc_ex;
 			ex->ee_block = cpu_to_le32(map.m_lblk);
author maintainer
#155 lore raw

PATCH 155/172 ext4: fix reserved space counter leakage

In reply to Greg Kroah-Hartman

From: Jeffle Xu <[email protected]>

commit 6fed83957f21eff11c8496e9f24253b03d2bc1dc upstream.

When ext4_insert_delayed block receives and recovers from an error from ext4_es_insert_delayed_block(), e.g., ENOMEM, it does not release the space it has reserved for that block insertion as it should. One effect of this bug is that s_dirtyclusters_counter is not decremented and remains incorrectly elevated until the file system has been unmounted. This can result in premature ENOSPC returns and apparent loss of free space.

Another effect of this bug is that /sys/fs/ext4/<dev>/delayed_allocation_blocks can remain non-zero even after syncfs has been executed on the filesystem.

Besides, add check for s_dirtyclusters_counter when inode is going to be evicted and freed. s_dirtyclusters_counter can still keep non-zero until inode is written back in .evict_inode(), and thus the check is delayed to .destroy_inode().

---
 fs/ext4/inode.c |    5 +++++
 fs/ext4/super.c |    6 ++++++
 2 files changed, 11 insertions(+)
fs/ext4/inode.c +5 -0
@@ -1640,6 +1640,7 @@ static int ext4_insert_delayed_block(str
 	struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
 	int ret;
 	bool allocated = false;
+	bool reserved = false;
 
 	/*
 	 * If the cluster containing lblk is shared with a delayed,
@@ -1656,6 +1657,7 @@ static int ext4_insert_delayed_block(str
 		ret = ext4_da_reserve_space(inode);
 		if (ret != 0)   /* ENOSPC */
 			goto errout;
+		reserved = true;
 	} else {   /* bigalloc */
 		if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) {
 			if (!ext4_es_scan_clu(inode,
@@ -1668,6 +1670,7 @@ static int ext4_insert_delayed_block(str
 					ret = ext4_da_reserve_space(inode);
 					if (ret != 0)   /* ENOSPC */
 						goto errout;
+					reserved = true;
 				} else {
 					allocated = true;
 				}
@@ -1678,6 +1681,8 @@ static int ext4_insert_delayed_block(str
 	}
 
 	ret = ext4_es_insert_delayed_block(inode, lblk, allocated);
+	if (ret && reserved)
+		ext4_da_release_space(inode, 1);
 
 errout:
 	return ret;
fs/ext4/super.c +6 -0
@@ -1351,6 +1351,12 @@ static void ext4_destroy_inode(struct in
 				true);
 		dump_stack();
 	}
+
+	if (EXT4_I(inode)->i_reserved_data_blocks)
+		ext4_msg(inode->i_sb, KERN_ERR,
+			 "Inode %lu (%p): i_reserved_data_blocks (%u) not cleared!",
+			 inode->i_ino, EXT4_I(inode),
+			 EXT4_I(inode)->i_reserved_data_blocks);
 }
 
 static void init_once(void *foo)
author maintainer
#156 lore raw

PATCH 156/172 ext4: add error checking to ext4_ext_replay_set_iblocks()

In reply to Greg Kroah-Hartman

From: Theodore Ts'o <[email protected]>

commit 1fd95c05d8f742abfe906620780aee4dbe1a2db0 upstream.

If the call to ext4_map_blocks() fails due to an corrupted file system, ext4_ext_replay_set_iblocks() can get stuck in an infinite loop. This could be reproduced by running generic/526 with a file system that has inline_data and fast_commit enabled. The system will repeatedly log to the console:

EXT4-fs warning (device dm-3): ext4_block_to_path:105: block 1074800922 > max in inode 131076

and the stack that it gets stuck in is:

   ext4_block_to_path+0xe3/0x130
   ext4_ind_map_blocks+0x93/0x690
   ext4_map_blocks+0x100/0x660
   skip_hole+0x47/0x70
   ext4_ext_replay_set_iblocks+0x223/0x440
   ext4_fc_replay_inode+0x29e/0x3b0
   ext4_fc_replay+0x278/0x550
   do_one_pass+0x646/0xc10
   jbd2_journal_recover+0x14a/0x270
   jbd2_journal_load+0xc4/0x150
   ext4_load_journal+0x1f3/0x490
   ext4_fill_super+0x22d4/0x2c00

With this patch, generic/526 still fails, but system is no longer locking up in a tight loop. It's likely the root casue is that fast_commit replay is corrupting file systems with inline_data, and we probably need to add better error handling in the fast commit replay code path beyond what is done here, which essentially just breaks the infinite loop without reporting the to the higher levels of the code.

Fixes 8016E29F4362 ("ext4: fast commit recovery path")
Cc Harshad Shirwadkar <[email protected]>
---
 fs/ext4/extents.c |   19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)
fs/ext4/extents.c +14 -5
@@ -5908,7 +5908,7 @@ void ext4_ext_replay_shrink_inode(struct
 }
 
 /* Check if *cur is a hole and if it is, skip it */
-static void skip_hole(struct inode *inode, ext4_lblk_t *cur)
+static int skip_hole(struct inode *inode, ext4_lblk_t *cur)
 {
 	int ret;
 	struct ext4_map_blocks map;
@@ -5917,9 +5917,12 @@ static void skip_hole(struct inode *inod
 	map.m_len = ((inode->i_size) >> inode->i_sb->s_blocksize_bits) - *cur;
 
 	ret = ext4_map_blocks(NULL, inode, &map, 0);
+	if (ret < 0)
+		return ret;
 	if (ret != 0)
-		return;
+		return 0;
 	*cur = *cur + map.m_len;
+	return 0;
 }
 
 /* Count number of blocks used by this inode and update i_blocks */
@@ -5968,7 +5971,9 @@ int ext4_ext_replay_set_iblocks(struct i
 	 * iblocks by total number of differences found.
 	 */
 	cur = 0;
-	skip_hole(inode, &cur);
+	ret = skip_hole(inode, &cur);
+	if (ret < 0)
+		goto out;
 	path = ext4_find_extent(inode, cur, NULL, 0);
 	if (IS_ERR(path))
 		goto out;
@@ -5987,8 +5992,12 @@ int ext4_ext_replay_set_iblocks(struct i
 		}
 		cur = max(cur + 1, le32_to_cpu(ex->ee_block) +
 					ext4_ext_get_actual_len(ex));
-		skip_hole(inode, &cur);
-
+		ret = skip_hole(inode, &cur);
+		if (ret < 0) {
+			ext4_ext_drop_refs(path);
+			kfree(path);
+			break;
+		}
 		path2 = ext4_find_extent(inode, cur, NULL, 0);
 		if (IS_ERR(path2)) {
 			ext4_ext_drop_refs(path);
author maintainer
#157 lore raw

PATCH 157/172 ext4: fix potential infinite loop in ext4_dx_readdir()

In reply to Greg Kroah-Hartman

From: yangerkun <[email protected]>

commit 42cb447410d024e9d54139ae9c21ea132a8c384c upstream.

When ext4_htree_fill_tree() fails, ext4_dx_readdir() can run into an infinite loop since if info->last_pos != ctx->pos this will reset the directory scan and reread the failing entry. For example:

1. a dx_dir which has 3 block, block 0 as dx_root block, block 1/2 as leaf block which own the ext4_dir_entry_2
2. block 1 read ok and call_filldir which will fill the dirent and update the ctx->pos
3. block 2 read fail, but we has already fill some dirent, so we will return back to userspace will a positive return val(see ksys_getdents64)
4. the second ext4_dx_readdir will reset the world since info->last_pos != ctx->pos, and will also init the curr_hash which pos to block 1
5. So we will read block1 too, and once block2 still read fail, we can only fill one dirent because the hash of the entry in block1(besides the last one) won't greater than curr_hash
6. this time, we forget update last_pos too since the read for block2 will fail, and since we has got the one entry, ksys_getdents64 can return success
7. Latter we will trapped in a loop with step 4~6

---
 fs/ext4/dir.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
fs/ext4/dir.c +3 -3
@@ -551,7 +551,7 @@ static int ext4_dx_readdir(struct file *
 	struct dir_private_info *info = file->private_data;
 	struct inode *inode = file_inode(file);
 	struct fname *fname;
-	int	ret;
+	int ret = 0;
 
 	if (!info) {
 		info = ext4_htree_create_dir_info(file, ctx->pos);
@@ -599,7 +599,7 @@ static int ext4_dx_readdir(struct file *
 						   info->curr_minor_hash,
 						   &info->next_hash);
 			if (ret < 0)
-				return ret;
+				goto finished;
 			if (ret == 0) {
 				ctx->pos = ext4_get_htree_eof(file);
 				break;
@@ -630,7 +630,7 @@ static int ext4_dx_readdir(struct file *
 	}
 finished:
 	info->last_pos = ctx->pos;
-	return 0;
+	return ret < 0 ? ret : 0;
 }
 
 static int ext4_release_dir(struct inode *inode, struct file *filp)
author maintainer
#158 lore raw

PATCH 158/172 ext4: flush s_error_work before journal destroy in ext4_fill_super

In reply to Greg Kroah-Hartman

From: yangerkun <[email protected]>

commit bb9464e08309f6befe80866f5be51778ca355ee9 upstream.

The error path in ext4_fill_super forget to flush s_error_work before journal destroy, and it may trigger the follow bug since flush_stashed_error_work can run concurrently with journal destroy without any protection for sbi->s_journal.

[32031.740193] EXT4-fs (loop66): get root inode failed
[32031.740484] EXT4-fs (loop66): mount failed
[32031.759805] ------------[ cut here ]------------
[32031.759807] kernel BUG at fs/jbd2/transaction.c:373!
[32031.760075] invalid opcode: 0000 [#1] SMP PTI
[32031.760336] CPU: 5 PID: 1029268 Comm: kworker/5:1 Kdump: loaded
4.18.0
[32031.765112] Call Trace:
[32031.765375]  ? __switch_to_asm+0x35/0x70
[32031.765635]  ? __switch_to_asm+0x41/0x70
[32031.765893]  ? __switch_to_asm+0x35/0x70
[32031.766148]  ? __switch_to_asm+0x41/0x70
[32031.766405]  ? _cond_resched+0x15/0x40
[32031.766665]  jbd2__journal_start+0xf1/0x1f0 [jbd2]
[32031.766934]  jbd2_journal_start+0x19/0x20 [jbd2]
[32031.767218]  flush_stashed_error_work+0x30/0x90 [ext4]
[32031.767487]  process_one_work+0x195/0x390
[32031.767747]  worker_thread+0x30/0x390
[32031.768007]  ? process_one_work+0x390/0x390
[32031.768265]  kthread+0x10d/0x130
[32031.768521]  ? kthread_flush_work_fn+0x10/0x10
[32031.768778]  ret_from_fork+0x35/0x40

static int start_this_handle(...)

    BUG_ON(journal->j_flags & JBD2_UNMOUNT); <---- Trigger this

Besides, after we enable fast commit, ext4_fc_replay can add work to s_error_work but return success, so the latter journal destroy in ext4_load_journal can trigger this problem too.

Fix this problem with two steps:
1. Call ext4_commit_super directly in ext4_handle_error for the case that called from ext4_fc_replay
2. Since it's hard to pair the init and flush for s_error_work, we'd better add a extras flush_work before journal destroy in ext4_fill_super

Besides, this patch will call ext4_commit_super in ext4_handle_error for any nojournal case too. But it seems safe since the reason we call schedule_work was that we should save error info to sb through journal if available. Conversely, for the nojournal case, it seems useless delay commit superblock to s_error_work.

Fixes c92dc856848f ("ext4: defer saving error info from atomic context")
Fixes 2d01ddc86606 ("ext4: save error info to sb through journal if available")
---
 fs/ext4/super.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
fs/ext4/super.c +4 -1
@@ -661,7 +661,7 @@ static void ext4_handle_error(struct sup
 		 * constraints, it may not be safe to do it right here so we
 		 * defer superblock flushing to a workqueue.
 		 */
-		if (continue_fs)
+		if (continue_fs && journal)
 			schedule_work(&EXT4_SB(sb)->s_error_work);
 		else
 			ext4_commit_super(sb);
@@ -5189,12 +5189,15 @@ failed_mount_wq:
 	sbi->s_ea_block_cache = NULL;
 
 	if (sbi->s_journal) {
+		/* flush s_error_work before journal destroy. */
+		flush_work(&sbi->s_error_work);
 		jbd2_journal_destroy(sbi->s_journal);
 		sbi->s_journal = NULL;
 	}
 failed_mount3a:
 	ext4_es_unregister_shrinker(sbi);
 failed_mount3:
+	/* flush s_error_work before sbi destroy */
 	flush_work(&sbi->s_error_work);
 	del_timer_sync(&sbi->s_err_report);
 	ext4_stop_mmpd(sbi);
author maintainer
#159 lore raw

PATCH 159/172 HID: u2fzero: ignore incomplete packets without data

In reply to Greg Kroah-Hartman

From: Andrej Shadura <[email protected]>

commit 22d65765f211cc83186fd8b87521159f354c0da9 upstream.

Since the actual_length calculation is performed unsigned, packets shorter than 7 bytes (e.g. packets without data or otherwise truncated) or non-received packets ("zero" bytes) can cause buffer overflow.

Fixes 42337b9d4d958("HID: add driver for U2F Zero built-in LED and RNG")
---
 drivers/hid/hid-u2fzero.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/hid/hid-u2fzero.c +3 -1
@@ -198,7 +198,9 @@ static int u2fzero_rng_read(struct hwrng
 	}
 
 	ret = u2fzero_recv(dev, &req, &resp);
-	if (ret < 0)
+
+	/* ignore errors or packets without data */
+	if (ret < offsetof(struct u2f_hid_msg, init.data))
 		return 0;
 
 	/* only take the minimum amount of data it is safe to take */
author maintainer
#160 lore raw

PATCH 160/172 net: udp: annotate data race around udp_sk(sk)->corkflag

In reply to Greg Kroah-Hartman

From: Eric Dumazet <[email protected]>

commit a9f5970767d11eadc805d5283f202612c7ba1f59 upstream.

up->corkflag field can be read or written without any lock. Annotate accesses to avoid possible syzbot/KCSAN reports.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")
---
 net/ipv4/udp.c |   10 +++++-----
 net/ipv6/udp.c |    2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)
net/ipv4/udp.c +5 -5
@@ -1053,7 +1053,7 @@ int udp_sendmsg(struct sock *sk, struct
 	__be16 dport;
 	u8  tos;
 	int err, is_udplite = IS_UDPLITE(sk);
-	int corkreq = up->corkflag || msg->msg_flags&MSG_MORE;
+	int corkreq = READ_ONCE(up->corkflag) || msg->msg_flags&MSG_MORE;
 	int (*getfrag)(void *, char *, int, int, int, struct sk_buff *);
 	struct sk_buff *skb;
 	struct ip_options_data opt_copy;
@@ -1361,7 +1361,7 @@ int udp_sendpage(struct sock *sk, struct
 	}
 
 	up->len += size;
-	if (!(up->corkflag || (flags&MSG_MORE)))
+	if (!(READ_ONCE(up->corkflag) || (flags&MSG_MORE)))
 		ret = udp_push_pending_frames(sk);
 	if (!ret)
 		ret = size;
@@ -2662,9 +2662,9 @@ int udp_lib_setsockopt(struct sock *sk,
 	switch (optname) {
 	case UDP_CORK:
 		if (val != 0) {
-			up->corkflag = 1;
+			WRITE_ONCE(up->corkflag, 1);
 		} else {
-			up->corkflag = 0;
+			WRITE_ONCE(up->corkflag, 0);
 			lock_sock(sk);
 			push_pending_frames(sk);
 			release_sock(sk);
@@ -2787,7 +2787,7 @@ int udp_lib_getsockopt(struct sock *sk,
 
 	switch (optname) {
 	case UDP_CORK:
-		val = up->corkflag;
+		val = READ_ONCE(up->corkflag);
 		break;
 
 	case UDP_ENCAP:
net/ipv6/udp.c +1 -1
@@ -1303,7 +1303,7 @@ int udpv6_sendmsg(struct sock *sk, struc
 	int addr_len = msg->msg_namelen;
 	bool connected = false;
 	int ulen = len;
-	int corkreq = up->corkflag || msg->msg_flags&MSG_MORE;
+	int corkreq = READ_ONCE(up->corkflag) || msg->msg_flags&MSG_MORE;
 	int err;
 	int is_udplite = IS_UDPLITE(sk);
 	int (*getfrag)(void *, char *, int, int, int, struct sk_buff *);
author maintainer
#161 lore raw

PATCH 161/172 NIOS2: setup.c: drop unused variable dram_start

In reply to Greg Kroah-Hartman

From: Randy Dunlap <[email protected]>

commit 9523b33cc31cf8ce703f8facee9fd16cba36d5ad upstream.

This is a nuisance when CONFIG_WERROR is set, so drop the variable declaration since the code that used it was removed.

../arch/nios2/kernel/setup.c: In function 'setup_arch':
../arch/nios2/kernel/setup.c:152:13: warning: unused variable 'dram_start' [-Wunused-variable]
152 | int dram_start;

Fixes 7f7bc20bc41a ("nios2: Don't use _end for calculating min_low_pfn")
Cc Andreas Oetken <[email protected]>
---
 arch/nios2/kernel/setup.c |    2 --
 1 file changed, 2 deletions(-)
arch/nios2/kernel/setup.c +0 -2
@@ -149,8 +149,6 @@ static void __init find_limits(unsigned
 
 void __init setup_arch(char **cmdline_p)
 {
-	int dram_start;
-
 	console_verbose();
 
 	memory_start = memblock_start_of_DRAM();
author maintainer
#162 lore raw

PATCH 162/172 usb: hso: remove the bailout parameter

In reply to Greg Kroah-Hartman

From: Dongliang Mu <[email protected]>

commit dcb713d53e2eadf42b878c12a471e74dc6ed3145 upstream.

There are two invocation sites of hso_free_net_device. After refactoring hso_create_net_device, this parameter is useless. Remove the bailout in the hso_free_net_device and change the invocation sites of this function.

[Backport this cleanup patch to 5.10 and 5.14 in order to keep the codebase consistent with the 4.14/4.19/5.4 patchseries]

---
 drivers/net/usb/hso.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/usb/hso.c +3 -3
@@ -2353,7 +2353,7 @@ static int remove_net_device(struct hso_
 }
 
 /* Frees our network device */
-static void hso_free_net_device(struct hso_device *hso_dev, bool bailout)
+static void hso_free_net_device(struct hso_device *hso_dev)
 {
 	int i;
 	struct hso_net *hso_net = dev2net(hso_dev);
@@ -2376,7 +2376,7 @@ static void hso_free_net_device(struct h
 	kfree(hso_net->mux_bulk_tx_buf);
 	hso_net->mux_bulk_tx_buf = NULL;
 
-	if (hso_net->net && !bailout)
+	if (hso_net->net)
 		free_netdev(hso_net->net);
 
 	kfree(hso_dev);
@@ -3136,7 +3136,7 @@ static void hso_free_interface(struct us
 				rfkill_unregister(rfk);
 				rfkill_destroy(rfk);
 			}
-			hso_free_net_device(network_table[i], false);
+			hso_free_net_device(network_table[i]);
 		}
 	}
 }
author maintainer
#163 lore raw

PATCH 163/172 HID: betop: fix slab-out-of-bounds Write in betop_probe

In reply to Greg Kroah-Hartman

From: F.A.Sulaiman <[email protected]>

commit 1e4ce418b1cb1a810256b5fb3fd33d22d1325993 upstream.

Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver. The problem is the driver assumes the device must have an input report but some malicious devices violate this assumption.

So this patch checks hid_device's input is non empty before it's been used.

---
 drivers/hid/hid-betopff.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)
drivers/hid/hid-betopff.c +10 -3
@@ -56,15 +56,22 @@ static int betopff_init(struct hid_devic
 {
 	struct betopff_device *betopff;
 	struct hid_report *report;
-	struct hid_input *hidinput =
-			list_first_entry(&hid->inputs, struct hid_input, list);
+	struct hid_input *hidinput;
 	struct list_head *report_list =
 			&hid->report_enum[HID_OUTPUT_REPORT].report_list;
-	struct input_dev *dev = hidinput->input;
+	struct input_dev *dev;
 	int field_count = 0;
 	int error;
 	int i, j;
 
+	if (list_empty(&hid->inputs)) {
+		hid_err(hid, "no inputs found\n");
+		return -ENODEV;
+	}
+
+	hidinput = list_first_entry(&hid->inputs, struct hid_input, list);
+	dev = hidinput->input;
+
 	if (list_empty(report_list)) {
 		hid_err(hid, "no output reports found\n");
 		return -ENODEV;
author maintainer
#164 lore raw

PATCH 164/172 netfilter: ipset: Fix oversized kvmalloc() calls

In reply to Greg Kroah-Hartman

From: Jozsef Kadlecsik <[email protected]>

commit 7bbc3d385bd813077acaf0e6fdb2a86a901f5382 upstream.

The commit

commit 7661809d493b426e979f39ab512e3adf41fbcc69

Author: Linus Torvalds <[email protected]>
Date:   Wed Jul 14 09:45:49 2021 -0700

mm: don't allow oversized kvmalloc() calls

limits the max allocatable memory via kvmalloc() to MAX_INT. Apply the same limit in ipset.

---
 net/netfilter/ipset/ip_set_hash_gen.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/netfilter/ipset/ip_set_hash_gen.h +2 -2
@@ -130,11 +130,11 @@ htable_size(u8 hbits)
 {
 	size_t hsize;
 
-	/* We must fit both into u32 in jhash and size_t */
+	/* We must fit both into u32 in jhash and INT_MAX in kvmalloc_node() */
 	if (hbits > 31)
 		return 0;
 	hsize = jhash_size(hbits);
-	if ((((size_t)-1) - sizeof(struct htable)) / sizeof(struct hbucket *)
+	if ((INT_MAX - sizeof(struct htable)) / sizeof(struct hbucket *)
 	    < hsize)
 		return 0;
 
author maintainer
#165 lore raw

PATCH 165/172 mm: dont allow oversized kvmalloc() calls

In reply to Greg Kroah-Hartman

From: Linus Torvalds <[email protected]>

commit 7661809d493b426e979f39ab512e3adf41fbcc69 upstream.

'kvmalloc()' is a convenience function for people who want to do a kmalloc() but fall back on vmalloc() if there aren't enough physically contiguous pages, or if the allocation is larger than what kmalloc() supports.

However, let's make sure it doesn't get _too_ easy to do crazy things with it. In particular, don't allow big allocations that could be due to integer overflow or underflow. So make sure the allocation size fits in an 'int', to protect against trivial integer conversion issues.

---
 mm/util.c |    4 ++++
 1 file changed, 4 insertions(+)
mm/util.c +4 -0
@@ -593,6 +593,10 @@ void *kvmalloc_node(size_t size, gfp_t f
 	if (ret || size <= PAGE_SIZE)
 		return ret;
 
+	/* Don't even allow crazy sizes */
+	if (WARN_ON_ONCE(size > INT_MAX))
+		return NULL;
+
 	return __vmalloc_node(size, 1, flags, node,
 			__builtin_return_address(0));
 }
author maintainer
#166 lore raw

PATCH 166/172 HID: usbhid: free raw_report buffers in usbhid_stop

In reply to Greg Kroah-Hartman

From: Anirudh Rayabharam <[email protected]>

commit f7744fa16b96da57187dc8e5634152d3b63d72de upstream.

Free the unsent raw_report buffers when the device is removed.

Fixes a memory leak reported by syzbot at:
https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47

---
 drivers/hid/usbhid/hid-core.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/hid/usbhid/hid-core.c +12 -1
@@ -505,7 +505,7 @@ static void hid_ctrl(struct urb *urb)
 
 	if (unplug) {
 		usbhid->ctrltail = usbhid->ctrlhead;
-	} else {
+	} else if (usbhid->ctrlhead != usbhid->ctrltail) {
 		usbhid->ctrltail = (usbhid->ctrltail + 1) & (HID_CONTROL_FIFO_SIZE - 1);
 
 		if (usbhid->ctrlhead != usbhid->ctrltail &&
@@ -1223,9 +1223,20 @@ static void usbhid_stop(struct hid_devic
 	mutex_lock(&usbhid->mutex);
 
 	clear_bit(HID_STARTED, &usbhid->iofl);
+
 	spin_lock_irq(&usbhid->lock);	/* Sync with error and led handlers */
 	set_bit(HID_DISCONNECTED, &usbhid->iofl);
+	while (usbhid->ctrltail != usbhid->ctrlhead) {
+		if (usbhid->ctrl[usbhid->ctrltail].dir == USB_DIR_OUT) {
+			kfree(usbhid->ctrl[usbhid->ctrltail].raw_report);
+			usbhid->ctrl[usbhid->ctrltail].raw_report = NULL;
+		}
+
+		usbhid->ctrltail = (usbhid->ctrltail + 1) &
+			(HID_CONTROL_FIFO_SIZE - 1);
+	}
 	spin_unlock_irq(&usbhid->lock);
+
 	usb_kill_urb(usbhid->urbin);
 	usb_kill_urb(usbhid->urbout);
 	usb_kill_urb(usbhid->urbctrl);
author maintainer
#167 lore raw

PATCH 167/172 crypto: aesni - xts_crypt() return if walk.nbytes is 0

In reply to Greg Kroah-Hartman

From: Shreyansh Chouhan <[email protected]>

commit 72ff2bf04db2a48840df93a461b7115900f46c05 upstream.

xts_crypt() code doesn't call kernel_fpu_end() after calling kernel_fpu_begin() if walk.nbytes is 0. The correct behavior should be not calling kernel_fpu_begin() if walk.nbytes is 0.

---
 arch/x86/crypto/aesni-intel_glue.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/crypto/aesni-intel_glue.c +1 -1
@@ -849,7 +849,7 @@ static int xts_crypt(struct skcipher_req
 		return -EINVAL;
 
 	err = skcipher_walk_virt(&walk, req, false);
-	if (err)
+	if (!walk.nbytes)
 		return err;
 
 	if (unlikely(tail > 0 && walk.nbytes < walk.total)) {
author maintainer
#168 lore raw

PATCH 168/172 net: mdiobus: Fix memory leak in __mdiobus_register

In reply to Greg Kroah-Hartman

From: Yanfei Xu <[email protected]>

commit ab609f25d19858513919369ff3d9a63c02cd9e2e upstream.

Once device_register() failed, we should call put_device() to decrement reference count for cleanup. Or it will cause memory leak.

BUG: memory leak
unreferenced object 0xffff888114032e00 (size 256):
  comm "kworker/1:3", pid 2960, jiffies 4294943572 (age 15.920s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 08 2e 03 14 81 88 ff ff  ................
    08 2e 03 14 81 88 ff ff 90 76 65 82 ff ff ff ff  .........ve.....
  backtrace:
    [<ffffffff8265cfab>] kmalloc include/linux/slab.h:591 [inline]
    [<ffffffff8265cfab>] kzalloc include/linux/slab.h:721 [inline]
    [<ffffffff8265cfab>] device_private_init drivers/base/core.c:3203 [inline]
    [<ffffffff8265cfab>] device_add+0x89b/0xdf0 drivers/base/core.c:3253
    [<ffffffff828dd643>] __mdiobus_register+0xc3/0x450 drivers/net/phy/mdio_bus.c:537
    [<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
    [<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
    [<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
    [<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
    [<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
    [<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
    [<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
    [<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
    [<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
    [<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
    [<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
    [<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
    [<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969
    [<ffffffff82660916>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
    [<ffffffff8265cd0b>] device_add+0x5fb/0xdf0 drivers/base/core.c:3359
    [<ffffffff82c343b9>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2170
    [<ffffffff82c4473c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238

BUG: memory leak
unreferenced object 0xffff888116f06900 (size 32):
  comm "kworker/0:2", pid 2670, jiffies 4294944448 (age 7.160s)
  hex dump (first 32 bytes):
    75 73 62 2d 30 30 31 3a 30 30 33 00 00 00 00 00  usb-001:003.....
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff81484516>] kstrdup+0x36/0x70 mm/util.c:60
    [<ffffffff814845a3>] kstrdup_const+0x53/0x80 mm/util.c:83
    [<ffffffff82296ba2>] kvasprintf_const+0xc2/0x110 lib/kasprintf.c:48
    [<ffffffff82358d4b>] kobject_set_name_vargs+0x3b/0xe0 lib/kobject.c:289
    [<ffffffff826575f3>] dev_set_name+0x63/0x90 drivers/base/core.c:3147
    [<ffffffff828dd63b>] __mdiobus_register+0xbb/0x450 drivers/net/phy/mdio_bus.c:535
    [<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
    [<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
    [<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
    [<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
    [<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
    [<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
    [<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
    [<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
    [<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
    [<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
    [<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
    [<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
    [<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969
---
 drivers/net/phy/mdio_bus.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/phy/mdio_bus.c +1 -0
@@ -541,6 +541,7 @@ int __mdiobus_register(struct mii_bus *b
 	err = device_register(&bus->dev);
 	if (err) {
 		pr_err("mii_bus %s failed to register\n", bus->id);
+		put_device(&bus->dev);
 		return -EINVAL;
 	}
 
author maintainer
#169 lore raw

PATCH 169/172 KVM: x86: Handle SRCU initialization failure during page track init

In reply to Greg Kroah-Hartman

From: Haimin Zhang <[email protected]>

commit eb7511bf9182292ef1df1082d23039e856d1ddfb upstream.

Check the return of init_srcu_struct(), which can fail due to OOM, when initializing the page track mechanism. Lack of checking leads to a NULL pointer deref found by a modified syzkaller.

Message-Id: <[email protected]>

[Move the call towards the beginning of kvm_arch_init_vm. - Paolo]
---
 arch/x86/include/asm/kvm_page_track.h |    2 +-
 arch/x86/kvm/mmu/page_track.c         |    4 ++--
 arch/x86/kvm/x86.c                    |    7 ++++++-
 3 files changed, 9 insertions(+), 4 deletions(-)
arch/x86/include/asm/kvm_page_track.h +1 -1
@@ -46,7 +46,7 @@ struct kvm_page_track_notifier_node {
 			    struct kvm_page_track_notifier_node *node);
 };
 
-void kvm_page_track_init(struct kvm *kvm);
+int kvm_page_track_init(struct kvm *kvm);
 void kvm_page_track_cleanup(struct kvm *kvm);
 
 void kvm_page_track_free_memslot(struct kvm_memory_slot *slot);
arch/x86/kvm/mmu/page_track.c +2 -2
@@ -163,13 +163,13 @@ void kvm_page_track_cleanup(struct kvm *
 	cleanup_srcu_struct(&head->track_srcu);
 }
 
-void kvm_page_track_init(struct kvm *kvm)
+int kvm_page_track_init(struct kvm *kvm)
 {
 	struct kvm_page_track_notifier_head *head;
 
 	head = &kvm->arch.track_notifier_head;
-	init_srcu_struct(&head->track_srcu);
 	INIT_HLIST_HEAD(&head->track_notifier_list);
+	return init_srcu_struct(&head->track_srcu);
 }
 
 /*
arch/x86/kvm/x86.c +6 -1
@@ -11093,9 +11093,15 @@ void kvm_arch_free_vm(struct kvm *kvm)
 
 int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
 {
+	int ret;
+
 	if (type)
 		return -EINVAL;
 
+	ret = kvm_page_track_init(kvm);
+	if (ret)
+		return ret;
+
 	INIT_HLIST_HEAD(&kvm->arch.mask_notifier_list);
 	INIT_LIST_HEAD(&kvm->arch.active_mmu_pages);
 	INIT_LIST_HEAD(&kvm->arch.zapped_obsolete_pages);
@@ -11128,7 +11134,6 @@ int kvm_arch_init_vm(struct kvm *kvm, un
 
 	kvm_apicv_init(kvm);
 	kvm_hv_init_vm(kvm);
-	kvm_page_track_init(kvm);
 	kvm_mmu_init_vm(kvm);
 
 	return static_call(kvm_x86_vm_init)(kvm);
author maintainer
#170 lore raw

PATCH 170/172 netfilter: conntrack: serialize hash resizes and cleanups

In reply to Greg Kroah-Hartman

From: Eric Dumazet <[email protected]>

commit e9edc188fc76499b0b9bd60364084037f6d03773 upstream.

Syzbot was able to trigger the following warning [1]

No repro found by syzbot yet but I was able to trigger similar issue by having 2 scripts running in parallel, changing conntrack hash sizes, and:

for j in seq 1 1000 ; do unshare -n /bin/true >/dev/null ; done

It would take more than 5 minutes for net_namespace structures to be cleaned up.

This is because nf_ct_iterate_cleanup() has to restart everytime a resize happened.

By adding a mutex, we can serialize hash resizes and cleanups and also make get_next_corpse() faster by skipping over empty buckets.

Even without resizes in the picture, this patch considerably speeds up network namespace dismantles.

[1]

INFO: task syz-executor.0:8312 can't die for more than 144 seconds.
task:syz-executor.0  state:R  running task     stack:25672 pid: 8312 ppid:  6573 flags:0x00004006
Call Trace:
 context_switch kernel/sched/core.c:4955 [inline]
 __schedule+0x940/0x26f0 kernel/sched/core.c:6236
 preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408
 preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35
 __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390
 local_bh_enable include/linux/bottom_half.h:32 [inline]
 get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline]
 nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275
 nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469
 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171
 setup_net+0x639/0xa30 net/core/net_namespace.c:349
 copy_net_ns+0x319/0x760 net/core/net_namespace.c:470
 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
 unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226
 ksys_unshare+0x445/0x920 kernel/fork.c:3128
 __do_sys_unshare kernel/fork.c:3202 [inline]
 __se_sys_unshare kernel/fork.c:3200 [inline]
 __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f63da68e739
RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000
RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80
R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000

Showing all locks held in the system:
1 lock held by khungtaskd/27:
 #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446
2 locks held by kworker/u4:2/153:
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline]
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline]
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline]
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268
 #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272
1 lock held by systemd-udevd/2970:
1 lock held by in:imklog/6258:
 #0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990
3 locks held by kworker/1:6/8158:
1 lock held by syz-executor.0/8312:
2 locks held by kworker/u4:13/9320:
1 lock held by syz-executor.5/10178:
1 lock held by syz-executor.4/10217:
---
 net/netfilter/nf_conntrack_core.c |   70 ++++++++++++++++++++------------------
 1 file changed, 37 insertions(+), 33 deletions(-)
net/netfilter/nf_conntrack_core.c +37 -33
@@ -75,6 +75,9 @@ static __read_mostly struct kmem_cache *
 static DEFINE_SPINLOCK(nf_conntrack_locks_all_lock);
 static __read_mostly bool nf_conntrack_locks_all;
 
+/* serialize hash resizes and nf_ct_iterate_cleanup */
+static DEFINE_MUTEX(nf_conntrack_mutex);
+
 #define GC_SCAN_INTERVAL	(120u * HZ)
 #define GC_SCAN_MAX_DURATION	msecs_to_jiffies(10)
 
@@ -2192,28 +2195,31 @@ get_next_corpse(int (*iter)(struct nf_co
 	spinlock_t *lockp;
 
 	for (; *bucket < nf_conntrack_htable_size; (*bucket)++) {
+		struct hlist_nulls_head *hslot = &nf_conntrack_hash[*bucket];
+
+		if (hlist_nulls_empty(hslot))
+			continue;
+
 		lockp = &nf_conntrack_locks[*bucket % CONNTRACK_LOCKS];
 		local_bh_disable();
 		nf_conntrack_lock(lockp);
-		if (*bucket < nf_conntrack_htable_size) {
-			hlist_nulls_for_each_entry(h, n, &nf_conntrack_hash[*bucket], hnnode) {
-				if (NF_CT_DIRECTION(h) != IP_CT_DIR_REPLY)
-					continue;
-				/* All nf_conn objects are added to hash table twice, one
-				 * for original direction tuple, once for the reply tuple.
-				 *
-				 * Exception: In the IPS_NAT_CLASH case, only the reply
-				 * tuple is added (the original tuple already existed for
-				 * a different object).
-				 *
-				 * We only need to call the iterator once for each
-				 * conntrack, so we just use the 'reply' direction
-				 * tuple while iterating.
-				 */
-				ct = nf_ct_tuplehash_to_ctrack(h);
-				if (iter(ct, data))
-					goto found;
-			}
+		hlist_nulls_for_each_entry(h, n, hslot, hnnode) {
+			if (NF_CT_DIRECTION(h) != IP_CT_DIR_REPLY)
+				continue;
+			/* All nf_conn objects are added to hash table twice, one
+			 * for original direction tuple, once for the reply tuple.
+			 *
+			 * Exception: In the IPS_NAT_CLASH case, only the reply
+			 * tuple is added (the original tuple already existed for
+			 * a different object).
+			 *
+			 * We only need to call the iterator once for each
+			 * conntrack, so we just use the 'reply' direction
+			 * tuple while iterating.
+			 */
+			ct = nf_ct_tuplehash_to_ctrack(h);
+			if (iter(ct, data))
+				goto found;
 		}
 		spin_unlock(lockp);
 		local_bh_enable();
@@ -2231,26 +2237,20 @@ found:
 static void nf_ct_iterate_cleanup(int (*iter)(struct nf_conn *i, void *data),
 				  void *data, u32 portid, int report)
 {
-	unsigned int bucket = 0, sequence;
+	unsigned int bucket = 0;
 	struct nf_conn *ct;
 
 	might_sleep();
 
-	for (;;) {
-		sequence = read_seqcount_begin(&nf_conntrack_generation);
-
-		while ((ct = get_next_corpse(iter, data, &bucket)) != NULL) {
-			/* Time to push up daises... */
+	mutex_lock(&nf_conntrack_mutex);
+	while ((ct = get_next_corpse(iter, data, &bucket)) != NULL) {
+		/* Time to push up daises... */
 
-			nf_ct_delete(ct, portid, report);
-			nf_ct_put(ct);
-			cond_resched();
-		}
-
-		if (!read_seqcount_retry(&nf_conntrack_generation, sequence))
-			break;
-		bucket = 0;
+		nf_ct_delete(ct, portid, report);
+		nf_ct_put(ct);
+		cond_resched();
 	}
+	mutex_unlock(&nf_conntrack_mutex);
 }
 
 struct iter_data {
@@ -2486,8 +2486,10 @@ int nf_conntrack_hash_resize(unsigned in
 	if (!hash)
 		return -ENOMEM;
 
+	mutex_lock(&nf_conntrack_mutex);
 	old_size = nf_conntrack_htable_size;
 	if (old_size == hashsize) {
+		mutex_unlock(&nf_conntrack_mutex);
 		kvfree(hash);
 		return 0;
 	}
@@ -2523,6 +2525,8 @@ int nf_conntrack_hash_resize(unsigned in
 	nf_conntrack_all_unlock();
 	local_bh_enable();
 
+	mutex_unlock(&nf_conntrack_mutex);
+
 	synchronize_net();
 	kvfree(old_hash);
 	return 0;
author maintainer
#171 lore raw

PATCH 171/172 netfilter: nf_tables: Fix oversized kvmalloc() calls

In reply to Greg Kroah-Hartman

From: Pablo Neira Ayuso <[email protected]>

commit 45928afe94a094bcda9af858b96673d59bc4a0e9 upstream.

The commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls") limits the max allocatable memory via kvmalloc() to MAX_INT.

---
 net/netfilter/nf_tables_api.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/netfilter/nf_tables_api.c +1 -1
@@ -4336,7 +4336,7 @@ static int nf_tables_newset(struct sk_bu
 	if (ops->privsize != NULL)
 		size = ops->privsize(nla, &desc);
 	alloc_size = sizeof(*set) + size + udlen;
-	if (alloc_size < size)
+	if (alloc_size < size || alloc_size > INT_MAX)
 		return -ENOMEM;
 	set = kvzalloc(alloc_size, GFP_KERNEL);
 	if (!set)
author maintainer
#172 lore raw

PATCH 172/172 drivers: net: mhi: fix error path in mhi_net_newlink

In reply to Greg Kroah-Hartman

From: Daniele Palmas <[email protected]>

commit 4526fe74c3c5095cc55931a3a6fb4932f9e06002 upstream.

Fix double free_netdev when mhi_prepare_for_transfer fails.

---
 drivers/net/mhi/net.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/net/mhi/net.c +2 -4
@@ -337,7 +337,7 @@ static int mhi_net_newlink(void *ctxt, s
 	/* Start MHI channels */
 	err = mhi_prepare_for_transfer(mhi_dev);
 	if (err)
-		goto out_err;
+		return err;
 
 	/* Number of transfer descriptors determines size of the queue */
 	mhi_netdev->rx_queue_sz = mhi_get_free_desc_count(mhi_dev, DMA_FROM_DEVICE);
@@ -347,7 +347,7 @@ static int mhi_net_newlink(void *ctxt, s
 	else
 		err = register_netdev(ndev);
 	if (err)
-		goto out_err;
+		return err;
 
 	if (mhi_netdev->proto) {
 		err = mhi_netdev->proto->init(mhi_netdev);
@@ -359,8 +359,6 @@ static int mhi_net_newlink(void *ctxt, s
 
 out_err_proto:
 	unregister_netdevice(ndev);
-out_err:
-	free_netdev(ndev);
 	return err;
 }
 
Tested-by on the v1 series
#173 lore raw
In reply to Greg Kroah-Hartman

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 5.14.10 release. There are 172 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.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

Best regards,
Pavel

Signature · 2 lines
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
#174 lore raw
Quoted 10 lines · Pavel Machek

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 5.14.10 release. There are 172 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.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

Sorry, I replied to wrong email. We are not actually testing 5.14.

Best regards,
Pavel

Signature · 2 lines
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Tested-by on the v1 series
#175 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.14.10 release. There are 172 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 Wed, 06 Oct 2021 12:50:17 +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.14.10-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

5.14.10-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)

Tested-by on the v1 series
#176 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.14.10 release. There are 172 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 Wed, 06 Oct 2021 12:50:17 +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.14.10-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Tested-by on the v1 series
#177 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.14.10 release. There are 172 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 Wed, 06 Oct 2021 12:50:17 +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.14.10-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:

Similar to other comments., this commit:

net: mdiobus: Fix memory leak in __mdiobus_register

has since been reverted upstream. Thanks!

Signature · 1 line
Florian
Tested-by on the v1 series
#178 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.14.10 release. There are 172 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 Wed, 06 Oct 2021 12:50:17 +0000. Anything received after that time might be too late.

Build results:

	total: 154 pass: 154 fail: 0
Qemu test results:
	total: 480 pass: 480 fail: 0

Guenter

#179 lore raw
Quoted 6 lines · Guenter Roeck
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.14.10 release. There are 172 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
Quoted 3 lines

Responses should be made by Wed, 06 Oct 2021 12:50:17 +0000. Anything received after that time might be too late.

Build results:

	total: 154 pass: 154 fail: 0
Qemu test results:
	total: 480 pass: 480 fail: 0

I spoke too early. A large number of boot tests report the following warning tracebacks in this rc.

Guenter

====================================
WARNING: ip/134 still has locks held! 5.14.10-rc1-00173-gcda15f9c69e0 #1 Not tainted
------------------------------------
1 lock held by ip/134:
#0: c17acf0c (sk_lock-AF_INET){+.+.}-{0:0}, at: 0xc17c561c

stack backtrace:
CPU: 0 PID: 134 Comm: ip Not tainted 5.14.10-rc1-00173-gcda15f9c69e0 #1
Call trace:
[<(ptrval)>] dump_stack+0x34/0x48
[<(ptrval)>] debug_check_no_locks_held+0xc8/0xd0
[<(ptrval)>] do_exit+0x6a8/0xc2c
[<(ptrval)>] do_group_exit+0x68/0x114
[<(ptrval)>] __wake_up_parent+0x0/0x34
[<(ptrval)>] _syscall_return+0x0/0x4

=========================
WARNING: held lock freed!
5.14.10-rc1-00173-gcda15f9c69e0 #1 Not tainted
-------------------------
ip/182 is freeing memory 9000000002400040-90000000024006bf, with a lock still held there! 9000000002400160 (sk_lock-AF_INET){+.+.}-{0:0}, at: sk_common_release+0x28/0x118 2 locks held by ip/182:
#0: 90000000036a0280 (&sb->s_type->i_mutex_key#4){+.+.}-{3:3}, at: __sock_release+0x34/0xd8 #1: 9000000002400160 (sk_lock-AF_INET){+.+.}-{0:0}, at: sk_common_release+0x28/0x118

stack backtrace:
CPU: 0 PID: 182 Comm: ip Not tainted 5.14.10-rc1-00173-gcda15f9c69e0 #1
Stack : 0000000000000000 0000000000000000 0000000000000008 627881c1d8d1d123
        90000000021453c0 0000000000000000 90000000026cbb58 ffffffff80f3b950
        ffffffff81088f80 0000000000000001 90000000026cb9a8 0000000000000000
        0000000000000000 0000000000000010 ffffffff8071ee00 0000000000000000
        0000000000000000 ffffffff81060000 0000000000000001 ffffffff80f3b950
        9000000002ab2940 000000001000a4e0 000000007fe10f68 ffffffffffffffff
        0000000000000000 0000000000000000 ffffffff807a51a0 0000000000052798
        ffffffff81220000 90000000026c8000 90000000026cbb50 0000000000000000
        ffffffff80c7b6f0 0000000000000000 90000000026cbc88 ffffffff8121e440
        00000000000000b6 0000000000000000 ffffffff8010b304 627881c1d8d1d123
        ...
Call Trace:
[<ffffffff8010b304>] show_stack+0x3c/0x120
[<ffffffff80c7b6f0>] dump_stack_lvl+0xa0/0xec
[<ffffffff801a8228>] debug_check_no_locks_freed+0x168/0x1a0
[<ffffffff802d679c>] kmem_cache_free.part.0+0xf4/0x2b8
[<ffffffff809eb5d0>] __sk_destruct+0x150/0x230
[<ffffffff80b22094>] inet_release+0x4c/0x88
[<ffffffff809e2744>] __sock_release+0x44/0xd8
[<ffffffff809e27ec>] sock_close+0x14/0x28
[<ffffffff802e4d84>] __fput+0xac/0x2d8
[<ffffffff80163500>] task_work_run+0x90/0xf0
[<ffffffff8010a6e8>] do_notify_resume+0x348/0x360
[<ffffffff801039e8>] work_notifysig+0x10/0x18
#180 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.14.10 release. There are 172 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 Wed, 06 Oct 2021 12:50:17 +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.14.10-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

Regression found on arm.
following kernel BUG reported on stable-rc linux-5.14.y while booting BeagleBoard X15 device.

metadata:
git branch: linux-5.14.y
git repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
git commit: cda15f9c69e08480d4308d0e5c62bd44324a9ff0
git describe: v5.14.9-173-gcda15f9c69e0
make_kernelversion: 5.14.10-rc1
kernel-config: https://builds.tuxbuild.com/1z2ozt5ntwqausJUkOMJ8zBgRqi/config

Kernel crash:
--------------

[    6.457366] kernel BUG at kernel/cpu.c:1065!
[    6.461669] Internal error: Oops - BUG: 0 [#1] SMP ARM
[    6.466827] Modules linked in:
[    6.469909] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.14.10-rc1 #1
[    6.476318] Hardware name: Generic DRA74X (Flattened Device Tree)
[    6.482452] PC is at cpuhp_report_idle_dead+0x74/0x78
[    6.487518] LR is at do_idle+0x108/0x310
[    6.491485] pc : [<c035a700>]    lr : [<c03a3cc0>]    psr: 20000093
[    6.497772] sp : c2101ee0  ip : c2101f00  fp : c2101efc
[    6.503051] r10: 00000000  r9 : c2100000  r8 : 00000000
[    6.508300] r7 : c2108fe4  r6 : eeb04414  r5 : 2ca71000  r4 : c2093414
[    6.514862] r3 : c2101ee0  r2 : 00000000  r1 : 000000e0  r0 : 00000000
[    6.521423] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
Segment none
[    6.528686] Control: 10c5387d  Table: 8020406a  DAC: 00000051
[    6.534454] Register r0 information: NULL pointer
[    6.539215] Register r1 information: non-paged memory
[    6.544281] Register r2 information: NULL pointer
[    6.549011] Register r3 information: non-slab/vmalloc memory
[    6.554718] Register r4 information: non-slab/vmalloc memory
[    6.560424] Register r5 information: non-paged memory
[    6.565490] Register r6 information: non-slab/vmalloc memory
[    6.571197] Register r7 information: non-slab/vmalloc memory
[    6.576904] Register r8 information: NULL pointer
[    6.581634] Register r9 information: non-slab/vmalloc memory
[    6.587310] Register r10 information: NULL pointer
[    6.592132] Register r11 information: non-slab/vmalloc memory
[    6.597930] Register r12 information: non-slab/vmalloc memory
[    6.603698] Process swapper/0 (pid: 0, stack limit = 0x(ptrval))
[    6.609741] Stack: (0xc2101ee0 to 0xc2102000)
[    6.614135] 1ee0: 00000000 c2100000 c2108f90 c2108fe4 c2101f44
c2101f00 c03a3cc0 c035a698
[    6.622375] 1f00: c210e0c0 00000002 c2101f00 c209f0f0 c2100000
5a76ee47 c2101f3c 000000e0
[    6.630584] 1f20: c2101f58 00000002 c2108f40 00000000 c2100000
10c5387d c2101f54 c2101f48
[    6.638824] 1f40: c03a4334 c03a3bc4 c2101f84 c2101f58 c1556b84
c03a4318 00000000 00000000
[    6.647033] 1f60: c1556a88 c2101f70 c0322004 c239e068 c1fd7a80
ffffffff c2101f94 c2101f88
[    6.655273] 1f80: c1f00af0 c15569c0 c2101ff4 c2101f98 c1f012a0
c1f00ae4 ffffffff ffffffff
[    6.663482] 1fa0: 00000000 c1f00640 00000000 00000000 00000000
00000000 00000000 c1fd7a80
[    6.671722] 1fc0: 5a73e04d 00000000 00000000 c1f00330 00000051
10c0387d 00000000 8ffda000
[    6.679931] 1fe0: 412fc0f2 10c5387d 00000000 c2101ff8 00000000
c1f00b78 00000000 00000000
[    6.688140] Backtrace:
[    6.690612] [<c035a68c>] (cpuhp_report_idle_dead) from [<c03a3cc0>]
(do_idle+0x108/0x310)
[    6.698852]  r7:c2108fe4 r6:c2108f90 r5:c2100000 r4:00000000
[    6.704559] [<c03a3bb8>] (do_idle) from [<c03a4334>]
(cpu_startup_entry+0x28/0x2c)
[    6.712188]  r10:10c5387d r9:c2100000 r8:00000000 r7:c2108f40
r6:00000002 r5:c2101f58
[    6.720031]  r4:000000e0
[    6.722595] [<c03a430c>] (cpu_startup_entry) from [<c1556b84>]
(rest_init+0x1d0/0x2fc)
[    6.730560] [<c15569b4>] (rest_init) from [<c1f00af0>]
(arch_call_rest_init+0x18/0x1c)
[    6.738555]  r6:ffffffff r5:c1fd7a80 r4:c239e068
[    6.743194] [<c1f00ad8>] (arch_call_rest_init) from [<c1f012a0>]
(start_kernel+0x734/0x780)
[    6.751586] [<c1f00b6c>] (start_kernel) from [<00000000>] (0x0)
[    6.757568]  r10:10c5387d r9:412fc0f2 r8:8ffda000 r7:00000000
r6:10c0387d r5:00000051
[    6.765441]  r4:c1f00330
[    6.767974] Code: e34c1035 e3a03000 eb039b62 e89da8f0 (e7f001f2)
[    6.774108] ---[ end trace 8e1c46209559ca84 ]---

ref:
https://lkft.validation.linaro.org/scheduler/job/3659621#L2841

Signature · 2 lines
Linaro LKFT
https://lkft.linaro.org
author maintainer
#181 lore raw
Quoted 107 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.14.10 release. There are 172 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 Wed, 06 Oct 2021 12:50:17 +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.14.10-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

Regression found on arm.
following kernel BUG reported on stable-rc linux-5.14.y while booting BeagleBoard X15 device.

metadata:
git branch: linux-5.14.y
git repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
git commit: cda15f9c69e08480d4308d0e5c62bd44324a9ff0
git describe: v5.14.9-173-gcda15f9c69e0
make_kernelversion: 5.14.10-rc1
kernel-config: https://builds.tuxbuild.com/1z2ozt5ntwqausJUkOMJ8zBgRqi/config

Kernel crash:
--------------

[    6.457366] kernel BUG at kernel/cpu.c:1065!
[    6.461669] Internal error: Oops - BUG: 0 [#1] SMP ARM
[    6.466827] Modules linked in:
[    6.469909] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.14.10-rc1 #1
[    6.476318] Hardware name: Generic DRA74X (Flattened Device Tree)
[    6.482452] PC is at cpuhp_report_idle_dead+0x74/0x78
[    6.487518] LR is at do_idle+0x108/0x310
[    6.491485] pc : [<c035a700>]    lr : [<c03a3cc0>]    psr: 20000093
[    6.497772] sp : c2101ee0  ip : c2101f00  fp : c2101efc
[    6.503051] r10: 00000000  r9 : c2100000  r8 : 00000000
[    6.508300] r7 : c2108fe4  r6 : eeb04414  r5 : 2ca71000  r4 : c2093414
[    6.514862] r3 : c2101ee0  r2 : 00000000  r1 : 000000e0  r0 : 00000000
[    6.521423] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
Segment none
[    6.528686] Control: 10c5387d  Table: 8020406a  DAC: 00000051
[    6.534454] Register r0 information: NULL pointer
[    6.539215] Register r1 information: non-paged memory
[    6.544281] Register r2 information: NULL pointer
[    6.549011] Register r3 information: non-slab/vmalloc memory
[    6.554718] Register r4 information: non-slab/vmalloc memory
[    6.560424] Register r5 information: non-paged memory
[    6.565490] Register r6 information: non-slab/vmalloc memory
[    6.571197] Register r7 information: non-slab/vmalloc memory
[    6.576904] Register r8 information: NULL pointer
[    6.581634] Register r9 information: non-slab/vmalloc memory
[    6.587310] Register r10 information: NULL pointer
[    6.592132] Register r11 information: non-slab/vmalloc memory
[    6.597930] Register r12 information: non-slab/vmalloc memory
[    6.603698] Process swapper/0 (pid: 0, stack limit = 0x(ptrval))
[    6.609741] Stack: (0xc2101ee0 to 0xc2102000)
[    6.614135] 1ee0: 00000000 c2100000 c2108f90 c2108fe4 c2101f44
c2101f00 c03a3cc0 c035a698
[    6.622375] 1f00: c210e0c0 00000002 c2101f00 c209f0f0 c2100000
5a76ee47 c2101f3c 000000e0
[    6.630584] 1f20: c2101f58 00000002 c2108f40 00000000 c2100000
10c5387d c2101f54 c2101f48
[    6.638824] 1f40: c03a4334 c03a3bc4 c2101f84 c2101f58 c1556b84
c03a4318 00000000 00000000
[    6.647033] 1f60: c1556a88 c2101f70 c0322004 c239e068 c1fd7a80
ffffffff c2101f94 c2101f88
[    6.655273] 1f80: c1f00af0 c15569c0 c2101ff4 c2101f98 c1f012a0
c1f00ae4 ffffffff ffffffff
[    6.663482] 1fa0: 00000000 c1f00640 00000000 00000000 00000000
00000000 00000000 c1fd7a80
[    6.671722] 1fc0: 5a73e04d 00000000 00000000 c1f00330 00000051
10c0387d 00000000 8ffda000
[    6.679931] 1fe0: 412fc0f2 10c5387d 00000000 c2101ff8 00000000
c1f00b78 00000000 00000000
[    6.688140] Backtrace:
[    6.690612] [<c035a68c>] (cpuhp_report_idle_dead) from [<c03a3cc0>]
(do_idle+0x108/0x310)
[    6.698852]  r7:c2108fe4 r6:c2108f90 r5:c2100000 r4:00000000
[    6.704559] [<c03a3bb8>] (do_idle) from [<c03a4334>]
(cpu_startup_entry+0x28/0x2c)
[    6.712188]  r10:10c5387d r9:c2100000 r8:00000000 r7:c2108f40
r6:00000002 r5:c2101f58
[    6.720031]  r4:000000e0
[    6.722595] [<c03a430c>] (cpu_startup_entry) from [<c1556b84>]
(rest_init+0x1d0/0x2fc)
[    6.730560] [<c15569b4>] (rest_init) from [<c1f00af0>]
(arch_call_rest_init+0x18/0x1c)
[    6.738555]  r6:ffffffff r5:c1fd7a80 r4:c239e068
[    6.743194] [<c1f00ad8>] (arch_call_rest_init) from [<c1f012a0>]
(start_kernel+0x734/0x780)
[    6.751586] [<c1f00b6c>] (start_kernel) from [<00000000>] (0x0)
[    6.757568]  r10:10c5387d r9:412fc0f2 r8:8ffda000 r7:00000000
r6:10c0387d r5:00000051
[    6.765441]  r4:c1f00330
[    6.767974] Code: e34c1035 e3a03000 eb039b62 e89da8f0 (e7f001f2)
[    6.774108] ---[ end trace 8e1c46209559ca84 ]---
Quoted 8 lines

ref:
https://lkft.validation.linaro.org/scheduler/job/3659621#L2841

Signature · 2 lines
Linaro LKFT
https://lkft.linaro.org

Any chance at bisection?

#182 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.14.10 release. There are 172 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 Wed, 06 Oct 2021 12:50:17 +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.14.10-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

Regression found on i386 and x86.
following kernel warning reported on stable-rc linux-5.14.y while booting x86.

metadata:
git branch: linux-5.14.y
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git commit: cda15f9c69e08480d4308d0e5c62bd44324a9ff0
git describe: v5.14.9-173-gcda15f9c69e0
make_kernelversion: 5.14.10-rc1
kernel-config:
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-stable-rc-5.14/36/config

Kernel crash:
--------------

[   22.356755] =========================
[   22.360414] WARNING: held lock freed!
[   22.364071] 5.14.10-rc1 #1 Not tainted
[   22.367824] -------------------------
[   22.371489] systemd-network/341 is freeing memory
ffff9d21cbea0000-ffff9d21cbea06bf, with a lock still held there!
[   22.381828] ffff9d21cbea0120 (sk_lock-AF_INET){+.+.}-{0:0}, at:
sk_common_release+0x21/0x100
[   22.384624] igb 0000:02:00.0 eno2: renamed from eth1
[   22.390260] 2 locks held by systemd-network/341:
[   22.390261]  #0: ffff9d21c406eb10
(&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, at: __sock_release+0x32/0xc0
[   22.390267]  #1: ffff9d21cbea0120 (sk_lock-AF_INET){+.+.}-{0:0},
at: sk_common_release+0x21/0x100
[   22.390272]
[   22.390272] stack backtrace:
[   22.390273] CPU: 2 PID: 341 Comm: systemd-network Not tainted 5.14.10-rc1 #1
[   22.390275] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[   22.390276] Call Trace:
[   22.390278]  dump_stack_lvl+0x49/0x5e
[   22.390281]  dump_stack+0x10/0x12
[   22.390283]  debug_check_no_locks_freed+0x111/0x120
[   22.390286]  slab_free_freelist_hook+0x119/0x1d0
[   22.390289]  kmem_cache_free+0x102/0x540
[   22.390291]  ? __sk_destruct+0x145/0x210
[   22.390294]  __sk_destruct+0x145/0x210
[   22.390296]  sk_destruct+0x48/0x50
[   22.409489] ata_id (348) used greatest stack depth: 11952 bytes left
[   22.418194]  __sk_free+0x2f/0xc0
[   22.418198]  sk_free+0x26/0x40
[   22.418200]  sk_common_release+0xa9/0x100
[   22.487567]  udp_lib_close+0x9/0x10
[   22.491057]  inet_release+0x44/0x80
[   22.494542]  __sock_release+0x42/0xc0
[   22.498209]  sock_close+0x18/0x20
[   22.501525]  __fput+0xb5/0x260
[   22.504578]  ____fput+0xe/0x10
[   22.507636]  task_work_run+0x6f/0xc0
[   22.511216]  exit_to_user_mode_prepare+0x1f6/0x200
[   22.515999]  syscall_exit_to_user_mode+0x1d/0x50
[   22.520610]  do_syscall_64+0x67/0x80
[   22.524190]  ? irqentry_exit+0x75/0x80
[   22.527940]  ? exc_page_fault+0x6c/0x200
[   22.531859]  ? asm_exc_page_fault+0x8/0x30
[   22.535950]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   22.541002] RIP: 0033:0x7f52fe67e641
[   22.544580] Code: f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f
1f 84 00 00 00 00 00 66 90 8b 05 aa cd 20 00 85 c0 75 16 b8 03 00 00
00 0f 05 <48> 3d 00 f0 ff ff 77 3f c3 66 0f 1f 44 00 00 53 89 fb 48 83
ec 10
[   22.563318] RSP: 002b:00007ffe31761878 EFLAGS: 00000246 ORIG_RAX:
0000000000000003
[   22.570884] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 00007f52fe67e641
[   22.578007] RDX: 00000000000073b0 RSI: 0000000000000000 RDI: 0000000000000010
[   22.585130] RBP: 00007f52feed8338 R08: 000055893cf103c3 R09: 0000000000000078
[   22.592253] R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000000
[   22.599379] R13: 00007ffe317618c0 R14: 0000000000000000 R15: 00007ffe31762a60

ref:
https://lkft.validation.linaro.org/scheduler/job/3658919#L1477

Signature · 2 lines
Linaro LKFT
https://lkft.linaro.org
author maintainer
#183 lore raw
Quoted 95 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.14.10 release. There are 172 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 Wed, 06 Oct 2021 12:50:17 +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.14.10-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

Regression found on i386 and x86.
following kernel warning reported on stable-rc linux-5.14.y while booting x86.

metadata:
git branch: linux-5.14.y
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git commit: cda15f9c69e08480d4308d0e5c62bd44324a9ff0
git describe: v5.14.9-173-gcda15f9c69e0
make_kernelversion: 5.14.10-rc1
kernel-config:
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-stable-rc-5.14/36/config

Kernel crash:
--------------

[   22.356755] =========================
[   22.360414] WARNING: held lock freed!
[   22.364071] 5.14.10-rc1 #1 Not tainted
[   22.367824] -------------------------
[   22.371489] systemd-network/341 is freeing memory
ffff9d21cbea0000-ffff9d21cbea06bf, with a lock still held there!
[   22.381828] ffff9d21cbea0120 (sk_lock-AF_INET){+.+.}-{0:0}, at:
sk_common_release+0x21/0x100
[   22.384624] igb 0000:02:00.0 eno2: renamed from eth1
[   22.390260] 2 locks held by systemd-network/341:
[   22.390261]  #0: ffff9d21c406eb10
(&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, at: __sock_release+0x32/0xc0
[   22.390267]  #1: ffff9d21cbea0120 (sk_lock-AF_INET){+.+.}-{0:0},
at: sk_common_release+0x21/0x100
[   22.390272]
[   22.390272] stack backtrace:
[   22.390273] CPU: 2 PID: 341 Comm: systemd-network Not tainted 5.14.10-rc1 #1
[   22.390275] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[   22.390276] Call Trace:
[   22.390278]  dump_stack_lvl+0x49/0x5e
[   22.390281]  dump_stack+0x10/0x12
[   22.390283]  debug_check_no_locks_freed+0x111/0x120
[   22.390286]  slab_free_freelist_hook+0x119/0x1d0
[   22.390289]  kmem_cache_free+0x102/0x540
[   22.390291]  ? __sk_destruct+0x145/0x210
[   22.390294]  __sk_destruct+0x145/0x210
[   22.390296]  sk_destruct+0x48/0x50
[   22.409489] ata_id (348) used greatest stack depth: 11952 bytes left
[   22.418194]  __sk_free+0x2f/0xc0
[   22.418198]  sk_free+0x26/0x40
[   22.418200]  sk_common_release+0xa9/0x100
[   22.487567]  udp_lib_close+0x9/0x10
[   22.491057]  inet_release+0x44/0x80
[   22.494542]  __sock_release+0x42/0xc0
[   22.498209]  sock_close+0x18/0x20
[   22.501525]  __fput+0xb5/0x260
[   22.504578]  ____fput+0xe/0x10
[   22.507636]  task_work_run+0x6f/0xc0
[   22.511216]  exit_to_user_mode_prepare+0x1f6/0x200
[   22.515999]  syscall_exit_to_user_mode+0x1d/0x50
[   22.520610]  do_syscall_64+0x67/0x80
[   22.524190]  ? irqentry_exit+0x75/0x80
[   22.527940]  ? exc_page_fault+0x6c/0x200
[   22.531859]  ? asm_exc_page_fault+0x8/0x30
[   22.535950]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   22.541002] RIP: 0033:0x7f52fe67e641
[   22.544580] Code: f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f
1f 84 00 00 00 00 00 66 90 8b 05 aa cd 20 00 85 c0 75 16 b8 03 00 00
00 0f 05 <48> 3d 00 f0 ff ff 77 3f c3 66 0f 1f 44 00 00 53 89 fb 48 83
ec 10
[   22.563318] RSP: 002b:00007ffe31761878 EFLAGS: 00000246 ORIG_RAX:
0000000000000003
[   22.570884] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 00007f52fe67e641
[   22.578007] RDX: 00000000000073b0 RSI: 0000000000000000 RDI: 0000000000000010
[   22.585130] RBP: 00007f52feed8338 R08: 000055893cf103c3 R09: 0000000000000078
[   22.592253] R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000000
[   22.599379] R13: 00007ffe317618c0 R14: 0000000000000000 R15: 00007ffe31762a60
Quoted 8 lines

ref:
https://lkft.validation.linaro.org/scheduler/job/3658919#L1477

Signature · 2 lines
Linaro LKFT
https://lkft.linaro.org

Any chance at bisection?