--- /dev/null
+From 1354df83bc8bbbdda6910d2e6a93c6d74fa9dfc9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 10 Oct 2022 13:34:23 -0700
+Subject: ACPI: extlog: Handle multiple records
+
+From: Tony Luck <tony.luck@intel.com>
+
+[ 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 <tony.luck@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 <linux/ratelimit.h>
+ #include <linux/edac.h>
+ #include <linux/ras.h>
++#include <acpi/ghes.h>
+ #include <asm/cpu.h>
+ #include <asm/mce.h>
+
+@@ -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
+
--- /dev/null
+From 7f817248aeb10f399cce88c1d599c0ca1bbbf901 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Oct 2022 13:16:51 +0100
+Subject: btrfs: fix processing of delayed data refs during backref walking
+
+From: Filipe Manana <fdmanana@suse.com>
+
+[ 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 <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 2b68dba09f0be1b11caf659068373b371a65cf65 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Oct 2022 13:16:52 +0100
+Subject: btrfs: fix processing of delayed tree block refs during backref
+ walking
+
+From: Filipe Manana <fdmanana@suse.com>
+
+[ 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 <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 78401707e6d0f39bb343e3cfb1f516ff8dd19f71 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <jose.exposito89@gmail.com>
+
+[ 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 <git@nulo.in>
+Signed-off-by: José Expósito <jose.exposito89@gmail.com>
+Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Link: https://lore.kernel.org/r/20221009182747.90730-1-jose.exposito89@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 36ed2fc95fd6d4cbc1d11ac8bc4ec0cc8592a457 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <jsnitsel@redhat.com>
+
+[ 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 <baolu.lu@linux.intel.com>
+Cc: Joerg Roedel <joro@8bytes.org>
+Cc: Will Deacon <will@kernel.org>
+Cc: Robin Murphy <robin.murphy@arm.com>
+Fixes: 86080ccc223a ("iommu/vt-d: Allocate si_domain in init_dmars()")
+Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
+Link: https://lore.kernel.org/r/20221010144842.308890-1-jsnitsel@redhat.com
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From a58ab426b261fd6e2dd6e2410151fc9eec0e5ca4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 14 Oct 2022 10:05:40 +0800
+Subject: net/atm: fix proc_mpc_write incorrect return value
+
+From: Xiaobo Liu <cppcoffee@gmail.com>
+
+[ 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 <cppcoffee@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From bd2ba49b9b0e18f0c3ac7b8af303a2bd8be2a3bd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 18 Oct 2022 20:24:51 +0800
+Subject: net: hns: fix possible memory leak in hnae_ae_register()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ 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 <yangyingliang@huawei.com>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Link: https://lore.kernel.org/r/20221018122451.1749171-1-yangyingliang@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From a51d8fbd4d59d01201759b63350cfcfb2f322e42 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <shaozhengchao@huawei.com>
+
+[ 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:
+<TASK>
+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
+</TASK>
+
+Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
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
--- /dev/null
+From d5a3b88b6064cad26f6b8d12c4a23f58ab38d732 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 12 Oct 2022 17:25:14 +0200
+Subject: tipc: fix an information leak in tipc_topsrv_kern_subscr
+
+From: Alexander Potapenko <glider@google.com>
+
+[ 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 <glider@google.com>
+Fixes: 026321c6d056a5 ("tipc: rename tipc_server to tipc_topsrv")
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From fed6c9e1a994a86242d0ee4d531b4841c6eb1049 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 10 Oct 2022 15:46:13 +1300
+Subject: tipc: Fix recognition of trial period
+
+From: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
+
+[ 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 <mark.tomlinson@alliedtelesis.co.nz>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
