- Kernel - mailweb.openeuler.org

[openeuler:OLK-6.6 1834/1834] drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_drive.c:41:30: sparse: sparse: symbol 'kbox_fops' was not declared. Should it be static?
by kernel test robot 22 Jan '25

22 Jan '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 75c81bcddd82381fbd4cef477a5b56eb2fe56697 commit: cd2978286f40089fcd83f74ffdff733bfbe1e52a [1834/1834] Huawei BMA: Adding Huawei BMA driver: host_kbox_drv config: x86_64-randconfig-121-20250122 (https://download.01.org/0day-ci/archive/20250122/202501221527.POAEXa7r-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250122/202501221527.POAEXa7r-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202501221527.POAEXa7r-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_drive.c:41:30: sparse: sparse: symbol 'kbox_fops' was not declared. Should it be static? -- drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:51:28: sparse: sparse: cast removes address space '__iomem' of expression drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:42:6: sparse: sparse: symbol 'kbox_write_to_pci' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:120:27: sparse: sparse: cast removes address space '__iomem' of expression drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:111:6: sparse: sparse: symbol 'kbox_read_from_pci' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:179:28: sparse: sparse: cast removes address space '__iomem' of expression drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:172:6: sparse: sparse: symbol 'kbox_memset_pci' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:360:26: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char *user_buf @@ got char [noderef] __user *data @@ drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:360:26: sparse: expected char *user_buf drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:360:26: sparse: got char [noderef] __user *data drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:395:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] __user *to @@ got char *user_buf @@ drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:395:34: sparse: expected void [noderef] __user *to drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:395:34: sparse: got char *user_buf >> drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:422:32: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char const *user_buf @@ got char const [noderef] __user *data @@ drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:422:32: sparse: expected char const *user_buf drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:422:32: sparse: got char const [noderef] __user *data drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:453:51: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const [noderef] __user *from @@ got char const *user_buf @@ drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:453:51: sparse: expected void const [noderef] __user *from drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c:453:51: sparse: got char const *user_buf vim +/kbox_fops +41 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_drive.c 40 > 41 const struct file_operations kbox_fops = { 42 .owner = THIS_MODULE, 43 .read = kbox_read, 44 .write = kbox_write, 45 .unlocked_ioctl = kbox_ioctl, 46 .mmap = kbox_mmap, 47 .open = kbox_open, 48 .release = kbox_release, 49 }; 50 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10 0/2] Two CVE fixes for ksmbd
by Wang Zhaolong 22 Jan '25

22 Jan '25

Namjae Jeon (2): ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16() ksmbd: fix potencial out-of-bounds when buffer offset is invalid fs/ksmbd/smb2misc.c | 27 ++++++++++++++++++------- fs/ksmbd/smb2pdu.c | 48 ++++++++++++++++++++++++--------------------- 2 files changed, 46 insertions(+), 29 deletions(-) -- 2.34.3

2 3

[PATCH OLK-6.6 0/2] Two CVE fixes for ksmbd
by Wang Zhaolong 22 Jan '25

22 Jan '25

Namjae Jeon (2): ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16() ksmbd: fix potencial out-of-bounds when buffer offset is invalid fs/smb/server/smb2misc.c | 26 ++++++++++++++++------ fs/smb/server/smb2pdu.c | 48 ++++++++++++++++++++++------------------ 2 files changed, 45 insertions(+), 29 deletions(-) -- 2.34.3

2 3

[PATCH OLK-6.6 0/7] Support MATA monitor feature for MPAM
by Zeng Heng 22 Jan '25

22 Jan '25

Zeng Heng (7): arm64/mpam: Support MATA monitor feature for MPAM arm64/mpam: Add judgment to distinguish MSMON_MBWU_CAPTURE definition arm64/mpam: fix MBA granularity conversion formula arm64/mpam: fix bug in percent_to_mbw_max() arm64/mpam: Fix out-of-bound access of mbwu_state array arm64/mpam: Fix out-of-bound access of cfg array arm64/mpam: Improve conversion accuracy between percent and fixed-point fraction drivers/platform/mpam/mpam_devices.c | 31 ++++++++++--- drivers/platform/mpam/mpam_resctrl.c | 68 ++++++++++++++++++---------- fs/resctrl/monitor.c | 42 ++++++++++++----- 3 files changed, 98 insertions(+), 43 deletions(-) -- 2.25.1

2 8

[openeuler:OLK-6.6 1834/1834] drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:88:23: sparse: sparse: symbol 'g_bspveth_dev' was not declared. Should it be static?
by kernel test robot 22 Jan '25

22 Jan '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 75c81bcddd82381fbd4cef477a5b56eb2fe56697 commit: 0cafdd73feea92b9a246d4fab07872eb6bec9f2b [1834/1834] Huawei BMA: Adding Huawei BMA driver: host_veth_drv config: x86_64-randconfig-121-20250122 (https://download.01.org/0day-ci/archive/20250122/202501221218.JgRI8RlC-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250122/202501221218.JgRI8RlC-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202501221218.JgRI8RlC-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:88:23: sparse: sparse: symbol 'g_bspveth_dev' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:400:5: sparse: sparse: symbol 'bspveth_setup_tx_resources' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:449:6: sparse: sparse: symbol 'bspveth_free_tx_resources' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:491:5: sparse: sparse: symbol 'bspveth_setup_all_tx_resources' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:560:6: sparse: sparse: symbol 'bspveth_free_all_tx_resources' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:577:5: sparse: sparse: symbol 'veth_alloc_one_rx_skb' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:622:5: sparse: sparse: symbol 'veth_refill_rxskb' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:661:5: sparse: sparse: symbol 'bspveth_setup_rx_skb' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:693:6: sparse: sparse: symbol 'bspveth_free_rx_skb' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:726:5: sparse: sparse: symbol 'bspveth_setup_all_rx_skb' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:754:6: sparse: sparse: symbol 'bspveth_free_all_rx_skb' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:766:5: sparse: sparse: symbol 'bspveth_setup_rx_resources' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:817:6: sparse: sparse: symbol 'bspveth_free_rx_resources' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:849:5: sparse: sparse: symbol 'bspveth_setup_all_rx_resources' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:914:6: sparse: sparse: symbol 'bspveth_free_all_rx_resources' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:932:5: sparse: sparse: symbol 'bspveth_dev_install' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:967:5: sparse: sparse: symbol 'bspveth_dev_uninstall' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1052:5: sparse: sparse: symbol 'veth_config' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1069:6: sparse: sparse: symbol 'bspveth_initstatis' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1094:5: sparse: sparse: symbol 'veth_ioctl' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1099:25: sparse: sparse: symbol 'veth_stats' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1104:5: sparse: sparse: symbol 'veth_mac_set' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1235:6: sparse: sparse: symbol 'veth_netdev_func_init' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1265:5: sparse: sparse: symbol 'veth_send_one_pkt' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1544:6: sparse: sparse: symbol 'veth_skbtrtimer_do' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1591:6: sparse: sparse: symbol 'veth_netdev_exit' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1630:5: sparse: sparse: symbol 'veth_netdev_init' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1721:6: sparse: sparse: symbol 'veth_dma_tx_timer_do_H' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1771:5: sparse: sparse: symbol 'dmacmp_err_deal' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1808:5: sparse: sparse: symbol 'veth_check_dma_status' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1836:5: sparse: sparse: symbol '__check_dmacmp_H' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1908:5: sparse: sparse: symbol '__checkspace_H' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:1989:5: sparse: sparse: symbol '__make_dmalistbd_h2b_H' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:2093:5: sparse: sparse: symbol '__make_dmalistbd_b2h_H' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:2196:5: sparse: sparse: symbol '__start_dmalist_H' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:2242:5: sparse: sparse: symbol 'check_dma_queue_fault' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:2390:6: sparse: sparse: symbol 'bspveth_host_exit_H' was not declared. Should it be static? >> drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:2439:26: sparse: sparse: cast removes address space '__iomem' of expression drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c:2404:5: sparse: sparse: symbol 'bspveth_host_init_H' was not declared. Should it be static? vim +/g_bspveth_dev +88 drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.c 87 > 88 struct bspveth_device g_bspveth_dev = {}; 89 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 1411/1411] drivers/cpuidle/.tmp_cpuidle-haltpoll.o: warning: objtool: missing symbol for section .init.text
by kernel test robot 22 Jan '25

22 Jan '25

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: fdf62dff2537450d438667d817333e17ec71148a commit: 8104395ba98a81c8cb1ddd245482baca0d57d163 [1411/1411] add cpuidle-haltpoll driver config: x86_64-buildonly-randconfig-005-20250121 (https://download.01.org/0day-ci/archive/20250122/202501221206.KfU0Mays-lkp@…) compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250122/202501221206.KfU0Mays-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202501221206.KfU0Mays-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/cpuidle/.tmp_cpuidle-haltpoll.o: warning: objtool: missing symbol for section .init.text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] scsi: sg: Fix slab-use-after-free read in sg_release()
by Zheng Qixing 22 Jan '25

22 Jan '25

From: Suraj Sonawane <surajsonawane0215(a)gmail.com> mainline inclusion from mainline-v6.13-rc2 commit f10593ad9bc36921f623361c9e3dd96bd52d85ee category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAN7 CVE: CVE-2024-56631 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838 __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407 In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is called before releasing the open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via sg_remove_sfp_usercontext(), which ultimately frees sfp. After kref_put(), sg_release() continues to unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error. Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the open_rel_lock mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. - Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release(). The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release(). Reported-by: syzbot+7efb5850a17ba6ce098b(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7efb5850a17ba6ce098b Tested-by: syzbot+7efb5850a17ba6ce098b(a)syzkaller.appspotmail.com Fixes: cc833acbee9d ("sg: O_EXCL and other lock handling") Signed-off-by: Suraj Sonawane <surajsonawane0215(a)gmail.com> Link: https://lore.kernel.org/r/20241120125944.88095-1-surajsonawane0215@gmail.com Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Conflicts: drivers/scsi/sg.c [Context conflicts.] Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- drivers/scsi/sg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c index 10da329fa53f..7c9c63be214d 100644 --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -395,7 +395,6 @@ sg_release(struct inode *inode, struct file *filp) mutex_lock(&sdp->open_rel_lock); scsi_autopm_put_device(sdp->device); - kref_put(&sfp->f_ref, sg_remove_sfp); sdp->open_cnt--; /* possibly many open()s waiting on exlude clearing, start many; @@ -407,6 +406,7 @@ sg_release(struct inode *inode, struct file *filp) wake_up_interruptible(&sdp->open_wait); } mutex_unlock(&sdp->open_rel_lock); + kref_put(&sfp->f_ref, sg_remove_sfp); return 0; } -- 2.39.2

2 1

[openeuler:OLK-6.6 1834/1834] drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:87:21: sparse: sparse: symbol 'g_cdev_set' was not declared. Should it be static?
by kernel test robot 22 Jan '25

22 Jan '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 75c81bcddd82381fbd4cef477a5b56eb2fe56697 commit: 0b6609ecfba8575f870350666ab13e25accc8d14 [1834/1834] Huawei BMA: Adding Huawei BMA driver: host_cdev_drv config: x86_64-randconfig-121-20250122 (https://download.01.org/0day-ci/archive/20250122/202501221109.65gRQ9hH-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250122/202501221109.65gRQ9hH-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202501221109.65gRQ9hH-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:246:17: sparse: sparse: Using plain integer as NULL pointer drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:258:17: sparse: sparse: Using plain integer as NULL pointer drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:264:17: sparse: sparse: Using plain integer as NULL pointer drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:313:9: sparse: sparse: Using plain integer as NULL pointer drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:323:9: sparse: sparse: Using plain integer as NULL pointer drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:349:9: sparse: sparse: Using plain integer as NULL pointer >> drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:87:21: sparse: sparse: symbol 'g_cdev_set' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:151:17: sparse: sparse: incorrect type in initializer (different base types) @@ expected restricted __poll_t ( *poll )( ... ) @@ got unsigned int ( * )( ... ) @@ drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:151:17: sparse: expected restricted __poll_t ( *poll )( ... ) drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:151:17: sparse: got unsigned int ( * )( ... ) drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:147:30: sparse: sparse: symbol 'g_bma_cdev_fops' was not declared. Should it be static? drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:185:25: sparse: sparse: Using plain integer as NULL pointer drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:196:25: sparse: sparse: Using plain integer as NULL pointer drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:208:17: sparse: sparse: Using plain integer as NULL pointer drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:213:17: sparse: sparse: Using plain integer as NULL pointer vim +/g_cdev_set +87 drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c 78 79 static int cdev_open(struct inode *inode, struct file *filp); 80 static int cdev_release(struct inode *inode, struct file *filp); 81 static unsigned int cdev_poll(struct file *file, poll_table *wait); 82 static ssize_t cdev_read(struct file *filp, char __user *data, size_t count, 83 loff_t *ppos); 84 static ssize_t cdev_write(struct file *filp, const char __user *data, 85 size_t count, loff_t *ppos); 86 > 87 struct cdev_dev_set g_cdev_set; 88 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH] mm/slub: Reduce memory consumption in extreme scenarios
by Kaixiong Yu 22 Jan '25

22 Jan '25

From: Chen Jun <chenjun102(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit 9198ffbd2b494daae3a67cac1d59c3a2754e64cd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBH72Q Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When kmalloc_node() is called without __GFP_THISNODE and the target node lacks sufficient memory, SLUB allocates a folio from a different node other than the requested node, instead of taking a partial slab from it. However, since the allocated folio does not belong to the requested node, on the following allocation it is deactivated and added to the partial slab list of the node it belongs to. This behavior can result in excessive memory usage when the requested node has insufficient memory, as SLUB will repeatedly allocate folios from other nodes without reusing the previously allocated ones. To prevent memory wastage, when a preferred node is indicated (not NUMA_NO_NODE) but without a prior __GFP_THISNODE constraint: 1) try to get a partial slab from target node only by having __GFP_THISNODE in pc.flags for get_partial() 2) if 1) failed, try to allocate a new slab from target node with GFP_NOWAIT | __GFP_THISNODE opportunistically. 3) if 2) failed, retry with original gfpflags which will allow get_partial() try partial lists of other nodes before potentially allocating new page from other nodes Without a preferred node, or with __GFP_THISNODE constraint, the behavior remains unchanged. On qemu with 4 numa nodes and each numa has 1G memory. Write a test ko to call kmalloc_node(196, GFP_KERNEL, 3) for (4 * 1024 + 4) * 1024 times. cat /proc/slabinfo shows: kmalloc-256 4200530 13519712 256 32 2 : tunables.. after this patch, cat /proc/slabinfo shows: kmalloc-256 4200558 4200768 256 32 2 : tunables.. Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Conflicts: mm/slub.c [The conflict is large. Because OLK-5.10 does not merge mainline patch 53a0de06e50acb372c75d87fcc72ddfdf4a060ee ("mm, slub: dissolve new_slab_objects() into ___slab_alloc()")] Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- mm/slub.c | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index 9dd4cc478ec3..d4e7e88df7ff 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2105,7 +2105,7 @@ static void *get_partial(struct kmem_cache *s, gfp_t flags, int node, searchnode = numa_mem_id(); object = get_partial_node(s, get_node(s, searchnode), c, flags); - if (object || node != NUMA_NO_NODE) + if (object || (node != NUMA_NO_NODE && (flags & __GFP_THISNODE))) return object; return get_any_partial(s, flags, c); @@ -2687,6 +2687,8 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, { void *freelist; struct page *page; + bool try_thisnode = true; + gfp_t pc_gfpflags; stat(s, ALLOC_SLOWPATH); @@ -2764,9 +2766,33 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, goto redo; } - freelist = new_slab_objects(s, gfpflags, node, &c); +new_objects: + + pc_gfpflags = gfpflags; + /* + * When a preferred node is indicated but no __GFP_THISNODE + * + * 1) try to get a partial slab from target node only by having + * __GFP_THISNODE in pc_gfpflags for new_slab_objects() + * 2) if 1) failed, try to allocate a new slab from target node with + * GPF_NOWAIT | __GFP_THISNODE opportunistically + * 3) if 2) failed, retry with original gfpflags which will allow + * new_slab_objects() try partial lists of other nodes before potentially + * allocating new page from other nodes + */ + if (unlikely(node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) + && try_thisnode)) + pc_gfpflags = GFP_NOWAIT | __GFP_THISNODE; + + freelist = new_slab_objects(s, pc_gfpflags, node, &c); if (unlikely(!freelist)) { + if (node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) + && try_thisnode) { + try_thisnode = false; + goto new_objects; + } + slab_out_of_memory(s, gfpflags, node); return NULL; } -- 2.34.1

1 0

[PATCH OLK-6.6] bpf: Fix theoretical prog_array UAF in __uprobe_perf_func()
by Pu Lehui 22 Jan '25

22 Jan '25

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v6.6.67 commit 68d23ee1bdf1c7ce499897d738033d67db46fffa category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBJ838 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 7d0d673627e20cfa3b21a829a896ce03b58a4f1c upstream. Currently, the pointer stored in call->prog_array is loaded in __uprobe_perf_func(), with no RCU annotation and no immediately visible RCU protection, so it looks as if the loaded pointer can immediately be dangling. Later, bpf_prog_run_array_uprobe() starts a RCU-trace read-side critical section, but this is too late. It then uses rcu_dereference_check(), but this use of rcu_dereference_check() does not actually dereference anything. Fix it by aligning the semantics to bpf_prog_run_array(): Let the caller provide rcu_read_lock_trace() protection and then load call->prog_array with rcu_dereference_check(). This issue seems to be theoretical: I don't know of any way to reach this code without having handle_swbp() further up the stack, which is already holding a rcu_read_lock_trace() lock, so where we take rcu_read_lock_trace() in __uprobe_perf_func()/bpf_prog_run_array_uprobe() doesn't actually have any effect. Fixes: 8c7dcb84e3b7 ("bpf: implement sleepable uprobes by chaining gps") Suggested-by: Andrii Nakryiko <andrii(a)kernel.org> Signed-off-by: Jann Horn <jannh(a)google.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20241210-bpf-fix-uprobe-uaf-v4-1-5fc8959b2b74@g… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- include/linux/bpf.h | 13 +++++-------- kernel/trace/trace_uprobe.c | 6 +++++- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/include/linux/bpf.h b/include/linux/bpf.h index 73ef8dda7ada..8f4c303080a8 100644 --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -2078,26 +2078,25 @@ bpf_prog_run_array(const struct bpf_prog_array *array, * rcu-protected dynamically sized maps. */ static __always_inline u32 -bpf_prog_run_array_uprobe(const struct bpf_prog_array __rcu *array_rcu, +bpf_prog_run_array_uprobe(const struct bpf_prog_array *array, const void *ctx, bpf_prog_run_fn run_prog) { const struct bpf_prog_array_item *item; const struct bpf_prog *prog; - const struct bpf_prog_array *array; struct bpf_run_ctx *old_run_ctx; struct bpf_trace_run_ctx run_ctx; u32 ret = 1; might_fault(); + RCU_LOCKDEP_WARN(!rcu_read_lock_trace_held(), "no rcu lock held"); + + if (unlikely(!array)) + return ret; - rcu_read_lock_trace(); migrate_disable(); run_ctx.is_uprobe = true; - array = rcu_dereference_check(array_rcu, rcu_read_lock_trace_held()); - if (unlikely(!array)) - goto out; old_run_ctx = bpf_set_run_ctx(&run_ctx.run_ctx); item = &array->items[0]; while ((prog = READ_ONCE(item->prog))) { @@ -2112,9 +2111,7 @@ bpf_prog_run_array_uprobe(const struct bpf_prog_array __rcu *array_rcu, rcu_read_unlock(); } bpf_reset_run_ctx(old_run_ctx); -out: migrate_enable(); - rcu_read_unlock_trace(); return ret; } diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c index 791c0723212b..9110a759e882 100644 --- a/kernel/trace/trace_uprobe.c +++ b/kernel/trace/trace_uprobe.c @@ -1346,9 +1346,13 @@ static void __uprobe_perf_func(struct trace_uprobe *tu, #ifdef CONFIG_BPF_EVENTS if (bpf_prog_array_valid(call)) { + const struct bpf_prog_array *array; u32 ret; - ret = bpf_prog_run_array_uprobe(call->prog_array, regs, bpf_prog_run); + rcu_read_lock_trace(); + array = rcu_dereference_check(call->prog_array, rcu_read_lock_trace_held()); + ret = bpf_prog_run_array_uprobe(array, regs, bpf_prog_run); + rcu_read_unlock_trace(); if (!ret) return; } -- 2.34.1

2 1