From: Sasha Levin Date: Thu, 27 Oct 2022 01:36:33 +0000 (-0400) Subject: Fixes for 4.19 X-Git-Tag: v5.10.151~37 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d957996b9b2f4cc05da9ea674670dba197b8bb70;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.19 Signed-off-by: Sasha Levin --- diff --git a/queue-4.19/acpi-extlog-handle-multiple-records.patch b/queue-4.19/acpi-extlog-handle-multiple-records.patch new file mode 100644 index 00000000000..cff2d270fed --- /dev/null +++ b/queue-4.19/acpi-extlog-handle-multiple-records.patch @@ -0,0 +1,93 @@ +From 1354df83bc8bbbdda6910d2e6a93c6d74fa9dfc9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 10 Oct 2022 13:34:23 -0700 +Subject: ACPI: extlog: Handle multiple records + +From: Tony Luck + +[ Upstream commit f6ec01da40e4139b41179f046044ee7c4f6370dc ] + +If there is no user space consumer of extlog_mem trace records, then +Linux properly handles multiple error records in an ELOG block + + extlog_print() + print_extlog_rcd() + __print_extlog_rcd() + cper_estatus_print() + apei_estatus_for_each_section() + +But the other code path hard codes looking for a single record to +output a trace record. + +Fix by using the same apei_estatus_for_each_section() iterator +to step over all records. + +Fixes: 2dfb7d51a61d ("trace, RAS: Add eMCA trace event interface") +Signed-off-by: Tony Luck +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + drivers/acpi/acpi_extlog.c | 33 ++++++++++++++++++++------------- + 1 file changed, 20 insertions(+), 13 deletions(-) + +diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c +index 943b1dc2d0b3..e05309bc41cc 100644 +--- a/drivers/acpi/acpi_extlog.c ++++ b/drivers/acpi/acpi_extlog.c +@@ -13,6 +13,7 @@ + #include + #include + #include ++#include + #include + #include + +@@ -141,8 +142,8 @@ static int extlog_print(struct notifier_block *nb, unsigned long val, + int cpu = mce->extcpu; + struct acpi_hest_generic_status *estatus, *tmp; + struct acpi_hest_generic_data *gdata; +- const guid_t *fru_id = &guid_null; +- char *fru_text = ""; ++ const guid_t *fru_id; ++ char *fru_text; + guid_t *sec_type; + static u32 err_seq; + +@@ -163,17 +164,23 @@ static int extlog_print(struct notifier_block *nb, unsigned long val, + + /* log event via trace */ + err_seq++; +- gdata = (struct acpi_hest_generic_data *)(tmp + 1); +- if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID) +- fru_id = (guid_t *)gdata->fru_id; +- if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT) +- fru_text = gdata->fru_text; +- sec_type = (guid_t *)gdata->section_type; +- if (guid_equal(sec_type, &CPER_SEC_PLATFORM_MEM)) { +- struct cper_sec_mem_err *mem = (void *)(gdata + 1); +- if (gdata->error_data_length >= sizeof(*mem)) +- trace_extlog_mem_event(mem, err_seq, fru_id, fru_text, +- (u8)gdata->error_severity); ++ apei_estatus_for_each_section(tmp, gdata) { ++ if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID) ++ fru_id = (guid_t *)gdata->fru_id; ++ else ++ fru_id = &guid_null; ++ if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT) ++ fru_text = gdata->fru_text; ++ else ++ fru_text = ""; ++ sec_type = (guid_t *)gdata->section_type; ++ if (guid_equal(sec_type, &CPER_SEC_PLATFORM_MEM)) { ++ struct cper_sec_mem_err *mem = (void *)(gdata + 1); ++ ++ if (gdata->error_data_length >= sizeof(*mem)) ++ trace_extlog_mem_event(mem, err_seq, fru_id, fru_text, ++ (u8)gdata->error_severity); ++ } + } + + out: +-- +2.35.1 + diff --git a/queue-4.19/btrfs-fix-processing-of-delayed-data-refs-during-bac.patch b/queue-4.19/btrfs-fix-processing-of-delayed-data-refs-during-bac.patch new file mode 100644 index 00000000000..e33caa40d32 --- /dev/null +++ b/queue-4.19/btrfs-fix-processing-of-delayed-data-refs-during-bac.patch @@ -0,0 +1,249 @@ +From 7f817248aeb10f399cce88c1d599c0ca1bbbf901 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 11 Oct 2022 13:16:51 +0100 +Subject: btrfs: fix processing of delayed data refs during backref walking + +From: Filipe Manana + +[ Upstream commit 4fc7b57228243d09c0d878873bf24fa64a90fa01 ] + +When processing delayed data references during backref walking and we are +using a share context (we are being called through fiemap), whenever we +find a delayed data reference for an inode different from the one we are +interested in, then we immediately exit and consider the data extent as +shared. This is wrong, because: + +1) This might be a DROP reference that will cancel out a reference in the + extent tree; + +2) Even if it's an ADD reference, it may be followed by a DROP reference + that cancels it out. + +In either case we should not exit immediately. + +Fix this by never exiting when we find a delayed data reference for +another inode - instead add the reference and if it does not cancel out +other delayed reference, we will exit early when we call +extent_is_shared() after processing all delayed references. If we find +a drop reference, then signal the code that processes references from +the extent tree (add_inline_refs() and add_keyed_refs()) to not exit +immediately if it finds there a reference for another inode, since we +have delayed drop references that may cancel it out. In this later case +we exit once we don't have references in the rb trees that cancel out +each other and have two references for different inodes. + +Example reproducer for case 1): + + $ cat test-1.sh + #!/bin/bash + + DEV=/dev/sdj + MNT=/mnt/sdj + + mkfs.btrfs -f $DEV + mount $DEV $MNT + + xfs_io -f -c "pwrite 0 64K" $MNT/foo + cp --reflink=always $MNT/foo $MNT/bar + + echo + echo "fiemap after cloning:" + xfs_io -c "fiemap -v" $MNT/foo + + rm -f $MNT/bar + echo + echo "fiemap after removing file bar:" + xfs_io -c "fiemap -v" $MNT/foo + + umount $MNT + +Running it before this patch, the extent is still listed as shared, it has +the flag 0x2000 (FIEMAP_EXTENT_SHARED) set: + + $ ./test-1.sh + fiemap after cloning: + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [0..127]: 26624..26751 128 0x2001 + + fiemap after removing file bar: + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [0..127]: 26624..26751 128 0x2001 + +Example reproducer for case 2): + + $ cat test-2.sh + #!/bin/bash + + DEV=/dev/sdj + MNT=/mnt/sdj + + mkfs.btrfs -f $DEV + mount $DEV $MNT + + xfs_io -f -c "pwrite 0 64K" $MNT/foo + cp --reflink=always $MNT/foo $MNT/bar + + # Flush delayed references to the extent tree and commit current + # transaction. + sync + + echo + echo "fiemap after cloning:" + xfs_io -c "fiemap -v" $MNT/foo + + rm -f $MNT/bar + echo + echo "fiemap after removing file bar:" + xfs_io -c "fiemap -v" $MNT/foo + + umount $MNT + +Running it before this patch, the extent is still listed as shared, it has +the flag 0x2000 (FIEMAP_EXTENT_SHARED) set: + + $ ./test-2.sh + fiemap after cloning: + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [0..127]: 26624..26751 128 0x2001 + + fiemap after removing file bar: + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [0..127]: 26624..26751 128 0x2001 + +After this patch, after deleting bar in both tests, the extent is not +reported with the 0x2000 flag anymore, it gets only the flag 0x1 +(which is FIEMAP_EXTENT_LAST): + + $ ./test-1.sh + fiemap after cloning: + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [0..127]: 26624..26751 128 0x2001 + + fiemap after removing file bar: + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [0..127]: 26624..26751 128 0x1 + + $ ./test-2.sh + fiemap after cloning: + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [0..127]: 26624..26751 128 0x2001 + + fiemap after removing file bar: + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [0..127]: 26624..26751 128 0x1 + +These tests will later be converted to a test case for fstests. + +Fixes: dc046b10c8b7d4 ("Btrfs: make fiemap not blow when you have lots of snapshots") +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/backref.c | 33 ++++++++++++++++++++++++--------- + 1 file changed, 24 insertions(+), 9 deletions(-) + +diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c +index 3fe15d6f4087..5e27e30fd887 100644 +--- a/fs/btrfs/backref.c ++++ b/fs/btrfs/backref.c +@@ -136,6 +136,7 @@ struct share_check { + u64 root_objectid; + u64 inum; + int share_count; ++ bool have_delayed_delete_refs; + }; + + static inline int extent_is_shared(struct share_check *sc) +@@ -825,13 +826,22 @@ static int add_delayed_refs(const struct btrfs_fs_info *fs_info, + key.offset = ref->offset; + + /* +- * Found a inum that doesn't match our known inum, we +- * know it's shared. ++ * If we have a share check context and a reference for ++ * another inode, we can't exit immediately. This is ++ * because even if this is a BTRFS_ADD_DELAYED_REF ++ * reference we may find next a BTRFS_DROP_DELAYED_REF ++ * which cancels out this ADD reference. ++ * ++ * If this is a DROP reference and there was no previous ++ * ADD reference, then we need to signal that when we ++ * process references from the extent tree (through ++ * add_inline_refs() and add_keyed_refs()), we should ++ * not exit early if we find a reference for another ++ * inode, because one of the delayed DROP references ++ * may cancel that reference in the extent tree. + */ +- if (sc && sc->inum && ref->objectid != sc->inum) { +- ret = BACKREF_FOUND_SHARED; +- goto out; +- } ++ if (sc && count < 0) ++ sc->have_delayed_delete_refs = true; + + ret = add_indirect_ref(fs_info, preftrees, ref->root, + &key, 0, node->bytenr, count, sc, +@@ -861,7 +871,7 @@ static int add_delayed_refs(const struct btrfs_fs_info *fs_info, + } + if (!ret) + ret = extent_is_shared(sc); +-out: ++ + spin_unlock(&head->lock); + return ret; + } +@@ -965,7 +975,8 @@ static int add_inline_refs(const struct btrfs_fs_info *fs_info, + key.type = BTRFS_EXTENT_DATA_KEY; + key.offset = btrfs_extent_data_ref_offset(leaf, dref); + +- if (sc && sc->inum && key.objectid != sc->inum) { ++ if (sc && sc->inum && key.objectid != sc->inum && ++ !sc->have_delayed_delete_refs) { + ret = BACKREF_FOUND_SHARED; + break; + } +@@ -975,6 +986,7 @@ static int add_inline_refs(const struct btrfs_fs_info *fs_info, + ret = add_indirect_ref(fs_info, preftrees, root, + &key, 0, bytenr, count, + sc, GFP_NOFS); ++ + break; + } + default: +@@ -1064,7 +1076,8 @@ static int add_keyed_refs(struct btrfs_fs_info *fs_info, + key.type = BTRFS_EXTENT_DATA_KEY; + key.offset = btrfs_extent_data_ref_offset(leaf, dref); + +- if (sc && sc->inum && key.objectid != sc->inum) { ++ if (sc && sc->inum && key.objectid != sc->inum && ++ !sc->have_delayed_delete_refs) { + ret = BACKREF_FOUND_SHARED; + break; + } +@@ -1490,6 +1503,7 @@ int btrfs_check_shared(struct btrfs_root *root, u64 inum, u64 bytenr) + .root_objectid = root->objectid, + .inum = inum, + .share_count = 0, ++ .have_delayed_delete_refs = false, + }; + + tmp = ulist_alloc(GFP_NOFS); +@@ -1528,6 +1542,7 @@ int btrfs_check_shared(struct btrfs_root *root, u64 inum, u64 bytenr) + break; + bytenr = node->val; + shared.share_count = 0; ++ shared.have_delayed_delete_refs = false; + cond_resched(); + } + +-- +2.35.1 + diff --git a/queue-4.19/btrfs-fix-processing-of-delayed-tree-block-refs-duri.patch b/queue-4.19/btrfs-fix-processing-of-delayed-tree-block-refs-duri.patch new file mode 100644 index 00000000000..7f63e905ff7 --- /dev/null +++ b/queue-4.19/btrfs-fix-processing-of-delayed-tree-block-refs-duri.patch @@ -0,0 +1,204 @@ +From 2b68dba09f0be1b11caf659068373b371a65cf65 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 11 Oct 2022 13:16:52 +0100 +Subject: btrfs: fix processing of delayed tree block refs during backref + walking + +From: Filipe Manana + +[ Upstream commit 943553ef9b51db303ab2b955c1025261abfdf6fb ] + +During backref walking, when processing a delayed reference with a type of +BTRFS_TREE_BLOCK_REF_KEY, we have two bugs there: + +1) We are accessing the delayed references extent_op, and its key, without + the protection of the delayed ref head's lock; + +2) If there's no extent op for the delayed ref head, we end up with an + uninitialized key in the stack, variable 'tmp_op_key', and then pass + it to add_indirect_ref(), which adds the reference to the indirect + refs rb tree. + + This is wrong, because indirect references should have a NULL key + when we don't have access to the key, and in that case they should be + added to the indirect_missing_keys rb tree and not to the indirect rb + tree. + + This means that if have BTRFS_TREE_BLOCK_REF_KEY delayed ref resulting + from freeing an extent buffer, therefore with a count of -1, it will + not cancel out the corresponding reference we have in the extent tree + (with a count of 1), since both references end up in different rb + trees. + + When using fiemap, where we often need to check if extents are shared + through shared subtrees resulting from snapshots, it means we can + incorrectly report an extent as shared when it's no longer shared. + However this is temporary because after the transaction is committed + the extent is no longer reported as shared, as running the delayed + reference results in deleting the tree block reference from the extent + tree. + + Outside the fiemap context, the result is unpredictable, as the key was + not initialized but it's used when navigating the rb trees to insert + and search for references (prelim_ref_compare()), and we expect all + references in the indirect rb tree to have valid keys. + +The following reproducer triggers the second bug: + + $ cat test.sh + #!/bin/bash + + DEV=/dev/sdj + MNT=/mnt/sdj + + mkfs.btrfs -f $DEV + mount -o compress $DEV $MNT + + # With a compressed 128M file we get a tree height of 2 (level 1 root). + xfs_io -f -c "pwrite -b 1M 0 128M" $MNT/foo + + btrfs subvolume snapshot $MNT $MNT/snap + + # Fiemap should output 0x2008 in the flags column. + # 0x2000 means shared extent + # 0x8 means encoded extent (because it's compressed) + echo + echo "fiemap after snapshot, range [120M, 120M + 128K):" + xfs_io -c "fiemap -v 120M 128K" $MNT/foo + echo + + # Overwrite one extent and fsync to flush delalloc and COW a new path + # in the snapshot's tree. + # + # After this we have a BTRFS_DROP_DELAYED_REF delayed ref of type + # BTRFS_TREE_BLOCK_REF_KEY with a count of -1 for every COWed extent + # buffer in the path. + # + # In the extent tree we have inline references of type + # BTRFS_TREE_BLOCK_REF_KEY, with a count of 1, for the same extent + # buffers, so they should cancel each other, and the extent buffers in + # the fs tree should no longer be considered as shared. + # + echo "Overwriting file range [120M, 120M + 128K)..." + xfs_io -c "pwrite -b 128K 120M 128K" $MNT/snap/foo + xfs_io -c "fsync" $MNT/snap/foo + + # Fiemap should output 0x8 in the flags column. The extent in the range + # [120M, 120M + 128K) is no longer shared, it's now exclusive to the fs + # tree. + echo + echo "fiemap after overwrite range [120M, 120M + 128K):" + xfs_io -c "fiemap -v 120M 128K" $MNT/foo + echo + + umount $MNT + +Running it before this patch: + + $ ./test.sh + (...) + wrote 134217728/134217728 bytes at offset 0 + 128 MiB, 128 ops; 0.1152 sec (1.085 GiB/sec and 1110.5809 ops/sec) + Create a snapshot of '/mnt/sdj' in '/mnt/sdj/snap' + + fiemap after snapshot, range [120M, 120M + 128K): + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [245760..246015]: 34304..34559 256 0x2008 + + Overwriting file range [120M, 120M + 128K)... + wrote 131072/131072 bytes at offset 125829120 + 128 KiB, 1 ops; 0.0001 sec (683.060 MiB/sec and 5464.4809 ops/sec) + + fiemap after overwrite range [120M, 120M + 128K): + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [245760..246015]: 34304..34559 256 0x2008 + +The extent in the range [120M, 120M + 128K) is still reported as shared +(0x2000 bit set) after overwriting that range and flushing delalloc, which +is not correct - an entire path was COWed in the snapshot's tree and the +extent is now only referenced by the original fs tree. + +Running it after this patch: + + $ ./test.sh + (...) + wrote 134217728/134217728 bytes at offset 0 + 128 MiB, 128 ops; 0.1198 sec (1.043 GiB/sec and 1068.2067 ops/sec) + Create a snapshot of '/mnt/sdj' in '/mnt/sdj/snap' + + fiemap after snapshot, range [120M, 120M + 128K): + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [245760..246015]: 34304..34559 256 0x2008 + + Overwriting file range [120M, 120M + 128K)... + wrote 131072/131072 bytes at offset 125829120 + 128 KiB, 1 ops; 0.0001 sec (694.444 MiB/sec and 5555.5556 ops/sec) + + fiemap after overwrite range [120M, 120M + 128K): + /mnt/sdj/foo: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [245760..246015]: 34304..34559 256 0x8 + +Now the extent is not reported as shared anymore. + +So fix this by passing a NULL key pointer to add_indirect_ref() when +processing a delayed reference for a tree block if there's no extent op +for our delayed ref head with a defined key. Also access the extent op +only after locking the delayed ref head's lock. + +The reproducer will be converted later to a test case for fstests. + +Fixes: 86d5f994425252 ("btrfs: convert prelimary reference tracking to use rbtrees") +Fixes: a6dbceafb915e8 ("btrfs: Remove unused op_key var from add_delayed_refs") +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/backref.c | 13 +++++++------ + 1 file changed, 7 insertions(+), 6 deletions(-) + +diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c +index 5e27e30fd887..781c725e6432 100644 +--- a/fs/btrfs/backref.c ++++ b/fs/btrfs/backref.c +@@ -761,16 +761,11 @@ static int add_delayed_refs(const struct btrfs_fs_info *fs_info, + struct share_check *sc) + { + struct btrfs_delayed_ref_node *node; +- struct btrfs_delayed_extent_op *extent_op = head->extent_op; + struct btrfs_key key; +- struct btrfs_key tmp_op_key; + struct rb_node *n; + int count; + int ret = 0; + +- if (extent_op && extent_op->update_key) +- btrfs_disk_key_to_cpu(&tmp_op_key, &extent_op->key); +- + spin_lock(&head->lock); + for (n = rb_first(&head->ref_tree); n; n = rb_next(n)) { + node = rb_entry(n, struct btrfs_delayed_ref_node, +@@ -797,10 +792,16 @@ static int add_delayed_refs(const struct btrfs_fs_info *fs_info, + case BTRFS_TREE_BLOCK_REF_KEY: { + /* NORMAL INDIRECT METADATA backref */ + struct btrfs_delayed_tree_ref *ref; ++ struct btrfs_key *key_ptr = NULL; ++ ++ if (head->extent_op && head->extent_op->update_key) { ++ btrfs_disk_key_to_cpu(&key, &head->extent_op->key); ++ key_ptr = &key; ++ } + + ref = btrfs_delayed_node_to_tree_ref(node); + ret = add_indirect_ref(fs_info, preftrees, ref->root, +- &tmp_op_key, ref->level + 1, ++ key_ptr, ref->level + 1, + node->bytenr, count, sc, + GFP_ATOMIC); + break; +-- +2.35.1 + diff --git a/queue-4.19/hid-magicmouse-do-not-set-btn_mouse-on-double-report.patch b/queue-4.19/hid-magicmouse-do-not-set-btn_mouse-on-double-report.patch new file mode 100644 index 00000000000..b15622c5d17 --- /dev/null +++ b/queue-4.19/hid-magicmouse-do-not-set-btn_mouse-on-double-report.patch @@ -0,0 +1,48 @@ +From 78401707e6d0f39bb343e3cfb1f516ff8dd19f71 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 9 Oct 2022 20:27:47 +0200 +Subject: HID: magicmouse: Do not set BTN_MOUSE on double report +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: José Expósito + +[ Upstream commit bb5f0c855dcfc893ae5ed90e4c646bde9e4498bf ] + +Under certain conditions the Magic Trackpad can group 2 reports in a +single packet. The packet is split and the raw event function is +invoked recursively for each part. + +However, after processing each part, the BTN_MOUSE status is updated, +sending multiple click events. [1] + +Return after processing double reports to avoid this issue. + +Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/811 # [1] +Fixes: a462230e16ac ("HID: magicmouse: enable Magic Trackpad support") +Reported-by: Nulo +Signed-off-by: José Expósito +Signed-off-by: Benjamin Tissoires +Link: https://lore.kernel.org/r/20221009182747.90730-1-jose.exposito89@gmail.com +Signed-off-by: Sasha Levin +--- + drivers/hid/hid-magicmouse.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c +index 8af62696f2ca..5604175c0661 100644 +--- a/drivers/hid/hid-magicmouse.c ++++ b/drivers/hid/hid-magicmouse.c +@@ -343,7 +343,7 @@ static int magicmouse_raw_event(struct hid_device *hdev, + magicmouse_raw_event(hdev, report, data + 2, data[1]); + magicmouse_raw_event(hdev, report, data + 2 + data[1], + size - 2 - data[1]); +- break; ++ return 0; + default: + return 0; + } +-- +2.35.1 + diff --git a/queue-4.19/iommu-vt-d-clean-up-si_domain-in-the-init_dmars-erro.patch b/queue-4.19/iommu-vt-d-clean-up-si_domain-in-the-init_dmars-erro.patch new file mode 100644 index 00000000000..87d8fb84cbe --- /dev/null +++ b/queue-4.19/iommu-vt-d-clean-up-si_domain-in-the-init_dmars-erro.patch @@ -0,0 +1,56 @@ +From 36ed2fc95fd6d4cbc1d11ac8bc4ec0cc8592a457 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 19 Oct 2022 08:44:47 +0800 +Subject: iommu/vt-d: Clean up si_domain in the init_dmars() error path + +From: Jerry Snitselaar + +[ Upstream commit 620bf9f981365c18cc2766c53d92bf8131c63f32 ] + +A splat from kmem_cache_destroy() was seen with a kernel prior to +commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool") +when there was a failure in init_dmars(), because the iommu_domain +cache still had objects. While the mempool code is now gone, there +still is a leak of the si_domain memory if init_dmars() fails. So +clean up si_domain in the init_dmars() error path. + +Cc: Lu Baolu +Cc: Joerg Roedel +Cc: Will Deacon +Cc: Robin Murphy +Fixes: 86080ccc223a ("iommu/vt-d: Allocate si_domain in init_dmars()") +Signed-off-by: Jerry Snitselaar +Link: https://lore.kernel.org/r/20221010144842.308890-1-jsnitsel@redhat.com +Signed-off-by: Lu Baolu +Signed-off-by: Joerg Roedel +Signed-off-by: Sasha Levin +--- + drivers/iommu/intel-iommu.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c +index dcb865d19309..1b25f5c0dfad 100644 +--- a/drivers/iommu/intel-iommu.c ++++ b/drivers/iommu/intel-iommu.c +@@ -2800,6 +2800,7 @@ static int __init si_domain_init(int hw) + + if (md_domain_init(si_domain, DEFAULT_DOMAIN_ADDRESS_WIDTH)) { + domain_exit(si_domain); ++ si_domain = NULL; + return -EFAULT; + } + +@@ -3502,6 +3503,10 @@ static int __init init_dmars(void) + disable_dmar_iommu(iommu); + free_dmar_iommu(iommu); + } ++ if (si_domain) { ++ domain_exit(si_domain); ++ si_domain = NULL; ++ } + + kfree(g_iommus); + +-- +2.35.1 + diff --git a/queue-4.19/net-atm-fix-proc_mpc_write-incorrect-return-value.patch b/queue-4.19/net-atm-fix-proc_mpc_write-incorrect-return-value.patch new file mode 100644 index 00000000000..f3190921158 --- /dev/null +++ b/queue-4.19/net-atm-fix-proc_mpc_write-incorrect-return-value.patch @@ -0,0 +1,41 @@ +From a58ab426b261fd6e2dd6e2410151fc9eec0e5ca4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 14 Oct 2022 10:05:40 +0800 +Subject: net/atm: fix proc_mpc_write incorrect return value + +From: Xiaobo Liu + +[ Upstream commit d8bde3bf7f82dac5fc68a62c2816793a12cafa2a ] + +Then the input contains '\0' or '\n', proc_mpc_write has read them, +so the return value needs +1. + +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Signed-off-by: Xiaobo Liu +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/atm/mpoa_proc.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/net/atm/mpoa_proc.c b/net/atm/mpoa_proc.c +index 46d6cd9a36ae..c4e9538ac144 100644 +--- a/net/atm/mpoa_proc.c ++++ b/net/atm/mpoa_proc.c +@@ -222,11 +222,12 @@ static ssize_t proc_mpc_write(struct file *file, const char __user *buff, + if (!page) + return -ENOMEM; + +- for (p = page, len = 0; len < nbytes; p++, len++) { ++ for (p = page, len = 0; len < nbytes; p++) { + if (get_user(*p, buff++)) { + free_page((unsigned long)page); + return -EFAULT; + } ++ len += 1; + if (*p == '\0' || *p == '\n') + break; + } +-- +2.35.1 + diff --git a/queue-4.19/net-hns-fix-possible-memory-leak-in-hnae_ae_register.patch b/queue-4.19/net-hns-fix-possible-memory-leak-in-hnae_ae_register.patch new file mode 100644 index 00000000000..c1b7094bf95 --- /dev/null +++ b/queue-4.19/net-hns-fix-possible-memory-leak-in-hnae_ae_register.patch @@ -0,0 +1,61 @@ +From bd2ba49b9b0e18f0c3ac7b8af303a2bd8be2a3bd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 18 Oct 2022 20:24:51 +0800 +Subject: net: hns: fix possible memory leak in hnae_ae_register() + +From: Yang Yingliang + +[ Upstream commit ff2f5ec5d009844ec28f171123f9e58750cef4bf ] + +Inject fault while probing module, if device_register() fails, +but the refcount of kobject is not decreased to 0, the name +allocated in dev_set_name() is leaked. Fix this by calling +put_device(), so that name can be freed in callback function +kobject_cleanup(). + +unreferenced object 0xffff00c01aba2100 (size 128): + comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) + hex dump (first 32 bytes): + 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + backtrace: + [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0 + [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 + [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390 + [<000000006c0ffb13>] kvasprintf+0x8c/0x118 + [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8 + [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 + [<000000000b87affc>] dev_set_name+0x7c/0xa0 + [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] + [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] + [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf] + +Fixes: 6fe6611ff275 ("net: add Hisilicon Network Subsystem hnae framework support") +Signed-off-by: Yang Yingliang +Reviewed-by: Leon Romanovsky +Link: https://lore.kernel.org/r/20221018122451.1749171-1-yangyingliang@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/hisilicon/hns/hnae.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.c b/drivers/net/ethernet/hisilicon/hns/hnae.c +index b758b3e79337..38aa4b74a6ab 100644 +--- a/drivers/net/ethernet/hisilicon/hns/hnae.c ++++ b/drivers/net/ethernet/hisilicon/hns/hnae.c +@@ -423,8 +423,10 @@ int hnae_ae_register(struct hnae_ae_dev *hdev, struct module *owner) + hdev->cls_dev.release = hnae_release; + (void)dev_set_name(&hdev->cls_dev, "hnae%d", hdev->id); + ret = device_register(&hdev->cls_dev); +- if (ret) ++ if (ret) { ++ put_device(&hdev->cls_dev); + return ret; ++ } + + __module_get(THIS_MODULE); + +-- +2.35.1 + diff --git a/queue-4.19/net-sched-cake-fix-null-pointer-access-issue-when-ca.patch b/queue-4.19/net-sched-cake-fix-null-pointer-access-issue-when-ca.patch new file mode 100644 index 00000000000..d78ada9cb94 --- /dev/null +++ b/queue-4.19/net-sched-cake-fix-null-pointer-access-issue-when-ca.patch @@ -0,0 +1,86 @@ +From a51d8fbd4d59d01201759b63350cfcfb2f322e42 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 18 Oct 2022 14:31:59 +0800 +Subject: net: sched: cake: fix null pointer access issue when cake_init() + fails +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Zhengchao Shao + +[ Upstream commit 51f9a8921ceacd7bf0d3f47fa867a64988ba1dcb ] + +When the default qdisc is cake, if the qdisc of dev_queue fails to be +inited during mqprio_init(), cake_reset() is invoked to clear +resources. In this case, the tins is NULL, and it will cause gpf issue. + +The process is as follows: +qdisc_create_dflt() + cake_init() + q->tins = kvcalloc(...) --->failed, q->tins is NULL + ... + qdisc_put() + ... + cake_reset() + ... + cake_dequeue_one() + b = &q->tins[...] --->q->tins is NULL + +The following is the Call Trace information: +general protection fault, probably for non-canonical address +0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN +KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] +RIP: 0010:cake_dequeue_one+0xc9/0x3c0 +Call Trace: + +cake_reset+0xb1/0x140 +qdisc_reset+0xed/0x6f0 +qdisc_destroy+0x82/0x4c0 +qdisc_put+0x9e/0xb0 +qdisc_create_dflt+0x2c3/0x4a0 +mqprio_init+0xa71/0x1760 +qdisc_create+0x3eb/0x1000 +tc_modify_qdisc+0x408/0x1720 +rtnetlink_rcv_msg+0x38e/0xac0 +netlink_rcv_skb+0x12d/0x3a0 +netlink_unicast+0x4a2/0x740 +netlink_sendmsg+0x826/0xcc0 +sock_sendmsg+0xc5/0x100 +____sys_sendmsg+0x583/0x690 +___sys_sendmsg+0xe8/0x160 +__sys_sendmsg+0xbf/0x160 +do_syscall_64+0x35/0x80 +entry_SYSCALL_64_after_hwframe+0x46/0xb0 +RIP: 0033:0x7f89e5122d04 + + +Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") +Signed-off-by: Zhengchao Shao +Acked-by: Toke Høiland-Jørgensen +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/sched/sch_cake.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c +index 18c207b85d51..01a177cfa533 100644 +--- a/net/sched/sch_cake.c ++++ b/net/sched/sch_cake.c +@@ -2149,8 +2149,12 @@ static struct sk_buff *cake_dequeue(struct Qdisc *sch) + + static void cake_reset(struct Qdisc *sch) + { ++ struct cake_sched_data *q = qdisc_priv(sch); + u32 c; + ++ if (!q->tins) ++ return; ++ + for (c = 0; c < CAKE_MAX_TINS; c++) + cake_clear_tin(sch, c); + } +-- +2.35.1 + diff --git a/queue-4.19/series b/queue-4.19/series index 240c0b9f77a..ec62266a5c9 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -8,3 +8,13 @@ kvm-arm64-vgic-fix-exit-condition-in-scan_its_table.patch media-venus-dec-handle-the-case-where-find_format-fails.patch arm64-errata-remove-aes-hwcap-for-compat-tasks.patch r8152-add-pid-for-the-lenovo-onelink-dock.patch +btrfs-fix-processing-of-delayed-data-refs-during-bac.patch +btrfs-fix-processing-of-delayed-tree-block-refs-duri.patch +acpi-extlog-handle-multiple-records.patch +tipc-fix-recognition-of-trial-period.patch +tipc-fix-an-information-leak-in-tipc_topsrv_kern_sub.patch +hid-magicmouse-do-not-set-btn_mouse-on-double-report.patch +net-atm-fix-proc_mpc_write-incorrect-return-value.patch +net-sched-cake-fix-null-pointer-access-issue-when-ca.patch +net-hns-fix-possible-memory-leak-in-hnae_ae_register.patch +iommu-vt-d-clean-up-si_domain-in-the-init_dmars-erro.patch diff --git a/queue-4.19/tipc-fix-an-information-leak-in-tipc_topsrv_kern_sub.patch b/queue-4.19/tipc-fix-an-information-leak-in-tipc_topsrv_kern_sub.patch new file mode 100644 index 00000000000..ded331e1d11 --- /dev/null +++ b/queue-4.19/tipc-fix-an-information-leak-in-tipc_topsrv_kern_sub.patch @@ -0,0 +1,87 @@ +From d5a3b88b6064cad26f6b8d12c4a23f58ab38d732 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 12 Oct 2022 17:25:14 +0200 +Subject: tipc: fix an information leak in tipc_topsrv_kern_subscr + +From: Alexander Potapenko + +[ Upstream commit 777ecaabd614d47c482a5c9031579e66da13989a ] + +Use a 8-byte write to initialize sub.usr_handle in +tipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized +when issuing setsockopt(..., SOL_TIPC, ...). +This resulted in an infoleak reported by KMSAN when the packet was +received: + + ===================================================== + BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169 + instrument_copy_to_user ./include/linux/instrumented.h:121 + copyout+0xbc/0x100 lib/iov_iter.c:169 + _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527 + copy_to_iter ./include/linux/uio.h:176 + simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513 + __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419 + skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527 + skb_copy_datagram_msg ./include/linux/skbuff.h:3903 + packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469 + ____sys_recvmsg+0x2c4/0x810 net/socket.c:? + ___sys_recvmsg+0x217/0x840 net/socket.c:2743 + __sys_recvmsg net/socket.c:2773 + __do_sys_recvmsg net/socket.c:2783 + __se_sys_recvmsg net/socket.c:2780 + __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780 + do_syscall_x64 arch/x86/entry/common.c:50 + do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 + entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 + + ... + + Uninit was stored to memory at: + tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156 + tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375 + tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579 + tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 + tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084 + tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201 + __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252 + __do_sys_setsockopt net/socket.c:2263 + __se_sys_setsockopt net/socket.c:2260 + __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260 + do_syscall_x64 arch/x86/entry/common.c:50 + do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 + entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 + + Local variable sub created at: + tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562 + tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 + + Bytes 84-87 of 88 are uninitialized + Memory access of size 88 starts at ffff88801ed57cd0 + Data copied to user address 0000000020000400 + ... + ===================================================== + +Signed-off-by: Alexander Potapenko +Fixes: 026321c6d056a5 ("tipc: rename tipc_server to tipc_topsrv") +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/tipc/topsrv.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/tipc/topsrv.c b/net/tipc/topsrv.c +index 1c4733153d74..ceb1e4c5aa2a 100644 +--- a/net/tipc/topsrv.c ++++ b/net/tipc/topsrv.c +@@ -575,7 +575,7 @@ bool tipc_topsrv_kern_subscr(struct net *net, u32 port, u32 type, u32 lower, + sub.seq.upper = upper; + sub.timeout = TIPC_WAIT_FOREVER; + sub.filter = filter; +- *(u32 *)&sub.usr_handle = port; ++ *(u64 *)&sub.usr_handle = (u64)port; + + con = tipc_conn_alloc(tipc_topsrv(net)); + if (IS_ERR(con)) +-- +2.35.1 + diff --git a/queue-4.19/tipc-fix-recognition-of-trial-period.patch b/queue-4.19/tipc-fix-recognition-of-trial-period.patch new file mode 100644 index 00000000000..3fd9ede258d --- /dev/null +++ b/queue-4.19/tipc-fix-recognition-of-trial-period.patch @@ -0,0 +1,39 @@ +From fed6c9e1a994a86242d0ee4d531b4841c6eb1049 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 10 Oct 2022 15:46:13 +1300 +Subject: tipc: Fix recognition of trial period + +From: Mark Tomlinson + +[ Upstream commit 28be7ca4fcfd69a2d52aaa331adbf9dbe91f9e6e ] + +The trial period exists until jiffies is after addr_trial_end. But as +jiffies will eventually overflow, just using time_after will eventually +give incorrect results. As the node address is set once the trial period +ends, this can be used to know that we are not in the trial period. + +Fixes: e415577f57f4 ("tipc: correct discovery message handling during address trial period") +Signed-off-by: Mark Tomlinson +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/tipc/discover.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/tipc/discover.c b/net/tipc/discover.c +index c138d68e8a69..0006c9f87199 100644 +--- a/net/tipc/discover.c ++++ b/net/tipc/discover.c +@@ -146,8 +146,8 @@ static bool tipc_disc_addr_trial_msg(struct tipc_discoverer *d, + { + struct net *net = d->net; + struct tipc_net *tn = tipc_net(net); +- bool trial = time_before(jiffies, tn->addr_trial_end); + u32 self = tipc_own_addr(net); ++ bool trial = time_before(jiffies, tn->addr_trial_end) && !self; + + if (mtyp == DSC_TRIAL_FAIL_MSG) { + if (!trial) +-- +2.35.1 +