commit 77f85ccd3618f324d221f0faaed6d9cdc118c74a
Author: Greg Kroah-Hartman
Date: Thu Jan 2 10:34:26 2025 +0100
Linux 6.12.8
Link: https://lore.kernel.org/r/[email protected]
Tested-by: Ronald Warsow
Tested-by: Salvatore Bonaccorso
Tested-by: Florian Fainelli
Tested-by: Pavel Machek (CIP)
Tested-by: Shuah Khan
Tested-by: Takeshi Ogasawara
Tested-by: kernelci.org bot
Tested-by: Linux Kernel Functional Testing
Tested-by: Markus Reichelt
Tested-by: Harshit Mogalapalli
Tested-by: Ron Economos
Tested-by: Hardik Garg
Tested-by: Justin M. Forbes
Signed-off-by: Greg Kroah-Hartman
commit f3e6eaf033f44ad10a141f44f5cea766ad54c3dc
Author: Takashi Iwai
Date: Fri Dec 20 12:44:16 2024 +0100
ALSA: sh: Fix wrong argument order for copy_from_iter()
commit 66a0a2b0473c39ae85c44628d14e4366fdc0aa0d upstream.
Fix a brown paper bag bug I introduced at converting to the standard
iter helper; the arguments were wrongly passed and have to be
swapped.
Fixes: 9b5f8ee43e48 ("ALSA: sh: Use standard helper for buffer accesses")
Reported-by: kernel test robot
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
commit f59b81fe8df97f6de66a084c8e795f21fa69b8f8
Author: Takashi Iwai
Date: Sat Nov 30 10:00:08 2024 +0100
ALSA: ump: Shut up truncated string warning
commit ed990c07af70d286f5736021c6e25d8df6f2f7b0 upstream.
The recent change for the legacy substream name update brought a
compile warning for some compilers due to the nature of snprintf().
Use scnprintf() to shut up the warning since the truncation is
intentional.
Fixes: e29e504e7890 ("ALSA: ump: Indicate the inactive group in legacy substream names")
Reported-by: kernel test robot
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
commit f5c5661f02b5539d88aea8497f8d0835d165e945
Author: Chris Lu
Date: Mon Sep 23 16:47:05 2024 +0800
Bluetooth: btusb: mediatek: change the conditions for ISO interface
commit defc33b5541e0a7e45cc2d99d72fbe80a597afc5 upstream.
Change conditions for Bluetooth driver claiming and releasing usb
ISO interface for MediaTek ISO data transmission.
Signed-off-by: Chris Lu
Signed-off-by: Luiz Augusto von Dentz
Cc: Fedor Pchelkin
Signed-off-by: Greg Kroah-Hartman
commit cc569d791ab2a0de74f76e470515d25d24c9b84b
Author: Chris Lu
Date: Mon Sep 23 16:47:04 2024 +0800
Bluetooth: btusb: mediatek: add intf release flow when usb disconnect
commit 489304e67087abddc2666c5af0159cb95afdcf59 upstream.
MediaTek claim an special usb intr interface for ISO data transmission.
The interface need to be released before unregistering hci device when
usb disconnect. Removing BT usb dongle without properly releasing the
interface may cause Kernel panic while unregister hci device.
Signed-off-by: Chris Lu
Signed-off-by: Luiz Augusto von Dentz
Cc: Fedor Pchelkin
Signed-off-by: Greg Kroah-Hartman
commit 9da1cfc4f111b7e4ea3d7f388b16b17bb881795e
Author: Chris Lu
Date: Mon Sep 23 16:47:03 2024 +0800
Bluetooth: btusb: mediatek: add callback function in btusb_disconnect
commit cea1805f165cdd783dd21f26df957118cb8641b4 upstream.
Add disconnect callback function in btusb_disconnect which is reserved
for vendor specific usage before deregister hci in btusb_disconnect.
Signed-off-by: Chris Lu
Signed-off-by: Luiz Augusto von Dentz
Cc: Fedor Pchelkin
Signed-off-by: Greg Kroah-Hartman
commit b967b37cefdf7ae1b0d3dc26cce6bfd1e7faf315
Author: Chris Lu
Date: Mon Sep 23 16:47:02 2024 +0800
Bluetooth: btusb: mediatek: move Bluetooth power off command position
commit ad0c6f603bb0b07846fda484c59a176a8cd02838 upstream.
Move MediaTek Bluetooth power off command before releasing
usb ISO interface.
Signed-off-by: Chris Lu
Signed-off-by: Luiz Augusto von Dentz
Cc: Fedor Pchelkin
Signed-off-by: Greg Kroah-Hartman
commit d508e56270389b3a16f5b3cf247f4eb1bbad1578
Author: Boris Burkov
Date: Fri Dec 13 12:22:32 2024 -0800
btrfs: check folio mapping after unlock in relocate_one_folio()
commit 3e74859ee35edc33a022c3f3971df066ea0ca6b9 upstream.
When we call btrfs_read_folio() to bring a folio uptodate, we unlock the
folio. The result of that is that a different thread can modify the
mapping (like remove it with invalidate) before we call folio_lock().
This results in an invalid page and we need to try again.
In particular, if we are relocating concurrently with aborting a
transaction, this can result in a crash like the following:
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: 0000 [#1] SMP
CPU: 76 PID: 1411631 Comm: kworker/u322:5
Workqueue: events_unbound btrfs_reclaim_bgs_work
RIP: 0010:set_page_extent_mapped+0x20/0xb0
RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246
RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880
RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0
R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000
R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff
FS: 0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
? __die+0x78/0xc0
? page_fault_oops+0x2a8/0x3a0
? __switch_to+0x133/0x530
? wq_worker_running+0xa/0x40
? exc_page_fault+0x63/0x130
? asm_exc_page_fault+0x22/0x30
? set_page_extent_mapped+0x20/0xb0
relocate_file_extent_cluster+0x1a7/0x940
relocate_data_extent+0xaf/0x120
relocate_block_group+0x20f/0x480
btrfs_relocate_block_group+0x152/0x320
btrfs_relocate_chunk+0x3d/0x120
btrfs_reclaim_bgs_work+0x2ae/0x4e0
process_scheduled_works+0x184/0x370
worker_thread+0xc6/0x3e0
? blk_add_timer+0xb0/0xb0
kthread+0xae/0xe0
? flush_tlb_kernel_range+0x90/0x90
ret_from_fork+0x2f/0x40
? flush_tlb_kernel_range+0x90/0x90
ret_from_fork_asm+0x11/0x20
This occurs because cleanup_one_transaction() calls
destroy_delalloc_inodes() which calls invalidate_inode_pages2() which
takes the folio_lock before setting mapping to NULL. We fail to check
this, and subsequently call set_extent_mapping(), which assumes that
mapping != NULL (in fact it asserts that in debug mode)
Note that the "fixes" patch here is not the one that introduced the
race (the very first iteration of this code from 2009) but a more recent
change that made this particular crash happen in practice.
Fixes: e7f1326cc24e ("btrfs: set page extent mapped after read_folio in relocate_one_page")
CC: [email protected] # 6.1+
Reviewed-by: Qu Wenruo
Signed-off-by: Boris Burkov
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
commit dd8bbfe723778bfcb49256ac15c66eae966b8632
Author: Boris Burkov
Date: Fri Dec 13 12:33:22 2024 -0800
btrfs: check folio mapping after unlock in put_file_data()
commit 0fba7be1ca6df2881e68386e5575fe096f33c4ca upstream.
When we call btrfs_read_folio() we get an unlocked folio, so it is possible
for a different thread to concurrently modify folio->mapping. We must
check that this hasn't happened once we do have the lock.
CC: [email protected] # 6.12+
Reviewed-by: Qu Wenruo
Signed-off-by: Boris Burkov
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
commit c3a403d8ce36f5a809a492581de5ad17843e4701
Author: Filipe Manana
Date: Wed Dec 11 16:08:07 2024 +0000
btrfs: fix use-after-free when COWing tree bock and tracing is enabled
commit 44f52bbe96dfdbe4aca3818a2534520082a07040 upstream.
When a COWing a tree block, at btrfs_cow_block(), and we have the
tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled
(CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent
buffer while inside the tracepoint code. This is because in some paths
that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding
the last reference on the extent buffer @buf so btrfs_force_cow_block()
drops the last reference on the @buf extent buffer when it calls
free_extent_buffer_stale(buf), which schedules the release of the extent
buffer with RCU. This means that if we are on a kernel with preemption,
the current task may be preempted before calling trace_btrfs_cow_block()
and the extent buffer already released by the time trace_btrfs_cow_block()
is called, resulting in a use-after-free.
Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to
btrfs_force_cow_block() before the COWed extent buffer is freed.
This also has a side effect of invoking the tracepoint in the tree defrag
code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is
called there, but this is fine and it was actually missing there.
Reported-by: [email protected]
Link: https://lore.kernel.org/linux-btrfs/[email protected]/
CC: [email protected] # 5.4+
Reviewed-by: Qu Wenruo
Signed-off-by: Filipe Manana
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
commit dbebb0cc5139606e9c78ae674e033c35421486fc
Author: Qu Wenruo
Date: Wed Dec 18 17:00:56 2024 +1030
btrfs: sysfs: fix direct super block member reads
commit fca432e73db2bec0fdbfbf6d98d3ebcd5388a977 upstream.
The following sysfs entries are reading super block member directly,
which can have a different endian and cause wrong values:
- sys/fs/btrfs//nodesize
- sys/fs/btrfs//sectorsize
- sys/fs/btrfs//clone_alignment
Thankfully those values (nodesize and sectorsize) are always aligned
inside the btrfs_super_block, so it won't trigger unaligned read errors,
just endian problems.
Fix them by using the native cached members instead.
Fixes: df93589a1737 ("btrfs: export more from FS_INFO to sysfs")
CC: [email protected]
Reviewed-by: Naohiro Aota
Reviewed-by: Johannes Thumshirn
Signed-off-by: Qu Wenruo
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
commit b87c9b9ba05ba6e8e2ee9ecd29a8c930b35648ed
Author: Julian Sun
Date: Wed Dec 11 19:13:15 2024 +0800
btrfs: fix transaction atomicity bug when enabling simple quotas
commit f2363e6fcc7938c5f0f6ac066fad0dd247598b51 upstream.
Set squota incompat bit before committing the transaction that enables
the feature.
With the config CONFIG_BTRFS_ASSERT enabled, an assertion
failure occurs regarding the simple quota feature.
[5.596534] assertion failed: btrfs_fs_incompat(fs_info, SIMPLE_QUOTA), in fs/btrfs/qgroup.c:365
[5.597098] ------------[ cut here ]------------
[5.597371] kernel BUG at fs/btrfs/qgroup.c:365!
[5.597946] CPU: 1 UID: 0 PID: 268 Comm: mount Not tainted 6.13.0-rc2-00031-gf92f4749861b #146
[5.598450] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[5.599008] RIP: 0010:btrfs_read_qgroup_config+0x74d/0x7a0
[5.604303]
[5.605230] ? btrfs_read_qgroup_config+0x74d/0x7a0
[5.605538] ? exc_invalid_op+0x56/0x70
[5.605775] ? btrfs_read_qgroup_config+0x74d/0x7a0
[5.606066] ? asm_exc_invalid_op+0x1f/0x30
[5.606441] ? btrfs_read_qgroup_config+0x74d/0x7a0
[5.606741] ? btrfs_read_qgroup_config+0x74d/0x7a0
[5.607038] ? try_to_wake_up+0x317/0x760
[5.607286] open_ctree+0xd9c/0x1710
[5.607509] btrfs_get_tree+0x58a/0x7e0
[5.608002] vfs_get_tree+0x2e/0x100
[5.608224] fc_mount+0x16/0x60
[5.608420] btrfs_get_tree+0x2f8/0x7e0
[5.608897] vfs_get_tree+0x2e/0x100
[5.609121] path_mount+0x4c8/0xbc0
[5.609538] __x64_sys_mount+0x10d/0x150
The issue can be easily reproduced using the following reproducer:
root@q:linux# cat repro.sh
set -e
mkfs.btrfs -q -f /dev/sdb
mount /dev/sdb /mnt/btrfs
btrfs quota enable -s /mnt/btrfs
umount /mnt/btrfs
mount /dev/sdb /mnt/btrfs
The issue is that when enabling quotas, at btrfs_quota_enable(), we set
BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE at fs_info->qgroup_flags and persist
it in the quota root in the item with the key BTRFS_QGROUP_STATUS_KEY, but
we only set the incompat bit BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA after we
commit the transaction used to enable simple quotas.
This means that if after that transaction commit we unmount the filesystem
without starting and committing any other transaction, or we have a power
failure, the next time we mount the filesystem we will find the flag
BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE set in the item with the key
BTRFS_QGROUP_STATUS_KEY but we will not find the incompat bit
BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA set in the superblock, triggering an
assertion failure at:
btrfs_read_qgroup_config() -> qgroup_read_enable_gen()
To fix this issue, set the BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA flag
immediately after setting the BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE.
This ensures that both flags are flushed to disk within the same
transaction.
Fixes: 182940f4f4db ("btrfs: qgroup: add new quota mode for simple quotas")
CC: [email protected] # 6.6+
Reviewed-by: Filipe Manana
Signed-off-by: Julian Sun
Signed-off-by: Filipe Manana
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
commit 8faba508242b224fcab4ca54262f2d944d44a701
Author: Filipe Manana
Date: Mon Dec 9 12:54:14 2024 +0000
btrfs: fix swap file activation failure due to extents that used to be shared
commit 03018e5d8508254534511d40fb57bc150e6a87f2 upstream.
When activating a swap file, to determine if an extent is shared we use
can_nocow_extent(), which ends up at btrfs_cross_ref_exist(). That helper
is meant to be quick because it's used in the NOCOW write path, when
flushing delalloc and when doing a direct IO write, however it does return
some false positives, meaning it may indicate that an extent is shared
even if it's no longer the case. For the write path this is fine, we just
do a unnecessary COW operation instead of doing a more rigorous check
which would be too heavy (calling btrfs_is_data_extent_shared()).
However when activating a swap file, the false positives simply result
in a failure, which is confusing for users/applications. One particular
case where this happens is when a data extent only has 1 reference but
that reference is not inlined in the extent item located in the extent
tree - this happens when we create more than 33 references for an extent
and then delete those 33 references plus every other non-inline reference
except one. The function check_committed_ref() assumes that if the size
of an extent item doesn't match the size of struct btrfs_extent_item
plus the size of an inline reference (plus an owner reference in case
simple quotas are enabled), then the extent is shared - that is not the
case however, we can have a single reference but it's not inlined - the
reason we do this is to be fast and avoid inspecting non-inline references
which may be located in another leaf of the extent tree, slowing down
write paths.
The following test script reproduces the bug:
$ cat test.sh
#!/bin/bash
DEV=/dev/sdi
MNT=/mnt/sdi
NUM_CLONES=50
umount $DEV &> /dev/null
run_test()
{
local sync_after_add_reflinks=$1
local sync_after_remove_reflinks=$2
mkfs.btrfs -f $DEV > /dev/null
#mkfs.xfs -f $DEV > /dev/null
mount $DEV $MNT
touch $MNT/foo
chmod 0600 $MNT/foo
# On btrfs the file must be NOCOW.
chattr +C $MNT/foo &> /dev/null
xfs_io -s -c "pwrite -b 1M 0 1M" $MNT/foo
mkswap $MNT/foo
for ((i = 1; i <= $NUM_CLONES; i++)); do
touch $MNT/foo_clone_$i
chmod 0600 $MNT/foo_clone_$i
# On btrfs the file must be NOCOW.
chattr +C $MNT/foo_clone_$i &> /dev/null
cp --reflink=always $MNT/foo $MNT/foo_clone_$i
done
if [ $sync_after_add_reflinks -ne 0 ]; then
# Flush delayed refs and commit current transaction.
sync -f $MNT
fi
# Remove the original file and all clones except the last.
rm -f $MNT/foo
for ((i = 1; i < $NUM_CLONES; i++)); do
rm -f $MNT/foo_clone_$i
done
if [ $sync_after_remove_reflinks -ne 0 ]; then
# Flush delayed refs and commit current transaction.
sync -f $MNT
fi
# Now use the last clone as a swap file. It should work since
# its extent are not shared anymore.
swapon $MNT/foo_clone_${NUM_CLONES}
swapoff $MNT/foo_clone_${NUM_CLONES}
umount $MNT
}
echo -e "\nTest without sync after creating and removing clones"
run_test 0 0
echo -e "\nTest with sync after creating clones"
run_test 1 0
echo -e "\nTest with sync after removing clones"
run_test 0 1
echo -e "\nTest with sync after creating and removing clones"
run_test 1 1
Running the test:
$ ./test.sh
Test without sync after creating and removing clones
wrote 1048576/1048576 bytes at offset 0
1 MiB, 1 ops; 0.0017 sec (556.793 MiB/sec and 556.7929 ops/sec)
Setting up swapspace version 1, size = 1020 KiB (1044480 bytes)
no label, UUID=a6b9c29e-5ef4-4689-a8ac-bc199c750f02
swapon: /mnt/sdi/foo_clone_50: swapon failed: Invalid argument
swapoff: /mnt/sdi/foo_clone_50: swapoff failed: Invalid argument
Test with sync after creating clones
wrote 1048576/1048576 bytes at offset 0
1 MiB, 1 ops; 0.0036 sec (271.739 MiB/sec and 271.7391 ops/sec)
Setting up swapspace version 1, size = 1020 KiB (1044480 bytes)
no label, UUID=5e9008d6-1f7a-4948-a1b4-3f30aba20a33
swapon: /mnt/sdi/foo_clone_50: swapon failed: Invalid argument
swapoff: /mnt/sdi/foo_clone_50: swapoff failed: Invalid argument
Test with sync after removing clones
wrote 1048576/1048576 bytes at offset 0
1 MiB, 1 ops; 0.0103 sec (96.665 MiB/sec and 96.6651 ops/sec)
Setting up swapspace version 1, size = 1020 KiB (1044480 bytes)
no label, UUID=916c2740-fa9f-4385-9f06-29c3f89e4764
Test with sync after creating and removing clones
wrote 1048576/1048576 bytes at offset 0
1 MiB, 1 ops; 0.0031 sec (314.268 MiB/sec and 314.2678 ops/sec)
Setting up swapspace version 1, size = 1020 KiB (1044480 bytes)
no label, UUID=06aab1dd-4d90-49c0-bd9f-3a8db4e2f912
swapon: /mnt/sdi/foo_clone_50: swapon failed: Invalid argument
swapoff: /mnt/sdi/foo_clone_50: swapoff failed: Invalid argument
Fix this by reworking btrfs_swap_activate() to instead of using extent
maps and checking for shared extents with can_nocow_extent(), iterate
over the inode's file extent items and use the accurate
btrfs_is_data_extent_shared().
CC: [email protected] # 5.4+
Reviewed-by: Qu Wenruo
Signed-off-by: Filipe Manana
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
commit 9f372e86b9bd1914df58c8f6e30939b7a224c6b0
Author: Filipe Manana
Date: Mon Dec 9 16:43:44 2024 +0000
btrfs: avoid monopolizing a core when activating a swap file
commit 2c8507c63f5498d4ee4af404a8e44ceae4345056 upstream.
During swap activation we iterate over the extents of a file and we can
have many thousands of them, so we can end up in a busy loop monopolizing
a core. Avoid this by doing a voluntary reschedule after processing each
extent.
CC: [email protected] # 5.4+
Reviewed-by: Qu Wenruo
Signed-off-by: Filipe Manana
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
commit f6174bb982a831b96b8ebbd7c4aabe29d5ad97b7
Author: Filipe Manana
Date: Fri Nov 29 12:25:30 2024 +0000
btrfs: fix race with memory mapped writes when activating swap file
commit 0525064bb82e50d59543b62b9d41a606198a4a44 upstream.
When activating the swap file we flush all delalloc and wait for ordered
extent completion, so that we don't miss any delalloc and extents before
we check that the file's extent layout is usable for a swap file and
activate the swap file. We are called with the inode's VFS lock acquired,
so we won't race with buffered and direct IO writes, however we can still
race with memory mapped writes since they don't acquire the inode's VFS
lock. The race window is between flushing all delalloc and locking the
whole file's extent range, since memory mapped writes lock an extent range
with the length of a page.
Fix this by acquiring the inode's mmap lock before we flush delalloc.
CC: [email protected] # 5.4+
Reviewed-by: Qu Wenruo
Signed-off-by: Filipe Manana
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
commit f6279a98db132da0cfff18712a1b06478c32007f
Author: Dimitri Fedrau
Date: Mon Dec 9 11:46:15 2024 +0100
power: supply: gpio-charger: Fix set charge current limits
commit afc6e39e824ad0e44b2af50a97885caec8d213d1 upstream.
Fix set charge current limits for devices which allow to set the lowest
charge current limit to be greater zero. If requested charge current limit
is below lowest limit, the index equals current_limit_map_size which leads
to accessing memory beyond allocated memory.
Fixes: be2919d8355e ("power: supply: gpio-charger: add charge-current-limit feature")
Cc: [email protected]
Signed-off-by: Dimitri Fedrau
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel
Signed-off-by: Greg Kroah-Hartman
commit c110095013ad13d5e834e00569682b2936ebb483
Author: Thomas Weißschuh
Date: Sun Dec 8 15:59:28 2024 +0100
power: supply: cros_charge-control: hide start threshold on v2 cmd
commit c28dc9fc24f5fa802d44ef7620a511035bdd803e upstream.
ECs implementing the v2 command will not stop charging when the end
threshold is reached. Instead they will begin discharging until the
start threshold is reached, leading to permanent charge and discharge
cycles. This defeats the point of the charge control mechanism.
Avoid the issue by hiding the start threshold on v2 systems.
Instead on those systems program the EC with start == end which forces
the EC to reach and stay at that level.
v1 does not support thresholds and v3 works correctly,
at least judging from the code.
Reported-by: Thomas Koch
Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver")
Cc: [email protected]
Signed-off-by: Thomas Weißschuh
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel
Signed-off-by: Greg Kroah-Hartman
commit 5792ae1cb1b00ae91ce514d2ec94c2efd954e6ca
Author: Thomas Weißschuh
Date: Sun Dec 8 15:59:27 2024 +0100
power: supply: cros_charge-control: allow start_threshold == end_threshold
commit e65a1b7fad0e112573eea7d64d4ab4fc513b8695 upstream.
Allow setting the start and stop thresholds to the same value.
There is no reason to disallow it.
Suggested-by: Thomas Koch
Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver")
Cc: [email protected]
Signed-off-by: Thomas Weißschuh
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel
Signed-off-by: Greg Kroah-Hartman
commit 77e6c8adf8d66c5464ee8a85942823b4302e4942
Author: Thomas Weißschuh
Date: Sun Dec 8 15:59:26 2024 +0100
power: supply: cros_charge-control: add mutex for driver data
commit e5f84d1cf562f7b45e28d6e5f6490626f870f81c upstream.
Concurrent accesses through sysfs may lead to inconsistent state in the
priv data. Introduce a mutex to avoid this.
Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver")
Cc: [email protected]
Signed-off-by: Thomas Weißschuh
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sebastian Reichel
Signed-off-by: Greg Kroah-Hartman
commit 7182f93bb358a99eeb9087c645230d29491230a8
Author: Kan Liang
Date: Mon Dec 16 12:45:02 2024 -0800
perf/x86/intel/ds: Add PEBS format 6
commit b8c3a2502a205321fe66c356f4b70cabd8e1a5fc upstream.
The only difference between 5 and 6 is the new counters snapshotting
group, without the following counters snapshotting enabling patches,
it's impossible to utilize the feature in a PEBS record. It's safe to
share the same code path with format 5.
Add format 6, so the end user can at least utilize the legacy PEBS
features.
Fixes: a932aa0e868f ("perf/x86: Add Lunar Lake and Arrow Lake support")
Signed-off-by: Kan Liang
Signed-off-by: Peter Zijlstra (Intel)
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman
commit 2a9cbd6c9049abea2825b43eaa4da68b685452be
Author: Conor Dooley
Date: Wed Dec 18 12:07:42 2024 +0000
i2c: microchip-core: fix "ghost" detections
commit 49e1f0fd0d4cb03a16b8526c4e683e1958f71490 upstream.
Running i2c-detect currently produces an output akin to:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 08 -- 0a -- 0c -- 0e --
10: 10 -- 12 -- 14 -- 16 -- UU 19 -- 1b -- 1d -- 1f
20: -- 21 -- 23 -- 25 -- 27 -- 29 -- 2b -- 2d -- 2f
30: -- -- -- -- -- -- -- -- 38 -- 3a -- 3c -- 3e --
40: 40 -- 42 -- 44 -- 46 -- 48 -- 4a -- 4c -- 4e --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: 60 -- 62 -- 64 -- 66 -- 68 -- 6a -- 6c -- 6e --
70: 70 -- 72 -- 74 -- 76 --
This happens because for an i2c_msg with a len of 0 the driver will
mark the transmission of the message as a success once the START has
been sent, without waiting for the devices on the bus to respond with an
ACK/NAK. Since i2cdetect seems to run in a tight loop over all addresses
the NAK is treated as part of the next test for the next address.
Delete the fast path that marks a message as complete when idev->msg_len
is zero after sending a START/RESTART since this isn't a valid scenario.
CC: [email protected]
Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers")
Signed-off-by: Conor Dooley
Reviewed-by: Andi Shyti
Link: https://lore.kernel.org/r/20241218-outbid-encounter-b2e78b1cc707@spud
Signed-off-by: Andi Shyti
Signed-off-by: Greg Kroah-Hartman
commit bcfb9d856bd6bbd077484e57cd316d1079b42b76
Author: Carlos Song
Date: Wed Dec 18 12:42:38 2024 +0800
i2c: imx: add imx7d compatible string for applying erratum ERR007805
commit e0cec363197e41af870613e8e17b30bf0e3d41b5 upstream.
Compatible string "fsl,imx7d-i2c" is not exited at i2c-imx driver
compatible string table, at the result, "fsl,imx21-i2c" will be
matched, but it will cause erratum ERR007805 not be applied in fact.
So Add "fsl,imx7d-i2c" compatible string in i2c-imx driver to apply
the erratum ERR007805(https://www.nxp.com/docs/en/errata/IMX7DS_3N09P.pdf).
"
ERR007805 I2C: When the I2C clock speed is configured for 400 kHz,
the SCL low period violates the I2C spec of 1.3 uS min
Description: When the I2C module is programmed to operate at the
maximum clock speed of 400 kHz (as defined by the I2C spec), the SCL
clock low period violates the I2C spec of 1.3 uS min. The user must
reduce the clock speed to obtain the SCL low time to meet the 1.3us
I2C minimum required. This behavior means the SoC is not compliant
to the I2C spec at 400kHz.
Workaround: To meet the clock low period requirement in fast speed
mode, SCL must be configured to 384KHz or less.
"
"fsl,imx7d-i2c" already is documented in binding doc. This erratum
fix has been included in imx6_i2c_hwdata and it is the same in all
I.MX6/7/8, so just reuse it.
Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit")
Cc: [email protected] # v5.18+
Signed-off-by: Carlos Song
Signed-off-by: Haibo Chen
Reviewed-by: Frank Li
Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit")
Acked-by: Oleksij Rempel
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andi Shyti
Signed-off-by: Greg Kroah-Hartman
commit 5e44779d12bd3cd3930d4b7566edec2ea69972b7
Author: Kan Liang
Date: Mon Dec 16 08:02:52 2024 -0800
perf/x86/intel: Fix bitmask of OCR and FRONTEND events for LNC
commit aa5d2ca7c179c40669edb5e96d931bf9828dea3d upstream.
The released OCR and FRONTEND events utilized more bits on Lunar Lake
p-core. The corresponding mask in the extra_regs has to be extended to
unblock the extra bits.
Add a dedicated intel_lnc_extra_regs.
Fixes: a932aa0e868f ("perf/x86: Add Lunar Lake and Arrow Lake support")
Reported-by: Andi Kleen
Signed-off-by: Kan Liang
Signed-off-by: Peter Zijlstra (Intel)
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman
commit aed157301c659a48f5564cc4568cf0e5c8831af0
Author: Thomas Gleixner
Date: Sat Dec 14 12:50:18 2024 +0100
PCI/MSI: Handle lack of irqdomain gracefully
commit a60b990798eb17433d0283788280422b1bd94b18 upstream.
Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a
RISCV platform which does not provide PCI/MSI support:
WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32
__pci_enable_msix_range+0x30c/0x596
pci_msi_setup_msi_irqs+0x2c/0x32
pci_alloc_irq_vectors_affinity+0xb8/0xe2
RISCV uses hierarchical interrupt domains and correctly does not implement
the legacy fallback. The warning triggers from the legacy fallback stub.
That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent
domain is associated with the device or not. There is a check for MSI-X,
which has a legacy assumption. But that legacy fallback assumption is only
valid when legacy support is enabled, but otherwise the check should simply
return -ENOTSUPP.
Loongarch tripped over the same problem and blindly enabled legacy support
without implementing the legacy fallbacks. There are weak implementations
which return an error, so the problem was papered over.
Correct pci_msi_domain_supports() to evaluate the legacy mode and add
the missing supported check into the MSI enable path to complete it.
Fixes: d2a463b29741 ("PCI/MSI: Reject multi-MSI early")
Reported-by: Alexandre Ghiti
Signed-off-by: Thomas Gleixner
Tested-by: Alexandre Ghiti
Cc: [email protected]
Link: https://lore.kernel.org/all/87ed2a8ow5.ffs@tglx
Signed-off-by: Greg Kroah-Hartman
commit 1429ae7b7d4759a1e362456b8911c701bae655b4
Author: Li RongQing
Date: Wed Jun 19 19:18:01 2024 +0800
virt: tdx-guest: Just leak decrypted memory on unrecoverable errors
commit 27834971f616c5e154423c578fa95e0444444ce1 upstream.
In CoCo VMs it is possible for the untrusted host to cause
set_memory_decrypted() to fail such that an error is returned
and the resulting memory is shared. Callers need to take care
to handle these errors to avoid returning decrypted (shared)
memory to the page allocator, which could lead to functional
or security issues.
Leak the decrypted memory when set_memory_decrypted() fails,
and don't need to print an error since set_memory_decrypted()
will call WARN_ONCE().
Fixes: f4738f56d1dc ("virt: tdx-guest: Add Quote generation support using TSM_REPORTS")
Signed-off-by: Li RongQing
Signed-off-by: Dave Hansen
Signed-off-by: Ingo Molnar
Reviewed-by: Rick Edgecombe
Reviewed-by: Kirill A. Shutemov
Cc: [email protected]
Link: https://lore.kernel.org/all/20240619111801.25630-1-lirongqing%40baidu.com
Signed-off-by: Greg Kroah-Hartman
commit b939f108e86b76119428a6fa4e92491e09ac7867
Author: Xin Li (Intel)
Date: Wed Nov 13 09:59:34 2024 -0800
x86/fred: Clear WFE in missing-ENDBRANCH #CPs
commit dc81e556f2a017d681251ace21bf06c126d5a192 upstream.
An indirect branch instruction sets the CPU indirect branch tracker
(IBT) into WAIT_FOR_ENDBRANCH (WFE) state and WFE stays asserted
across the instruction boundary. When the decoder finds an
inappropriate instruction while WFE is set ENDBR, the CPU raises a #CP
fault.
For the "kernel IBT no ENDBR" selftest where #CPs are deliberately
triggered, the WFE state of the interrupted context needs to be
cleared to let execution continue. Otherwise when the CPU resumes
from the instruction that just caused the previous #CP, another
missing-ENDBRANCH #CP is raised and the CPU enters a dead loop.
This is not a problem with IDT because it doesn't preserve WFE and
IRET doesn't set WFE. But FRED provides space on the entry stack
(in an expanded CS area) to save and restore the WFE state, thus the
WFE state is no longer clobbered, so software must clear it.
Clear WFE to avoid dead looping in ibt_clear_fred_wfe() and the
!ibt_fatal code path when execution is allowed to continue.
Clobbering WFE in any other circumstance is a security-relevant bug.
[ dhansen: changelog rewording ]
Fixes: a5f6c2ace997 ("x86/shstk: Add user control-protection fault handler")
Signed-off-by: Xin Li (Intel)
Signed-off-by: Dave Hansen
Signed-off-by: Ingo Molnar
Acked-by: Dave Hansen
Cc: [email protected]
Link: https://lore.kernel.org/all/20241113175934.3897541-1-xin%40zytor.com
Signed-off-by: Greg Kroah-Hartman
commit a0d637675f2ba98743d0f649c3f7d1cc5cf12ef2
Author: Conor Dooley
Date: Wed Dec 18 12:07:40 2024 +0000
i2c: microchip-core: actually use repeated sends
commit 9a8f9320d67b27ddd7f1ee88d91820197a0e908f upstream.
At present, where repeated sends are intended to be used, the
i2c-microchip-core driver sends a stop followed by a start. Lots of i2c
devices must not malfunction in the face of this behaviour, because the
driver has operated like this for years! Try to keep track of whether or
not a repeated send is required, and suppress sending a stop in these
cases.
CC: [email protected]
Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers")
Signed-off-by: Conor Dooley
Reviewed-by: Andi Shyti
Link: https://lore.kernel.org/r/20241218-football-composure-e56df2461461@spud
Signed-off-by: Andi Shyti
Signed-off-by: Greg Kroah-Hartman
commit 8e8494c83cf73168118587e9567e4f7e50ce4fd8
Author: Pavel Begunkov
Date: Thu Dec 26 16:49:23 2024 +0000
io_uring/sqpoll: fix sqpoll error handling races
commit e33ac68e5e21ec1292490dfe061e75c0dbdd3bd4 upstream.
BUG: KASAN: slab-use-after-free in __lock_acquire+0x370b/0x4a10 kernel/locking/lockdep.c:5089
Call Trace:
...
_raw_spin_lock_irqsave+0x3d/0x60 kernel/locking/spinlock.c:162
class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]
try_to_wake_up+0xb5/0x23c0 kernel/sched/core.c:4205
io_sq_thread_park+0xac/0xe0 io_uring/sqpoll.c:55
io_sq_thread_finish+0x6b/0x310 io_uring/sqpoll.c:96
io_sq_offload_create+0x162/0x11d0 io_uring/sqpoll.c:497
io_uring_create io_uring/io_uring.c:3724 [inline]
io_uring_setup+0x1728/0x3230 io_uring/io_uring.c:3806
...
Kun Hu reports that the SQPOLL creating error path has UAF, which
happens if io_uring_alloc_task_context() fails and then io_sq_thread()
manages to run and complete before the rest of error handling code,
which means io_sq_thread_finish() is looking at already killed task.
Note that this is mostly theoretical, requiring fault injection on
the allocation side to trigger in practice.
Cc: [email protected]
Reported-by: Kun Hu
Signed-off-by: Pavel Begunkov
Link: https://lore.kernel.org/r/0f2f1aa5729332612bd01fe0f2f385fd1f06ce7c.1735231717.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
commit 4c0f79cbc42d48a00acc4d77586b38250a3d3178
Author: Tomas Glozar
Date: Wed Nov 27 14:41:30 2024 +0100
rtla/timerlat: Fix histogram ALL for zero samples
commit 6cc45f8c1f898570916044f606be9890d295e129 upstream.
rtla timerlat hist currently computers the minimum, maximum and average
latency even in cases when there are zero samples. This leads to
nonsensical values being calculated for maximum and minimum, and to
divide by zero for average.
A similar bug is fixed by 01b05fc0e5f3 ("rtla/timerlat: Fix histogram
report when a cpu count is 0") but the bug still remains for printing
the sum over all CPUs in timerlat_print_stats_all.
The issue can be reproduced with this command:
$ rtla timerlat hist -U -d 1s
Index
over:
count:
min:
avg:
max:
Floating point exception (core dumped)
(There are always no samples with -U unless the user workload is
created.)
Fix the bug by omitting max/min/avg when sample count is zero,
displaying a dash instead, just like we already do for the individual
CPUs. The logic is moved into a new function called
format_summary_value, which is used for both the individual CPUs
and for the overall summary.
Cc: [email protected]
Link: https://lore.kernel.org/[email protected]
Fixes: 1462501c7a8 ("rtla/timerlat: Add a summary for hist mode")
Signed-off-by: Tomas Glozar
Signed-off-by: Steven Rostedt (Google)
Signed-off-by: Greg Kroah-Hartman
commit 1cca920af19df5dd91254e5ff35e68e911683706
Author: Lizhi Xu
Date: Mon Dec 16 15:32:38 2024 +0800
tracing: Prevent bad count for tracing_cpumask_write
commit 98feccbf32cfdde8c722bc4587aaa60ee5ac33f0 upstream.
If a large count is provided, it will trigger a warning in bitmap_parse_user.
Also check zero for it.
Cc: [email protected]
Fixes: 9e01c1b74c953 ("cpumask: convert kernel trace functions")
Link: https://lore.kernel.org/[email protected]
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=0aecfd34fb878546f3fd
Tested-by: [email protected]
Signed-off-by: Lizhi Xu
Signed-off-by: Steven Rostedt (Google)
Signed-off-by: Greg Kroah-Hartman
commit a744146969a0ec8d949aad06889243ad97927a17
Author: Christian Göttsche
Date: Mon Nov 25 11:50:25 2024 +0100
tracing: Constify string literal data member in struct trace_event_call
commit 452f4b31e3f70a52b97890888eeb9eaa9a87139a upstream.
The name member of the struct trace_event_call is assigned with
generated string literals; declare them pointer to read-only.
Reported by clang:
security/landlock/syscalls.c:179:1: warning: initializing 'char *' with an expression of type 'const char[34]' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
179 | SYSCALL_DEFINE3(landlock_create_ruleset,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
180 | const struct landlock_ruleset_attr __user *const, attr,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
181 | const size_t, size, const __u32, flags)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/syscalls.h:226:36: note: expanded from macro 'SYSCALL_DEFINE3'
226 | #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/syscalls.h:234:2: note: expanded from macro 'SYSCALL_DEFINEx'
234 | SYSCALL_METADATA(sname, x, __VA_ARGS__) \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/syscalls.h:184:2: note: expanded from macro 'SYSCALL_METADATA'
184 | SYSCALL_TRACE_ENTER_EVENT(sname); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/syscalls.h:151:30: note: expanded from macro 'SYSCALL_TRACE_ENTER_EVENT'
151 | .name = "sys_enter"#sname, \
| ^~~~~~~~~~~~~~~~~
Cc: [email protected]
Cc: Masami Hiramatsu
Cc: Mathieu Desnoyers
Cc: Mickaël Salaün
Cc: Günther Noack
Cc: Nathan Chancellor
Cc: Nick Desaulniers
Cc: Bill Wendling
Cc: Justin Stitt
Link: https://lore.kernel.org/[email protected]
Fixes: b77e38aa240c3 ("tracing: add event trace infrastructure")
Signed-off-by: Christian Göttsche
Signed-off-by: Steven Rostedt (Google)
Signed-off-by: Greg Kroah-Hartman
commit 8659da87d21678088ddbed263ad713381db86745
Author: Kan Liang
Date: Wed Dec 11 08:11:46 2024 -0800
perf/x86/intel/uncore: Add Clearwater Forest support
commit b6ccddd6fe1fd49c7a82b6fbed01cccad21a29c7 upstream.
From the perspective of the uncore PMU, the Clearwater Forest is the
same as the previous Sierra Forest. The only difference is the event
list, which will be supported in the perf tool later.
Signed-off-by: Kan Liang
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman
commit 908dd70d54463eec26660e91aaff0891cad11c6e
Author: Binbin Zhou
Date: Mon Dec 30 09:39:19 2024 +0800
dmaengine: loongson2-apb: Change GENMASK to GENMASK_ULL
[ Upstream commit 4b65d5322e1d8994acfdb9b867aa00bdb30d177b ]
Fix the following smatch static checker warning:
drivers/dma/loongson2-apb-dma.c:189 ls2x_dma_write_cmd()
warn: was expecting a 64 bit value instead of '~(((0)) + (((~((0))) - (((1)) << (0)) + 1) & (~((0)) >> ((8 * 4) - 1 - (4)))))'
The GENMASK macro used "unsigned long", which caused build issues when
using a 32-bit toolchain because it would try to access bits > 31. This
patch switches GENMASK to GENMASK_ULL, which uses "unsigned long long".
Fixes: 71e7d3cb6e55 ("dmaengine: ls2x-apb: New driver for the Loongson LS2X APB DMA controller")
Reported-by: Dan Carpenter
Closes: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Binbin Zhou
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul
Signed-off-by: Sasha Levin
commit 79a47fd0f1766064d85c0cea80ca98166087705f
Author: Chen Ridong
Date: Tue Dec 17 00:48:18 2024 +0000
freezer, sched: Report frozen tasks as 'D' instead of 'R'
[ Upstream commit f718faf3940e95d5d34af9041f279f598396ab7d ]
Before commit:
f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
the frozen task stat was reported as 'D' in cgroup v1.
However, after rewriting the core freezer logic, the frozen task stat is
reported as 'R'. This is confusing, especially when a task with stat of
'S' is frozen.
This bug can be reproduced with these steps:
$ cd /sys/fs/cgroup/freezer/
$ mkdir test
$ sleep 1000 &
[1] 739 // task whose stat is 'S'
$ echo 739 > test/cgroup.procs
$ echo FROZEN > test/freezer.state
$ ps -aux | grep 739
root 739 0.1 0.0 8376 1812 pts/0 R 10:56 0:00 sleep 1000
As shown above, a task whose stat is 'S' was changed to 'R' when it was
frozen.
To solve this regression, simply maintain the same reported state as
before the rewrite.
[ mingo: Enhanced the changelog and comments ]
Fixes: f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
Signed-off-by: Chen Ridong
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Acked-by: Tejun Heo
Acked-by: Michal Koutný
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin
commit 2cae02a84b980642a319f718504324db6cb254b7
Author: chenchangcheng
Date: Fri Dec 20 15:48:47 2024 +0800
objtool: Add bch2_trans_unlocked_error() to bcachefs noreturns
[ Upstream commit 31ad36a271290648e7c2288a03d7b933d20254d6 ]
Fix the following objtool warning during build time:
fs/bcachefs/btree_trans_commit.o: warning: objtool: bch2_trans_commit_write_locked.isra.0() falls through to next function do_bch2_trans_commit.isra.0()
fs/bcachefs/btree_trans_commit.o: warning: objtool: .text: unexpected end of section
......
fs/bcachefs/btree_update.o: warning: objtool: bch2_trans_update_get_key_cache() falls through to next function flush_new_cached_update()
fs/bcachefs/btree_update.o: warning: objtool: flush_new_cached_update() falls through to next function bch2_trans_update_by_path()
bch2_trans_unlocked_error() is an Obviously Correct (tm) panic() wrapper,
add it to the list of known noreturns.
[ mingo: Improved the changelog ]
Fixes: fd104e2967b7 ("bcachefs: bch2_trans_verify_not_unlocked()")
Signed-off-by: chenchangcheng
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin
commit 1d397722cf3e78ad44b46daaec10e41f9270cba4
Author: John Harrison
Date: Thu Nov 28 13:08:23 2024 -0800
drm/xe: Move the coredump registration to the worker thread
[ Upstream commit 5dce85fecb87751ec94526e1ac516dd7871e2e0c ]
Adding lockdep checking to the coredump code showed that there was an
existing violation. The dev_coredumpm_timeout() call is used to
register the dump with the base coredump subsystem. However, that
makes multiple memory allocations, only some of which use the GFP_
flags passed in. So that also needs to be deferred to the worker
function where it is safe to allocate with arbitrary flags.
In order to not add protoypes for the callback functions, moving the
_timeout call also means moving the worker thread function to later in
the file.
v2: Rebased after other changes to the worker function.
Fixes: e799485044cb ("drm/xe: Introduce the dev_coredump infrastructure.")
Cc: Thomas Hellström
Cc: Matthew Brost
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Francois Dugast
Cc: Rodrigo Vivi
Cc: Lucas De Marchi
Cc: "Thomas Hellström"
Cc: Sumit Semwal
Cc: "Christian König"
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: # v6.8+
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 90f51a7f4ec1004fc4ddfbc6d1f1068d85ef4771)
Signed-off-by: Thomas Hellström
Signed-off-by: Sasha Levin
commit 5db43dfda1f232c0baa3333df1568811230d3547
Author: Matthew Brost
Date: Tue Nov 26 09:46:11 2024 -0800
drm/xe: Take PM ref in delayed snapshot capture worker
[ Upstream commit aef0b4a07277f715bfc2a0d76a16da2bc4e89205 ]
The delayed snapshot capture worker can access the GPU or VRAM both of
which require a PM reference. Take a reference in this worker.
Cc: Rodrigo Vivi
Cc: Maarten Lankhorst
Fixes: 4f04d07c0a94 ("drm/xe: Faster devcoredump")
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Auld
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 1c6878af115a4586a40d6c14d530fa9f93e0bd83)
Signed-off-by: Thomas Hellström
Stable-dep-of: 5dce85fecb87 ("drm/xe: Move the coredump registration to the worker thread")
Signed-off-by: Sasha Levin
commit 7d680f2f76a3417fdfc3946da7471e81464f7b41
Author: Ming Lei
Date: Wed Dec 25 19:06:40 2024 +0800
ublk: detach gendisk from ublk device if add_disk() fails
[ Upstream commit 75cd4005da5492129917a4a4ee45e81660556104 ]
Inside ublk_abort_requests(), gendisk is grabbed for aborting all
inflight requests. And ublk_abort_requests() is called when exiting
the uring context or handling timeout.
If add_disk() fails, the gendisk may have been freed when calling
ublk_abort_requests(), so use-after-free can be caused when getting
disk's reference in ublk_abort_requests().
Fixes the bug by detaching gendisk from ublk device if add_disk() fails.
Fixes: bd23f6c2c2d0 ("ublk: quiesce request queue when aborting queue")
Signed-off-by: Ming Lei
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
commit ccdc8fd86fc7b34630bc1ce2da26537219f8b473
Author: Emmanuel Grumbach
Date: Mon Dec 23 14:13:59 2024 +0200
wifi: iwlwifi: be less noisy if the NIC is dead in S3
commit 0572b7715ffd2cac20aac00333706f3094028180 upstream
If the NIC is dead upon resume, try to catch the error earlier and exit
earlier. We'll print less error messages and get to the same recovery
path as before: reload the firmware.
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Miri Korenblit
Link: https://patch.msgid.link/20241028135215.3a18682261e5.I18f336a4537378a4c1a8537d7246cee1fc82b42c@changeid
Signed-off-by: Johannes Berg
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219597
Signed-off-by: Sasha Levin
commit 16b54ee81d8a44781ddeb5e577262d22c4e6c853
Author: Ming Lei
Date: Fri Dec 6 19:16:06 2024 +0800
blk-mq: register cpuhp callback after hctx is added to xarray table
[ Upstream commit 4bf485a7db5d82ddd0f3ad2b299893199090375e ]
We need to retrieve 'hctx' from xarray table in the cpuhp callback, so the
callback should be registered after this 'hctx' is added to xarray table.
Cc: Reinette Chatre
Cc: Fenghua Yu
Cc: Peter Newman
Cc: Babu Moger
Cc: Luck Tony
Signed-off-by: Ming Lei
Tested-by: Tony Luck
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
commit 92d5139b91147ab372a17daf5dc27a5b9278e516
Author: Ming Lei
Date: Tue Nov 12 20:58:21 2024 +0800
virtio-blk: don't keep queue frozen during system suspend
[ Upstream commit 7678abee0867e6b7fb89aa40f6e9f575f755fb37 ]
Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before
deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's
PM callbacks. And the motivation is to drain inflight IOs before suspending.
block layer's queue freeze looks very handy, but it is also easy to cause
deadlock, such as, any attempt to call into bio_queue_enter() may run into
deadlock if the queue is frozen in current context. There are all kinds
of ->suspend() called in suspend context, so keeping queue frozen in the
whole suspend context isn't one good idea. And Marek reported lockdep
warning[1] caused by virtio-blk's freeze queue in virtblk_freeze().
[1] https://lore.kernel.org/linux-block/[email protected]/
Given the motivation is to drain in-flight IOs, it can be done by calling
freeze & unfreeze, meantime restore to previous behavior by keeping queue
quiesced during suspend.
Cc: Yi Sun
Cc: Michael S. Tsirkin
Cc: Jason Wang
Cc: Stefan Hajnoczi
Cc: [email protected]
Reported-by: Marek Szyprowski
Signed-off-by: Ming Lei
Acked-by: Stefan Hajnoczi
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
commit ce55818b2d3a999f886af91679589e4644ff1dc8
Author: Imre Deak
Date: Wed Dec 4 15:20:07 2024 +0200
drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()
[ Upstream commit e54b00086f7473dbda1a7d6fc47720ced157c6a8 ]
While receiving an MST up request message from one thread in
drm_dp_mst_handle_up_req(), the MST topology could be removed from
another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing
mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL.
This could lead to a NULL deref/use-after-free of mst_primary in
drm_dp_mst_handle_up_req().
Avoid the above by holding a reference for mst_primary in
drm_dp_mst_handle_up_req() while it's used.
v2: Fix kfreeing the request if getting an mst_primary reference fails.
Cc: Lyude Paul