--- /dev/null
+From 7529542d0c4292ba884d384e7d43ffc32bc74db6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 9 Jun 2024 09:27:16 +0200
+Subject: ACPI: battery: create alarm sysfs attribute atomically
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Weißschuh <linux@weissschuh.net>
+
+[ Upstream commit a231eed10ed5a290129fda36ad7bcc263c53ff7d ]
+
+Let the power supply core register the attribute.
+This ensures that the attribute is created before the device is
+announced to userspace, avoid a race condition.
+
+Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/battery.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
+index a49a09e3de1b3..af78f76a28729 100644
+--- a/drivers/acpi/battery.c
++++ b/drivers/acpi/battery.c
+@@ -681,12 +681,18 @@ static ssize_t acpi_battery_alarm_store(struct device *dev,
+ return count;
+ }
+
+-static const struct device_attribute alarm_attr = {
++static struct device_attribute alarm_attr = {
+ .attr = {.name = "alarm", .mode = 0644},
+ .show = acpi_battery_alarm_show,
+ .store = acpi_battery_alarm_store,
+ };
+
++static struct attribute *acpi_battery_attrs[] = {
++ &alarm_attr.attr,
++ NULL
++};
++ATTRIBUTE_GROUPS(acpi_battery);
++
+ /*
+ * The Battery Hooking API
+ *
+@@ -823,7 +829,10 @@ static void __exit battery_hook_exit(void)
+
+ static int sysfs_add_battery(struct acpi_battery *battery)
+ {
+- struct power_supply_config psy_cfg = { .drv_data = battery, };
++ struct power_supply_config psy_cfg = {
++ .drv_data = battery,
++ .attr_grp = acpi_battery_groups,
++ };
+ bool full_cap_broken = false;
+
+ if (!ACPI_BATTERY_CAPACITY_VALID(battery->full_charge_capacity) &&
+@@ -868,7 +877,7 @@ static int sysfs_add_battery(struct acpi_battery *battery)
+ return result;
+ }
+ battery_hook_add_battery(battery);
+- return device_create_file(&battery->bat->dev, &alarm_attr);
++ return 0;
+ }
+
+ static void sysfs_remove_battery(struct acpi_battery *battery)
+@@ -879,7 +888,6 @@ static void sysfs_remove_battery(struct acpi_battery *battery)
+ return;
+ }
+ battery_hook_remove_battery(battery);
+- device_remove_file(&battery->bat->dev, &alarm_attr);
+ power_supply_unregister(battery->bat);
+ battery->bat = NULL;
+ mutex_unlock(&battery->sysfs_lock);
+--
+2.43.0
+
--- /dev/null
+From 630db6d885aa6d7906caddcc5fc11b309edccd19 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 9 Jun 2024 13:13:28 +0200
+Subject: ACPI: SBS: manage alarm sysfs attribute through psy core
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Weißschuh <linux@weissschuh.net>
+
+[ Upstream commit 6bad28cfc30988a845fb3f59a99f4b8a4ce8fe95 ]
+
+Let the power supply core register the attribute.
+
+This ensures that the attribute is created before the device is
+announced to userspace, avoiding a race condition.
+
+Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/sbs.c | 23 ++++++++++++-----------
+ 1 file changed, 12 insertions(+), 11 deletions(-)
+
+diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c
+index 6e88224f60f09..4aa55d8d43859 100644
+--- a/drivers/acpi/sbs.c
++++ b/drivers/acpi/sbs.c
+@@ -80,7 +80,6 @@ struct acpi_battery {
+ u16 spec;
+ u8 id;
+ u8 present:1;
+- u8 have_sysfs_alarm:1;
+ };
+
+ #define to_acpi_battery(x) power_supply_get_drvdata(x)
+@@ -465,12 +464,18 @@ static ssize_t acpi_battery_alarm_store(struct device *dev,
+ return count;
+ }
+
+-static const struct device_attribute alarm_attr = {
++static struct device_attribute alarm_attr = {
+ .attr = {.name = "alarm", .mode = 0644},
+ .show = acpi_battery_alarm_show,
+ .store = acpi_battery_alarm_store,
+ };
+
++static struct attribute *acpi_battery_attrs[] = {
++ &alarm_attr.attr,
++ NULL
++};
++ATTRIBUTE_GROUPS(acpi_battery);
++
+ /* --------------------------------------------------------------------------
+ Driver Interface
+ -------------------------------------------------------------------------- */
+@@ -512,7 +517,10 @@ static int acpi_battery_read(struct acpi_battery *battery)
+ static int acpi_battery_add(struct acpi_sbs *sbs, int id)
+ {
+ struct acpi_battery *battery = &sbs->battery[id];
+- struct power_supply_config psy_cfg = { .drv_data = battery, };
++ struct power_supply_config psy_cfg = {
++ .drv_data = battery,
++ .attr_grp = acpi_battery_groups,
++ };
+ int result;
+
+ battery->id = id;
+@@ -542,10 +550,6 @@ static int acpi_battery_add(struct acpi_sbs *sbs, int id)
+ goto end;
+ }
+
+- result = device_create_file(&battery->bat->dev, &alarm_attr);
+- if (result)
+- goto end;
+- battery->have_sysfs_alarm = 1;
+ end:
+ printk(KERN_INFO PREFIX "%s [%s]: Battery Slot [%s] (battery %s)\n",
+ ACPI_SBS_DEVICE_NAME, acpi_device_bid(sbs->device),
+@@ -557,11 +561,8 @@ static void acpi_battery_remove(struct acpi_sbs *sbs, int id)
+ {
+ struct acpi_battery *battery = &sbs->battery[id];
+
+- if (battery->bat) {
+- if (battery->have_sysfs_alarm)
+- device_remove_file(&battery->bat->dev, &alarm_attr);
++ if (battery->bat)
+ power_supply_unregister(battery->bat);
+- }
+ }
+
+ static int acpi_charger_add(struct acpi_sbs *sbs)
+--
+2.43.0
+
--- /dev/null
+From c8fc98d9537d61aff03150117fa260deb1809ff8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 31 Jul 2024 12:19:36 +0300
+Subject: Bluetooth: l2cap: always unlock channel in l2cap_conless_channel()
+
+From: Dmitry Antipov <dmantipov@yandex.ru>
+
+[ Upstream commit c531e63871c0b50c8c4e62c048535a08886fba3e ]
+
+Add missing call to 'l2cap_chan_unlock()' on receive error handling
+path in 'l2cap_conless_channel()'.
+
+Fixes: a24cce144b98 ("Bluetooth: Fix reference counting of global L2CAP channels")
+Reported-by: syzbot+45ac74737e866894acb0@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=45ac74737e866894acb0
+Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/l2cap_core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
+index 2eea802a9cb2f..874f12d93bfa2 100644
+--- a/net/bluetooth/l2cap_core.c
++++ b/net/bluetooth/l2cap_core.c
+@@ -7089,6 +7089,7 @@ static void l2cap_conless_channel(struct l2cap_conn *conn, __le16 psm,
+ bt_cb(skb)->l2cap.psm = psm;
+
+ if (!chan->ops->recv(chan, skb)) {
++ l2cap_chan_unlock(chan);
+ l2cap_chan_put(chan);
+ return;
+ }
+--
+2.43.0
+
--- /dev/null
+From 42d6c0f6df45296ace55dabcba0a85c0ac62f3f8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 3 Jul 2024 15:40:59 +0100
+Subject: btrfs: fix bitmap leak when loading free space cache on duplicate
+ entry
+
+From: Filipe Manana <fdmanana@suse.com>
+
+[ Upstream commit 320d8dc612660da84c3b70a28658bb38069e5a9a ]
+
+If we failed to link a free space entry because there's already a
+conflicting entry for the same offset, we free the free space entry but
+we don't free the associated bitmap that we had just allocated before.
+Fix that by freeing the bitmap before freeing the entry.
+
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/free-space-cache.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
+index 0cb93f73acb2d..af89fce57ff75 100644
+--- a/fs/btrfs/free-space-cache.c
++++ b/fs/btrfs/free-space-cache.c
+@@ -788,6 +788,7 @@ static int __load_free_space_cache(struct btrfs_root *root, struct inode *inode,
+ spin_unlock(&ctl->tree_lock);
+ btrfs_err(fs_info,
+ "Duplicate entries in free space cache, dumping");
++ kmem_cache_free(btrfs_free_space_bitmap_cachep, e->bitmap);
+ kmem_cache_free(btrfs_free_space_cachep, e);
+ goto free_cache;
+ }
+--
+2.43.0
+
--- /dev/null
+From ed4bd3c4c5e19b03947fe0f9625820b4b3998af6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 2 Jul 2024 21:02:30 +0200
+Subject: clocksource/drivers/sh_cmt: Address race condition for clock events
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
+
+[ Upstream commit db19d3aa77612983a02bd223b3f273f896b243cf ]
+
+There is a race condition in the CMT interrupt handler. In the interrupt
+handler the driver sets a driver private flag, FLAG_IRQCONTEXT. This
+flag is used to indicate any call to set_next_event() should not be
+directly propagated to the device, but instead cached. This is done as
+the interrupt handler itself reprograms the device when needed before it
+completes and this avoids this operation to take place twice.
+
+It is unclear why this design was chosen, my suspicion is to allow the
+struct clock_event_device.event_handler callback, which is called while
+the FLAG_IRQCONTEXT is set, can update the next event without having to
+write to the device twice.
+
+Unfortunately there is a race between when the FLAG_IRQCONTEXT flag is
+set and later cleared where the interrupt handler have already started to
+write the next event to the device. If set_next_event() is called in
+this window the value is only cached in the driver but not written. This
+leads to the board to misbehave, or worse lockup and produce a splat.
+
+ rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
+ rcu: 0-...!: (0 ticks this GP) idle=f5e0/0/0x0 softirq=519/519 fqs=0 (false positive?)
+ rcu: (detected by 1, t=6502 jiffies, g=-595, q=77 ncpus=2)
+ Sending NMI from CPU 1 to CPUs 0:
+ NMI backtrace for cpu 0
+ CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.10.0-rc5-arm64-renesas-00019-g74a6f86eaf1c-dirty #20
+ Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
+ pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+ pc : tick_check_broadcast_expired+0xc/0x40
+ lr : cpu_idle_poll.isra.0+0x8c/0x168
+ sp : ffff800081c63d70
+ x29: ffff800081c63d70 x28: 00000000580000c8 x27: 00000000bfee5610
+ x26: 0000000000000027 x25: 0000000000000000 x24: 0000000000000000
+ x23: ffff00007fbb9100 x22: ffff8000818f1008 x21: ffff8000800ef07c
+ x20: ffff800081c79ec0 x19: ffff800081c70c28 x18: 0000000000000000
+ x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffc2c717d8
+ x14: 0000000000000000 x13: ffff000009c18080 x12: ffff8000825f7fc0
+ x11: 0000000000000000 x10: ffff8000818f3cd4 x9 : 0000000000000028
+ x8 : ffff800081c79ec0 x7 : ffff800081c73000 x6 : 0000000000000000
+ x5 : 0000000000000000 x4 : ffff7ffffe286000 x3 : 0000000000000000
+ x2 : ffff7ffffe286000 x1 : ffff800082972900 x0 : ffff8000818f1008
+ Call trace:
+ tick_check_broadcast_expired+0xc/0x40
+ do_idle+0x9c/0x280
+ cpu_startup_entry+0x34/0x40
+ kernel_init+0x0/0x11c
+ do_one_initcall+0x0/0x260
+ __primary_switched+0x80/0x88
+ rcu: rcu_preempt kthread timer wakeup didn't happen for 6501 jiffies! g-595 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
+ rcu: Possible timer handling issue on cpu=0 timer-softirq=262
+ rcu: rcu_preempt kthread starved for 6502 jiffies! g-595 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
+ rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
+ rcu: RCU grace-period kthread stack dump:
+ task:rcu_preempt state:I stack:0 pid:15 tgid:15 ppid:2 flags:0x00000008
+ Call trace:
+ __switch_to+0xbc/0x100
+ __schedule+0x358/0xbe0
+ schedule+0x48/0x148
+ schedule_timeout+0xc4/0x138
+ rcu_gp_fqs_loop+0x12c/0x764
+ rcu_gp_kthread+0x208/0x298
+ kthread+0x10c/0x110
+ ret_from_fork+0x10/0x20
+
+The design have been part of the driver since it was first merged in
+early 2009. It becomes increasingly harder to trigger the issue the
+older kernel version one tries. It only takes a few boots on v6.10-rc5,
+while hundreds of boots are needed to trigger it on v5.10.
+
+Close the race condition by using the CMT channel lock for the two
+competing sections. The channel lock was added to the driver after its
+initial design.
+
+Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
+Link: https://lore.kernel.org/r/20240702190230.3825292-1-niklas.soderlund+renesas@ragnatech.se
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/clocksource/sh_cmt.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
+index b1ec79ddb7f2a..66789b3838d05 100644
+--- a/drivers/clocksource/sh_cmt.c
++++ b/drivers/clocksource/sh_cmt.c
+@@ -510,6 +510,7 @@ static void sh_cmt_set_next(struct sh_cmt_channel *ch, unsigned long delta)
+ static irqreturn_t sh_cmt_interrupt(int irq, void *dev_id)
+ {
+ struct sh_cmt_channel *ch = dev_id;
++ unsigned long flags;
+
+ /* clear flags */
+ sh_cmt_write_cmcsr(ch, sh_cmt_read_cmcsr(ch) &
+@@ -540,6 +541,8 @@ static irqreturn_t sh_cmt_interrupt(int irq, void *dev_id)
+
+ ch->flags &= ~FLAG_SKIPEVENT;
+
++ raw_spin_lock_irqsave(&ch->lock, flags);
++
+ if (ch->flags & FLAG_REPROGRAM) {
+ ch->flags &= ~FLAG_REPROGRAM;
+ sh_cmt_clock_event_program_verify(ch, 1);
+@@ -552,6 +555,8 @@ static irqreturn_t sh_cmt_interrupt(int irq, void *dev_id)
+
+ ch->flags &= ~FLAG_IRQCONTEXT;
+
++ raw_spin_unlock_irqrestore(&ch->lock, flags);
++
+ return IRQ_HANDLED;
+ }
+
+@@ -750,12 +755,18 @@ static int sh_cmt_clock_event_next(unsigned long delta,
+ struct clock_event_device *ced)
+ {
+ struct sh_cmt_channel *ch = ced_to_sh_cmt(ced);
++ unsigned long flags;
+
+ BUG_ON(!clockevent_state_oneshot(ced));
++
++ raw_spin_lock_irqsave(&ch->lock, flags);
++
+ if (likely(ch->flags & FLAG_IRQCONTEXT))
+ ch->next_match_value = delta - 1;
+ else
+- sh_cmt_set_next(ch, delta - 1);
++ __sh_cmt_set_next(ch, delta - 1);
++
++ raw_spin_unlock_irqrestore(&ch->lock, flags);
+
+ return 0;
+ }
+--
+2.43.0
+
--- /dev/null
+From f8ecfb611eb3b9ebd6e5c9008f82100fd664134c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 11 May 2024 15:48:02 +0800
+Subject: drm/amdgpu: Fix the null pointer dereference to ras_manager
+
+From: Ma Jun <Jun.Ma2@amd.com>
+
+[ Upstream commit 4c11d30c95576937c6c35e6f29884761f2dddb43 ]
+
+Check ras_manager before using it
+
+Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
+Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+index b6fc191c353a7..96aad6cc83b1e 100644
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+@@ -1053,12 +1053,15 @@ static void amdgpu_ras_interrupt_process_handler(struct work_struct *work)
+ int amdgpu_ras_interrupt_dispatch(struct amdgpu_device *adev,
+ struct ras_dispatch_if *info)
+ {
+- struct ras_manager *obj = amdgpu_ras_find_obj(adev, &info->head);
+- struct ras_ih_data *data = &obj->ih_data;
++ struct ras_manager *obj;
++ struct ras_ih_data *data;
+
++ obj = amdgpu_ras_find_obj(adev, &info->head);
+ if (!obj)
+ return -EINVAL;
+
++ data = &obj->ih_data;
++
+ if (data->inuse == 0)
+ return 0;
+
+--
+2.43.0
+
--- /dev/null
+From 0c92edbffbd1c0f42efcc279bcb32d54d33fe5cd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 30 Jul 2024 09:44:00 +0800
+Subject: irqchip/mbigen: Fix mbigen node address layout
+
+From: Yipeng Zou <zouyipeng@huawei.com>
+
+[ Upstream commit 6be6cba9c4371d27f78d900ccfe34bb880d9ee20 ]
+
+The mbigen interrupt chip has its per node registers located in a
+contiguous region of page sized chunks. The code maps them into virtual
+address space as a contiguous region and determines the address of a node
+by using the node ID as index.
+
+ mbigen chip
+ |-----------------|------------|--------------|
+ mgn_node_0 mgn_node_1 ... mgn_node_i
+|--------------| |--------------| |----------------------|
+[0x0000, 0x0x0FFF] [0x1000, 0x1FFF] [i*0x1000, (i+1)*0x1000 - 1]
+
+This works correctly up to 10 nodes, but then fails because the 11th's
+array slot is used for the MGN_CLEAR registers.
+
+ mbigen chip
+ |-----------|--------|--------|---------------|--------|
+mgn_node_0 mgn_node_1 ... mgn_clear_register ... mgn_node_i
+ |-----------------|
+ [0xA000, 0xAFFF]
+
+Skip the MGN_CLEAR register space when calculating the offset for node IDs
+greater than or equal to ten.
+
+Fixes: a6c2f87b8820 ("irqchip/mbigen: Implement the mbigen irq chip operation functions")
+Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lore.kernel.org/all/20240730014400.1751530-1-zouyipeng@huawei.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/irqchip/irq-mbigen.c | 20 ++++++++++++++++----
+ 1 file changed, 16 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
+index ff7627b577726..192950e9909b9 100644
+--- a/drivers/irqchip/irq-mbigen.c
++++ b/drivers/irqchip/irq-mbigen.c
+@@ -64,6 +64,20 @@ struct mbigen_device {
+ void __iomem *base;
+ };
+
++static inline unsigned int get_mbigen_node_offset(unsigned int nid)
++{
++ unsigned int offset = nid * MBIGEN_NODE_OFFSET;
++
++ /*
++ * To avoid touched clear register in unexpected way, we need to directly
++ * skip clear register when access to more than 10 mbigen nodes.
++ */
++ if (nid >= (REG_MBIGEN_CLEAR_OFFSET / MBIGEN_NODE_OFFSET))
++ offset += MBIGEN_NODE_OFFSET;
++
++ return offset;
++}
++
+ static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq)
+ {
+ unsigned int nid, pin;
+@@ -72,8 +86,7 @@ static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq)
+ nid = hwirq / IRQS_PER_MBIGEN_NODE + 1;
+ pin = hwirq % IRQS_PER_MBIGEN_NODE;
+
+- return pin * 4 + nid * MBIGEN_NODE_OFFSET
+- + REG_MBIGEN_VEC_OFFSET;
++ return pin * 4 + get_mbigen_node_offset(nid) + REG_MBIGEN_VEC_OFFSET;
+ }
+
+ static inline void get_mbigen_type_reg(irq_hw_number_t hwirq,
+@@ -88,8 +101,7 @@ static inline void get_mbigen_type_reg(irq_hw_number_t hwirq,
+ *mask = 1 << (irq_ofst % 32);
+ ofst = irq_ofst / 32 * 4;
+
+- *addr = ofst + nid * MBIGEN_NODE_OFFSET
+- + REG_MBIGEN_TYPE_OFFSET;
++ *addr = ofst + get_mbigen_node_offset(nid) + REG_MBIGEN_TYPE_OFFSET;
+ }
+
+ static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
+--
+2.43.0
+
--- /dev/null
+From d0a79948c1bef7a708aa94d79745092a9ca49234 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 May 2024 19:24:30 +0800
+Subject: jbd2: avoid memleak in jbd2_journal_write_metadata_buffer
+
+From: Kemeng Shi <shikemeng@huaweicloud.com>
+
+[ Upstream commit cc102aa24638b90e04364d64e4f58a1fa91a1976 ]
+
+The new_bh is from alloc_buffer_head, we should call free_buffer_head to
+free it in error case.
+
+Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
+Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://patch.msgid.link/20240514112438.1269037-2-shikemeng@huaweicloud.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/jbd2/journal.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
+index 81bd7b29a10b6..cfa21c29f3123 100644
+--- a/fs/jbd2/journal.c
++++ b/fs/jbd2/journal.c
+@@ -408,6 +408,7 @@ int jbd2_journal_write_metadata_buffer(transaction_t *transaction,
+ tmp = jbd2_alloc(bh_in->b_size, GFP_NOFS);
+ if (!tmp) {
+ brelse(new_bh);
++ free_buffer_head(new_bh);
+ return -ENOMEM;
+ }
+ jbd_lock_bh_state(bh_in);
+--
+2.43.0
+
--- /dev/null
+From 93edbb56f45b455e56f967ea0a354d18d2067203 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Jun 2024 21:22:51 +0800
+Subject: md/raid5: avoid BUG_ON() while continue reshape after reassembling
+
+From: Yu Kuai <yukuai3@huawei.com>
+
+[ Upstream commit 305a5170dc5cf3d395bb4c4e9239bca6d0b54b49 ]
+
+Currently, mdadm support --revert-reshape to abort the reshape while
+reassembling, as the test 07revert-grow. However, following BUG_ON()
+can be triggerred by the test:
+
+kernel BUG at drivers/md/raid5.c:6278!
+invalid opcode: 0000 [#1] PREEMPT SMP PTI
+irq event stamp: 158985
+CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94
+RIP: 0010:reshape_request+0x3f1/0xe60
+Call Trace:
+ <TASK>
+ raid5_sync_request+0x43d/0x550
+ md_do_sync+0xb7a/0x2110
+ md_thread+0x294/0x2b0
+ kthread+0x147/0x1c0
+ ret_from_fork+0x59/0x70
+ ret_from_fork_asm+0x1a/0x30
+ </TASK>
+
+Root cause is that --revert-reshape update the raid_disks from 5 to 4,
+while reshape position is still set, and after reassembling the array,
+reshape position will be read from super block, then during reshape the
+checking of 'writepos' that is caculated by old reshape position will
+fail.
+
+Fix this panic the easy way first, by converting the BUG_ON() to
+WARN_ON(), and stop the reshape if checkings fail.
+
+Noted that mdadm must fix --revert-shape as well, and probably md/raid
+should enhance metadata validation as well, however this means
+reassemble will fail and there must be user tools to fix the wrong
+metadata.
+
+Signed-off-by: Yu Kuai <yukuai3@huawei.com>
+Signed-off-by: Song Liu <song@kernel.org>
+Link: https://lore.kernel.org/r/20240611132251.1967786-13-yukuai1@huaweicloud.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/md/raid5.c | 20 +++++++++++++-------
+ 1 file changed, 13 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
+index bba5e61cc1456..41556f5d4dcba 100644
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -5821,7 +5821,9 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk
+ safepos = conf->reshape_safe;
+ sector_div(safepos, data_disks);
+ if (mddev->reshape_backwards) {
+- BUG_ON(writepos < reshape_sectors);
++ if (WARN_ON(writepos < reshape_sectors))
++ return MaxSector;
++
+ writepos -= reshape_sectors;
+ readpos += reshape_sectors;
+ safepos += reshape_sectors;
+@@ -5839,14 +5841,18 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk
+ * to set 'stripe_addr' which is where we will write to.
+ */
+ if (mddev->reshape_backwards) {
+- BUG_ON(conf->reshape_progress == 0);
++ if (WARN_ON(conf->reshape_progress == 0))
++ return MaxSector;
++
+ stripe_addr = writepos;
+- BUG_ON((mddev->dev_sectors &
+- ~((sector_t)reshape_sectors - 1))
+- - reshape_sectors - stripe_addr
+- != sector_nr);
++ if (WARN_ON((mddev->dev_sectors &
++ ~((sector_t)reshape_sectors - 1)) -
++ reshape_sectors - stripe_addr != sector_nr))
++ return MaxSector;
+ } else {
+- BUG_ON(writepos != sector_nr + reshape_sectors);
++ if (WARN_ON(writepos != sector_nr + reshape_sectors))
++ return MaxSector;
++
+ stripe_addr = sector_nr;
+ }
+
+--
+2.43.0
+
--- /dev/null
+From 88cd9dbd85aadd3fc032c136de4a92ac80fd5b5a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 14 Apr 2024 19:00:40 +0200
+Subject: media: uvcvideo: Fix the bandwdith quirk on USB 3.x
+
+From: Michal Pecio <michal.pecio@gmail.com>
+
+[ Upstream commit 9e3d55fbd160b3ca376599a68b4cddfdc67d4153 ]
+
+The bandwidth fixup quirk doesn't know that SuperSpeed exists and has
+the same 8 service intervals per millisecond as High Speed, hence its
+calculations are wrong.
+
+Assume that all speeds from HS up use 8 intervals per millisecond.
+
+No further changes are needed, updated code has been confirmed to work
+with all speeds from FS to SS.
+
+Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
+Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Link: https://lore.kernel.org/r/20240414190040.2255a0bc@foxbook
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/usb/uvc/uvc_video.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
+index 43c9660b729e0..8a8271e23c63f 100644
+--- a/drivers/media/usb/uvc/uvc_video.c
++++ b/drivers/media/usb/uvc/uvc_video.c
+@@ -207,13 +207,13 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
+ /* Compute a bandwidth estimation by multiplying the frame
+ * size by the number of video frames per second, divide the
+ * result by the number of USB frames (or micro-frames for
+- * high-speed devices) per second and add the UVC header size
+- * (assumed to be 12 bytes long).
++ * high- and super-speed devices) per second and add the UVC
++ * header size (assumed to be 12 bytes long).
+ */
+ bandwidth = frame->wWidth * frame->wHeight / 8 * format->bpp;
+ bandwidth *= 10000000 / interval + 1;
+ bandwidth /= 1000;
+- if (stream->dev->udev->speed == USB_SPEED_HIGH)
++ if (stream->dev->udev->speed >= USB_SPEED_HIGH)
+ bandwidth /= 8;
+ bandwidth += 12;
+
+--
+2.43.0
+
--- /dev/null
+From 5eecce6f1d03308bd7df2e52f07bedcfea90f5f8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 23 Mar 2024 10:48:03 +0000
+Subject: media: uvcvideo: Ignore empty TS packets
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+[ Upstream commit 5cd7c25f6f0576073b3d03bc4cfb1e8ca63a1195 ]
+
+Some SunplusIT cameras took a borderline interpretation of the UVC 1.5
+standard, and fill the PTS and SCR fields with invalid data if the
+package does not contain data.
+
+"STC must be captured when the first video data of a video frame is put
+on the USB bus."
+
+Some SunplusIT devices send, e.g.,
+
+buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000
+buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000
+buffer: 0xa7755c00 len 000668 header:0x8c stc 73779dba sof 070c pts 7376d37a
+
+While the UVC specification meant that the first two packets shouldn't
+have had the SCR bit set in the header.
+
+This borderline/buggy interpretation has been implemented in a variety
+of devices, from directly SunplusIT and from other OEMs that rebrand
+SunplusIT products. So quirking based on VID:PID will be problematic.
+
+All the affected modules have the following extension unit:
+VideoControl Interface Descriptor:
+ guidExtensionCode {82066163-7050-ab49-b8cc-b3855e8d221d}
+
+But the vendor plans to use that GUID in the future and fix the bug,
+this means that we should use heuristic to figure out the broken
+packets.
+
+This patch takes care of this.
+
+lsusb of one of the affected cameras:
+
+Bus 001 Device 003: ID 1bcf:2a01 Sunplus Innovation Technology Inc.
+Device Descriptor:
+ bLength 18
+ bDescriptorType 1
+ bcdUSB 2.01
+ bDeviceClass 239 Miscellaneous Device
+ bDeviceSubClass 2 ?
+ bDeviceProtocol 1 Interface Association
+ bMaxPacketSize0 64
+ idVendor 0x1bcf Sunplus Innovation Technology Inc.
+ idProduct 0x2a01
+ bcdDevice 0.02
+ iManufacturer 1 SunplusIT Inc
+ iProduct 2 HanChen Wise Camera
+ iSerial 3 01.00.00
+ bNumConfigurations 1
+
+Tested-by: HungNien Chen <hn.chen@sunplusit.com>
+Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Reviewed-by: Tomasz Figa <tfiga@chromium.org>
+Link: https://lore.kernel.org/r/20240323-resend-hwtimestamp-v10-2-b08e590d97c7@chromium.org
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/usb/uvc/uvc_video.c | 31 ++++++++++++++++++++++++++++++-
+ 1 file changed, 30 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
+index 6dff8e2fadbac..43c9660b729e0 100644
+--- a/drivers/media/usb/uvc/uvc_video.c
++++ b/drivers/media/usb/uvc/uvc_video.c
+@@ -468,6 +468,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
+ ktime_t time;
+ u16 host_sof;
+ u16 dev_sof;
++ u32 dev_stc;
+
+ switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
+ case UVC_STREAM_PTS | UVC_STREAM_SCR:
+@@ -512,6 +513,34 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
+ if (dev_sof == stream->clock.last_sof)
+ return;
+
++ dev_stc = get_unaligned_le32(&data[header_size - 6]);
++
++ /*
++ * STC (Source Time Clock) is the clock used by the camera. The UVC 1.5
++ * standard states that it "must be captured when the first video data
++ * of a video frame is put on the USB bus". This is generally understood
++ * as requiring devices to clear the payload header's SCR bit before
++ * the first packet containing video data.
++ *
++ * Most vendors follow that interpretation, but some (namely SunplusIT
++ * on some devices) always set the `UVC_STREAM_SCR` bit, fill the SCR
++ * field with 0's,and expect that the driver only processes the SCR if
++ * there is data in the packet.
++ *
++ * Ignore all the hardware timestamp information if we haven't received
++ * any data for this frame yet, the packet contains no data, and both
++ * STC and SOF are zero. This heuristics should be safe on compliant
++ * devices. This should be safe with compliant devices, as in the very
++ * unlikely case where a UVC 1.1 device would send timing information
++ * only before the first packet containing data, and both STC and SOF
++ * happen to be zero for a particular frame, we would only miss one
++ * clock sample from many and the clock recovery algorithm wouldn't
++ * suffer from this condition.
++ */
++ if (buf && buf->bytesused == 0 && len == header_size &&
++ dev_stc == 0 && dev_sof == 0)
++ return;
++
+ stream->clock.last_sof = dev_sof;
+
+ host_sof = usb_get_current_frame_number(stream->dev->udev);
+@@ -549,7 +578,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
+ spin_lock_irqsave(&stream->clock.lock, flags);
+
+ sample = &stream->clock.samples[stream->clock.head];
+- sample->dev_stc = get_unaligned_le32(&data[header_size - 6]);
++ sample->dev_stc = dev_stc;
+ sample->dev_sof = dev_sof;
+ sample->host_sof = host_sof;
+ sample->host_time = time;
+--
+2.43.0
+
--- /dev/null
+From f92d674e49b0b724dd1f0d5c52c29c70ea816d6c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 7 Aug 2024 10:09:56 +0200
+Subject: net: fec: Stop PPS on driver remove
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Csókás, Bence <csokas.bence@prolan.hu>
+
+[ Upstream commit 8fee6d5ad5fa18c270eedb2a2cdf58dbadefb94b ]
+
+PPS was not stopped in `fec_ptp_stop()`, called when
+the adapter was removed. Consequentially, you couldn't
+safely reload the driver with the PPS signal on.
+
+Fixes: 32cba57ba74b ("net: fec: introduce fec_ptp_stop and use in probe fail path")
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Link: https://lore.kernel.org/netdev/CAOMZO5BzcZR8PwKKwBssQq_wAGzVgf1ffwe_nhpQJjviTdxy-w@mail.gmail.com/T/#m01dcb810bfc451a492140f6797ca77443d0cb79f
+Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Reviewed-by: Frank Li <Frank.Li@nxp.com>
+Link: https://patch.msgid.link/20240807080956.2556602-1-csokas.bence@prolan.hu
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/freescale/fec_ptp.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c
+index 37b8ad29b5b30..c5af845b1b253 100644
+--- a/drivers/net/ethernet/freescale/fec_ptp.c
++++ b/drivers/net/ethernet/freescale/fec_ptp.c
+@@ -635,6 +635,9 @@ void fec_ptp_stop(struct platform_device *pdev)
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct fec_enet_private *fep = netdev_priv(ndev);
+
++ if (fep->pps_enable)
++ fec_ptp_enable_pps(fep, 0);
++
+ cancel_delayed_work_sync(&fep->time_keep);
+ if (fep->ptp_clock)
+ ptp_clock_unregister(fep->ptp_clock);
+--
+2.43.0
+
--- /dev/null
+From a7d3abde1a50db7b75376b4ded46ca86318dbb26 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 5 Aug 2024 08:58:21 +0000
+Subject: net: linkwatch: use system_unbound_wq
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit 3e7917c0cdad835a5121520fc5686d954b7a61ab ]
+
+linkwatch_event() grabs possibly very contended RTNL mutex.
+
+system_wq is not suitable for such work.
+
+Inspired by many noisy syzbot reports.
+
+3 locks held by kworker/0:7/5266:
+ #0: ffff888015480948 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3206 [inline]
+ #0: ffff888015480948 ((wq_completion)events){+.+.}-{0:0}, at: process_scheduled_works+0x90a/0x1830 kernel/workqueue.c:3312
+ #1: ffffc90003f6fd00 ((linkwatch_work).work){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3207 [inline]
+ , at: process_scheduled_works+0x945/0x1830 kernel/workqueue.c:3312
+ #2: ffffffff8fa6f208 (rtnl_mutex){+.+.}-{3:3}, at: linkwatch_event+0xe/0x60 net/core/link_watch.c:276
+
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Link: https://patch.msgid.link/20240805085821.1616528-1-edumazet@google.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/core/link_watch.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/core/link_watch.c b/net/core/link_watch.c
+index 35b0e39030daf..a70b2adc47a16 100644
+--- a/net/core/link_watch.c
++++ b/net/core/link_watch.c
+@@ -130,9 +130,9 @@ static void linkwatch_schedule_work(int urgent)
+ * override the existing timer.
+ */
+ if (test_bit(LW_URGENT, &linkwatch_flags))
+- mod_delayed_work(system_wq, &linkwatch_work, 0);
++ mod_delayed_work(system_unbound_wq, &linkwatch_work, 0);
+ else
+- schedule_delayed_work(&linkwatch_work, delay);
++ queue_delayed_work(system_unbound_wq, &linkwatch_work, delay);
+ }
+
+
+--
+2.43.0
+
--- /dev/null
+From e507b12898c9ae49e96fe2cd4ced853cd4c8a6e8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 1 Aug 2024 15:55:12 +0200
+Subject: net: usb: qmi_wwan: fix memory leak for not ip packets
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Daniele Palmas <dnlplm@gmail.com>
+
+[ Upstream commit 7ab107544b777c3bd7feb9fe447367d8edd5b202 ]
+
+Free the unused skb when not ip packets arrive.
+
+Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support")
+Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
+Acked-by: Bjørn Mork <bjorn@mork.no>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/usb/qmi_wwan.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
+index 17aa52ed892b5..3e219cf4dd851 100644
+--- a/drivers/net/usb/qmi_wwan.c
++++ b/drivers/net/usb/qmi_wwan.c
+@@ -238,6 +238,7 @@ static int qmimux_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+ break;
+ default:
+ /* not ip - do not know what to do */
++ kfree_skb(skbn);
+ goto skip;
+ }
+
+--
+2.43.0
+
--- /dev/null
+From d8d6610de04e8cdbed88f2ec166e075fe583d010 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 24 Jun 2024 08:55:01 +0900
+Subject: PCI: Add Edimax Vendor ID to pci_ids.h
+
+From: FUJITA Tomonori <fujita.tomonori@gmail.com>
+
+[ Upstream commit eee5528890d54b22b46f833002355a5ee94c3bb4 ]
+
+Add the Edimax Vendor ID (0x1432) for an ethernet driver for Tehuti
+Networks TN40xx chips. This ID can be used for Realtek 8180 and Ralink
+rt28xx wireless drivers.
+
+Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
+Acked-by: Bjorn Helgaas <bhelgaas@google.com>
+Link: https://patch.msgid.link/20240623235507.108147-2-fujita.tomonori@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/pci_ids.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
+index d8b188643a875..bf8548fbdf558 100644
+--- a/include/linux/pci_ids.h
++++ b/include/linux/pci_ids.h
+@@ -2136,6 +2136,8 @@
+
+ #define PCI_VENDOR_ID_CHELSIO 0x1425
+
++#define PCI_VENDOR_ID_EDIMAX 0x1432
++
+ #define PCI_VENDOR_ID_ADLINK 0x144a
+
+ #define PCI_VENDOR_ID_SAMSUNG 0x144d
+--
+2.43.0
+
--- /dev/null
+From 757b6878c7ecca73a234070ac7643d1211ca55c7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 27 May 2024 21:20:16 +0200
+Subject: r8169: remove detection of chip version 11 (early RTL8168b)
+
+From: Heiner Kallweit <hkallweit1@gmail.com>
+
+[ Upstream commit 982300c115d229565d7af8e8b38aa1ee7bb1f5bd ]
+
+This early RTL8168b version was the first PCIe chip version, and it's
+quite quirky. Last sign of life is from more than 15 yrs ago.
+Let's remove detection of this chip version, we'll see whether anybody
+complains. If not, support for this chip version can be removed a few
+kernel versions later.
+
+Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
+Link: https://lore.kernel.org/r/875cdcf4-843c-420a-ad5d-417447b68572@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/realtek/r8169_main.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
+index 319f8d7a502da..32ea1d902a173 100644
+--- a/drivers/net/ethernet/realtek/r8169_main.c
++++ b/drivers/net/ethernet/realtek/r8169_main.c
+@@ -2185,7 +2185,9 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp)
+ /* 8168B family. */
+ { 0x7cf, 0x380, RTL_GIGA_MAC_VER_12 },
+ { 0x7c8, 0x380, RTL_GIGA_MAC_VER_17 },
+- { 0x7c8, 0x300, RTL_GIGA_MAC_VER_11 },
++ /* This one is very old and rare, let's see if anybody complains.
++ * { 0x7c8, 0x300, RTL_GIGA_MAC_VER_11 },
++ */
+
+ /* 8101 family. */
+ { 0x7c8, 0x448, RTL_GIGA_MAC_VER_39 },
+--
+2.43.0
+
--- /dev/null
+From 5927cb656c6d4596c33f66d45558be27285f1074 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Jun 2024 14:20:27 +0200
+Subject: s390/sclp: Prevent release of buffer in I/O
+
+From: Peter Oberparleiter <oberpar@linux.ibm.com>
+
+[ Upstream commit bf365071ea92b9579d5a272679b74052a5643e35 ]
+
+When a task waiting for completion of a Store Data operation is
+interrupted, an attempt is made to halt this operation. If this attempt
+fails due to a hardware or firmware problem, there is a chance that the
+SCLP facility might store data into buffers referenced by the original
+operation at a later time.
+
+Handle this situation by not releasing the referenced data buffers if
+the halt attempt fails. For current use cases, this might result in a
+leak of few pages of memory in case of a rare hardware/firmware
+malfunction.
+
+Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
+Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/s390/char/sclp_sd.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/s390/char/sclp_sd.c b/drivers/s390/char/sclp_sd.c
+index 1e244f78f1929..64581433c3349 100644
+--- a/drivers/s390/char/sclp_sd.c
++++ b/drivers/s390/char/sclp_sd.c
+@@ -319,8 +319,14 @@ static int sclp_sd_store_data(struct sclp_sd_data *result, u8 di)
+ &esize);
+ if (rc) {
+ /* Cancel running request if interrupted */
+- if (rc == -ERESTARTSYS)
+- sclp_sd_sync(page, SD_EQ_HALT, di, 0, 0, NULL, NULL);
++ if (rc == -ERESTARTSYS) {
++ if (sclp_sd_sync(page, SD_EQ_HALT, di, 0, 0, NULL, NULL)) {
++ pr_warn("Could not stop Store Data request - leaking at least %zu bytes\n",
++ (size_t)dsize * PAGE_SIZE);
++ data = NULL;
++ asce = 0;
++ }
++ }
+ vfree(data);
+ goto out;
+ }
+--
+2.43.0
+
--- /dev/null
+From f9ec8cd589cdc1b8df80f4ef97337f0092ad232d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 31 Jul 2024 16:46:24 -0700
+Subject: sctp: Fix null-ptr-deref in reuseport_add_sock().
+
+From: Kuniyuki Iwashima <kuniyu@amazon.com>
+
+[ Upstream commit 9ab0faa7f9ffe31296dbb9bbe6f76c72c14eea18 ]
+
+syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in
+reuseport_add_sock(). [0]
+
+The repro first creates a listener with SO_REUSEPORT. Then, it creates
+another listener on the same port and concurrently closes the first
+listener.
+
+The second listen() calls reuseport_add_sock() with the first listener as
+sk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently,
+but the close() does clear it by reuseport_detach_sock().
+
+The problem is SCTP does not properly synchronise reuseport_alloc(),
+reuseport_add_sock(), and reuseport_detach_sock().
+
+The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must
+provide synchronisation for sockets that are classified into the same
+reuseport group.
+
+Otherwise, such sockets form multiple identical reuseport groups, and
+all groups except one would be silently dead.
+
+ 1. Two sockets call listen() concurrently
+ 2. No socket in the same group found in sctp_ep_hashtable[]
+ 3. Two sockets call reuseport_alloc() and form two reuseport groups
+ 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives
+ incoming packets
+
+Also, the reported null-ptr-deref could occur.
+
+TCP/UDP guarantees that would not happen by holding the hash bucket lock.
+
+Let's apply the locking strategy to __sctp_hash_endpoint() and
+__sctp_unhash_endpoint().
+
+[0]:
+Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI
+KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
+CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
+RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350
+Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14
+RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202
+RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000
+RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012
+RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385
+R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0
+R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000
+FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+ DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ <TASK>
+ __sctp_hash_endpoint net/sctp/input.c:762 [inline]
+ sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790
+ sctp_listen_start net/sctp/socket.c:8570 [inline]
+ sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625
+ __sys_listen_socket net/socket.c:1883 [inline]
+ __sys_listen+0x1b7/0x230 net/socket.c:1894
+ __do_sys_listen net/socket.c:1902 [inline]
+ __se_sys_listen net/socket.c:1900 [inline]
+ __x64_sys_listen+0x5a/0x70 net/socket.c:1900
+ do_syscall_x64 arch/x86/entry/common.c:52 [inline]
+ do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+RIP: 0033:0x7f24e46039b9
+Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
+RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032
+RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9
+RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004
+RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0
+R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c
+R13: 00007f24e465a5dc R14: 0020000000000001 R15: 00007ffcced5f7d8
+ </TASK>
+Modules linked in:
+
+Fixes: 6ba845740267 ("sctp: process sk_reuseport in sctp_get_port_local")
+Reported-by: syzbot+e6979a5d2f10ecb700e4@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=e6979a5d2f10ecb700e4
+Tested-by: syzbot+e6979a5d2f10ecb700e4@syzkaller.appspotmail.com
+Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Acked-by: Xin Long <lucien.xin@gmail.com>
+Link: https://patch.msgid.link/20240731234624.94055-1-kuniyu@amazon.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sctp/input.c | 19 +++++++++++--------
+ 1 file changed, 11 insertions(+), 8 deletions(-)
+
+diff --git a/net/sctp/input.c b/net/sctp/input.c
+index 87a69335e5521..b1d3e342ac830 100644
+--- a/net/sctp/input.c
++++ b/net/sctp/input.c
+@@ -722,15 +722,19 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep)
+ struct sock *sk = ep->base.sk;
+ struct net *net = sock_net(sk);
+ struct sctp_hashbucket *head;
++ int err = 0;
+
+ ep->hashent = sctp_ep_hashfn(net, ep->base.bind_addr.port);
+ head = &sctp_ep_hashtable[ep->hashent];
+
++ write_lock(&head->lock);
+ if (sk->sk_reuseport) {
+ bool any = sctp_is_ep_boundall(sk);
+ struct sctp_endpoint *ep2;
+ struct list_head *list;
+- int cnt = 0, err = 1;
++ int cnt = 0;
++
++ err = 1;
+
+ list_for_each(list, &ep->base.bind_addr.address_list)
+ cnt++;
+@@ -748,24 +752,24 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep)
+ if (!err) {
+ err = reuseport_add_sock(sk, sk2, any);
+ if (err)
+- return err;
++ goto out;
+ break;
+ } else if (err < 0) {
+- return err;
++ goto out;
+ }
+ }
+
+ if (err) {
+ err = reuseport_alloc(sk, any);
+ if (err)
+- return err;
++ goto out;
+ }
+ }
+
+- write_lock(&head->lock);
+ hlist_add_head(&ep->node, &head->chain);
++out:
+ write_unlock(&head->lock);
+- return 0;
++ return err;
+ }
+
+ /* Add an endpoint to the hash. Local BH-safe. */
+@@ -790,10 +794,9 @@ static void __sctp_unhash_endpoint(struct sctp_endpoint *ep)
+
+ head = &sctp_ep_hashtable[ep->hashent];
+
++ write_lock(&head->lock);
+ if (rcu_access_pointer(sk->sk_reuseport_cb))
+ reuseport_detach_sock(sk);
+-
+- write_lock(&head->lock);
+ hlist_del_init(&ep->node);
+ write_unlock(&head->lock);
+ }
+--
+2.43.0
+
--- /dev/null
+From 4c43be7aea5317e6912fb617fbff13d842f5d2a0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 21 Dec 2021 16:40:30 -0500
+Subject: sctp: move hlist_node and hashent out of sctp_ep_common
+
+From: Xin Long <lucien.xin@gmail.com>
+
+[ Upstream commit 3d3b2f57d4447e6e9f4096ad01d0e4129f7bc7e9 ]
+
+Struct sctp_ep_common is included in both asoc and ep, but hlist_node
+and hashent are only needed by ep after asoc_hashtable was dropped by
+Commit b5eff7128366 ("sctp: drop the old assoc hashtable of sctp").
+
+So it is better to move hlist_node and hashent from sctp_ep_common to
+sctp_endpoint, and it saves some space for each asoc.
+
+Signed-off-by: Xin Long <lucien.xin@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Stable-dep-of: 9ab0faa7f9ff ("sctp: Fix null-ptr-deref in reuseport_add_sock().")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/sctp/sctp.h | 4 ++--
+ include/net/sctp/structs.h | 8 ++++----
+ net/sctp/input.c | 27 ++++++++++-----------------
+ net/sctp/proc.c | 10 ++++------
+ net/sctp/socket.c | 6 +++---
+ 5 files changed, 23 insertions(+), 32 deletions(-)
+
+diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
+index 35c108a6b8720..aa29695f4bd79 100644
+--- a/include/net/sctp/sctp.h
++++ b/include/net/sctp/sctp.h
+@@ -506,8 +506,8 @@ static inline int sctp_ep_hashfn(struct net *net, __u16 lport)
+ return (net_hash_mix(net) + lport) & (sctp_ep_hashsize - 1);
+ }
+
+-#define sctp_for_each_hentry(epb, head) \
+- hlist_for_each_entry(epb, head, node)
++#define sctp_for_each_hentry(ep, head) \
++ hlist_for_each_entry(ep, head, node)
+
+ /* Is a socket of this style? */
+ #define sctp_style(sk, style) __sctp_style((sk), (SCTP_SOCKET_##style))
+diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
+index 48cbf3352042f..146d46a44b439 100644
+--- a/include/net/sctp/structs.h
++++ b/include/net/sctp/structs.h
+@@ -1224,10 +1224,6 @@ enum sctp_endpoint_type {
+ */
+
+ struct sctp_ep_common {
+- /* Fields to help us manage our entries in the hash tables. */
+- struct hlist_node node;
+- int hashent;
+-
+ /* Runtime type information. What kind of endpoint is this? */
+ enum sctp_endpoint_type type;
+
+@@ -1279,6 +1275,10 @@ struct sctp_endpoint {
+ /* Common substructure for endpoint and association. */
+ struct sctp_ep_common base;
+
++ /* Fields to help us manage our entries in the hash tables. */
++ struct hlist_node node;
++ int hashent;
++
+ /* Associations: A list of current associations and mappings
+ * to the data consumers for each association. This
+ * may be in the form of a hash table or other
+diff --git a/net/sctp/input.c b/net/sctp/input.c
+index c306cb25f5246..87a69335e5521 100644
+--- a/net/sctp/input.c
++++ b/net/sctp/input.c
+@@ -722,23 +722,21 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep)
+ struct sock *sk = ep->base.sk;
+ struct net *net = sock_net(sk);
+ struct sctp_hashbucket *head;
+- struct sctp_ep_common *epb;
+
+- epb = &ep->base;
+- epb->hashent = sctp_ep_hashfn(net, epb->bind_addr.port);
+- head = &sctp_ep_hashtable[epb->hashent];
++ ep->hashent = sctp_ep_hashfn(net, ep->base.bind_addr.port);
++ head = &sctp_ep_hashtable[ep->hashent];
+
+ if (sk->sk_reuseport) {
+ bool any = sctp_is_ep_boundall(sk);
+- struct sctp_ep_common *epb2;
++ struct sctp_endpoint *ep2;
+ struct list_head *list;
+ int cnt = 0, err = 1;
+
+ list_for_each(list, &ep->base.bind_addr.address_list)
+ cnt++;
+
+- sctp_for_each_hentry(epb2, &head->chain) {
+- struct sock *sk2 = epb2->sk;
++ sctp_for_each_hentry(ep2, &head->chain) {
++ struct sock *sk2 = ep2->base.sk;
+
+ if (!net_eq(sock_net(sk2), net) || sk2 == sk ||
+ !uid_eq(sock_i_uid(sk2), sock_i_uid(sk)) ||
+@@ -765,7 +763,7 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep)
+ }
+
+ write_lock(&head->lock);
+- hlist_add_head(&epb->node, &head->chain);
++ hlist_add_head(&ep->node, &head->chain);
+ write_unlock(&head->lock);
+ return 0;
+ }
+@@ -787,19 +785,16 @@ static void __sctp_unhash_endpoint(struct sctp_endpoint *ep)
+ {
+ struct sock *sk = ep->base.sk;
+ struct sctp_hashbucket *head;
+- struct sctp_ep_common *epb;
+
+- epb = &ep->base;
++ ep->hashent = sctp_ep_hashfn(sock_net(sk), ep->base.bind_addr.port);
+
+- epb->hashent = sctp_ep_hashfn(sock_net(sk), epb->bind_addr.port);
+-
+- head = &sctp_ep_hashtable[epb->hashent];
++ head = &sctp_ep_hashtable[ep->hashent];
+
+ if (rcu_access_pointer(sk->sk_reuseport_cb))
+ reuseport_detach_sock(sk);
+
+ write_lock(&head->lock);
+- hlist_del_init(&epb->node);
++ hlist_del_init(&ep->node);
+ write_unlock(&head->lock);
+ }
+
+@@ -832,7 +827,6 @@ static struct sctp_endpoint *__sctp_rcv_lookup_endpoint(
+ const union sctp_addr *paddr)
+ {
+ struct sctp_hashbucket *head;
+- struct sctp_ep_common *epb;
+ struct sctp_endpoint *ep;
+ struct sock *sk;
+ __be16 lport;
+@@ -842,8 +836,7 @@ static struct sctp_endpoint *__sctp_rcv_lookup_endpoint(
+ hash = sctp_ep_hashfn(net, ntohs(lport));
+ head = &sctp_ep_hashtable[hash];
+ read_lock(&head->lock);
+- sctp_for_each_hentry(epb, &head->chain) {
+- ep = sctp_ep(epb);
++ sctp_for_each_hentry(ep, &head->chain) {
+ if (sctp_endpoint_is_match(ep, net, laddr))
+ goto hit;
+ }
+diff --git a/net/sctp/proc.c b/net/sctp/proc.c
+index 963b94517ec20..ec00ee75d59a6 100644
+--- a/net/sctp/proc.c
++++ b/net/sctp/proc.c
+@@ -161,7 +161,6 @@ static void *sctp_eps_seq_next(struct seq_file *seq, void *v, loff_t *pos)
+ static int sctp_eps_seq_show(struct seq_file *seq, void *v)
+ {
+ struct sctp_hashbucket *head;
+- struct sctp_ep_common *epb;
+ struct sctp_endpoint *ep;
+ struct sock *sk;
+ int hash = *(loff_t *)v;
+@@ -171,18 +170,17 @@ static int sctp_eps_seq_show(struct seq_file *seq, void *v)
+
+ head = &sctp_ep_hashtable[hash];
+ read_lock_bh(&head->lock);
+- sctp_for_each_hentry(epb, &head->chain) {
+- ep = sctp_ep(epb);
+- sk = epb->sk;
++ sctp_for_each_hentry(ep, &head->chain) {
++ sk = ep->base.sk;
+ if (!net_eq(sock_net(sk), seq_file_net(seq)))
+ continue;
+ seq_printf(seq, "%8pK %8pK %-3d %-3d %-4d %-5d %5u %5lu ", ep, sk,
+ sctp_sk(sk)->type, sk->sk_state, hash,
+- epb->bind_addr.port,
++ ep->base.bind_addr.port,
+ from_kuid_munged(seq_user_ns(seq), sock_i_uid(sk)),
+ sock_i_ino(sk));
+
+- sctp_seq_dump_local_addrs(seq, epb);
++ sctp_seq_dump_local_addrs(seq, &ep->base);
+ seq_printf(seq, "\n");
+ }
+ read_unlock_bh(&head->lock);
+diff --git a/net/sctp/socket.c b/net/sctp/socket.c
+index c188a0acfa594..614130ff6ba06 100644
+--- a/net/sctp/socket.c
++++ b/net/sctp/socket.c
+@@ -5365,14 +5365,14 @@ int sctp_for_each_endpoint(int (*cb)(struct sctp_endpoint *, void *),
+ void *p) {
+ int err = 0;
+ int hash = 0;
+- struct sctp_ep_common *epb;
++ struct sctp_endpoint *ep;
+ struct sctp_hashbucket *head;
+
+ for (head = sctp_ep_hashtable; hash < sctp_ep_hashsize;
+ hash++, head++) {
+ read_lock_bh(&head->lock);
+- sctp_for_each_hentry(epb, &head->chain) {
+- err = cb(sctp_ep(epb), p);
++ sctp_for_each_hentry(ep, &head->chain) {
++ err = cb(ep, p);
+ if (err)
+ break;
+ }
+--
+2.43.0
+
--- /dev/null
+From 7f8fa90142c79f17dc2955b27da899c110ceb183 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 5 Jun 2024 13:12:03 -0700
+Subject: selftests/bpf: Fix send_signal test with nested CONFIG_PARAVIRT
+
+From: Yonghong Song <yonghong.song@linux.dev>
+
+[ Upstream commit 7015843afcaf68c132784c89528dfddc0005e483 ]
+
+Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT
+configs. In this particular case, the base VM is AMD with 166 cpus, and I
+run selftests with regular qemu on top of that and indeed send_signal test
+failed. I also tried with an Intel box with 80 cpus and there is no issue.
+
+The main qemu command line includes:
+
+ -enable-kvm -smp 16 -cpu host
+
+The failure log looks like:
+
+ $ ./test_progs -t send_signal
+ [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225]
+ [ 48.503622] Modules linked in: bpf_testmod(O)
+ [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty #69
+ [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
+ [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290
+ [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb
+ [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246
+ [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0
+ [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000
+ [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000
+ [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280
+ [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
+ [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000
+ [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0
+ [ 48.537538] Call Trace:
+ [ 48.537538] <IRQ>
+ [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250
+ [ 48.539590] ? lockup_detector_update_enable+0x50/0x50
+ [ 48.539590] ? __hrtimer_run_queues+0xff/0x280
+ [ 48.542520] ? hrtimer_interrupt+0x103/0x230
+ [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140
+ [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90
+ [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
+ [ 48.547612] ? handle_softirqs+0x71/0x290
+ [ 48.547612] irq_exit_rcu+0x63/0x80
+ [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90
+ [ 48.552521] </IRQ>
+ [ 48.553529] <TASK>
+ [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20
+ [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260
+ [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74
+ [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282
+ [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620
+ [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00
+ [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000
+ [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000
+ [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00
+ [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260
+ [ 48.576523] __schedule+0x364/0xac0
+ [ 48.577535] schedule+0x2e/0x110
+ [ 48.578555] pipe_read+0x301/0x400
+ [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30
+ [ 48.579589] vfs_read+0x2b3/0x2f0
+ [ 48.579589] ksys_read+0x8b/0xc0
+ [ 48.583590] do_syscall_64+0x3d/0xc0
+ [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53
+ [ 48.586525] RIP: 0033:0x7f2f28703fa1
+ [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0
+ [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
+ [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1
+ [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006
+ [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000
+ [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
+ [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0
+ [ 48.605527] </TASK>
+
+In the test, two processes are communicating through pipe. Further debugging
+with strace found that the above splat is triggered as read() syscall could
+not receive the data even if the corresponding write() syscall in another
+process successfully wrote data into the pipe.
+
+The failed subtest is "send_signal_perf". The corresponding perf event has
+sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every
+overflow event will trigger a call to the BPF program. So I suspect this may
+overwhelm the system. So I increased the sample_period to 100,000 and the test
+passed. The sample_period 10,000 still has the test failed.
+
+In other parts of selftest, e.g., [1], sample_freq is used instead. So I
+decided to use sample_freq = 1,000 since the test can pass as well.
+
+ [1] https://lore.kernel.org/bpf/20240604070700.3032142-1-song@kernel.org/
+
+Reported-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Link: https://lore.kernel.org/bpf/20240605201203.2603846-1-yonghong.song@linux.dev
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/bpf/prog_tests/send_signal.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/tools/testing/selftests/bpf/prog_tests/send_signal.c b/tools/testing/selftests/bpf/prog_tests/send_signal.c
+index b607112c64e7a..281d097b4b76a 100644
+--- a/tools/testing/selftests/bpf/prog_tests/send_signal.c
++++ b/tools/testing/selftests/bpf/prog_tests/send_signal.c
+@@ -174,7 +174,8 @@ static void test_send_signal_tracepoint(void)
+ static void test_send_signal_perf(void)
+ {
+ struct perf_event_attr attr = {
+- .sample_period = 1,
++ .freq = 1,
++ .sample_freq = 1000,
+ .type = PERF_TYPE_SOFTWARE,
+ .config = PERF_COUNT_SW_CPU_CLOCK,
+ };
+--
+2.43.0
+
net-usb-sr9700-fix-uninitialized-variable-use-in-sr_mdio_read.patch
netfilter-ipset-add-list-flush-to-cancel_gc.patch
genirq-allow-irq_chip-registration-functions-to-take.patch
+irqchip-mbigen-fix-mbigen-node-address-layout.patch
+x86-mm-fix-pti_clone_pgtable-alignment-assumption.patch
+sctp-move-hlist_node-and-hashent-out-of-sctp_ep_comm.patch
+sctp-fix-null-ptr-deref-in-reuseport_add_sock.patch
+net-usb-qmi_wwan-fix-memory-leak-for-not-ip-packets.patch
+net-linkwatch-use-system_unbound_wq.patch
+bluetooth-l2cap-always-unlock-channel-in-l2cap_conle.patch
+net-fec-stop-pps-on-driver-remove.patch
+md-raid5-avoid-bug_on-while-continue-reshape-after-r.patch
+clocksource-drivers-sh_cmt-address-race-condition-fo.patch
+acpi-battery-create-alarm-sysfs-attribute-atomically.patch
+acpi-sbs-manage-alarm-sysfs-attribute-through-psy-co.patch
+r8169-remove-detection-of-chip-version-11-early-rtl8.patch
+selftests-bpf-fix-send_signal-test-with-nested-confi.patch
+pci-add-edimax-vendor-id-to-pci_ids.h.patch
+udf-prevent-integer-overflow-in-udf_bitmap_free_bloc.patch
+wifi-nl80211-don-t-give-key-data-to-userspace.patch
+btrfs-fix-bitmap-leak-when-loading-free-space-cache-.patch
+drm-amdgpu-fix-the-null-pointer-dereference-to-ras_m.patch
+media-uvcvideo-ignore-empty-ts-packets.patch
+media-uvcvideo-fix-the-bandwdith-quirk-on-usb-3.x.patch
+jbd2-avoid-memleak-in-jbd2_journal_write_metadata_bu.patch
+s390-sclp-prevent-release-of-buffer-in-i-o.patch
+sunrpc-fix-a-race-to-wake-a-sync-task.patch
--- /dev/null
+From 784c35ff0912f99e86a0ba006c469dfe10f6423e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 Jul 2024 10:49:33 -0400
+Subject: SUNRPC: Fix a race to wake a sync task
+
+From: Benjamin Coddington <bcodding@redhat.com>
+
+[ Upstream commit ed0172af5d6fc07d1b40ca82f5ca3979300369f7 ]
+
+We've observed NFS clients with sync tasks sleeping in __rpc_execute
+waiting on RPC_TASK_QUEUED that have not responded to a wake-up from
+rpc_make_runnable(). I suspect this problem usually goes unnoticed,
+because on a busy client the task will eventually be re-awoken by another
+task completion or xprt event. However, if the state manager is draining
+the slot table, a sync task missing a wake-up can result in a hung client.
+
+We've been able to prove that the waker in rpc_make_runnable() successfully
+calls wake_up_bit() (ie- there's no race to tk_runstate), but the
+wake_up_bit() call fails to wake the waiter. I suspect the waker is
+missing the load of the bit's wait_queue_head, so waitqueue_active() is
+false. There are some very helpful comments about this problem above
+wake_up_bit(), prepare_to_wait(), and waitqueue_active().
+
+Fix this by inserting smp_mb__after_atomic() before the wake_up_bit(),
+which pairs with prepare_to_wait() calling set_current_state().
+
+Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sunrpc/sched.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
+index a5c6a3d05741a..df83c59cde7fe 100644
+--- a/net/sunrpc/sched.c
++++ b/net/sunrpc/sched.c
+@@ -368,8 +368,10 @@ static void rpc_make_runnable(struct workqueue_struct *wq,
+ if (RPC_IS_ASYNC(task)) {
+ INIT_WORK(&task->u.tk_work, rpc_async_schedule);
+ queue_work(wq, &task->u.tk_work);
+- } else
++ } else {
++ smp_mb__after_atomic();
+ wake_up_bit(&task->tk_runstate, RPC_TASK_QUEUED);
++ }
+ }
+
+ /*
+--
+2.43.0
+
--- /dev/null
+From f8b488e244c7b68620228bbe7ed04e63087f90d3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Jun 2024 10:24:13 +0300
+Subject: udf: prevent integer overflow in udf_bitmap_free_blocks()
+
+From: Roman Smirnov <r.smirnov@omp.ru>
+
+[ Upstream commit 56e69e59751d20993f243fb7dd6991c4e522424c ]
+
+An overflow may occur if the function is called with the last
+block and an offset greater than zero. It is necessary to add
+a check to avoid this.
+
+Found by Linux Verification Center (linuxtesting.org) with Svace.
+
+[JK: Make test cover also unalloc table freeing]
+
+Link: https://patch.msgid.link/20240620072413.7448-1-r.smirnov@omp.ru
+Suggested-by: Jan Kara <jack@suse.com>
+Signed-off-by: Roman Smirnov <r.smirnov@omp.ru>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/udf/balloc.c | 36 +++++++++++++-----------------------
+ 1 file changed, 13 insertions(+), 23 deletions(-)
+
+diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
+index c4c18eeacb60c..aa73ab1b50a52 100644
+--- a/fs/udf/balloc.c
++++ b/fs/udf/balloc.c
+@@ -22,6 +22,7 @@
+ #include "udfdecl.h"
+
+ #include <linux/bitops.h>
++#include <linux/overflow.h>
+
+ #include "udf_i.h"
+ #include "udf_sb.h"
+@@ -144,7 +145,6 @@ static void udf_bitmap_free_blocks(struct super_block *sb,
+ {
+ struct udf_sb_info *sbi = UDF_SB(sb);
+ struct buffer_head *bh = NULL;
+- struct udf_part_map *partmap;
+ unsigned long block;
+ unsigned long block_group;
+ unsigned long bit;
+@@ -153,19 +153,9 @@ static void udf_bitmap_free_blocks(struct super_block *sb,
+ unsigned long overflow;
+
+ mutex_lock(&sbi->s_alloc_mutex);
+- partmap = &sbi->s_partmaps[bloc->partitionReferenceNum];
+- if (bloc->logicalBlockNum + count < count ||
+- (bloc->logicalBlockNum + count) > partmap->s_partition_len) {
+- udf_debug("%u < %d || %u + %u > %u\n",
+- bloc->logicalBlockNum, 0,
+- bloc->logicalBlockNum, count,
+- partmap->s_partition_len);
+- goto error_return;
+- }
+-
++ /* We make sure this cannot overflow when mounting the filesystem */
+ block = bloc->logicalBlockNum + offset +
+ (sizeof(struct spaceBitmapDesc) << 3);
+-
+ do {
+ overflow = 0;
+ block_group = block >> (sb->s_blocksize_bits + 3);
+@@ -395,7 +385,6 @@ static void udf_table_free_blocks(struct super_block *sb,
+ uint32_t count)
+ {
+ struct udf_sb_info *sbi = UDF_SB(sb);
+- struct udf_part_map *partmap;
+ uint32_t start, end;
+ uint32_t elen;
+ struct kernel_lb_addr eloc;
+@@ -404,16 +393,6 @@ static void udf_table_free_blocks(struct super_block *sb,
+ struct udf_inode_info *iinfo;
+
+ mutex_lock(&sbi->s_alloc_mutex);
+- partmap = &sbi->s_partmaps[bloc->partitionReferenceNum];
+- if (bloc->logicalBlockNum + count < count ||
+- (bloc->logicalBlockNum + count) > partmap->s_partition_len) {
+- udf_debug("%u < %d || %u + %u > %u\n",
+- bloc->logicalBlockNum, 0,
+- bloc->logicalBlockNum, count,
+- partmap->s_partition_len);
+- goto error_return;
+- }
+-
+ iinfo = UDF_I(table);
+ udf_add_free_space(sb, sbi->s_partition, count);
+
+@@ -688,6 +667,17 @@ void udf_free_blocks(struct super_block *sb, struct inode *inode,
+ {
+ uint16_t partition = bloc->partitionReferenceNum;
+ struct udf_part_map *map = &UDF_SB(sb)->s_partmaps[partition];
++ uint32_t blk;
++
++ if (check_add_overflow(bloc->logicalBlockNum, offset, &blk) ||
++ check_add_overflow(blk, count, &blk) ||
++ bloc->logicalBlockNum + count > map->s_partition_len) {
++ udf_debug("Invalid request to free blocks: (%d, %u), off %u, "
++ "len %u, partition len %u\n",
++ partition, bloc->logicalBlockNum, offset, count,
++ map->s_partition_len);
++ return;
++ }
+
+ if (map->s_partition_flags & UDF_PART_FLAG_UNALLOC_BITMAP) {
+ udf_bitmap_free_blocks(sb, map->s_uspace.s_bitmap,
+--
+2.43.0
+
--- /dev/null
+From 57f5178ba602e1b3c13cd92cdc6f8774d369caeb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 27 Jun 2024 10:44:11 +0200
+Subject: wifi: nl80211: don't give key data to userspace
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+[ Upstream commit a7e5793035792cc46a1a4b0a783655ffa897dfe9 ]
+
+When a key is requested by userspace, there's really no need
+to include the key data, the sequence counter is really what
+userspace needs in this case. The fact that it's included is
+just a historic quirk.
+
+Remove the key data.
+
+Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
+Link: https://patch.msgid.link/20240627104411.b6a4f097e4ea.I7e6cc976cb9e8a80ef25a3351330f313373b4578@changeid
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/wireless/nl80211.c | 10 ++--------
+ 1 file changed, 2 insertions(+), 8 deletions(-)
+
+diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
+index 0d15dd68565cb..e85e8f7b48f92 100644
+--- a/net/wireless/nl80211.c
++++ b/net/wireless/nl80211.c
+@@ -3723,10 +3723,7 @@ static void get_key_callback(void *c, struct key_params *params)
+ struct nlattr *key;
+ struct get_key_cookie *cookie = c;
+
+- if ((params->key &&
+- nla_put(cookie->msg, NL80211_ATTR_KEY_DATA,
+- params->key_len, params->key)) ||
+- (params->seq &&
++ if ((params->seq &&
+ nla_put(cookie->msg, NL80211_ATTR_KEY_SEQ,
+ params->seq_len, params->seq)) ||
+ (params->cipher &&
+@@ -3738,10 +3735,7 @@ static void get_key_callback(void *c, struct key_params *params)
+ if (!key)
+ goto nla_put_failure;
+
+- if ((params->key &&
+- nla_put(cookie->msg, NL80211_KEY_DATA,
+- params->key_len, params->key)) ||
+- (params->seq &&
++ if ((params->seq &&
+ nla_put(cookie->msg, NL80211_KEY_SEQ,
+ params->seq_len, params->seq)) ||
+ (params->cipher &&
+--
+2.43.0
+
--- /dev/null
+From c45e8f43bfa20bd6371f0a1aa60b5782da859b13 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 31 Jul 2024 18:31:05 +0200
+Subject: x86/mm: Fix pti_clone_pgtable() alignment assumption
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+[ Upstream commit 41e71dbb0e0a0fe214545fe64af031303a08524c ]
+
+Guenter reported dodgy crashes on an i386-nosmp build using GCC-11
+that had the form of endless traps until entry stack exhaust and then
+#DF from the stack guard.
+
+It turned out that pti_clone_pgtable() had alignment assumptions on
+the start address, notably it hard assumes start is PMD aligned. This
+is true on x86_64, but very much not true on i386.
+
+These assumptions can cause the end condition to malfunction, leading
+to a 'short' clone. Guess what happens when the user mapping has a
+short copy of the entry text?
+
+Use the correct increment form for addr to avoid alignment
+assumptions.
+
+Fixes: 16a3fe634f6a ("x86/mm/pti: Clone kernel-image on PTE level for 32 bit")
+Reported-by: Guenter Roeck <linux@roeck-us.net>
+Tested-by: Guenter Roeck <linux@roeck-us.net>
+Suggested-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Link: https://lkml.kernel.org/r/20240731163105.GG33588@noisy.programming.kicks-ass.net
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/mm/pti.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
+index 7f2140414440d..29eaf3cd9bbdb 100644
+--- a/arch/x86/mm/pti.c
++++ b/arch/x86/mm/pti.c
+@@ -375,14 +375,14 @@ pti_clone_pgtable(unsigned long start, unsigned long end,
+ */
+ *target_pmd = *pmd;
+
+- addr += PMD_SIZE;
++ addr = round_up(addr + 1, PMD_SIZE);
+
+ } else if (level == PTI_CLONE_PTE) {
+
+ /* Walk the page-table down to the pte level */
+ pte = pte_offset_kernel(pmd, addr);
+ if (pte_none(*pte)) {
+- addr += PAGE_SIZE;
++ addr = round_up(addr + 1, PAGE_SIZE);
+ continue;
+ }
+
+@@ -402,7 +402,7 @@ pti_clone_pgtable(unsigned long start, unsigned long end,
+ /* Clone the PTE */
+ *target_pte = *pte;
+
+- addr += PAGE_SIZE;
++ addr = round_up(addr + 1, PAGE_SIZE);
+
+ } else {
+ BUG();
+--
+2.43.0
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
