- Mar 18, 2025
-
-
Jianan Huang authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3548320 Change-Id: Ibc357d396603b78e7ecadc95805d4cd6c93adf2b Signed-off-by:
Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
-
Jianan Huang authored
When testing the atomic write fix patches, the f2fs_bug_on was triggered as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/inode.c:935! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 3 UID: 0 PID: 257 Comm: bash Not tainted 6.13.0-rc1-00033-gc283a70d3497 #5 RIP: 0010:f2fs_evict_inode+0x50f/0x520 Call Trace: <TASK> ? __die_body+0x65/0xb0 ? die+0x9f/0xc0 ? do_trap+0xa1/0x170 ? f2fs_evict_inode+0x50f/0x520 ? f2fs_evict_inode+0x50f/0x520 ? handle_invalid_op+0x65/0x80 ? f2fs_evict_inode+0x50f/0x520 ? exc_invalid_op+0x39/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_f2fs_get_dquots+0x10/0x10 ? f2fs_evict_inode+0x50f/0x520 ? f2fs_evict_inode+0x2e5/0x520 evict+0x186/0x2f0 prune_icache_sb+0x75/0xb0 super_cache_scan+0x1a8/0x200 do_shrink_slab+0x163/0x320 shrink_slab+0x2fc/0x470 drop_slab+0x82/0xf0 drop_caches_sysctl_handler+0x4e/0xb0 proc_sys_call_handler+0x183/0x280 vfs_write+0x36d/0x450 ksys_write+0x68/0xd0 do_syscall_64+0xc8/0x1a0 ? arch_exit_to_user_mode_prepare+0x11/0x60 ? irqentry_exit_to_user_mode+0x7e/0xa0 The root cause is: f2fs uses FI_ATOMIC_DIRTIED to indicate dirty atomic files during commit. If the inode is dirtied during commit, such as by f2fs_i_pino_write, the vfs inode keeps clean and the f2fs inode is set to FI_DIRTY_INODE. The FI_DIRTY_INODE flag cann't be cleared by write_inode later due to the clean vfs inode. Finally, f2fs_bug_on is triggered due to this inconsistent state when evict. To reproduce this situation: - fd = open("/mnt/test.db", O_WRONLY) - ioctl(fd, F2FS_IOC_START_ATOMIC_WRITE) - mv /mnt/test.db /mnt/test1.db - ioctl(fd, F2FS_IOC_COMMIT_ATOMIC_WRITE) - echo 3 > /proc/sys/vm/drop_caches To fix this problem, clear FI_DIRTY_INODE after commit, then f2fs_mark_inode_dirty_sync will ensure a consistent dirty state. Bug: 402645924 Fixes: fccaa81d ("f2fs: prevent atomic file from being dirtied before commit") Change-Id: I2c637b4bc544453b07ab124527efb694da9b757f Signed-off-by:Yunlei He <heyunlei@xiaomi.com> Signed-off-by:
Jianan Huang <huangjianan@xiaomi.com> Reviewed-by:
Chao Yu <chao@kernel.org> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> (cherry picked from commit 03511e93) (cherry picked from commit 0e0c5304) (cherry picked from commit 52d776ea)
-
Antoine Tenart authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3548042 Change-Id: I02176b605ab7a5208d05e355daca7b8c044c666c Signed-off-by:
-
Quang Le authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3548045 Change-Id: Ic3d9901d7a3b06868e764d2b0de1164350c9dce4 Signed-off-by:
-
Michal Luczaj authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3548052 Change-Id: I20ea7217ab6c3249c743bf2e1ee8daaa5578b121 Signed-off-by:
-
Michal Luczaj authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3548051 Change-Id: Ie33e87d7abf3044ae32681fc626f16ad03261a2d Signed-off-by:
-
Michal Luczaj authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3548050 Change-Id: I3274114af600cdb944aef0f347d67c399fab445a Signed-off-by:
-
Antoine Tenart authored
[ Upstream commit 12e070eb ] The following trace can be seen if a device is being unregistered while its number of channels are being modified. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120 CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771 RIP: 0010:__mutex_lock+0xc8a/0x1120 Call Trace: <TASK> ethtool_check_max_channel+0x1ea/0x880 ethnl_set_channels+0x3c3/0xb10 ethnl_default_set_doit+0x306/0x650 genl_family_rcv_msg_doit+0x1e3/0x2c0 genl_rcv_msg+0x432/0x6f0 netlink_rcv_skb+0x13d/0x3b0 genl_rcv+0x28/0x40 netlink_unicast+0x42e/0x720 netlink_sendmsg+0x765/0xc20 __sys_sendto+0x3ac/0x420 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x95/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is because unregister_netdevice_many_notify might run before the rtnl lock section of ethnl operations, eg. set_channels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea. Fix this by denying any operation on devices being unregistered. A check was already there in ethnl_ops_begin, but not wide enough. Note that the same issue cannot be seen on the ioctl version (__dev_ethtool) because the device reference is retrieved from within the rtnl lock section there. Once dismantle started, the net device is unlisted and no reference will be found. Bug: 392852041 Fixes: dde91ccf ("ethtool: do not perform operations on net devices being unregistered") Signed-off-by:
Antoine Tenart <atenart@kernel.org> Reviewed-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by:
Edward Cree <ecree.xilinx@gmail.com> Link: https://patch.msgid.link/20250116092159.50890-1-atenart@kernel.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> (cherry picked from commit b1cb37a3) Signed-off-by:
Lee Jones <joneslee@google.com> Change-Id: I56dbd897bb6db194d1eab1d5370796d2e3142fe2
-
Quang Le authored
commit 647cef20 upstream. Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code. Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code. The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch->limit == 0`. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B. Enqueue packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) - Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return `NET_XMIT_CN` - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A. The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen. Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable. Bug: 395539871 Fixes: 57dbb2d8 ("sched: add head drop fifo queue") Reported-by:
Quang Le <quanglex97@gmail.com> Signed-off-by:
Cong Wang <cong.wang@bytedance.com> Link: https://patch.msgid.link/20250204005841.223511-2-xiyou.wangcong@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 79a955ea) Signed-off-by:
-
Michal Luczaj authored
commit 78dafe1c upstream. During socket release, sock_orphan() is called without considering that it sets sk->sk_wq to NULL. Later, if SO_LINGER is enabled, this leads to a null pointer dereferenced in virtio_transport_wait_close(). Orphan the socket only after transport release. Partially reverts the 'Fixes:' commit. KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] lock_acquire+0x19e/0x500 _raw_spin_lock_irqsave+0x47/0x70 add_wait_queue+0x46/0x230 virtio_transport_release+0x4e7/0x7f0 __vsock_release+0xfd/0x490 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x35e/0xa90 __x64_sys_close+0x78/0xd0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug: 396331793 Reported-by:
<syzbot+9d55b199192a4be7d02c@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=9d55b199192a4be7d02c Fixes: fcdd2242 ("vsock: Keep the binding until socket destruction") Tested-by:
Luigi Leonardi <leonardi@redhat.com> Reviewed-by:
Michal Luczaj <mhal@rbox.co> Link: https://patch.msgid.link/20250210-vsock-linger-nullderef-v3-1-ef6244d02b54@rbox.co Signed-off-by:
-
Michal Luczaj authored
commit fcdd2242 upstream. Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect(). Prevents socket unbinding during a transport reassignment, which fixes a use-after-free: 1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2) 2. transport->release() calls vsock_remove_bound() without checking if sk was bound and moved to bound list (refcnt=1) 3. vsock_bind() assumes sk is in unbound list and before __vsock_insert_bound(vsock_bound_sockets()) calls __vsock_remove_bound() which does: list_del_init(&vsk->bound_table); // nop sock_put(&vsk->sk); // refcnt=0 BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 __vsock_bind+0x62e/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 __vsock_create.constprop.0+0x2e/0xb60 vsock_create+0xe4/0x420 __sock_create+0x241/0x650 __sys_socket+0xf2/0x1a0 __x64_sys_socket+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 __vsock_bind+0x5e1/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150 __vsock_bind+0x66d/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150 vsock_remove_bound+0x187/0x1e0 __vsock_release+0x383/0x4a0 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x359/0xa80 task_work_run+0x107/0x1d0 do_exit+0x847/0x2560 do_group_exit+0xb8/0x250 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0xfec/0x14f0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug: 396331793 Fixes: c0cfa2d8 ("vsock: add multi-transports support") Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
Michal Luczaj authored
commit 135ffc7b upstream. vsock defines a BPF callback to be invoked when close() is called. However, this callback is never actually executed. As a result, a closed vsock socket is not automatically removed from the sockmap/sockhash. Introduce a dummy vsock_close() and make vsock_release() call proto::close. Note: changes in __vsock_release() look messy, but it's only due to indent level reduction and variables xmas tree reorder. Bug: 396331793 Fixes: 634f1a71 ("vsock: support sockmap") Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
John Fastabend <john.fastabend@gmail.com> [LL: There is no sockmap support for this kernel version. This patch has been backported because it helps reduce conflicts on future backports] Signed-off-by:
-
Yeongjin Gil authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3545819 Change-Id: I975a6d054f300d891c51d050ad5bce46a2eb765d Signed-off-by:
-
Yeongjin Gil authored
In the case of the following call stack for an atomic file, FI_DIRTY_INODE is set, but FI_ATOMIC_DIRTIED is not subsequently set. f2fs_file_write_iter f2fs_map_blocks f2fs_reserve_new_blocks inc_valid_block_count __mark_inode_dirty(dquot) f2fs_dirty_inode If FI_ATOMIC_DIRTIED is not set, atomic file can encounter corruption due to a mismatch between old file size and new data. To resolve this issue, I changed to set FI_ATOMIC_DIRTIED when FI_DIRTY_INODE is set. This ensures that FI_DIRTY_INODE, which was previously cleared by the Writeback thread during the commit atomic, is set and i_size is updated. Cc: <stable@vger.kernel.org> Fixes: fccaa81d ("f2fs: prevent atomic file from being dirtied before commit") Reviewed-by:Sungjong Seo <sj1557.seo@samsung.com> Reviewed-by:
Sunmin Jeong <s_min.jeong@samsung.com> Signed-off-by:
Yeongjin Gil <youngjin.gil@samsung.com> Reviewed-by:
Daeho Jeong <daehojeong@google.com> Reviewed-by:
-
- Mar 17, 2025
-
-
Srinivasarao Pathipati authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3496753 Change-Id: Ica9aa3e30ec11e468a52e2c5021a802b6f86d9f2 Signed-off-by:
-
Srinivasarao Pathipati authored
Add xas_load to qcom abi symbol list. Bug: 397560786 Change-Id: Ia4a7bab9c2f7670fd62b7aba6a8858a1c1890969 Signed-off-by:
Ravi Kumar Bokka <quic_c_rbokka@quicinc.com> Signed-off-by:
Srinivasarao Pathipati <quic_c_spathi@quicinc.com>
-
- Mar 15, 2025
-
-
Dongbum Kim authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3526291 Change-Id: I768f3142989dd9c70e6b2b12f33e265bd3f45857 Signed-off-by:
-
Dongbum Kim authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3526290 Change-Id: I2ec4fa17715f949894234706310a8614e2adf94a Signed-off-by:
-
Dongbum Kim authored
Adding the following symbols: - __traceiter_android_vh_vprintk_store - __tracepoint_android_vh_vprintk_store Bug: 342523877 Change-Id: I8ddbe5f40960a9f04084da5b0fbdc06eadab0746 Signed-off-by:Dongbum Kim <dongbum.kim@lge.com>
-
Dongbum Kim authored
If hibernation fail, user cannot check log during hibernation. During hibernation, we cannot get any log from copying hibernation image to shutdown the system, for example, write image to storage. A vendor hook copies every log with all loglevel to reserved memory address. We cannot get all loglevels with pstore, so we add vendor hook for copying every log. When the system is rebooted, user can check log from reserved memory address where vendor hook stored in. Bug: 342523877 Change-Id: I31f61378f555ea65ccecfa5b7a96a3ed3e4061a6 Signed-off-by:
-
- Mar 14, 2025
-
-
Chao Yu authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3542428 Change-Id: I91b2f204d118d2e9c3d64ad9014de0b85f2b176e Signed-off-by:
-
Chao Yu authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3541984 Change-Id: Id0d7e708c204d5d166075dd548b81e743d7438ce Signed-off-by:
-
If checkpoint is disabled, GC can not reclaim any segments, we need to detect such condition and bail out from fallocate() of a pinfile, rather than letting allocator running out of free segment, which may cause f2fs to be shutdown. reproducer: mkfs.f2fs -f /dev/vda 16777216 mount -o checkpoint=disable:10% /dev/vda /mnt/f2fs for ((i=0;i<4096;i++)) do { dd if=/dev/zero of=/mnt/f2fs/$i bs=1M count=1; } done sync for ((i=0;i<4096;i+=2)) do { rm /mnt/f2fs/$i; } done sync touch /mnt/f2fs/pinfile f2fs_io pinfile set /mnt/f2fs/pinfile f2fs_io fallocate 0 0 4201644032 /mnt/f2fs/pinfile cat /sys/kernel/debug/f2fs/status output: - Free: 0 (0) Fixes: f5a53edc ("f2fs: support aligned pinned file") Signed-off-by: -
syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2746! CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 Not tainted 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [inline] RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876 Call Trace: <TASK> __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210 f2fs_allocate_new_section fs/f2fs/segment.c:3224 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238 f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830 f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940 vfs_fallocate+0x569/0x6e0 fs/open.c:327 do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885 __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892 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 Concurrent pinfile allocation may run out of free section, result in panic in get_new_segment(), let's expand pin_sem lock coverage to include f2fs_gc(), so that we can make sure to reclaim enough free space for following allocation. In addition, do below changes to enhance error path handling: - call f2fs_bug_on() only in non-pinfile allocation path in get_new_segment(). - call reset_curseg_fields() to reset all fields of curseg in new_curseg() Fixes: f5a53edc ("f2fs: support aligned pinned file") Reported-by:
<syzbot+15669ec8c35ddf6c3d43@syzkaller.appspotmail.com> Closes: https://lore.kernel.org/linux-f2fs-devel/675cd64e.050a0220.37aaf.00bb.GAE@google.com Signed-off-by:
-
Qi Han authored
BACKPORT: f2fs: compress: fix inconsistent update of i_blocks in release_compress_blocks and reserve_compress_blocks am: 27895588 Original change: https://android-review.googlesource.com/c/kernel/common/+/3539002 Change-Id: I3942b6062534c31e3af92256b1a487806dd02d83 Signed-off-by:
-
Qi Han authored
BACKPORT: f2fs: compress: fix inconsistent update of i_blocks in release_compress_blocks and reserve_compress_blocks After release a file and subsequently reserve it, the FSCK flag is set when the file is deleted, as shown in the following backtrace: F2FS-fs (dm-48): Inconsistent i_blocks, ino:401231, iblocks:1448, sectors:1472 fs_rec_info_write_type+0x58/0x274 f2fs_rec_info_write+0x1c/0x2c set_sbi_flag+0x74/0x98 dec_valid_block_count+0x150/0x190 f2fs_truncate_data_blocks_range+0x2d4/0x3cc f2fs_do_truncate_blocks+0x2fc/0x5f0 f2fs_truncate_blocks+0x68/0x100 f2fs_truncate+0x80/0x128 f2fs_evict_inode+0x1a4/0x794 evict+0xd4/0x280 iput+0x238/0x284 do_unlinkat+0x1ac/0x298 __arm64_sys_unlinkat+0x48/0x68 invoke_syscall+0x58/0x11c For clusters of the following type, i_blocks are decremented by 1 and i_compr_blocks are incremented by 7 in release_compress_blocks, while updates to i_blocks and i_compr_blocks are skipped in reserve_compress_blocks. raw node: D D D D D D D D after compress: C D D D D D D D after reserve: C D D D D D D D Let's update i_blocks and i_compr_blocks properly in reserve_compress_blocks. Bug: 403145794 Fixes: eb8fbaa5 ("f2fs: compress: fix to check unreleased compressed cluster") Change-Id: I596af62bbd54941bfc77f30e182db94e81cba59b Signed-off-by:
Qi Han <hanqi@vivo.com> Reviewed-by:
-
- Mar 13, 2025
-
-
gy niu authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3539041 Change-Id: I47db1285292a70b7528b9d36d42cb96097347022 Signed-off-by:
-
gy niu authored
These symbols are required to third part ethernet driver pegasus.ko and smsc95xx.ko INFO: 2 function symbol(s) added 'void mii_ethtool_get_link_ksettings(struct mii_if_info*, struct ethtool_link_ksettings*)' 'int mii_ethtool_set_link_ksettings(struct mii_if_info*, const struct ethtool_link_ksettings*)' Bug: 403203480 Change-Id: Idfb8fad289516d5cbbe6235bca6c87bd24406ca0 Signed-off-by:gy niu <gyniu1024@gmail.com>
-
Bian Jin chen authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3535763 Change-Id: I7abc51169c6a610701dc3dbf9dc7664e5d642e80 Signed-off-by:
-
- Mar 12, 2025
-
-
Bian Jin chen authored
INFO: 4 function symbol(s) added 'bool drm_bridge_is_panel(const struct drm_bridge*)' 'int drm_panel_bridge_set_orientation(struct drm_connector*, struct drm_bridge*)' 'struct drm_bridge* drmm_of_get_bridge(struct drm_device*, struct device_node*, u32, u32)' 'struct drm_bridge* drmm_panel_bridge_add(struct drm_device*, struct drm_panel*)' Bug: 300024866 Signed-off-by:Bian Jin chen <kenjc.bian@rock-chips.com> Change-Id: I256402894b3a19be401c27113c0fe52647d43531
-
Seiya Wang authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3535780 Change-Id: Id54c2dce252fbcaf2ea1d95e8e61da2f6e6d08c2 Signed-off-by:
-
Seiya Wang authored
7 function symbol(s) added 'int nfnetlink_subsys_register(const struct nfnetlink_subsystem*)' 'int nfnetlink_subsys_unregister(const struct nfnetlink_subsystem*)' 'int nfnetlink_unicast(struct sk_buff*, struct net*, u32)' 'void nfnl_lock(__u8)' 'void nfnl_unlock(__u8)' 'int xt_register_matches(struct xt_match*, unsigned int)' 'void xt_unregister_matches(struct xt_match*, unsigned int)' Bug: 402616138 Change-Id: Ic3eaedb9ea04389141704e72e46e15e0936c0a78 Signed-off-by:Seiya Wang <seiya.wang@mediatek.com>
-
- Mar 11, 2025
-
-
Lokesh Gidra authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3534180 Change-Id: I7f69196f99d3104cf7441a73dd19741e1c1f761c Signed-off-by:
-
Suren Baghdasaryan authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3531406 Change-Id: I19696b589f34a3e772b7ad51bade6c7da2053e8f Signed-off-by:
-
Suren Baghdasaryan authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3531679 Change-Id: I2582036e2b9e217f765b5e4698811cac102dec17 Signed-off-by:
-
Barry Song authored
Original change: https://android-review.googlesource.com/c/kernel/common/+/3531678 Change-Id: Ieebb6884b69293e680e166b2d5a18826e1eb785a Signed-off-by:
-
Lokesh Gidra authored
Following issues were reported in the MOVE ioctl: 1. Panic when trying to move a source page which is in swap-cache [1] 2. Livelock when multiple threads try to move the same source page [2] Three patches have been upstreamed to fix these issues [3, 4, 5] MOVE ioctl was backported to ACK 6.1 and 6.6 for ART GC to use it [6]. Therefore, on these kernels in order to be able to identify in the userspace if the fixes are included, this mode is added. NOTE: UFFDIO_MOVE_MODE_CONFIRM_FIXED mode is only for 6.1 and 6.6 kernels, and will go away afterwards. [1] https://lore.kernel.org/linux-mm/20250219112519.92853-1-21cnbao@gmail.com/ [2] https://github.com/lokeshgidra/uffd_move_ioctl_deadlock [3] https://web.git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-hotfixes-stable&id=c50f8e6053b0503375c2975bf47f182445aebb4c [4] https://web.git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-hotfixes-stable&id=37b338eed10581784e854d4262da05c8d960c748 [5] https://web.git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-hotfixes-stable&id=927e926d72d9155fde3264459fe9bfd7b5e40d28 [6] b/274911254 Bug: 401790618 Change-Id: Ibd854ec7ac9ae6a2ca416767d032b6c71f1bc688 Signed-off-by:
Lokesh Gidra <lokeshgidra@google.com>
-
Suren Baghdasaryan authored
Current implementation of move_pages_pte() copies source and destination PTEs in order to detect concurrent changes to PTEs involved in the move. However these copies are also used to unmap the PTEs, which will fail if CONFIG_HIGHPTE is enabled because the copies are allocated on the stack. Fix this by using the actual PTEs which were kmap()ed. Link: https://lkml.kernel.org/r/20250226185510.2732648-3-surenb@google.com Fixes: adef4406 ("userfaultfd: UFFDIO_MOVE uABI") Signed-off-by:
Suren Baghdasaryan <surenb@google.com> Reported-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Suren Baghdasaryan authored
Lokesh recently raised an issue about UFFDIO_MOVE getting into a deadlock state when it goes into split_folio() with raised folio refcount. split_folio() expects the reference count to be exactly mapcount + num_pages_in_folio + 1 (see can_split_folio()) and fails with EAGAIN otherwise. If multiple processes are trying to move the same large folio, they raise the refcount (all tasks succeed in that) then one of them succeeds in locking the folio, while others will block in folio_lock() while keeping the refcount raised. The winner of this race will proceed with calling split_folio() and will fail returning EAGAIN to the caller and unlocking the folio. The next competing process will get the folio locked and will go through the same flow. In the meantime the original winner will be retried and will block in folio_lock(), getting into the queue of waiting processes only to repeat the same path. All this results in a livelock. An easy fix would be to avoid waiting for the folio lock while holding folio refcount, similar to madvise_free_huge_pmd() where folio lock is acquired before raising the folio refcount. Since we lock and take a refcount of the folio while holding the PTE lock, changing the order of these operations should not break anything. Modify move_pages_pte() to try locking the folio first and if that fails and the folio is large then return EAGAIN without touching the folio refcount. If the folio is single-page then split_folio() is not called, so we don't have this issue. Lokesh has a reproducer [1] and I verified that this change fixes the issue. [1] https://github.com/lokeshgidra/uffd_move_ioctl_deadlock [akpm@linux-foundation.org: reflow comment to 80 cols, s/end/end up/] Link: https://lkml.kernel.org/r/20250226185510.2732648-2-surenb@google.com Fixes: adef4406 ("userfaultfd: UFFDIO_MOVE uABI") Signed-off-by:
Liam R. Howlett <Liam.Howlett@Oracle.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Barry Song <21cnbao@gmail.com> Cc: Barry Song <v-songbaohua@oppo.com> Cc: David Hildenbrand <david@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: Jann Horn <jannh@google.com> Cc: Kalesh Singh <kaleshsingh@google.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Matthew Wilcow (Oracle) <willy@infradead.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Barry Song authored
userfaultfd_move() checks whether the PTE entry is present or a swap entry. - If the PTE entry is present, move_present_pte() handles folio migration by setting: src_folio->index = linear_page_index(dst_vma, dst_addr); - If the PTE entry is a swap entry, move_swap_pte() simply copies the PTE to the new dst_addr. This approach is incorrect because, even if the PTE is a swap entry, it can still reference a folio that remains in the swap cache. This creates a race window between steps 2 and 4. 1. add_to_swap: The folio is added to the swapcache. 2. try_to_unmap: PTEs are converted to swap entries. 3. pageout: The folio is written back. 4. Swapcache is cleared. If userfaultfd_move() occurs in the window between steps 2 and 4, after the swap PTE has been moved to the destination, accessing the destination triggers do_swap_page(), which may locate the folio in the swapcache. However, since the folio's index has not been updated to match the destination VMA, do_swap_page() will detect a mismatch. This can result in two critical issues depending on the system configuration. If KSM is disabled, both small and large folios can trigger a BUG during the add_rmap operation due to: page_pgoff(folio, page) != linear_page_index(vma, address) [ 13.336953] page: refcount:6 mapcount:1 mapping:00000000f43db19c index:0xffffaf150 pfn:0x4667c [ 13.337520] head: order:2 mapcount:1 entire_mapcount:0 nr_pages_mapped:1 pincount:0 [ 13.337716] memcg:ffff00000405f000 [ 13.337849] anon flags: 0x3fffc0000020459(locked|uptodate|dirty|owner_priv_1|head|swapbacked|node=0|zone=0|lastcpupid=0xffff) [ 13.338630] raw: 03fffc0000020459 ffff80008507b538 ffff80008507b538 ffff000006260361 [ 13.338831] raw: 0000000ffffaf150 0000000000004000 0000000600000000 ffff00000405f000 [ 13.339031] head: 03fffc0000020459 ffff80008507b538 ffff80008507b538 ffff000006260361 [ 13.339204] head: 0000000ffffaf150 0000000000004000 0000000600000000 ffff00000405f000 [ 13.339375] head: 03fffc0000000202 fffffdffc0199f01 ffffffff00000000 0000000000000001 [ 13.339546] head: 0000000000000004 0000000000000000 00000000ffffffff 0000000000000000 [ 13.339736] page dumped because: VM_BUG_ON_PAGE(page_pgoff(folio, page) != linear_page_index(vma, address)) [ 13.340190] ------------[ cut here ]------------ [ 13.340316] kernel BUG at mm/rmap.c:1380! [ 13.340683] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ 13.340969] Modules linked in: [ 13.341257] CPU: 1 UID: 0 PID: 107 Comm: a.out Not tainted 6.14.0-rc3-gcf42737e247a-dirty #299 [ 13.341470] Hardware name: linux,dummy-virt (DT) [ 13.341671] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 13.341815] pc : __page_check_anon_rmap+0xa0/0xb0 [ 13.341920] lr : __page_check_anon_rmap+0xa0/0xb0 [ 13.342018] sp : ffff80008752bb20 [ 13.342093] x29: ffff80008752bb20 x28: fffffdffc0199f00 x27: 0000000000000001 [ 13.342404] x26: 0000000000000000 x25: 0000000000000001 x24: 0000000000000001 [ 13.342575] x23: 0000ffffaf0d0000 x22: 0000ffffaf0d0000 x21: fffffdffc0199f00 [ 13.342731] x20: fffffdffc0199f00 x19: ffff000006210700 x18: 00000000ffffffff [ 13.342881] x17: 6c203d2120296567 x16: 6170202c6f696c6f x15: 662866666f67705f [ 13.343033] x14: 6567617028454741 x13: 2929737365726464 x12: ffff800083728ab0 [ 13.343183] x11: ffff800082996bf8 x10: 0000000000000fd7 x9 : ffff80008011bc40 [ 13.343351] x8 : 0000000000017fe8 x7 : 00000000fffff000 x6 : ffff8000829eebf8 [ 13.343498] x5 : c0000000fffff000 x4 : 0000000000000000 x3 : 0000000000000000 [ 13.343645] x2 : 0000000000000000 x1 : ffff0000062db980 x0 : 000000000000005f [ 13.343876] Call trace: [ 13.344045] __page_check_anon_rmap+0xa0/0xb0 (P) [ 13.344234] folio_add_anon_rmap_ptes+0x22c/0x320 [ 13.344333] do_swap_page+0x1060/0x1400 [ 13.344417] __handle_mm_fault+0x61c/0xbc8 [ 13.344504] handle_mm_fault+0xd8/0x2e8 [ 13.344586] do_page_fault+0x20c/0x770 [ 13.344673] do_translation_fault+0xb4/0xf0 [ 13.344759] do_mem_abort+0x48/0xa0 [ 13.344842] el0_da+0x58/0x130 [ 13.344914] el0t_64_sync_handler+0xc4/0x138 [ 13.345002] el0t_64_sync+0x1ac/0x1b0 [ 13.345208] Code: aa1503e0 f000f801 910f6021 97ff5779 (d4210000) [ 13.345504] ---[ end trace 0000000000000000 ]--- [ 13.345715] note: a.out[107] exited with irqs disabled [ 13.345954] note: a.out[107] exited with preempt_count 2 If KSM is enabled, Peter Xu also discovered that do_swap_page() may trigger an unexpected CoW operation for small folios because ksm_might_need_to_copy() allocates a new folio when the folio index does not match linear_page_index(vma, addr). This patch also checks the swapcache when handling swap entries. If a match is found in the swapcache, it processes it similarly to a present PTE. However, there are some differences. For example, the folio is no longer exclusive because folio_try_share_anon_rmap_pte() is performed during unmapping. Furthermore, in the case of swapcache, the folio has already been unmapped, eliminating the risk of concurrent rmap walks and removing the need to acquire src_folio's anon_vma or lock. Note that for large folios, in the swapcache handling path, we directly return -EBUSY since split_folio() will return -EBUSY regardless if the folio is under writeback or unmapped. This is not an urgent issue, so a follow-up patch may address it separately. [v-songbaohua@oppo.com: minor cleanup according to Peter Xu] Link: https://lkml.kernel.org/r/20250226024411.47092-1-21cnbao@gmail.com Link: https://lkml.kernel.org/r/20250226001400.9129-1-21cnbao@gmail.com Fixes: adef4406 ("userfaultfd: UFFDIO_MOVE uABI") Signed-off-by:
Barry Song <v-songbaohua@oppo.com> Acked-by:
-
