Re: [PATCH v2 1/2] vhost-scsi: use kvzalloc for vq array allocation
Mike Christie <[email protected]> Thu, 6 Aug 2026 13:30:04 -0500
| Newsgroups | dev.linux.lists.virtualization,org.kernel.vger.kvm |
|---|---|
| Message-ID | <[email protected]> |
On 8/2/26 12:24 PM, Dongli Zhang wrote: > vhost_scsi_open() allocates one "struct vhost_scsi_virtqueue" for each > virtqueue. With large max_io_vqs values, this array can require a > high-order contiguous allocation and trigger a page allocator warning. > > hv# cat /sys/module/vhost_scsi/parameters/max_io_vqs > 256 > > [ 766.075787] ------------[ cut here ]------------ > [ 766.077030] WARNING: mm/page_alloc.c:5280 at __alloc_frozen_pages_noprof+0x32c/0x15c0, CPU#23: qemu-system-x86/5964 > ... ... > [ 766.080351] RIP: 0010:__alloc_frozen_pages_noprof+0x32c/0x15c0 > ... ... > [ 766.085813] Call Trace: > [ 766.085969] <TASK> > [ 766.086098] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 766.086365] ? context_struct_compute_av+0x38a/0x4b0 > [ 766.086652] alloc_pages_mpol+0x9f/0x170 > [ 766.086883] ___kmalloc_large_node+0xb6/0xd0 > [ 766.087124] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 766.087389] __kmalloc_large_node_noprof+0x18/0xa0 > [ 766.087655] __kmalloc_noprof+0x3a0/0x440 > [ 766.087877] ? vhost_scsi_open+0xcb/0x2d0 [vhost_scsi] > [ 766.088162] vhost_scsi_open+0xcb/0x2d0 [vhost_scsi] > [ 766.088449] misc_open+0x123/0x160 > [ 766.088679] chrdev_open+0xb1/0x230 > [ 766.088885] ? __pfx_chrdev_open+0x10/0x10 > [ 766.089157] do_dentry_open+0x11a/0x470 > [ 766.089389] vfs_open+0x29/0xf0 > [ 766.089596] path_openat+0x7c0/0x1100 > [ 766.089821] do_file_open+0xdd/0x190 > [ 766.090032] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 766.090332] do_sys_openat2+0x7e/0x100 > [ 766.090601] __x64_sys_openat+0x51/0xa0 > [ 766.090857] do_syscall_64+0xfe/0x590 > [ 766.091087] entry_SYSCALL_64_after_hwframe+0x77/0x7f > [ 766.091411] RIP: 0033:0x7f9525a11fa6 > > The array does not require physical contiguity, so allocate it with > kvzalloc_objs() and free it with kvfree(). > > Signed-off-by: Dongli Zhang <[email protected]> Reviewed-by: Mike Christie <[email protected]>