[PATCHv7 RESEND wireguard 2/2] wireguard: selftests: update to using nft for qemu test

2025-05-27 Thread Hangbin Liu
Since we will replace iptables with nft for wireguard netns testing,
let's also convert the qemu test to use nft at the same time.

Co-developed-by: Phil Sutter 
Signed-off-by: Phil Sutter 
Signed-off-by: Hangbin Liu 
---
 .../testing/selftests/wireguard/qemu/Makefile | 36 ++-
 .../selftests/wireguard/qemu/kernel.config|  7 ++--
 2 files changed, 30 insertions(+), 13 deletions(-)

diff --git a/tools/testing/selftests/wireguard/qemu/Makefile 
b/tools/testing/selftests/wireguard/qemu/Makefile
index 35856b11c143..2442ae99f007 100644
--- a/tools/testing/selftests/wireguard/qemu/Makefile
+++ b/tools/testing/selftests/wireguard/qemu/Makefile
@@ -40,7 +40,9 @@ endef
 $(eval $(call 
tar_download,IPERF,iperf,3.11,.tar.gz,https://downloads.es.net/pub/iperf/,de8cb409fad61a0574f4cb07eb19ce1159707403ac2dc01b5d175e91240b7e5f))
 $(eval $(call 
tar_download,BASH,bash,5.1.16,.tar.gz,https://ftp.gnu.org/gnu/bash/,5bac17218d3911834520dad13cd1f85ab944e1c09ae1aba55906be1f8192f558))
 $(eval $(call 
tar_download,IPROUTE2,iproute2,5.17.0,.tar.gz,https://www.kernel.org/pub/linux/utils/net/iproute2/,bda331d5c4606138892f23a565d78fca18919b4d508a0b7ca8391c2da2db68b9))
-$(eval $(call 
tar_download,IPTABLES,iptables,1.8.7,.tar.bz2,https://www.netfilter.org/projects/iptables/files/,c109c96bb04998cd44156622d36f8e04b140701ec60531a10668cfdff5e8d8f0))
+$(eval $(call 
tar_download,LIBMNL,libmnl,1.0.5,.tar.bz2,https://www.netfilter.org/projects/libmnl/files/,274b9b919ef3152bfb3da3a13c950dd60d6e2bcd54230ffeca298d03b40d0525))
+$(eval $(call 
tar_download,LIBNFTNL,libnftnl,1.2.8,.tar.xz,https://www.netfilter.org/projects/libnftnl/files/,37fea5d6b5c9b08de7920d298de3cdc942e7ae64b1a3e8b880b2d390ae67ad95))
+$(eval $(call 
tar_download,NFTABLES,nftables,1.1.1,.tar.xz,https://www.netfilter.org/projects/nftables/files/,6358830f3a64f31e39b0ad421d7dadcd240b72343ded48d8ef13b8faf204865a))
 $(eval $(call 
tar_download,NMAP,nmap,7.92,.tgz,https://nmap.org/dist/,064183ea642dc4c12b1ab3b5358ce1cef7d2e7e11ffa2849f16d339f5b717117))
 $(eval $(call 
tar_download,IPUTILS,iputils,s20190709,.tar.gz,https://github.com/iputils/iputils/archive/s20190709.tar.gz/#,a15720dd741d7538dd2645f9f516d193636ae4300ff7dbc8bfca757bf166490a))
 $(eval $(call 
tar_download,WIREGUARD_TOOLS,wireguard-tools,1.0.20210914,.tar.xz,https://git.zx2c4.com/wireguard-tools/snapshot/,97ff31489217bb265b7ae850d3d0f335ab07d2652ba1feec88b734bc96bd05ac))
@@ -322,8 +324,7 @@ $(BUILD_PATH)/init-cpio-spec.txt: 
$(TOOLCHAIN_PATH)/.installed $(BUILD_PATH)/ini
echo "file /bin/ss $(IPROUTE2_PATH)/misc/ss 755 0 0" >> $@
echo "file /bin/ping $(IPUTILS_PATH)/ping 755 0 0" >> $@
echo "file /bin/ncat $(NMAP_PATH)/ncat/ncat 755 0 0" >> $@
-   echo "file /bin/xtables-legacy-multi 
$(IPTABLES_PATH)/iptables/xtables-legacy-multi 755 0 0" >> $@
-   echo "slink /bin/iptables xtables-legacy-multi 777 0 0" >> $@
+   echo "file /bin/nft $(NFTABLES_PATH)/src/nft 755 0 0" >> $@
echo "slink /bin/ping6 ping 777 0 0" >> $@
echo "dir /lib 755 0 0" >> $@
echo "file /lib/libc.so $(TOOLCHAIN_PATH)/$(CHOST)/lib/libc.so 755 0 0" 
>> $@
@@ -338,7 +339,7 @@ $(KERNEL_BUILD_PATH)/.config: $(TOOLCHAIN_PATH)/.installed 
kernel.config arch/$(
cd $(KERNEL_BUILD_PATH) && ARCH=$(KERNEL_ARCH) 
$(KERNEL_PATH)/scripts/kconfig/merge_config.sh -n $(KERNEL_BUILD_PATH)/.config 
$(KERNEL_BUILD_PATH)/minimal.config
$(if $(findstring yes,$(DEBUG_KERNEL)),cp debug.config 
$(KERNEL_BUILD_PATH) && cd $(KERNEL_BUILD_PATH) && ARCH=$(KERNEL_ARCH) 
$(KERNEL_PATH)/scripts/kconfig/merge_config.sh -n $(KERNEL_BUILD_PATH)/.config 
debug.config,)
 
-$(KERNEL_BZIMAGE): $(TOOLCHAIN_PATH)/.installed $(KERNEL_BUILD_PATH)/.config 
$(BUILD_PATH)/init-cpio-spec.txt $(IPERF_PATH)/src/iperf3 $(IPUTILS_PATH)/ping 
$(BASH_PATH)/bash $(IPROUTE2_PATH)/misc/ss $(IPROUTE2_PATH)/ip/ip 
$(IPTABLES_PATH)/iptables/xtables-legacy-multi $(NMAP_PATH)/ncat/ncat 
$(WIREGUARD_TOOLS_PATH)/src/wg $(BUILD_PATH)/init
+$(KERNEL_BZIMAGE): $(TOOLCHAIN_PATH)/.installed $(KERNEL_BUILD_PATH)/.config 
$(BUILD_PATH)/init-cpio-spec.txt $(IPERF_PATH)/src/iperf3 $(IPUTILS_PATH)/ping 
$(BASH_PATH)/bash $(IPROUTE2_PATH)/misc/ss $(IPROUTE2_PATH)/ip/ip 
$(LIBMNL_PATH)/libmnl $(LIBNFTNL_PATH)/libnftnl $(NFTABLES_PATH)/src/nft 
$(NMAP_PATH)/ncat/ncat $(WIREGUARD_TOOLS_PATH)/src/wg $(BUILD_PATH)/init
$(MAKE) -C $(KERNEL_PATH) O=$(KERNEL_BUILD_PATH) ARCH=$(KERNEL_ARCH) 
CROSS_COMPILE=$(CROSS_COMPILE)
 .PHONY: $(KERNEL_BZIMAGE)
 
@@ -421,15 +422,32 @@ $(IPROUTE2_PATH)/misc/ss: | $(IPROUTE2_PATH)/.installed 
$(USERSPACE_DEPS)
$(MAKE) -C $(IPROUTE2_PATH) PREFIX=/ misc/ss
$(STRIP) -s $@
 
-$(IPTABLES_PATH)/.installed: $(IPTABLES_TAR)
+$(LIBMNL_PATH)/.installed: $(LIBMNL_TAR)
mkdir -p $(BUILD_PATH)
flock -s $<.lock tar -C $(BUILD_PATH) -xf $<
-   sed -i -e "/nfnetlink=[01]/s:=[01]:=0:" -e 
"/nfconntrack=[01]/s:=[01]:=0:" $(IPTABLES_PATH)/configure
touch $@
 
-$(IPTABLES_PATH

[PATCH v3 4/6] modpost: Create modalias for builtin modules

2025-05-27 Thread Alexey Gladkov
For some modules, modalias is generated using the modpost utility and
the section is added to the module file.

When a module is added inside vmlinux, modpost does not generate
modalias for such modules and the information is lost.

As a result kmod (which uses modules.builtin.modinfo in userspace)
cannot determine that modalias is handled by a builtin kernel module.

$ cat /sys/devices/pci:00/:00:14.0/modalias
pci:v8086dA36Dsv1043sd8694bc0Csc03i30

$ modinfo xhci_pci
name:   xhci_pci
filename:   (builtin)
license:GPL
file:   drivers/usb/host/xhci-pci
description:xHCI PCI Host Controller Driver

Missing modalias "pci:v*d*sv*sd*bc0Csc03i30*" which will be generated by
modpost if the module is built separately.

To fix this it is necessary to generate the same modalias for vmlinux as
for the individual modules. Fortunately '.vmlinux.export.o' is already
generated from which '.modinfo' can be extracted in the same way as for
vmlinux.o.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Alexey Gladkov 
Reviewed-by: Petr Pavlu 
---
 include/linux/module.h   |  4 
 scripts/mod/file2alias.c | 16 
 scripts/mod/modpost.c| 13 -
 scripts/mod/modpost.h|  2 ++
 4 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index e7506684069d..0be9b0f1660e 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -259,14 +259,10 @@ struct module_kobject 
*lookup_or_create_module_kobject(const char *name);
__PASTE(type,   \
__PASTE(__, name)))
 
-#ifdef MODULE
 /* Creates an alias so file2alias.c can find device table. */
 #define MODULE_DEVICE_TABLE(type, name)\
 extern typeof(name) __mod_device_table(type, name) \
   __attribute__ ((unused, alias(__stringify(name
-#else  /* !MODULE */
-#define MODULE_DEVICE_TABLE(type, name)
-#endif
 
 /* Version of form [:][-].
  * Or for CVS/RCS ID version, everything but the number is stripped.
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index dff1799a4c79..d42f2c742fd6 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1527,5 +1527,21 @@ void handle_moddevtable(struct module *mod, struct 
elf_info *info,
}
}
 
+   if (mod->is_vmlinux) {
+   struct module_alias *alias;
+
+   /*
+* If this is vmlinux, record the name of the builtin module.
+* Traverse the linked list in the reverse order, and set the
+* builtin_modname unless it has already been set in the
+* previous call.
+*/
+   list_for_each_entry_reverse(alias, &mod->aliases, node) {
+   if (alias->builtin_modname)
+   break;
+   alias->builtin_modname = xstrndup(modname, modnamelen);
+   }
+   }
+
free(zeros);
 }
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index be89921d60b6..c7c601c6f82d 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -2021,11 +2021,22 @@ static void write_if_changed(struct buffer *b, const 
char *fname)
 static void write_vmlinux_export_c_file(struct module *mod)
 {
struct buffer buf = { };
+   struct module_alias *alias, *next;
 
buf_printf(&buf,
-  "#include \n");
+  "#include \n"
+  "#include \n");
 
add_exported_symbols(&buf, mod);
+
+   list_for_each_entry_safe(alias, next, &mod->aliases, node) {
+   buf_printf(&buf, "MODULE_ALIAS_MODNAME(\"%s\", \"%s\");\n",
+  alias->builtin_modname, alias->str);
+   list_del(&alias->node);
+   free(alias->builtin_modname);
+   free(alias);
+   }
+
write_if_changed(&buf, ".vmlinux.export.c");
free(buf.p);
 }
diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
index 9133e4c3803f..2aecb8f25c87 100644
--- a/scripts/mod/modpost.h
+++ b/scripts/mod/modpost.h
@@ -99,10 +99,12 @@ buf_write(struct buffer *buf, const char *s, int len);
  * struct module_alias - auto-generated MODULE_ALIAS()
  *
  * @node: linked to module::aliases
+ * @modname: name of the builtin module (only for vmlinux)
  * @str: a string for MODULE_ALIAS()
  */
 struct module_alias {
struct list_head node;
+   char *builtin_modname;
char str[];
 };
 
-- 
2.49.0




[PATCH v3 3/6] modpost: Make mod_device_table aliases more unique

2025-05-27 Thread Alexey Gladkov
In order to avoid symbol conflicts if they appear in the same binary, a
more unique alias identifier can be generated.

Signed-off-by: Alexey Gladkov 
Reviewed-by: Petr Pavlu 
---
 include/linux/module.h   | 14 --
 scripts/mod/file2alias.c | 18 ++
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index 88048561360f..e7506684069d 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -249,10 +249,20 @@ struct module_kobject 
*lookup_or_create_module_kobject(const char *name);
 /* What your module does. */
 #define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
 
+/* Format: __mod_device_tablekmod_ */
+#define __mod_device_table(type, name) \
+   __PASTE(__mod_device_table__,   \
+   __PASTE(__COUNTER__,\
+   __PASTE(__, \
+   __PASTE(__KBUILD_MODNAME,   \
+   __PASTE(__, \
+   __PASTE(type,   \
+   __PASTE(__, name)))
+
 #ifdef MODULE
 /* Creates an alias so file2alias.c can find device table. */
-#define MODULE_DEVICE_TABLE(type, name)
\
-extern typeof(name) __mod_device_table__##type##__##name   \
+#define MODULE_DEVICE_TABLE(type, name)\
+extern typeof(name) __mod_device_table(type, name) \
   __attribute__ ((unused, alias(__stringify(name
 #else  /* !MODULE */
 #define MODULE_DEVICE_TABLE(type, name)
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 00586119a25b..dff1799a4c79 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1476,8 +1476,8 @@ void handle_moddevtable(struct module *mod, struct 
elf_info *info,
 {
void *symval;
char *zeros = NULL;
-   const char *type, *name;
-   size_t typelen;
+   const char *type, *name, *modname;
+   size_t typelen, modnamelen;
static const char *prefix = "__mod_device_table__";
 
/* We're looking for a section relative symbol */
@@ -1488,10 +1488,20 @@ void handle_moddevtable(struct module *mod, struct 
elf_info *info,
if (ELF_ST_TYPE(sym->st_info) != STT_OBJECT)
return;
 
-   /* All our symbols are of form __mod_device_table. */
+   /* All our symbols are of form 
__mod_device_tablekmod_. */
if (!strstarts(symname, prefix))
return;
-   type = symname + strlen(prefix);
+
+   modname = strstr(symname, "__kmod_");
+   if (!modname)
+   return;
+   modname += strlen("__kmod_");
+
+   type = strstr(modname, "__");
+   if (!type)
+   return;
+   modnamelen = type - modname;
+   type += strlen("__");
 
name = strstr(type, "__");
if (!name)
-- 
2.49.0




Re: [PATCH v3] media: add virtio-media driver

2025-05-27 Thread Mauro Carvalho Chehab
Em Tue, 27 May 2025 15:14:50 +0900
"Alexandre Courbot"  escreveu:

> Hi Mauro,
> 
> On Mon May 26, 2025 at 9:13 PM JST, Mauro Carvalho Chehab wrote:
> > Hi Michael,
> >
> > Em Sat, 12 Apr 2025 13:08:01 +0900
> > Alexandre Courbot  escreveu:
> >  
> >> Add the first version of the virtio-media driver.
> >>
> >> This driver acts roughly as a V4L2 relay between user-space and the
> >> virtio virtual device on the host, so it is relatively simple, yet
> >> unconventional. It doesn't use VB2 or other frameworks typically used in
> >> a V4L2 driver, and most of its complexity resides in correctly and
> >> efficiently building the virtio descriptor chain to pass to the host,
> >> avoiding copies whenever possible. This is done by
> >> scatterlist_builder.[ch].
> >>
> >> virtio_media_ioctls.c proxies each supported ioctl to the host, using
> >> code generated through macros for ioctls that can be forwarded directly,
> >> which is most of them.
> >>
> >> virtio_media_driver.c provides the expected driver hooks, and support
> >> for mmapping and polling.
> >>
> >>  This version supports MMAP buffers, while USERPTR buffers can also be
> >>  enabled through a driver option. DMABUF support is still pending.  
> >
> > It sounds that you applied this one at the virtio tree, but it hasn't
> > being reviewed or acked by media maintainers.
> >
> > Please drop it.
> >
> > Alexandre,
> >
> > Please send media patches to media maintainers, c/c other subsystem
> > maintainers, as otherwise they might end being merged without a
> > proper review.  
> 
> Sorry about that, I put everyone in "To:" without giving it a second
> thought.
> 
> >
> > In this particular case, we need to double-check if this won't cause
> > any issues, in special with regards to media locks and mutexes.  
> 
> Agreed, I am not 100% confident about that part myself.
> 
> >
> > I'll try to look on it after this merge window, as it is too late
> > for it to be applied during this one.  
> 
> Appreciate that - given the high traffic on the list I was worried that
> this patch would eventually be overlooked. Not making it for this merge
> window should not be a problem, so please take the time you need.

Provided that your patch was caught by patchwork, it won't be lost:

https://patchwork.linuxtv.org/project/linux-media/patch/20250412-virtio-media-v3-1-97dc94c18...@gmail.com/

Please notice that our CI got a number of checkpatch issues there. 
Please check and fix the non-false-positive ones.

Btw, I was looking at:

https://github.com/chromeos/virtio-media

(I'm assuming that this is the QEMU counterpart, right?)

And I noticed something weird there:

"Unsupported ioctls

 A few ioctls are replaced by other, more suitable mechanisms. If being 
requested these ioctls, the device must return the same response as it would 
for an unknown ioctl, i.e. ENOTTY.

VIDIOC_QUERYCAP is replaced by reading the configuration area.
VIDIOC_DQBUF is replaced by a dedicated event.
VIDIOC_DQEVENT is replaced by a dedicated event."

While this could be ok for cromeOS, this will be broken for guests with 
Linux, as all Linux applications rely on VIDIOC_QUERYCAP and VIDIOC_DQBUF
to work. Please implement support for it, as otherwise we won't even be
able to test the driver with the v4l2-compliance tool (*).

(*) Passing at v4l2-compliance is a requirement for any media driver
to be merged.

With regards to testing, what's the expected testing scenario?
My guess is that, as a virtio device, a possible test scenario would be
to have the UVC camera from the host OS mapped using virtio-camera into 
the guest OS, allowing a V4L2 application running at the guest to map the 
camera from the host, right?

Regards,
Mauro



[PATCH net-next] selftest: Add selftest for multicast address notifications

2025-05-27 Thread Yuyang Huang
This commit adds a new kernel selftest to verify RTNLGRP_IPV4_MCADDR
and RTNLGRP_IPV6_MCADDR notifications. The test works by adding and
removing a dummy interface and then confirming that the system
correctly receives join and removal notifications for the 224.0.0.1
and ff02::1 multicast addresses.

The test relies on the iproute2 version to be 6.13+.

Tested by the following command:
$ vng -v --user root --cpus 16 -- \
make -C tools/testing/selftests TARGETS=net TEST_PROGS=rtnetlink.sh \
TEST_GEN_PROGS="" run_tests

Cc: Maciej Żenczykowski 
Cc: Lorenzo Colitti 
Signed-off-by: Yuyang Huang 
---
 tools/testing/selftests/net/rtnetlink.sh | 34 
 1 file changed, 34 insertions(+)

diff --git a/tools/testing/selftests/net/rtnetlink.sh 
b/tools/testing/selftests/net/rtnetlink.sh
index 2e8243a65b50..9dbcaaeaf8cd 100755
--- a/tools/testing/selftests/net/rtnetlink.sh
+++ b/tools/testing/selftests/net/rtnetlink.sh
@@ -21,6 +21,7 @@ ALL_TESTS="
kci_test_vrf
kci_test_encap
kci_test_macsec
+   kci_test_mcast_addr_notification
kci_test_ipsec
kci_test_ipsec_offload
kci_test_fdb_get
@@ -1334,6 +1335,39 @@ kci_test_mngtmpaddr()
return $ret
 }
 
+kci_test_mcast_addr_notification()
+{
+   local tmpfile
+   local monitor_pid
+   local match_result
+
+   tmpfile=$(mktemp)
+
+   ip monitor maddr > $tmpfile &
+   monitor_pid=$!
+   sleep 1
+
+   run_cmd ip link add name test-dummy1 type dummy
+   run_cmd ip link set test-dummy1 up
+   run_cmd ip link del dev test-dummy1
+   sleep 1
+
+   match_result=$(grep -cE "test-dummy1.*(224.0.0.1|ff02::1)" $tmpfile)
+
+   kill $monitor_pid
+   rm $tmpfile
+   # There should be 4 line matches as follows.
+   # 13: test-dummy1    inet6 mcast ff02::1 scope global 
+   # 13: test-dummy1    inet mcast 224.0.0.1 scope global 
+   # Deleted 13: test-dummy1    inet mcast 224.0.0.1 scope global 
+   # Deleted 13: test-dummy1    inet6 mcast ff02::1 scope global 
+   if [ $match_result -ne 4 ];then
+   end_test "FAIL: mcast addr notification"
+   return 1
+   fi
+   end_test "PASS: mcast addr notification"
+}
+
 kci_test_rtnl()
 {
local current_test
-- 
2.49.0.1204.g71687c7c1d-goog




Re: [PATCH bpf-next v2 1/2] bpf, arm64: Support up to 12 function arguments

2025-05-27 Thread Alexis Lothoré
On Tue May 27, 2025 at 11:09 AM CEST, Xu Kuohai wrote:
> On 5/27/2025 4:45 PM, Alexis Lothoré wrote:
>
> [...]
>
 +  /* We can not know for sure about exact alignment needs for
 +   * struct passed on stack, so deny those
 +   */
 +  if (m->arg_flags[i] & BTF_FMODEL_STRUCT_ARG)
 +  return -EOPNOTSUPP;
>>> leave the error code as is, namely, return -ENOTSUPP?
>> Actually this change follows a complaint from checkpatch:
>> 
>> "WARNING: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP"
>
> Seems we can just ignore this warning, as ENOTSUPP is already used
> throughout bpf, and the actual value -524 is well recognized.

Ok, then I'll switch it back to ENOTSUPP


-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com




[PATCH v3 6/6] kbuild: Create modules.builtin.modinfo for modpost results

2025-05-27 Thread Alexey Gladkov
Create modules.builtin.modinfo as a combination of modinfo from vmlinux
and the result of generating modalias by modpost.

Signed-off-by: Alexey Gladkov 
---
 scripts/Makefile.vmlinux | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index 250c0492b7e0..8fed895fd858 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -70,6 +70,18 @@ endif
 ifdef CONFIG_MODULES
 targets += .vmlinux.export.o
 $(vmlinux-final): .vmlinux.export.o
+
+# .module.builtin.modinfo.modpost
+# ---
+__default: .modules.builtin.modinfo.modpost
+
+OBJCOPYFLAGS_.modules.builtin.modinfo.modpost := -j .modinfo -O binary
+
+targets += .modules.builtin.modinfo.modpost
+.modules.builtin.modinfo.modpost: .vmlinux.export.o FORCE
+   $(call if_changed,objcopy)
+
+modules.builtin.modinfo: .modules.builtin.modinfo.modpost
 endif
 
 ifdef CONFIG_ARCH_WANTS_PRE_LINK_VMLINUX
@@ -97,14 +109,26 @@ ifdef CONFIG_BUILDTIME_TABLE_SORT
 $(vmlinux-final): scripts/sorttable
 endif
 
+# .module.builtin.modinfo.vmlinux
+# ---
+__default: .modules.builtin.modinfo.vmlinux
+
+OBJCOPYFLAGS_.modules.builtin.modinfo.vmlinux := -j .modinfo -O binary
+
+targets += .modules.builtin.modinfo.vmlinux
+.modules.builtin.modinfo.vmlinux: vmlinux.o FORCE
+   $(call if_changed,objcopy)
+
 # modules.builtin.modinfo
 # ---
 
-OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
+quiet_cmd_modules_builtin_modinfo = GEN $@
+  cmd_modules_builtin_modinfo = \
+   cat $< $(wildcard .modules.builtin.modinfo.modpost) > $@
 
 targets += modules.builtin.modinfo
-modules.builtin.modinfo: vmlinux.o FORCE
-   $(call if_changed,objcopy)
+modules.builtin.modinfo: .modules.builtin.modinfo.vmlinux FORCE
+   $(call if_changed,modules_builtin_modinfo)
 
 # modules.builtin
 # ---
-- 
2.49.0




[PATCH v3 2/6] modules: Add macros to specify modinfo prefix

2025-05-27 Thread Alexey Gladkov
The __MODULE_INFO macros always use __MODULE_INFO_PREFIX. The only way
to use a different prefix is to override __MODULE_INFO_PREFIX, which is
not very useful.

The new macro will be used in file2alias.c to generate modalias for
builtin modules.

Signed-off-by: Alexey Gladkov 
Reviewed-by: Petr Pavlu 
---
 include/linux/module.h  | 3 +++
 include/linux/moduleparam.h | 7 +--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index 8050f77c3b64..88048561360f 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -170,6 +170,9 @@ struct module_kobject 
*lookup_or_create_module_kobject(const char *name);
 /* For userspace: you can also call me... */
 #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
 
+#define MODULE_ALIAS_MODNAME(_modname, _alias) \
+   __MODULE_INFO_WITH_PREFIX(_modname ".", alias, alias, _alias)
+
 /* Soft module dependencies. See man modprobe.d for details.
  * Example: MODULE_SOFTDEP("pre: module-foo module-bar post: module-baz")
  */
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index bfb85fd13e1f..3f819fc67c43 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -20,10 +20,13 @@
 /* Chosen so that structs with an unsigned long line up. */
 #define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long))
 
-#define __MODULE_INFO(tag, name, info)   \
+#define __MODULE_INFO_WITH_PREFIX(prefix, tag, name, info)   \
static const char __UNIQUE_ID(name)[] \
__used __section(".modinfo") __aligned(1) \
-   = __MODULE_INFO_PREFIX __stringify(tag) "=" info
+   = prefix __stringify(tag) "=" info
+
+#define __MODULE_INFO(tag, name, info)   \
+   __MODULE_INFO_WITH_PREFIX(__MODULE_INFO_PREFIX, tag, name, info)
 
 #define __MODULE_PARM_TYPE(name, _type)
  \
__MODULE_INFO(parmtype, name##type, #name ":" _type)
-- 
2.49.0




Re: [PATCH 2/3] modpost: allow "make nsdeps" to skip module-specific symbol namespace

2025-05-27 Thread Petr Pavlu
On 5/22/25 09:17, Masahiro Yamada wrote:
> When MODULE_IMPORT_NS() is missing, "make nsdeps" runs the Coccinelle
> script to automatically add MODULE_IMPORT_NS() to each module.
> 
> This should not occur for users of EXPORT_SYMBOL_GPL_FOR_MODULES(), which
> is intended to export a symbol to a specific module only. In such cases,
> explicitly adding MODULE_IMPORT_NS("module:...") is disallowed.
> 
> This commit handles the latter case separately in order not to trigger
> the Coccinelle, and displays the error message:
> 
>   ERROR: modpost: module "foo" uses symbol "bar", which is exported only for 
> module "baz"
> 
> Apply the same logic for kernel space as well.
> 
> Fixes: 092a4f5985f2 ("module: Add module specific symbol namespace support")
> Signed-off-by: Masahiro Yamada 

Looks ok to me.

Reviewed-by: Petr Pavlu 

Does this patch make the following note about nsdeps in
Documentation/core-api/symbol-namespaces.rst (currently only in
linux-next) obsolete and can it now be removed?

"""
Note: it will happily generate an import statement for the module namespace;
which will not work and generates build and runtime failures.
"""

-- 
Thanks,
Petr



Re: [PATCH net-next v6 0/5] vsock: SOCK_LINGER rework

2025-05-27 Thread patchwork-bot+netdevbpf
Hello:

This series was applied to netdev/net-next.git (main)
by Paolo Abeni :

On Thu, 22 May 2025 01:18:20 +0200 you wrote:
> Change vsock's lingerning to wait on close() until all data is sent, i.e.
> until workers picked all the packets for processing.
> 
> Changes in v6:
> - Make vsock_wait_sent() return bool, parametrize enable_so_linger() with
>   timeout, don't open code DIV_ROUND_UP [Stefano]
> - Link to v5: 
> https://lore.kernel.org/r/20250521-vsock-linger-v5-0-94827860d...@rbox.co
> 
> [...]

Here is the summary with links:
  - [net-next,v6,1/5] vsock/virtio: Linger on unsent data
https://git.kernel.org/netdev/net-next/c/1c39f5dbbfd2
  - [net-next,v6,2/5] vsock: Move lingering logic to af_vsock core
https://git.kernel.org/netdev/net-next/c/5ec40864aaec
  - [net-next,v6,3/5] vsock/test: Introduce vsock_wait_sent() helper
https://git.kernel.org/netdev/net-next/c/e78e0596c762
  - [net-next,v6,4/5] vsock/test: Introduce enable_so_linger() helper
https://git.kernel.org/netdev/net-next/c/8b07b7e5c253
  - [net-next,v6,5/5] vsock/test: Add test for an unexpectedly lingering close()
https://git.kernel.org/netdev/net-next/c/393d070135ad

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html





[PATCH bpf-next v3 0/2] bpf, arm64: support up to 12 arguments

2025-05-27 Thread Alexis Lothoré
Hello,

this is the v2 of the many args series for arm64, being itself a revival
of Xu Kuhoai's work to enable larger arguments count for BPF programs on
ARM64 ([1]).

The discussions in v1 shed some light on some issues around specific
cases, for example with functions passing struct on stack with custom
packing/alignment attributes: those cases can not be properly detected
with the current BTF info. So this new revision aims to separate
concerns with a simpler implementation, just accepting additional args
on stack if we can make sure about the alignment constraints (and so,
refusing attachment to functions passing structs on stacks). I then
checked if the specific alignment constraints could be checked with
larger scalar types rather than structs, but it appears that this use
case is in fact rejected at the verifier level (see a9b59159d338 ("bpf:
Do not allow btf_ctx_access with __int128 types")). So in the end the
specific alignment corner cases raised in [1] can not really happen in
the kernel in its current state. This new revision still brings support
for the standard cases as a first step, it will then be possible to
iterate on top of it to add the more specific cases like struct passed
on stack and larger types.

[1] 
https://lore.kernel.org/all/20230917150752.69612-1-xukuo...@huaweicloud.com/#t

Signed-off-by: Alexis Lothoré (eBPF Foundation) 
---
Changes in v3:
- switch back -EOPNOTSUPP to -ENOTSUPP
- fix comment style
- group intializations for arg_aux
- remove some unneeded round_up
- Link to v2: 
https://lore.kernel.org/r/20250522-many_args_arm64-v2-0-d6afdb9cf...@bootlin.com

Changes in v2:
- remove alignment computation from btf.c
- deduce alignment constraints directly in jit compiler for simple types
- deny attachment to functions with "corner-cases" arguments (ie:
  structs on stack)
- remove custom tests, as the corresponding use cases are locked either
  by the JIT comp or the verifier
- drop RFC
- Link to v1: 
https://lore.kernel.org/r/20250411-many_args_arm64-v1-0-0a32fe723...@bootlin.com

---
Alexis Lothoré (eBPF Foundation) (1):
  selftests/bpf: enable many-args tests for arm64

Xu Kuohai (1):
  bpf, arm64: Support up to 12 function arguments

 arch/arm64/net/bpf_jit_comp.c| 225 ---
 tools/testing/selftests/bpf/DENYLIST.aarch64 |   2 -
 2 files changed, 171 insertions(+), 56 deletions(-)
---
base-commit: 9435138c069117cd59a4912b5ea2ae44cc2c5ffa
change-id: 20250220-many_args_arm64-8bd3747e6948

Best regards,
-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com




[PATCH bpf-next v3 1/2] bpf, arm64: Support up to 12 function arguments

2025-05-27 Thread Alexis Lothoré
From: Xu Kuohai 

Currently ARM64 bpf trampoline supports up to 8 function arguments.
According to the statistics from commit
473e3150e30a ("bpf, x86: allow function arguments up to 12 for TRACING"),
there are about 200 functions accept 9 to 12 arguments, so adding support
for up to 12 function arguments.

Due to bpf only supporting function arguments up to 16 bytes, according to
AAPCS64, starting from the first argument, each argument is first
attempted to be loaded to 1 or 2 smallest registers from x0-x7, if there
are no enough registers to hold the entire argument, then all remaining
arguments starting from this one are pushed to the stack for passing.
There are some non-trivial cases for which it is not possible to
correctly read arguments from/write arguments to the stack: for example
struct variables may have custom packing/alignment attributes that are
invisible in BTF info. Such cases are denied for now to make sure not to
read incorrect values.

Signed-off-by: Xu Kuohai 
Co-developed-by: Alexis Lothoré (eBPF Foundation) 
Signed-off-by: Alexis Lothoré (eBPF Foundation) 
---
Changes in v3:
- switch back -EOPNOTSUPP to -ENOTSUPP
- fix comment style
- remove useless round_up calls
- group initializations for arg_aux structure

Changes in v2:
- refuse attachment to functions passing structs on stack
- use simpler alignment rules for args passed on stack, assuming that
  exotic types are denied either by the verifier and/or the trampoline
  generation code
---
 arch/arm64/net/bpf_jit_comp.c | 225 --
 1 file changed, 171 insertions(+), 54 deletions(-)

diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 
70d7c89d3ac907798e86e0051e7b472c252c1412..b5c3ab6235362cf660da4b02d7381509fc17dcdf
 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -2064,7 +2064,7 @@ bool bpf_jit_supports_subprog_tailcalls(void)
 }
 
 static void invoke_bpf_prog(struct jit_ctx *ctx, struct bpf_tramp_link *l,
-   int args_off, int retval_off, int run_ctx_off,
+   int bargs_off, int retval_off, int run_ctx_off,
bool save_ret)
 {
__le32 *branch;
@@ -2106,7 +2106,7 @@ static void invoke_bpf_prog(struct jit_ctx *ctx, struct 
bpf_tramp_link *l,
branch = ctx->image + ctx->idx;
emit(A64_NOP, ctx);
 
-   emit(A64_ADD_I(1, A64_R(0), A64_SP, args_off), ctx);
+   emit(A64_ADD_I(1, A64_R(0), A64_SP, bargs_off), ctx);
if (!p->jited)
emit_addr_mov_i64(A64_R(1), (const u64)p->insnsi, ctx);
 
@@ -2131,7 +2131,7 @@ static void invoke_bpf_prog(struct jit_ctx *ctx, struct 
bpf_tramp_link *l,
 }
 
 static void invoke_bpf_mod_ret(struct jit_ctx *ctx, struct bpf_tramp_links *tl,
-  int args_off, int retval_off, int run_ctx_off,
+  int bargs_off, int retval_off, int run_ctx_off,
   __le32 **branches)
 {
int i;
@@ -2141,7 +2141,7 @@ static void invoke_bpf_mod_ret(struct jit_ctx *ctx, 
struct bpf_tramp_links *tl,
 */
emit(A64_STR64I(A64_ZR, A64_SP, retval_off), ctx);
for (i = 0; i < tl->nr_links; i++) {
-   invoke_bpf_prog(ctx, tl->links[i], args_off, retval_off,
+   invoke_bpf_prog(ctx, tl->links[i], bargs_off, retval_off,
run_ctx_off, true);
/* if (*(u64 *)(sp + retval_off) !=  0)
 *  goto do_fexit;
@@ -2155,23 +2155,125 @@ static void invoke_bpf_mod_ret(struct jit_ctx *ctx, 
struct bpf_tramp_links *tl,
}
 }
 
-static void save_args(struct jit_ctx *ctx, int args_off, int nregs)
+struct arg_aux {
+   /* how many args are passed through registers, the rest of the args are
+* passed through stack
+*/
+   int args_in_regs;
+   /* how many registers are used to pass arguments */
+   int regs_for_args;
+   /* how much stack is used for additional args passed to bpf program
+* that did not fit in original function registers
+*/
+   int bstack_for_args;
+   /* home much stack is used for additional args passed to the
+* original function when called from trampoline (this one needs
+* arguments to be properly aligned)
+*/
+   int ostack_for_args;
+};
+
+static int calc_arg_aux(const struct btf_func_model *m,
+struct arg_aux *a)
 {
-   int i;
+   int stack_slots, nregs, slots, i;
+
+   /* verifier ensures m->nr_args <= MAX_BPF_FUNC_ARGS */
+   for (i = 0, nregs = 0; i < m->nr_args; i++) {
+   slots = (m->arg_size[i] + 7) / 8;
+   if (nregs + slots <= 8) /* passed through register ? */
+   nregs += slots;
+   else
+   break;
+   }
+
+   a->args_in_regs = i;
+   a->regs_for_args = nregs;
+   a->ostack_for_args = 

[PATCH bpf-next v3 2/2] selftests/bpf: enable many-args tests for arm64

2025-05-27 Thread eBPF Foundation
Now that support for up to 12 args is enabled for tracing programs on
ARM64, enable the existing tests for this feature on this architecture.

Signed-off-by: Alexis Lothoré (eBPF Foundation) 
---
Changes in v2:
- keep tracing struct tests disabled, as structs passed on stack are not
  handled by the new revision
---
 tools/testing/selftests/bpf/DENYLIST.aarch64 | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/DENYLIST.aarch64 
b/tools/testing/selftests/bpf/DENYLIST.aarch64
index 
6d8feda27ce9de07d77d6e384666082923e3dc76..12e99c0277a8cbf9e63e8f6d3a108c8a1208407b
 100644
--- a/tools/testing/selftests/bpf/DENYLIST.aarch64
+++ b/tools/testing/selftests/bpf/DENYLIST.aarch64
@@ -1,3 +1 @@
-fentry_test/fentry_many_args # 
fentry_many_args:FAIL:fentry_many_args_attach unexpected error: -524
-fexit_test/fexit_many_args   # 
fexit_many_args:FAIL:fexit_many_args_attach unexpected error: -524
 tracing_struct/struct_many_args  # 
struct_many_args:FAIL:tracing_struct_many_args__attach unexpected error: -524

-- 
2.49.0




Re: [PATCH 3/4] selftests/mm: Report unique test names for each cow test

2025-05-27 Thread Lorenzo Stoakes
On Thu, May 22, 2025 at 06:38:52PM +0100, Mark Brown wrote:
> The kselftest framework uses the string logged when a test result is
> reported as the unique identifier for a test, using it to track test
> results between runs. The cow test completely fails to follow this pattern,
> it runs test functions repeatedly with various parameters with each result
> report from those functions being a string logging an error message which
> is fixed between runs.
>
> Since the code already logs each test uniquely before it starts refactor
> to also print this to a buffer, then use that name as the test result.
> This isn't especially pretty but is relatively straightforward and is a
> great help to tooling.
>
> Signed-off-by: Mark Brown 
> ---
>  tools/testing/selftests/mm/cow.c | 333 
> +--
>  1 file changed, 217 insertions(+), 116 deletions(-)
>
> diff --git a/tools/testing/selftests/mm/cow.c 
> b/tools/testing/selftests/mm/cow.c
> index e70cd3d900cc..a97f5ef79f17 100644
> --- a/tools/testing/selftests/mm/cow.c
> +++ b/tools/testing/selftests/mm/cow.c
> @@ -112,9 +112,12 @@ struct comm_pipes {
>
>  static int setup_comm_pipes(struct comm_pipes *comm_pipes)
>  {
> - if (pipe(comm_pipes->child_ready) < 0)
> + if (pipe(comm_pipes->child_ready) < 0) {
> + ksft_perror("pipe()");
>   return -errno;
> + }
>   if (pipe(comm_pipes->parent_ready) < 0) {
> + ksft_perror("pipe()");
>   close(comm_pipes->child_ready[0]);
>   close(comm_pipes->child_ready[1]);
>   return -errno;
> @@ -207,13 +210,14 @@ static void do_test_cow_in_parent(char *mem, size_t 
> size, bool do_mprotect,
>
>   ret = setup_comm_pipes(&comm_pipes);
>   if (ret) {
> - ksft_test_result_fail("pipe() failed\n");
> + log_test_result(KSFT_FAIL);
>   return;
>   }
>
>   ret = fork();
>   if (ret < 0) {
> - ksft_test_result_fail("fork() failed\n");
> + ksft_perror("fork() failed");
> + log_test_result(KSFT_FAIL);
>   goto close_comm_pipes;
>   } else if (!ret) {
>   exit(fn(mem, size, &comm_pipes));
> @@ -228,9 +232,18 @@ static void do_test_cow_in_parent(char *mem, size_t 
> size, bool do_mprotect,
>* write-faults by directly mapping pages writable.
>*/
>   ret = mprotect(mem, size, PROT_READ);
> - ret |= mprotect(mem, size, PROT_READ|PROT_WRITE);
>   if (ret) {
> - ksft_test_result_fail("mprotect() failed\n");
> + ksft_perror("mprotect() failed");
> + log_test_result(KSFT_FAIL);
> + write(comm_pipes.parent_ready[1], "0", 1);
> + wait(&ret);
> + goto close_comm_pipes;
> + }
> +
> + ret = mprotect(mem, size, PROT_READ|PROT_WRITE);
> + if (ret) {
> + ksft_perror("mprotect() failed");
> + log_test_result(KSFT_FAIL);
>   write(comm_pipes.parent_ready[1], "0", 1);
>   wait(&ret);
>   goto close_comm_pipes;
> @@ -248,16 +261,16 @@ static void do_test_cow_in_parent(char *mem, size_t 
> size, bool do_mprotect,
>   ret = -EINVAL;
>
>   if (!ret) {
> - ksft_test_result_pass("No leak from parent into child\n");
> + log_test_result(KSFT_PASS);
>   } else if (xfail) {
>   /*
>* With hugetlb, some vmsplice() tests are currently expected to
>* fail because (a) harder to fix and (b) nobody really cares.
>* Flag them as expected failure for now.
>*/
> - ksft_test_result_xfail("Leak from parent into child\n");
> + log_test_result(KSFT_XFAIL);
>   } else {
> - ksft_test_result_fail("Leak from parent into child\n");
> + log_test_result(KSFT_FAIL);
>   }
>  close_comm_pipes:
>   close_comm_pipes(&comm_pipes);
> @@ -306,26 +319,29 @@ static void do_test_vmsplice_in_parent(char *mem, 
> size_t size,
>
>   ret = setup_comm_pipes(&comm_pipes);
>   if (ret) {
> - ksft_test_result_fail("pipe() failed\n");
> + log_test_result(KSFT_FAIL);
>   goto free;
>   }
>
>   if (pipe(fds) < 0) {
> - ksft_test_result_fail("pipe() failed\n");
> + ksft_perror("pipe() failed");
> + log_test_result(KSFT_FAIL);
>   goto close_comm_pipes;
>   }
>
>   if (before_fork) {
>   transferred = vmsplice(fds[1], &iov, 1, 0);
>   if (transferred <= 0) {
> - ksft_test_result_fail("vmsplice() failed\n");
> + ksft_print_msg("vmsplice() failed\n");
> + log_test_result(KSFT_FAIL);
> 

Re: [PATCH v3 1/6] scsi: Define MODULE_DEVICE_TABLE only if necessary

2025-05-27 Thread James Bottomley
On Tue, 2025-05-27 at 11:07 +0200, Alexey Gladkov wrote:
> Define MODULE_DEVICE_TABLE only if a structure is defined for it.
> 
> drivers/scsi/BusLogic.c:3735:26: error: use of undeclared identifier
> 'blogic_pci_tbl'
>  3735 | MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);

Well, a) need to cc the scsi list and b) how is this possible when
MODULE_DEVICE_TABLE() has an empty definition if MODULE isn't defined
(so the guard you move should be over an empty statement)?

Regards,

James




[PATCH v3 5/6] kbuild: Move modules.builtin.modinfo to another makefile

2025-05-27 Thread Alexey Gladkov
The creation of modules.builtin.modinfo is going to depend on
.vmlinux.export.o so it is worth moving its creation closer to it.

Signed-off-by: Alexey Gladkov 
---
 scripts/Makefile.vmlinux   | 24 
 scripts/Makefile.vmlinux_o | 26 +-
 2 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index b64862dc6f08..250c0492b7e0 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -97,6 +97,30 @@ ifdef CONFIG_BUILDTIME_TABLE_SORT
 $(vmlinux-final): scripts/sorttable
 endif
 
+# modules.builtin.modinfo
+# ---
+
+OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
+
+targets += modules.builtin.modinfo
+modules.builtin.modinfo: vmlinux.o FORCE
+   $(call if_changed,objcopy)
+
+# modules.builtin
+# ---
+
+# The second line aids cases where multiple modules share the same object.
+
+quiet_cmd_modules_builtin = GEN $@
+  cmd_modules_builtin = \
+   tr '\0' '\n' < $< | \
+   sed -n 's/^[[:alnum:]:_]*\.file=//p' | \
+   tr ' ' '\n' | uniq | sed -e 's:^:kernel/:' -e 's/$$/.ko/' > $@
+
+targets += modules.builtin
+modules.builtin: modules.builtin.modinfo FORCE
+   $(call if_changed,modules_builtin)
+
 # modules.builtin.ranges
 # ---
 ifdef CONFIG_BUILTIN_MODULE_RANGES
diff --git a/scripts/Makefile.vmlinux_o b/scripts/Makefile.vmlinux_o
index b024ffb3e201..23c8751285d7 100644
--- a/scripts/Makefile.vmlinux_o
+++ b/scripts/Makefile.vmlinux_o
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 
 PHONY := __default
-__default: vmlinux.o modules.builtin.modinfo modules.builtin
+__default: vmlinux.o
 
 include include/config/auto.conf
 include $(srctree)/scripts/Kbuild.include
@@ -73,30 +73,6 @@ vmlinux.o: $(initcalls-lds) vmlinux.a $(KBUILD_VMLINUX_LIBS) 
FORCE
 
 targets += vmlinux.o
 
-# modules.builtin.modinfo
-# ---
-
-OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
-
-targets += modules.builtin.modinfo
-modules.builtin.modinfo: vmlinux.o FORCE
-   $(call if_changed,objcopy)
-
-# modules.builtin
-# ---
-
-# The second line aids cases where multiple modules share the same object.
-
-quiet_cmd_modules_builtin = GEN $@
-  cmd_modules_builtin = \
-   tr '\0' '\n' < $< | \
-   sed -n 's/^[[:alnum:]:_]*\.file=//p' | \
-   tr ' ' '\n' | uniq | sed -e 's:^:kernel/:' -e 's/$$/.ko/' > $@
-
-targets += modules.builtin
-modules.builtin: modules.builtin.modinfo FORCE
-   $(call if_changed,modules_builtin)
-
 # Add FORCE to the prerequisites of a target to force it to be always rebuilt.
 # ---
 
-- 
2.49.0




Re: [PATCH bpf-next v2 1/2] bpf, arm64: Support up to 12 function arguments

2025-05-27 Thread Xu Kuohai

On 5/27/2025 4:45 PM, Alexis Lothoré wrote:

[...]


+   /* We can not know for sure about exact alignment needs for
+* struct passed on stack, so deny those
+*/
+   if (m->arg_flags[i] & BTF_FMODEL_STRUCT_ARG)
+   return -EOPNOTSUPP;

leave the error code as is, namely, return -ENOTSUPP?

Actually this change follows a complaint from checkpatch:

"WARNING: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP"


Seems we can just ignore this warning, as ENOTSUPP is already used
throughout bpf, and the actual value -524 is well recognized.

[...]




Re: [PATCH bpf-next v3 0/2] bpf, arm64: support up to 12 arguments

2025-05-27 Thread Xu Kuohai

On 5/27/2025 6:06 PM, Alexis Lothoré wrote:

Hello,

this is the v2 of the many args series for arm64, being itself a revival
of Xu Kuhoai's work to enable larger arguments count for BPF programs on
ARM64 ([1]).

The discussions in v1 shed some light on some issues around specific
cases, for example with functions passing struct on stack with custom
packing/alignment attributes: those cases can not be properly detected
with the current BTF info. So this new revision aims to separate
concerns with a simpler implementation, just accepting additional args
on stack if we can make sure about the alignment constraints (and so,
refusing attachment to functions passing structs on stacks). I then
checked if the specific alignment constraints could be checked with
larger scalar types rather than structs, but it appears that this use
case is in fact rejected at the verifier level (see a9b59159d338 ("bpf:
Do not allow btf_ctx_access with __int128 types")). So in the end the
specific alignment corner cases raised in [1] can not really happen in
the kernel in its current state. This new revision still brings support
for the standard cases as a first step, it will then be possible to
iterate on top of it to add the more specific cases like struct passed
on stack and larger types.

[1] 
https://lore.kernel.org/all/20230917150752.69612-1-xukuo...@huaweicloud.com/#t

Signed-off-by: Alexis Lothoré (eBPF Foundation) 
---
Changes in v3:
- switch back -EOPNOTSUPP to -ENOTSUPP
- fix comment style
- group intializations for arg_aux
- remove some unneeded round_up
- Link to v2: 
https://lore.kernel.org/r/20250522-many_args_arm64-v2-0-d6afdb9cf...@bootlin.com

Changes in v2:
- remove alignment computation from btf.c
- deduce alignment constraints directly in jit compiler for simple types
- deny attachment to functions with "corner-cases" arguments (ie:
   structs on stack)
- remove custom tests, as the corresponding use cases are locked either
   by the JIT comp or the verifier
- drop RFC
- Link to v1: 
https://lore.kernel.org/r/20250411-many_args_arm64-v1-0-0a32fe723...@bootlin.com

---
Alexis Lothoré (eBPF Foundation) (1):
   selftests/bpf: enable many-args tests for arm64

Xu Kuohai (1):
   bpf, arm64: Support up to 12 function arguments

  arch/arm64/net/bpf_jit_comp.c| 225 ---
  tools/testing/selftests/bpf/DENYLIST.aarch64 |   2 -
  2 files changed, 171 insertions(+), 56 deletions(-)
---
base-commit: 9435138c069117cd59a4912b5ea2ae44cc2c5ffa
change-id: 20250220-many_args_arm64-8bd3747e6948

Best regards,


For the series:

Acked-by: Xu Kuohai 




Re: [PATCH 1/4] selftests/mm: Use standard ksft_finished() in cow and gup_longterm

2025-05-27 Thread David Hildenbrand

On 22.05.25 19:38, Mark Brown wrote:

The cow and gup_longterm test programs open code something that looks a
lot like the standard ksft_finished() helper to summarise the test
results and provide an exit code, convert to use ksft_finished().

Signed-off-by: Mark Brown 
---


Acked-by: David Hildenbrand 

--
Cheers,

David / dhildenb




Re: [PATCH v3 1/6] scsi: Define MODULE_DEVICE_TABLE only if necessary

2025-05-27 Thread Alexey Gladkov
On Tue, May 27, 2025 at 07:58:27AM -0400, James Bottomley wrote:
> On Tue, 2025-05-27 at 13:54 +0200, Alexey Gladkov wrote:
> > On Tue, May 27, 2025 at 07:28:59AM -0400, James Bottomley wrote:
> > > On Tue, 2025-05-27 at 11:07 +0200, Alexey Gladkov wrote:
> > > > Define MODULE_DEVICE_TABLE only if a structure is defined for it.
> > > > 
> > > > drivers/scsi/BusLogic.c:3735:26: error: use of undeclared
> > > > identifier
> > > > 'blogic_pci_tbl'
> > > >  3735 | MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);
> > > 
> > > Well, a) need to cc the scsi list
> > 
> > Sorry. I miss it.
> > 
> > > and b) how is this possible when MODULE_DEVICE_TABLE() has an empty
> > > definition if MODULE isn't defined (so the guard you move should be
> > > over an empty statement)?
> > 
> > In the next patch:
> > 
> > [PATCH v3 4/6] modpost: Create modalias for builtin modules
> > 
> > I remove this condition for the MODULE_DEVICE_TABLE macro and it will
> > be always defined.
> 
> Well, why?  If there's a reason for the table to always exist, wouldn't
> the best fix then be to remove the module guards from the PCI table in
> the buslogic ... they only really exist to prevent a defined but not
> used error which it sounds like you're getting rid of?

I wanted to keep the original logic and remove the build error. Before my
changes blogic_pci_tbl was only used when the module was built separately
(MODULE case).

But yes, you are right. In this case, it would be more appropriate to
remove the MODULE condition at all since MODULE_DEVICE_TABLE always
makes sense after my changes.

-- 
Rgrds, legion




Re: [PATCH 3/4] selftests/mm: Report unique test names for each cow test

2025-05-27 Thread Mark Brown
On Tue, May 27, 2025 at 12:53:30PM +0100, Lorenzo Stoakes wrote:
> On Tue, May 27, 2025 at 12:49:57PM +0100, Mark Brown wrote:
> > On Tue, May 27, 2025 at 11:08:05AM +0100, Lorenzo Stoakes wrote:
> > > On Thu, May 22, 2025 at 06:38:52PM +0100, Mark Brown wrote:
> >
> > > > ret = setup_comm_pipes(&comm_pipes);
> > > > if (ret) {
> > > > -   ksft_test_result_fail("pipe() failed\n");
> > > > +   log_test_result(KAFT_FAIL);
> > >
> > > Looks like a typo here :) Should be KSFT not KAFT.

Somewhat impressively clang is managing to build this perfectly happily
locally which also isn't helping, I can't figure out why.  Can't see a
system include with it.


signature.asc
Description: PGP signature


Re: [PATCH 3/4] selftests/mm: Report unique test names for each cow test

2025-05-27 Thread Mark Brown
On Tue, May 27, 2025 at 11:08:05AM +0100, Lorenzo Stoakes wrote:
> On Thu, May 22, 2025 at 06:38:52PM +0100, Mark Brown wrote:

> > ret = setup_comm_pipes(&comm_pipes);
> > if (ret) {
> > -   ksft_test_result_fail("pipe() failed\n");
> > +   log_test_result(KAFT_FAIL);
> 
> Looks like a typo here :) Should be KSFT not KAFT.
> 
> This is breaking the mm self test build for mm-new, could you 
> fix-patch/respin?
> Thanks!

Ugh, this was masked because it's part of a series and among the
problems with the kselftest build system is the fact that it eats
errors.

Please delete unneeded context from mails when replying.  Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.


signature.asc
Description: PGP signature


Re: [PATCH 3/4] selftests/mm: Report unique test names for each cow test

2025-05-27 Thread Lorenzo Stoakes
On Tue, May 27, 2025 at 12:49:57PM +0100, Mark Brown wrote:
> On Tue, May 27, 2025 at 11:08:05AM +0100, Lorenzo Stoakes wrote:
> > On Thu, May 22, 2025 at 06:38:52PM +0100, Mark Brown wrote:
>
> > >   ret = setup_comm_pipes(&comm_pipes);
> > >   if (ret) {
> > > - ksft_test_result_fail("pipe() failed\n");
> > > + log_test_result(KAFT_FAIL);
> >
> > Looks like a typo here :) Should be KSFT not KAFT.
> >
> > This is breaking the mm self test build for mm-new, could you 
> > fix-patch/respin?
> > Thanks!
>
> Ugh, this was masked because it's part of a series and among the
> problems with the kselftest build system is the fact that it eats
> errors.

Compile errors too? That's... not great.

>
> Please delete unneeded context from mails when replying.  Doing this
> makes it much easier to find your reply in the message, helping ensure
> it won't be missed by people scrolling through the irrelevant quoted
> material.

Yup I normally do, I sent this out quick and dirty because I just happened
to hit it when trying to do other work.



Re: [PATCH v3 1/6] scsi: Define MODULE_DEVICE_TABLE only if necessary

2025-05-27 Thread Alexey Gladkov
On Tue, May 27, 2025 at 07:28:59AM -0400, James Bottomley wrote:
> On Tue, 2025-05-27 at 11:07 +0200, Alexey Gladkov wrote:
> > Define MODULE_DEVICE_TABLE only if a structure is defined for it.
> > 
> > drivers/scsi/BusLogic.c:3735:26: error: use of undeclared identifier
> > 'blogic_pci_tbl'
> >  3735 | MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);
> 
> Well, a) need to cc the scsi list

Sorry. I miss it.

> and b) how is this possible when
> MODULE_DEVICE_TABLE() has an empty definition if MODULE isn't defined
> (so the guard you move should be over an empty statement)?

In the next patch:

[PATCH v3 4/6] modpost: Create modalias for builtin modules

I remove this condition for the MODULE_DEVICE_TABLE macro and it will be
always defined.

I put the drivers/scsi/BusLogic.c change before these changes to avoid
errors. Besides, even an empty macro uses a structure name that is not
defined (if MODULE isn't defined). This seems wrong in any case.

-- 
Rgrds, legion




Re: [PATCH v2 3/3] remoteproc: imx_rproc: add power mode check for remote core attachment

2025-05-27 Thread Ulf Hansson
On Tue, 27 May 2025 at 03:29, Peng Fan  wrote:
>
> On Mon, May 26, 2025 at 09:05:10PM -0300, Hiago De Franco wrote:
> >On Mon, May 26, 2025 at 12:07:49PM +0200, Ulf Hansson wrote:
> >> On Fri, 23 May 2025 at 21:17, Hiago De Franco  
> >> wrote:
> >> >
> >> > Hi Ulf,
> >> >
> >> > On Wed, May 21, 2025 at 02:11:02PM +0200, Ulf Hansson wrote:
> >> > > You should not provide any flag (or attach_data to
> >> > > dev_pm_domain_attach_list()) at all. In other words just call
> >> > > dev_pm_domain_attach_list(dev, NULL, &priv->pd_list), similar to how
> >> > > drivers/remoteproc/imx_dsp_rproc.c does it.
> >> > >
> >> > > In this way, the device_link is created by making the platform->dev
> >> > > the consumer and by keeping the supplier-devices (corresponding to the
> >> > > genpds) in RPM_SUSPENDED state.
> >> > >
> >> > > The PM domains (genpds) are then left in their current state, which
> >> > > should allow us to call dev_pm_genpd_is_on() for the corresponding
> >> > > supplier-devices, to figure out whether the bootloader turned them on
> >> > > or not, I think.
> >> > >
> >> > > Moreover, to make sure the genpds are turned on when needed, we also
> >> > > need to call pm_runtime_enable(platform->dev) and
> >> > > pm_runtime_get_sync(platform->dev). The easiest approach is probably
> >> > > to do that during ->probe() - and then as an improvement on top you
> >> > > may want to implement more fine-grained support for runtime PM.
> >> > >
> >> > > [...]
> >> > >
> >> > > Kind regards
> >> > > Uffe
> >> >
> >> > I did some tests here and I might be missing something. I used the
> >> > dev_pm_genpd_is_on() inside imx_rproc.c with the following changes:
> >> >
> >> > @@ -902,7 +902,12 @@ static int imx_rproc_attach_pd(struct imx_rproc 
> >> > *priv)
> >> > if (dev->pm_domain)
> >> > return 0;
> >> >
> >> > ret = dev_pm_domain_attach_list(dev, &pd_data, &priv->pd_list);
> >> > +   printk("hfranco: returned pd devs is %d", ret);
> >> > +   for (int i = 0; i < ret; i++) {
> >> > +   test = dev_pm_genpd_is_on(priv->pd_list->pd_devs[i]);
> >> > +   printk("hfranco: returned value is %d", test);
> >> > +   }
> >> > return ret < 0 ? ret : 0;
> >> >  }
> >> >
> >> > This was a quick test to check the returned value, and it always return
> >> > 1 for both pds, even if I did not boot the remote core.
> >> >
> >> > So I was wondering if it was because of PD_FLAG_DEV_LINK_ON, I removed
> >> > it and passed NULL to dev_pm_domain_attach_list().
> >>
> >> Right, that's exactly what we should be doing.
> >>
> >> > Booting the kernel
> >> > now it correctly reports 0 for both pds, however when I start the
> >> > remote core with a hello world firmware and boot the kernel, the CPU
> >> > resets with a fault reset ("Reset cause: SCFW fault reset").
> >> >
> >> > I added both pm functions to probe, just to test:
> >> >
> >> > @@ -1152,6 +1158,9 @@ static int imx_rproc_probe(struct platform_device 
> >> > *pdev)
> >> > goto err_put_clk;
> >> > }
> >> >
> >> > +   pm_runtime_enable(dev);
> >> > +   pm_runtime_get_sync(dev);
> >> > +
> >>
> >> Indeed, calling pm_runtime_enable() and then pm_runtime_get_sync()
> >> should turn on the PM domains for the device, which I assume is needed
> >> at some point.
> >>
> >> Although, I wonder if this may be a bit too late, I would expect that
> >> you at least need to call these *before* the call to rproc_add(), as I
> >> assume the rproc-core may start using the device/driver beyond that
> >> point.
> >>
> >> > return 0
> >> >
> >> > Now the kernel boot with the remote core running, but it still returns
> >> > 0 from dev_pm_genpd_is_on(). So basically now it always returns 0, with
> >> > or without the remote core running.
> >>
> >> dev_pm_genpd_is_on() is returning the current status of the PM domain
> >> (genpd) for the device.
> >>
> >> Could it be that the genpd provider doesn't register its PM domains
> >> with the state that the HW is really in? pm_genpd_init() is the call
> >> that allows the genpd provider to specify the initial state.
> >>
> >> I think we need Peng's help here to understand what goes on.
> >>
> >> >
> >> > I tried to move pm_runtime_get_sync() to .prepare function but it make
> >> > the kernel not boot anymore (with the SCU fault reset).
> >>
> >> Try move pm_runtime_enable() before rproc_add().
> >
> >Thanks Ulf, that indeed made it work, at least now the kernel does not
> >reset anymore with the SCU fault reset. However I am still only getting
> >0 from dev_pm_genpd_is_on(), no matter what the state of the remote
> >core. Maybe I am missing something in between?
> >
> >Peng, do you know what could be the issue here?
>
> imx_rproc_attach_pd
>  ->dev_pm_domain_attach_list
>   ->genpd_dev_pm_attach_by_id
>   ->genpd_queue_power_off_work
>  ->cm40_pid0 is powered off because the genpd is set with 
> is_off=false
>
> So dev_p

Re: [PATCH v2 0/4] CAMSS support for MSM8939

2025-05-27 Thread Konrad Dybcio
On 5/25/25 9:25 PM, Vincent Knecht via B4 Relay wrote:
> This series adds CAMSS support for MSM8939.
> It's mostly identical to MSM8916, except for some clocks
> and an additional CSI.
> 
> To fix black stripes across sensor output, and garbage in
> CSID TPG output, 2 VFE VBIF register settings are needed.
> So the 1st patch adds helper functions to do just that.
> 
> Patch 1: adds helper for VFE VBIF settings
> Patch 2: adds CAMSS_8x39 version in CAMSS driver
> Patch 3: documents qcom,msm8939-camss DT bindings
> Patch 4: adds camss and cci in msm8939.dtsi
> 
> Signed-off-by: Vincent Knecht 
> ---
> Changes in v2:
> - Patch 1:
>   - Fix devm_platform_ioremap_resource_byname line to not end with
> opening parenthesis (media-ci/1-checkpatch)
>   - Move camss-vfe-4-1.c handling of VBIF previously in patch 2 here
> (Dmitry)
> - Patch 2:
>   - Declare regulators in PHY entries, not CSID ones (Bryan)
> - Patch 3: (bindings)
>   - Fix bindings checks for new errors (Rob)
>   - Fix properties ordering, code-style and example (Krzysztof)
>   - Sort reg-names, clock-names and interrupt-names alphanumerically (Bryan)
> - Patch 4: (dtsi)
>   - Move #address/#size cells before status (Konrad)
>   - Aligned CCI with msm8916, thus removing ispif_ahb mention (Konrad)
> If "camss_ahb should be unnecessary", it's still required by 
> qcom,i2c-cci.yaml

Give it a shot (with camss disabled so that the clock isn't on) - make
sure it's off and see if you can still access i2c.

If it turns out it's fine, we'll fix up the bindings instead

Konrad



Re: [PATCH v3 1/6] scsi: Define MODULE_DEVICE_TABLE only if necessary

2025-05-27 Thread James Bottomley
On Tue, 2025-05-27 at 13:54 +0200, Alexey Gladkov wrote:
> On Tue, May 27, 2025 at 07:28:59AM -0400, James Bottomley wrote:
> > On Tue, 2025-05-27 at 11:07 +0200, Alexey Gladkov wrote:
> > > Define MODULE_DEVICE_TABLE only if a structure is defined for it.
> > > 
> > > drivers/scsi/BusLogic.c:3735:26: error: use of undeclared
> > > identifier
> > > 'blogic_pci_tbl'
> > >  3735 | MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);
> > 
> > Well, a) need to cc the scsi list
> 
> Sorry. I miss it.
> 
> > and b) how is this possible when MODULE_DEVICE_TABLE() has an empty
> > definition if MODULE isn't defined (so the guard you move should be
> > over an empty statement)?
> 
> In the next patch:
> 
> [PATCH v3 4/6] modpost: Create modalias for builtin modules
> 
> I remove this condition for the MODULE_DEVICE_TABLE macro and it will
> be always defined.

Well, why?  If there's a reason for the table to always exist, wouldn't
the best fix then be to remove the module guards from the PCI table in
the buslogic ... they only really exist to prevent a defined but not
used error which it sounds like you're getting rid of?

Regards,

James




Re: [PATCH v2 1/4] media: qcom: camss: vfe: Add VBIF setting support

2025-05-27 Thread Bryan O'Donoghue

On 26/05/2025 17:23, Vincent Knecht wrote:

Do you mean to just rename to vfe_vbif_write_reg()


Yep, its more natural language.

---
bod



Re: [PATCH] rust: kunit: use crate-level mapping for `c_void`

2025-05-27 Thread Benno Lossin
On Mon May 26, 2025 at 6:24 PM CEST, Jesung Yang wrote:
> Use `kernel::ffi::c_void` instead of `core::ffi::c_void` for consistency
> and to centralize abstraction.
>
> Since `kernel::ffi::c_void` is a transparent wrapper around
> `core::ffi::c_void`, both are functionally equivalent. However, using
> `kernel::ffi::c_void` improves consistency across the kernel's Rust code
> and provides a unified reference point in case the definition ever needs
> to change, even if such a change is unlikely.
>
> Signed-off-by: Jesung Yang 
> ---
>  rust/kernel/kunit.rs | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/rust/kernel/kunit.rs b/rust/kernel/kunit.rs
> index 81833a687b75..bd6fc712dd79 100644
> --- a/rust/kernel/kunit.rs
> +++ b/rust/kernel/kunit.rs
> @@ -6,7 +6,8 @@
>  //!
>  //! Reference: 
>  
> -use core::{ffi::c_void, fmt};
> +use core::fmt;
> +use kernel::ffi::c_void;

We don't need to explicitly import it, as `c_void` is present in the
prelude since 3d5bef5d47c3 ("rust: add C FFI types to the prelude").

With the import removed:

Reviewed-by: Benno Lossin 

---
Cheers,
Benno



Re: [PATCH 3/4] selftests/mm: Report unique test names for each cow test

2025-05-27 Thread Mark Brown
On Tue, May 27, 2025 at 12:53:30PM +0100, Lorenzo Stoakes wrote:
> On Tue, May 27, 2025 at 12:49:57PM +0100, Mark Brown wrote:

> > Ugh, this was masked because it's part of a series and among the
> > problems with the kselftest build system is the fact that it eats
> > errors.

> Compile errors too? That's... not great.

Yes, you only find out that something failed to build when the binary
doesn't show up in the output or if you read the logs which is terrible
in a CI system.  If you install things to actually run them you get a
lot of build log from that which scrolls things off the screen and you
might have the binary from last time lying around.


signature.asc
Description: PGP signature


[PATCH] selftests: futex: define SYS_futex on 32-bit architectures with 64-bit time_t

2025-05-27 Thread Ben Zong-You Xie
glibc does not define SYS_futex for 32-bit architectures using 64-bit
time_t e.g. riscv32, therefore this test fails to compile since it does not
find SYS_futex in C library headers. Define SYS_futex as SYS_futex_time64
in this situation to ensure successful compilation and compatibility.

Signed-off-by: Ben Zong-You Xie 
Signed-off-by: Cynthia Huang 
---
 tools/testing/selftests/futex/include/futextest.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/tools/testing/selftests/futex/include/futextest.h 
b/tools/testing/selftests/futex/include/futextest.h
index ddbcfc9b7bac..7a5fd1d5355e 100644
--- a/tools/testing/selftests/futex/include/futextest.h
+++ b/tools/testing/selftests/futex/include/futextest.h
@@ -47,6 +47,17 @@ typedef volatile u_int32_t futex_t;
 FUTEX_PRIVATE_FLAG)
 #endif
 
+/*
+ * SYS_futex is expected from system C library, in glibc some 32-bit
+ * architectures (e.g. RV32) are using 64-bit time_t, therefore it doesn't have
+ * SYS_futex defined but just SYS_futex_time64. Define SYS_futex as
+ * SYS_futex_time64 in this situation to ensure the compilation and the
+ * compatibility.
+ */
+#if !defined(SYS_futex) && defined(SYS_futex_time64)
+#define SYS_futex SYS_futex_time64
+#endif
+
 /**
  * futex() - SYS_futex syscall wrapper
  * @uaddr: address of first futex
-- 
2.34.1




Re: [PATCH v3] media: add virtio-media driver

2025-05-27 Thread Alexandre Courbot
On Tue, May 27, 2025 at 6:13 PM Mauro Carvalho Chehab
 wrote:
>
> Em Tue, 27 May 2025 15:14:50 +0900
> "Alexandre Courbot"  escreveu:
>
> > Hi Mauro,
> >
> > On Mon May 26, 2025 at 9:13 PM JST, Mauro Carvalho Chehab wrote:
> > > Hi Michael,
> > >
> > > Em Sat, 12 Apr 2025 13:08:01 +0900
> > > Alexandre Courbot  escreveu:
> > >
> > >> Add the first version of the virtio-media driver.
> > >>
> > >> This driver acts roughly as a V4L2 relay between user-space and the
> > >> virtio virtual device on the host, so it is relatively simple, yet
> > >> unconventional. It doesn't use VB2 or other frameworks typically used in
> > >> a V4L2 driver, and most of its complexity resides in correctly and
> > >> efficiently building the virtio descriptor chain to pass to the host,
> > >> avoiding copies whenever possible. This is done by
> > >> scatterlist_builder.[ch].
> > >>
> > >> virtio_media_ioctls.c proxies each supported ioctl to the host, using
> > >> code generated through macros for ioctls that can be forwarded directly,
> > >> which is most of them.
> > >>
> > >> virtio_media_driver.c provides the expected driver hooks, and support
> > >> for mmapping and polling.
> > >>
> > >>  This version supports MMAP buffers, while USERPTR buffers can also be
> > >>  enabled through a driver option. DMABUF support is still pending.
> > >
> > > It sounds that you applied this one at the virtio tree, but it hasn't
> > > being reviewed or acked by media maintainers.
> > >
> > > Please drop it.
> > >
> > > Alexandre,
> > >
> > > Please send media patches to media maintainers, c/c other subsystem
> > > maintainers, as otherwise they might end being merged without a
> > > proper review.
> >
> > Sorry about that, I put everyone in "To:" without giving it a second
> > thought.
> >
> > >
> > > In this particular case, we need to double-check if this won't cause
> > > any issues, in special with regards to media locks and mutexes.
> >
> > Agreed, I am not 100% confident about that part myself.
> >
> > >
> > > I'll try to look on it after this merge window, as it is too late
> > > for it to be applied during this one.
> >
> > Appreciate that - given the high traffic on the list I was worried that
> > this patch would eventually be overlooked. Not making it for this merge
> > window should not be a problem, so please take the time you need.
>
> Provided that your patch was caught by patchwork, it won't be lost:
> 
> https://patchwork.linuxtv.org/project/linux-media/patch/20250412-virtio-media-v3-1-97dc94c18...@gmail.com/
>
> Please notice that our CI got a number of checkpatch issues there.
> Please check and fix the non-false-positive ones.

Will do. The macro-related ones are false-positives AFAICT. Some of
the "lines should not end with a '('" are actually the result of
applying clang-format with the kernel-provided style...

>
> Btw, I was looking at:
>
> https://github.com/chromeos/virtio-media
>
> (I'm assuming that this is the QEMU counterpart, right?)

crosvm actually, but QEMU support is also being worked on.

>
> And I noticed something weird there:
>
> "Unsupported ioctls
>
>  A few ioctls are replaced by other, more suitable mechanisms. If 
> being requested these ioctls, the device must return the same response as it 
> would for an unknown ioctl, i.e. ENOTTY.
>
> VIDIOC_QUERYCAP is replaced by reading the configuration area.
> VIDIOC_DQBUF is replaced by a dedicated event.
> VIDIOC_DQEVENT is replaced by a dedicated event."
>
> While this could be ok for cromeOS, this will be broken for guests with
> Linux, as all Linux applications rely on VIDIOC_QUERYCAP and VIDIOC_DQBUF
> to work. Please implement support for it, as otherwise we won't even be
> able to test the driver with the v4l2-compliance tool (*).

The phrasing was a bit confusing. The guest driver does support these
ioctls, and passes v4l2-compliance. So there is no problem here.

Where these ioctls are not supported is between the guest and the
host, i.e. as ioctls encapsulated into a virtio request. For QUERYCAP,
that's because the virtio configuration area already provides the same
information. For DQBUF and DQEVENT, that's because we want to serve
these asynchronously for performance reasons (hence the dedicated
events).

But these differences don't affect guest user applications which will
be able to perform these ioctls exactly as they expect.

>
> (*) Passing at v4l2-compliance is a requirement for any media driver
> to be merged.
>
> With regards to testing, what's the expected testing scenario?
> My guess is that, as a virtio device, a possible test scenario would be
> to have the UVC camera from the host OS mapped using virtio-camera into
> the guest OS, allowing a V4L2 application running at the guest to map the
> camera from the host, right?

That's one of the scenarios, yes. Another one is to expose an
accelerated decoder on the host to the guest. One can also create
"fake" devices

Re: [PATCH v3] media: add virtio-media driver

2025-05-27 Thread Mauro Carvalho Chehab
Em Tue, 27 May 2025 22:21:42 +0900
Alexandre Courbot  escreveu:

> On Tue, May 27, 2025 at 6:13 PM Mauro Carvalho Chehab
>  wrote:
> >
> > Em Tue, 27 May 2025 15:14:50 +0900
> > "Alexandre Courbot"  escreveu:
> >  
> > > Hi Mauro,
> > >
> > > On Mon May 26, 2025 at 9:13 PM JST, Mauro Carvalho Chehab wrote:  
> > > > Hi Michael,
> > > >
> > > > Em Sat, 12 Apr 2025 13:08:01 +0900
> > > > Alexandre Courbot  escreveu:
> > > >  
> > > >> Add the first version of the virtio-media driver.
> > > >>
> > > >> This driver acts roughly as a V4L2 relay between user-space and the
> > > >> virtio virtual device on the host, so it is relatively simple, yet
> > > >> unconventional. It doesn't use VB2 or other frameworks typically used 
> > > >> in
> > > >> a V4L2 driver, and most of its complexity resides in correctly and
> > > >> efficiently building the virtio descriptor chain to pass to the host,
> > > >> avoiding copies whenever possible. This is done by
> > > >> scatterlist_builder.[ch].
> > > >>
> > > >> virtio_media_ioctls.c proxies each supported ioctl to the host, using
> > > >> code generated through macros for ioctls that can be forwarded 
> > > >> directly,
> > > >> which is most of them.
> > > >>
> > > >> virtio_media_driver.c provides the expected driver hooks, and support
> > > >> for mmapping and polling.
> > > >>
> > > >>  This version supports MMAP buffers, while USERPTR buffers can also be
> > > >>  enabled through a driver option. DMABUF support is still pending.  
> > > >
> > > > It sounds that you applied this one at the virtio tree, but it hasn't
> > > > being reviewed or acked by media maintainers.
> > > >
> > > > Please drop it.
> > > >
> > > > Alexandre,
> > > >
> > > > Please send media patches to media maintainers, c/c other subsystem
> > > > maintainers, as otherwise they might end being merged without a
> > > > proper review.  
> > >
> > > Sorry about that, I put everyone in "To:" without giving it a second
> > > thought.
> > >  
> > > >
> > > > In this particular case, we need to double-check if this won't cause
> > > > any issues, in special with regards to media locks and mutexes.  
> > >
> > > Agreed, I am not 100% confident about that part myself.
> > >  
> > > >
> > > > I'll try to look on it after this merge window, as it is too late
> > > > for it to be applied during this one.  
> > >
> > > Appreciate that - given the high traffic on the list I was worried that
> > > this patch would eventually be overlooked. Not making it for this merge
> > > window should not be a problem, so please take the time you need.  
> >
> > Provided that your patch was caught by patchwork, it won't be lost:
> > 
> > https://patchwork.linuxtv.org/project/linux-media/patch/20250412-virtio-media-v3-1-97dc94c18...@gmail.com/
> >
> > Please notice that our CI got a number of checkpatch issues there.
> > Please check and fix the non-false-positive ones.  
> 
> Will do. The macro-related ones are false-positives AFAICT. Some of
> the "lines should not end with a '('" are actually the result of
> applying clang-format with the kernel-provided style...

I don't know any lint tool that honors kernel style. The best one
is checkpatch with the auto-correcting parameter in pedantic mode,
but still one needs to manually review its output.

> 
> >
> > Btw, I was looking at:
> >
> > https://github.com/chromeos/virtio-media
> >
> > (I'm assuming that this is the QEMU counterpart, right?)  
> 
> crosvm actually, but QEMU support is also being worked on.

Do you have already QEMU patches? The best is to have the Kernel driver
submitted altogether with QEMU, as Kernel developers need it to do the
tests. In my case, I never use crosvm, and I don't have any Chromebook
anymore.

> > And I noticed something weird there:
> >
> > "Unsupported ioctls
> >
> >  A few ioctls are replaced by other, more suitable mechanisms. If 
> > being requested these ioctls, the device must return the same response as 
> > it would for an unknown ioctl, i.e. ENOTTY.
> >
> > VIDIOC_QUERYCAP is replaced by reading the configuration area.
> > VIDIOC_DQBUF is replaced by a dedicated event.
> > VIDIOC_DQEVENT is replaced by a dedicated event."
> >
> > While this could be ok for cromeOS, this will be broken for guests with
> > Linux, as all Linux applications rely on VIDIOC_QUERYCAP and VIDIOC_DQBUF
> > to work. Please implement support for it, as otherwise we won't even be
> > able to test the driver with the v4l2-compliance tool (*).  
> 
> The phrasing was a bit confusing. The guest driver does support these
> ioctls, and passes v4l2-compliance. So there is no problem here.

Please add v4l2-compliance output on the next patch series.

> Where these ioctls are not supported is between the guest and the
> host, i.e. as ioctls encapsulated into a virtio request. For QUERYCAP,
> that's because the virtio configuration area already provides the same
> information. For DQBUF and DQEVENT, that'

Re: [PATCH bpf-next v2 1/2] bpf, arm64: Support up to 12 function arguments

2025-05-27 Thread Xu Kuohai

On 5/22/2025 6:14 PM, Alexis Lothoré wrote:

[...]


-static void save_args(struct jit_ctx *ctx, int args_off, int nregs)
+struct arg_aux {
+   /* how many args are passed through registers, the rest of the args are
+* passed through stack
+*/
+   int args_in_regs;
+   /* how many registers are used to pass arguments */
+   int regs_for_args;
+   /* how much stack is used for additional args passed to bpf program
+* that did not fit in original function registers
+**/


nit: "**/" should be "*/"


+   int bstack_for_args;
+   /* home much stack is used for additional args passed to the
+* original function when called from trampoline (this one needs
+* arguments to be properly aligned)
+*/
+   int ostack_for_args;
+};
+
+static int calc_arg_aux(const struct btf_func_model *m,
+struct arg_aux *a)
  {
-   int i;
+   int stack_slots, nregs, slots, i;
+
+   /* verifier ensures m->nr_args <= MAX_BPF_FUNC_ARGS */
+   for (i = 0, nregs = 0; i < m->nr_args; i++) {
+   slots = (m->arg_size[i] + 7) / 8;
+   if (nregs + slots <= 8) /* passed through register ? */
+   nregs += slots;
+   else
+   break;
+   }
+
+   a->args_in_regs = i;
+   a->regs_for_args = nregs;
+   a->ostack_for_args = 0;
+
+   /* the rest arguments are passed through stack */
+   for (a->ostack_for_args = 0, a->bstack_for_args = 0;
+i < m->nr_args; i++) {


a->ostack_for_args is initialized twice.

move all initializations before the loop?


+   /* We can not know for sure about exact alignment needs for
+* struct passed on stack, so deny those
+*/
+   if (m->arg_flags[i] & BTF_FMODEL_STRUCT_ARG)
+   return -EOPNOTSUPP;


leave the error code as is, namely, return -ENOTSUPP?


+   stack_slots = (m->arg_size[i] + 7) / 8;
+   /* AAPCS 64 C.14: arguments passed on stack must be aligned to
+* max(8, arg_natural_alignment)
+*/
+   a->bstack_for_args += stack_slots * 8;
+   a->ostack_for_args = round_up(a->ostack_for_args + stack_slots 
* 8, 8);


since a->ostack_for_args starts from 0 and is always incremented
by multiples of 8, round_up() to 8 is not needed.


+   }
  
-	for (i = 0; i < nregs; i++) {

-   emit(A64_STR64I(i, A64_SP, args_off), ctx);
-   args_off += 8;
+   return 0;
+}
+
+static void clear_garbage(struct jit_ctx *ctx, int reg, int effective_bytes)
+{
+   if (effective_bytes) {
+   int garbage_bits = 64 - 8 * effective_bytes;
+#ifdef CONFIG_CPU_BIG_ENDIAN
+   /* garbage bits are at the right end */
+   emit(A64_LSR(1, reg, reg, garbage_bits), ctx);
+   emit(A64_LSL(1, reg, reg, garbage_bits), ctx);
+#else
+   /* garbage bits are at the left end */
+   emit(A64_LSL(1, reg, reg, garbage_bits), ctx);
+   emit(A64_LSR(1, reg, reg, garbage_bits), ctx);
+#endif
}
  }
  
-static void restore_args(struct jit_ctx *ctx, int args_off, int nregs)

+static void save_args(struct jit_ctx *ctx, int bargs_off, int oargs_off,
+ const struct btf_func_model *m,
+ const struct arg_aux *a,
+ bool for_call_origin)
  {
int i;
+   int reg;
+   int doff;
+   int soff;
+   int slots;
+   u8 tmp = bpf2a64[TMP_REG_1];
+
+   /* store arguments to the stack for the bpf program, or restore
+* arguments from stack for the original function
+*/
+   for (reg = 0; reg < a->regs_for_args; reg++) {
+   emit(for_call_origin ?
+A64_LDR64I(reg, A64_SP, bargs_off) :
+A64_STR64I(reg, A64_SP, bargs_off),
+ctx);
+   bargs_off += 8;
+   }
+
+   soff = 32; /* on stack arguments start from FP + 32 */
+   doff = (for_call_origin ? oargs_off : bargs_off);
+
+   /* save on stack arguments */
+   for (i = a->args_in_regs; i < m->nr_args; i++) {
+   slots = (m->arg_size[i] + 7) / 8;
+   /* AAPCS C.14: additional arguments on stack must be
+* aligned on max(8, arg_natural_alignment)
+*/
+   soff = round_up(soff, 8);
+   if (for_call_origin)
+   doff =  round_up(doff, 8);


since both soff and doff start from multiples of 8 and are
incremented by 8 each time, the two round_up()s are also
not needed.


+   /* verifier ensures arg_size <= 16, so slots equals 1 or 2 */
+   while (slots-- > 0) {
+   emit(A64_LDR64I(tmp, A64_FP, soff), ctx);
+   /* if there is unused space in the last slot, clear
+  

RE: [PATCH v6 1/5] x86/sgx: Introduce a counter to count the sgx_(vepc_)open()

2025-05-27 Thread Reshetova, Elena


> -Original Message-
> From: Huang, Kai 
> Sent: Tuesday, May 27, 2025 2:20 AM
> To: Reshetova, Elena ; jar...@kernel.org
> Cc: Raynor, Scott ; Hansen, Dave
> ; mi...@kernel.org; Scarlata, Vincent R
> ; x...@kernel.org; linux-...@vger.kernel.org;
> Annapurve, Vishal ; linux-kernel@vger.kernel.org;
> Mallick, Asit K ; Aktas, Erdem
> ; Cai, Chong ;
> bond...@google.com; sea...@google.com; dionnagl...@google.com
> Subject: Re: [PATCH v6 1/5] x86/sgx: Introduce a counter to count the
> sgx_(vepc_)open()
> 
> >
> >
> > > >  /*
> > > > diff --git a/arch/x86/kernel/cpu/sgx/main.c
> > > b/arch/x86/kernel/cpu/sgx/main.c
> > > > index 2de01b379aa3..a018b01b8736 100644
> > > > --- a/arch/x86/kernel/cpu/sgx/main.c
> > > > +++ b/arch/x86/kernel/cpu/sgx/main.c
> > > > @@ -917,6 +917,20 @@ int sgx_set_attribute(unsigned long
> > > *allowed_attributes,
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(sgx_set_attribute);
> > > >
> > > > +/* Counter to count the active SGX users */
> > > > +static atomic64_t sgx_usage_count;
> > > > +
> > > > +int sgx_inc_usage_count(void)
> > > > +{
> > > > +   atomic64_inc(&sgx_usage_count);
> > > > +   return 0;
> > > > +}
> > >
> > > Maybe this was discussed but why this is not just a void-function?
> >
> > The last patch is cleaner if the prototype is already
> > returning int here. Also error unwinding takes this into account
> > right in this patch. Do you have objections to leave it as it is?
> >
> >
> 
> You can clarify this in the changelog of this patch (which I also suggested in
> v5).

Sure, will do. The reason I didn’t do it in v6 now is because I actually added
the error handling in case error is returned in this patch, so thought it was
self-explanatory, but as this comment from Jarkko shows I was wrong. 

Best Regards,
Elena.


Re: [PATCH v2 1/4] media: qcom: camss: vfe: Add VBIF setting support

2025-05-27 Thread Bryan O'Donoghue

On 26/05/2025 17:20, Vincent Knecht wrote:

You have both

if (vfe->res->has_vbif) {

and the above switch, there's no point in checking this twice in two
different ways.

Choose one, suggest has_vbif is enough.

I think the switch is still needed, so that distinct settings
can be applied for different SoCs.

Or should I just apply the 8939 settings unconditionally, and keep it
as an exercice for the next dev who need other settings for another SoC
to deal with ? 🙂

Thanks


The flag should be enough.

---
bod



Re: [PATCH net-next] vsock/test: Cover more CIDs in transport_uaf test

2025-05-27 Thread Stefano Garzarella

On Mon, May 26, 2025 at 10:44:05PM +0200, Michal Luczaj wrote:

On 5/26/25 16:39, Stefano Garzarella wrote:

On Mon, May 26, 2025 at 02:51:18PM +0200, Michal Luczaj wrote:

On 5/26/25 10:25, Stefano Garzarella wrote:

On Fri, May 23, 2025 at 12:31:16AM +0200, Michal Luczaj wrote:

Increase the coverage of test for UAF due to socket unbinding, and losing
transport in general. It's a follow up to commit 301a62dfb0d0 ("vsock/test:
Add test for UAF due to socket unbinding") and discussion in [1].

The idea remains the same: take an unconnected stream socket with a
transport assigned and then attempt to switch the transport by trying (and
failing) to connect to some other CID. Now do this iterating over all the
well known CIDs (plus one).

Note that having only a virtio transport loaded (without vhost_vsock) is
unsupported; test will always pass. Depending on transports available, a


Do you think it might make sense to print a warning if we are in this
case, perhaps by parsing /proc/modules and looking at vsock
dependencies?


That'd nice, but would parsing /proc/modules work if a transport is
compiled-in (not a module)?


Good point, I think not, maybe we can see something under /sys/module,
though, I would say let's do best effort without going crazy ;-)


Grepping through /proc/kallsyms would do the trick. Is this still a sane
ground?


It also depends on a config right?
I see CONFIG_KALLSYMS, CONFIG_KALLSYMS_ALL, etc. but yeah, if it's 
enabled, it should work for both modules and built-in transports.





And I've just realized feeding VMADDR_CID_HYPERVISOR to bind() doesn't make
sense at all. Will fix.


Yeah, we don't support it for now and maybe it makes sense only in the
VMM code (e.g. QEMU), but it's a test, so if you want to leave to stress
it more, I don't think it's a big issue.


All right, I'll keep it then. Fails quickly and politely anyway.


+static void test_stream_transport_uaf_client(const struct test_opts *opts)
+{
+   bool tested = false;
+   int cid;
+
+   for (cid = VMADDR_CID_HYPERVISOR; cid <= VMADDR_CID_HOST + 1; ++cid)



+   tested |= test_stream_transport_uaf(cid);
+
+   if (!tested)
+   fprintf(stderr, "No transport tested\n");
+
control_writeln("DONE");


While we're at it, I think we can remove this message, looking at
run_tests() in util.c, we already have a barrier.


Ok, sure. Note that console output gets slightly de-synchronised: server
will immediately print next test's prompt and wait there.


I see, however I don't have a strong opinion, you can leave it that way
if you prefer.


How about adding a sync point to run_tests()? E.g.


Yep, why not, of course in another series :-)

And if you like, you can remove that specific sync point in that series 
and check also other tests, but I think we have only that one.


Thanks,
Stefano



diff --git a/tools/testing/vsock/util.c b/tools/testing/vsock/util.c
index de25892f865f..79a02b52dc19 100644
--- a/tools/testing/vsock/util.c
+++ b/tools/testing/vsock/util.c
@@ -451,6 +451,9 @@ void run_tests(const struct test_case *test_cases,
run(opts);

printf("ok\n");
+
+   control_writeln("RUN_TESTS_SYNC");
+   control_expectln("RUN_TESTS_SYNC");
}
}






Re: [PATCH] selftests: fix "memebers" typo in filesystems/mount-notify

2025-05-27 Thread Hendrik Hammernet


On 5/22/25 23:34, Shuah Khan wrote:
> Change the shortlog to indicate test clearly. Check a few logs
> for this file for examples. Here is how the correct format looks
> like:
>
> selftests: filesystems: fix "memebers" typo in mount-notify
>
> SZend v2 with this correction.
>
> thanks,
> -- Shuah

Thank you for the feedback. I have sent a v2 version of the patch a couple of 
days ago titled:
`[PATCH v2] selftests: filesystems: fix "memebers" typo in mount-notify`.

I did send it as a separate mail thread, which was probably a mistake.
In the mailing list history I've noticed new versions being sent both as new 
threads and in the same thread.
I also could not find a clear answer in the documentation. What is the correct 
way to do it?

Kind regards,
Hendrik




[PATCH v3 0/6] Add generated modalias to modules.builtin.modinfo

2025-05-27 Thread Alexey Gladkov
The modules.builtin.modinfo file is used by userspace (kmod to be specific) to
get information about builtin modules. Among other information about the module,
information about module aliases is stored. This is very important to determine
that a particular modalias will be handled by a module that is inside the
kernel.

There are several mechanisms for creating modalias for modules:

The first is to explicitly specify the MODULE_ALIAS of the macro. In this case,
the aliases go into the '.modinfo' section of the module if it is compiled
separately or into vmlinux.o if it is builtin into the kernel.

The second is the use of MODULE_DEVICE_TABLE followed by the use of the
modpost utility. In this case, vmlinux.o no longer has this information and
does not get it into modules.builtin.modinfo.

For example:

$ modinfo pci:v8086dA36Dsv1043sd8694bc0Csc03i30
modinfo: ERROR: Module pci:v8086dA36Dsv1043sd8694bc0Csc03i30 
not found.

$ modinfo xhci_pci
name:   xhci_pci
filename:   (builtin)
license:GPL
file:   drivers/usb/host/xhci-pci
description:xHCI PCI Host Controller Driver

The builtin module is missing alias "pci:v*d*sv*sd*bc0Csc03i30*" which will be
generated by modpost if the module is built separately.

To fix this it is necessary to add the generated by modpost modalias to
modules.builtin.modinfo.

Fortunately modpost already generates .vmlinux.export.c for exported symbols. It
is possible to use this file to create a '.modinfo' section for builtin modules.
The modules.builtin.modinfo file becomes a composite file. One part is extracted
from vmlinux.o, the other part from .vmlinux.export.o.

Notes:
- v3:
  * Add `Reviewed-by` tag to patches from Petr Pavlu.
  * Rebase to v6.15.
  * v2: https://lore.kernel.org/all/20250509164237.2886508-1-leg...@kernel.org/

- v2:
  * Drop patch for mfd because it was already applied and is in linux-next.
  * The generation of aliases for builtin modules has been redone as
suggested by Masahiro Yamada.
  * Rebase to v6.15-rc5-136-g9c69f8884904
  * v1: https://lore.kernel.org/all/cover.1745591072.git.leg...@kernel.org/

Alexey Gladkov (6):
  scsi: Define MODULE_DEVICE_TABLE only if necessary
  modules: Add macros to specify modinfo prefix
  modpost: Make mod_device_table aliases more unique
  modpost: Create modalias for builtin modules
  kbuild: Move modules.builtin.modinfo to another makefile
  kbuild: Create modules.builtin.modinfo for modpost results

 drivers/scsi/BusLogic.c |  2 +-
 include/linux/module.h  | 21 +++-
 include/linux/moduleparam.h |  7 --
 scripts/Makefile.vmlinux| 48 +
 scripts/Makefile.vmlinux_o  | 26 +---
 scripts/mod/file2alias.c| 34 ++
 scripts/mod/modpost.c   | 13 +-
 scripts/mod/modpost.h   |  2 ++
 8 files changed, 114 insertions(+), 39 deletions(-)

-- 
2.49.0




Re: [PATCH] rust: kunit: use crate-level mapping for `c_void`

2025-05-27 Thread Jesung Yang
Hi,

On Tue, May 27, 2025 at 9:06 PM Benno Lossin  wrote:
>
> We don't need to explicitly import it, as `c_void` is present in the
> prelude since 3d5bef5d47c3 ("rust: add C FFI types to the prelude").

The base commit of my patch is f4daa80d6be7 ("rust: compile libcore with
edition 2024 for 1.87+"), which unfortunately predates the addition of
`use crate::prelude::*`. As a result, removing `use kernel::ffi::c_void`
causes the build to fail with the following error:

```
error[E0412]: cannot find type `c_void` in this scope
  --> rust/kernel/kunit.rs:22:41
   |
22 | &args as *const _ as *const c_void,
   | ^^ not found in this scope
   |
help: consider importing one of these enums
   |
9  + use crate::prelude::c_void;
   |
9  + use core::ffi::c_void;
   |
9  + use ffi::c_void;
   |

error[E0412]: cannot find type `c_void` in this scope
  --> rust/kernel/kunit.rs:38:41
   |
38 | &args as *const _ as *const c_void,
   | ^^ not found in this scope
   |
help: consider importing one of these enums
   |
9  + use crate::prelude::c_void;
   |
9  + use core::ffi::c_void;
   |
9  + use ffi::c_void;
   |

error: aborting due to 2 previous errors
```

Starting from commit c4c0574ee33b ("rust: add `kunit_tests` to the
prelude"), we do have `use crate::prelude::*;`, so the explicit import
is no longer necessary in that context.

Thanks for pointing this out!

Best regards,
Jesung



[PATCH v2] selftests: acct: fix grammar and clarify output messages - Fixed email case mismatch in Signed-off-by

2025-05-27 Thread Abdelrahman Fekry
Hi, i already sent version 2 as a new thread 2 days ago
but found out that i should also send as reply to
the original thread so here it is.

v2 changes:
- Fixed email case mismatch in Signed-off-by

This patch improves the clarity and grammar of output messages
in the acct() selftest. Minor changes were made to
user-facing strings and comments to make them easier to understand
and more consistent with the kselftest style.

Changes include:
- Fixing grammar in printed messages and comments.
- Rewording error and success outputs for clarity and professionalism.
- Making the "root check" message more direct.

These updates improve readability without affecting test logic or behavior.

Signed-off-by: Abdelrahman Fekry 
---
 tools/testing/selftests/acct/acct_syscall.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/acct/acct_syscall.c 
b/tools/testing/selftests/acct/acct_syscall.c
index 87c044fb9293..2c120a527574 100644
--- a/tools/testing/selftests/acct/acct_syscall.c
+++ b/tools/testing/selftests/acct/acct_syscall.c
@@ -22,9 +22,9 @@ int main(void)
ksft_print_header();
ksft_set_plan(1);
 
-   // Check if test is run a root
+   // Check if test is run as root
if (geteuid()) {
-   ksft_exit_skip("This test needs root to run!\n");
+   ksft_exit_skip("This test must be run as root!\n");
return 1;
}
 
@@ -52,7 +52,7 @@ int main(void)
child_pid = fork();
 
if (child_pid < 0) {
-   ksft_test_result_error("Creating a child process to log 
failed\n");
+   ksft_test_result_error("Failed to create child process for 
logging\n");
acct(NULL);
return 1;
} else if (child_pid > 0) {
-- 
2.25.1




Re: [PATCH bpf-next v2 1/2] bpf, arm64: Support up to 12 function arguments

2025-05-27 Thread Alexis Lothoré
Hi Xu, thanks for the review

On Tue May 27, 2025 at 10:11 AM CEST, Xu Kuohai wrote:
> On 5/22/2025 6:14 PM, Alexis Lothoré wrote:
>
> [...]
>
>> -static void save_args(struct jit_ctx *ctx, int args_off, int nregs)
>> +struct arg_aux {
>> +/* how many args are passed through registers, the rest of the args are
>> + * passed through stack
>> + */
>> +int args_in_regs;
>> +/* how many registers are used to pass arguments */
>> +int regs_for_args;
>> +/* how much stack is used for additional args passed to bpf program
>> + * that did not fit in original function registers
>> + **/
>
> nit: "**/" should be "*/"

ACK

[...]

>> +a->ostack_for_args = 0;
>> +
>> +/* the rest arguments are passed through stack */
>> +for (a->ostack_for_args = 0, a->bstack_for_args = 0;
>> + i < m->nr_args; i++) {
>
> a->ostack_for_args is initialized twice.
>
> move all initializations before the loop?

ACK

>> +/* We can not know for sure about exact alignment needs for
>> + * struct passed on stack, so deny those
>> + */
>> +if (m->arg_flags[i] & BTF_FMODEL_STRUCT_ARG)
>> +return -EOPNOTSUPP;
>
> leave the error code as is, namely, return -ENOTSUPP?

Actually this change follows a complaint from checkpatch:

"WARNING: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP"

>> +stack_slots = (m->arg_size[i] + 7) / 8;
>> +/* AAPCS 64 C.14: arguments passed on stack must be aligned to
>> + * max(8, arg_natural_alignment)
>> + */
>> +a->bstack_for_args += stack_slots * 8;
>> +a->ostack_for_args = round_up(a->ostack_for_args + stack_slots 
>> * 8, 8);
>
> since a->ostack_for_args starts from 0 and is always incremented
> by multiples of 8, round_up() to 8 is not needed.

True. This is a (partial) remnant from the first attempt to handle more
exotic alignments like large structs or __int128, but that's indeed not
needed for this current version. I'll clean it up.

[...]

>> +for (i = a->args_in_regs; i < m->nr_args; i++) {
>> +slots = (m->arg_size[i] + 7) / 8;
>> +/* AAPCS C.14: additional arguments on stack must be
>> + * aligned on max(8, arg_natural_alignment)
>> + */
>> +soff = round_up(soff, 8);
>> +if (for_call_origin)
>> +doff =  round_up(doff, 8);
>
> since both soff and doff start from multiples of 8 and are
> incremented by 8 each time, the two round_up()s are also
> not needed.

ACK. I guess the small AAPCS mention can go too then.

>
>> +/* verifier ensures arg_size <= 16, so slots equals 1 or 2 */
>> +while (slots-- > 0) {
>> +emit(A64_LDR64I(tmp, A64_FP, soff), ctx);
>> +/* if there is unused space in the last slot, clear
>> + * the garbage contained in the space.
>> + */
>> +if (slots == 0 && !for_call_origin)
>> +clear_garbage(ctx, tmp, m->arg_size[i] % 8);
>> +emit(A64_STR64I(tmp, A64_SP, doff), ctx);
>> +soff += 8;
>> +doff += 8;
>> +}
>> +}
>> +}
>
> [...]




-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com




Re: [PATCH] rust: kunit: use crate-level mapping for `c_void`

2025-05-27 Thread Miguel Ojeda
On Tue, May 27, 2025 at 2:06 PM Benno Lossin  wrote:
>
> We don't need to explicitly import it, as `c_void` is present in the
> prelude since 3d5bef5d47c3 ("rust: add C FFI types to the prelude").

Hmm... But the prelude isn't there yet in this patch, no? i.e. our
prelude is (so far) not a "real prelude" that gets injected
automatically. So I guess you mean importing the prelude instead.

(It is imported in the KUnit series anyway, so it will llikely be
there either way)

Thanks!

Cheers,
Miguel



Re: [PATCH v3 7/6] scsi: Always define MODULE_DEVICE_TABLE

2025-05-27 Thread Alexey Gladkov
On Tue, May 27, 2025 at 09:22:09AM -0400, James Bottomley wrote:
> On Tue, 2025-05-27 at 15:15 +0200, Alexey Gladkov wrote:
> > Since MODULE_DEVICE_TABLE no longer depends on whether the module is
> > built separately or compiled into the kernel, it now makes sense to
> > always define DEVICE_TABLE. In this case, even if the module is in
> > the
> > kernel, correct module.builtin.modaliases will be generated.
> > 
> > Suggested-by: James Bottomley 
> > Signed-off-by: Alexey Gladkov 
> > ---
> >  drivers/scsi/BusLogic.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
> > index 8ce2ac9293a3..08e12a3d6703 100644
> > --- a/drivers/scsi/BusLogic.c
> > +++ b/drivers/scsi/BusLogic.c
> > @@ -3715,7 +3715,6 @@ static void __exit blogic_exit(void)
> >  
> >  __setup("BusLogic=", blogic_setup);
> >  
> > -#ifdef MODULE
> >  /*static const struct pci_device_id blogic_pci_tbl[] = {
> >     { PCI_VENDOR_ID_BUSLOGIC,
> > PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER,
> >       PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> > @@ -3732,7 +3731,6 @@ static const struct pci_device_id
> > blogic_pci_tbl[] = {
> >     {0, },
> >  };
> >  MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);
> > -#endif
> 
> You don't need to do this in two steps.  The original problem of
> defined but not used table stopped being a problem when the structure
> was converted to static const over ten years ago (the compiler doesn't
> warn about unused static consts).

Ah. Ok, I will recreate this patch shortly.

Basically my original plan was to fix compilation errors as a first step,
and second step make MODULE_DEVICE_TABLE be used independently of MODULE.
Because there are a bunch of modules that also use MODULE_DEVICE_TABLE
only if MODULE is defined.

-- 
Rgrds, legion




Re: [PATCH v2 3/3] remoteproc: imx_rproc: add power mode check for remote core attachment

2025-05-27 Thread Hiago De Franco
On Tue, May 27, 2025 at 01:58:46PM +0200, Ulf Hansson wrote:
> On Tue, 27 May 2025 at 03:29, Peng Fan  wrote:
> >
> > On Mon, May 26, 2025 at 09:05:10PM -0300, Hiago De Franco wrote:
> > >On Mon, May 26, 2025 at 12:07:49PM +0200, Ulf Hansson wrote:
> > >> On Fri, 23 May 2025 at 21:17, Hiago De Franco  
> > >> wrote:
> > >> >
> > >> > Hi Ulf,
> > >> >
> > >> > On Wed, May 21, 2025 at 02:11:02PM +0200, Ulf Hansson wrote:
> > >> > > You should not provide any flag (or attach_data to
> > >> > > dev_pm_domain_attach_list()) at all. In other words just call
> > >> > > dev_pm_domain_attach_list(dev, NULL, &priv->pd_list), similar to how
> > >> > > drivers/remoteproc/imx_dsp_rproc.c does it.
> > >> > >
> > >> > > In this way, the device_link is created by making the platform->dev
> > >> > > the consumer and by keeping the supplier-devices (corresponding to 
> > >> > > the
> > >> > > genpds) in RPM_SUSPENDED state.
> > >> > >
> > >> > > The PM domains (genpds) are then left in their current state, which
> > >> > > should allow us to call dev_pm_genpd_is_on() for the corresponding
> > >> > > supplier-devices, to figure out whether the bootloader turned them on
> > >> > > or not, I think.
> > >> > >
> > >> > > Moreover, to make sure the genpds are turned on when needed, we also
> > >> > > need to call pm_runtime_enable(platform->dev) and
> > >> > > pm_runtime_get_sync(platform->dev). The easiest approach is probably
> > >> > > to do that during ->probe() - and then as an improvement on top you
> > >> > > may want to implement more fine-grained support for runtime PM.
> > >> > >
> > >> > > [...]
> > >> > >
> > >> > > Kind regards
> > >> > > Uffe
> > >> >
> > >> > I did some tests here and I might be missing something. I used the
> > >> > dev_pm_genpd_is_on() inside imx_rproc.c with the following changes:
> > >> >
> > >> > @@ -902,7 +902,12 @@ static int imx_rproc_attach_pd(struct imx_rproc 
> > >> > *priv)
> > >> > if (dev->pm_domain)
> > >> > return 0;
> > >> >
> > >> > ret = dev_pm_domain_attach_list(dev, &pd_data, &priv->pd_list);
> > >> > +   printk("hfranco: returned pd devs is %d", ret);
> > >> > +   for (int i = 0; i < ret; i++) {
> > >> > +   test = dev_pm_genpd_is_on(priv->pd_list->pd_devs[i]);
> > >> > +   printk("hfranco: returned value is %d", test);
> > >> > +   }
> > >> > return ret < 0 ? ret : 0;
> > >> >  }
> > >> >
> > >> > This was a quick test to check the returned value, and it always return
> > >> > 1 for both pds, even if I did not boot the remote core.
> > >> >
> > >> > So I was wondering if it was because of PD_FLAG_DEV_LINK_ON, I removed
> > >> > it and passed NULL to dev_pm_domain_attach_list().
> > >>
> > >> Right, that's exactly what we should be doing.
> > >>
> > >> > Booting the kernel
> > >> > now it correctly reports 0 for both pds, however when I start the
> > >> > remote core with a hello world firmware and boot the kernel, the CPU
> > >> > resets with a fault reset ("Reset cause: SCFW fault reset").
> > >> >
> > >> > I added both pm functions to probe, just to test:
> > >> >
> > >> > @@ -1152,6 +1158,9 @@ static int imx_rproc_probe(struct 
> > >> > platform_device *pdev)
> > >> > goto err_put_clk;
> > >> > }
> > >> >
> > >> > +   pm_runtime_enable(dev);
> > >> > +   pm_runtime_get_sync(dev);
> > >> > +
> > >>
> > >> Indeed, calling pm_runtime_enable() and then pm_runtime_get_sync()
> > >> should turn on the PM domains for the device, which I assume is needed
> > >> at some point.
> > >>
> > >> Although, I wonder if this may be a bit too late, I would expect that
> > >> you at least need to call these *before* the call to rproc_add(), as I
> > >> assume the rproc-core may start using the device/driver beyond that
> > >> point.
> > >>
> > >> > return 0
> > >> >
> > >> > Now the kernel boot with the remote core running, but it still returns
> > >> > 0 from dev_pm_genpd_is_on(). So basically now it always returns 0, with
> > >> > or without the remote core running.
> > >>
> > >> dev_pm_genpd_is_on() is returning the current status of the PM domain
> > >> (genpd) for the device.
> > >>
> > >> Could it be that the genpd provider doesn't register its PM domains
> > >> with the state that the HW is really in? pm_genpd_init() is the call
> > >> that allows the genpd provider to specify the initial state.
> > >>
> > >> I think we need Peng's help here to understand what goes on.
> > >>
> > >> >
> > >> > I tried to move pm_runtime_get_sync() to .prepare function but it make
> > >> > the kernel not boot anymore (with the SCU fault reset).
> > >>
> > >> Try move pm_runtime_enable() before rproc_add().
> > >
> > >Thanks Ulf, that indeed made it work, at least now the kernel does not
> > >reset anymore with the SCU fault reset. However I am still only getting
> > >0 from dev_pm_genpd_is_on(), no matter what the state of the remote
> > >core. Maybe I am missing something in between?
> 

[PATCH v4 1/6] scsi: Always define blogic_pci_tbl structure

2025-05-27 Thread Alexey Gladkov
The blogic_pci_tbl structure is used by the MODULE_DEVICE_TABLE macro.
There is no longer a need to protect it with the MODULE condition, since
this no longer causes the compiler to warn about an unused variable.

Cc: Khalid Aziz 
Cc: "Martin K. Petersen" 
Suggested-by: James Bottomley 
Signed-off-by: Alexey Gladkov 
---
 drivers/scsi/BusLogic.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index 1f100270cd38..08e12a3d6703 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -3715,7 +3715,6 @@ static void __exit blogic_exit(void)
 
 __setup("BusLogic=", blogic_setup);
 
-#ifdef MODULE
 /*static const struct pci_device_id blogic_pci_tbl[] = {
{ PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER,
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
@@ -3731,7 +3730,6 @@ static const struct pci_device_id blogic_pci_tbl[] = {
{PCI_DEVICE(PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_FLASHPOINT)},
{0, },
 };
-#endif
 MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);
 
 module_init(blogic_init);
-- 
2.49.0




Re: [PATCH v3] media: add virtio-media driver

2025-05-27 Thread Alexandre Courbot
On Tue, May 27, 2025 at 10:35 PM Mauro Carvalho Chehab
 wrote:
>
> Em Tue, 27 May 2025 22:21:42 +0900
> Alexandre Courbot  escreveu:
>
> > On Tue, May 27, 2025 at 6:13 PM Mauro Carvalho Chehab
> >  wrote:
> > >
> > > Em Tue, 27 May 2025 15:14:50 +0900
> > > "Alexandre Courbot"  escreveu:
> > >
> > > > Hi Mauro,
> > > >
> > > > On Mon May 26, 2025 at 9:13 PM JST, Mauro Carvalho Chehab wrote:
> > > > > Hi Michael,
> > > > >
> > > > > Em Sat, 12 Apr 2025 13:08:01 +0900
> > > > > Alexandre Courbot  escreveu:
> > > > >
> > > > >> Add the first version of the virtio-media driver.
> > > > >>
> > > > >> This driver acts roughly as a V4L2 relay between user-space and the
> > > > >> virtio virtual device on the host, so it is relatively simple, yet
> > > > >> unconventional. It doesn't use VB2 or other frameworks typically 
> > > > >> used in
> > > > >> a V4L2 driver, and most of its complexity resides in correctly and
> > > > >> efficiently building the virtio descriptor chain to pass to the host,
> > > > >> avoiding copies whenever possible. This is done by
> > > > >> scatterlist_builder.[ch].
> > > > >>
> > > > >> virtio_media_ioctls.c proxies each supported ioctl to the host, using
> > > > >> code generated through macros for ioctls that can be forwarded 
> > > > >> directly,
> > > > >> which is most of them.
> > > > >>
> > > > >> virtio_media_driver.c provides the expected driver hooks, and support
> > > > >> for mmapping and polling.
> > > > >>
> > > > >>  This version supports MMAP buffers, while USERPTR buffers can also 
> > > > >> be
> > > > >>  enabled through a driver option. DMABUF support is still pending.
> > > > >
> > > > > It sounds that you applied this one at the virtio tree, but it hasn't
> > > > > being reviewed or acked by media maintainers.
> > > > >
> > > > > Please drop it.
> > > > >
> > > > > Alexandre,
> > > > >
> > > > > Please send media patches to media maintainers, c/c other subsystem
> > > > > maintainers, as otherwise they might end being merged without a
> > > > > proper review.
> > > >
> > > > Sorry about that, I put everyone in "To:" without giving it a second
> > > > thought.
> > > >
> > > > >
> > > > > In this particular case, we need to double-check if this won't cause
> > > > > any issues, in special with regards to media locks and mutexes.
> > > >
> > > > Agreed, I am not 100% confident about that part myself.
> > > >
> > > > >
> > > > > I'll try to look on it after this merge window, as it is too late
> > > > > for it to be applied during this one.
> > > >
> > > > Appreciate that - given the high traffic on the list I was worried that
> > > > this patch would eventually be overlooked. Not making it for this merge
> > > > window should not be a problem, so please take the time you need.
> > >
> > > Provided that your patch was caught by patchwork, it won't be lost:
> > > 
> > > https://patchwork.linuxtv.org/project/linux-media/patch/20250412-virtio-media-v3-1-97dc94c18...@gmail.com/
> > >
> > > Please notice that our CI got a number of checkpatch issues there.
> > > Please check and fix the non-false-positive ones.
> >
> > Will do. The macro-related ones are false-positives AFAICT. Some of
> > the "lines should not end with a '('" are actually the result of
> > applying clang-format with the kernel-provided style...
>
> I don't know any lint tool that honors kernel style. The best one
> is checkpatch with the auto-correcting parameter in pedantic mode,
> but still one needs to manually review its output.
>
> >
> > >
> > > Btw, I was looking at:
> > >
> > > https://github.com/chromeos/virtio-media
> > >
> > > (I'm assuming that this is the QEMU counterpart, right?)
> >
> > crosvm actually, but QEMU support is also being worked on.
>
> Do you have already QEMU patches? The best is to have the Kernel driver
> submitted altogether with QEMU, as Kernel developers need it to do the
> tests. In my case, I never use crosvm, and I don't have any Chromebook
> anymore.

IIRC Albert Esteve was working on this, maybe he can share the current status.

Note that crosvm does not require a Chromebook, you can build and run
it pretty easily on a regular PC. I have put together a document to
help with that:

https://github.com/chromeos/virtio-media/blob/main/TRY_IT_OUT.md

It also shows how to proxy a host UVC camera into the guest and use
some of the "fake" devices I talked about earlier. If following these
steps is too much friction, just reading through the document should
give you a decent idea of what virtio-media can do.

>
> > > And I noticed something weird there:
> > >
> > > "Unsupported ioctls
> > >
> > >  A few ioctls are replaced by other, more suitable mechanisms. If 
> > > being requested these ioctls, the device must return the same response as 
> > > it would for an unknown ioctl, i.e. ENOTTY.
> > >
> > > VIDIOC_QUERYCAP is replaced by reading the configuration area.
> > > VIDIOC_DQBUF is replaced by a dedicated event.
> > >

Re: [PATCH v3] media: add virtio-media driver

2025-05-27 Thread Michael S. Tsirkin
On Mon, May 26, 2025 at 02:13:16PM +0200, Mauro Carvalho Chehab wrote:
> Hi Michael,
> 
> Em Sat, 12 Apr 2025 13:08:01 +0900
> Alexandre Courbot  escreveu:
> 
> > Add the first version of the virtio-media driver.
> > 
> > This driver acts roughly as a V4L2 relay between user-space and the
> > virtio virtual device on the host, so it is relatively simple, yet
> > unconventional. It doesn't use VB2 or other frameworks typically used in
> > a V4L2 driver, and most of its complexity resides in correctly and
> > efficiently building the virtio descriptor chain to pass to the host,
> > avoiding copies whenever possible. This is done by
> > scatterlist_builder.[ch].
> > 
> > virtio_media_ioctls.c proxies each supported ioctl to the host, using
> > code generated through macros for ioctls that can be forwarded directly,
> > which is most of them.
> > 
> > virtio_media_driver.c provides the expected driver hooks, and support
> > for mmapping and polling.
> > 
> >  This version supports MMAP buffers, while USERPTR buffers can also be
> >  enabled through a driver option. DMABUF support is still pending.
> 
> It sounds that you applied this one at the virtio tree, but it hasn't
> being reviewed or acked by media maintainers.
> 
> Please drop it.
> 
> Alexandre,
> 
> Please send media patches to media maintainers, c/c other subsystem
> maintainers, as otherwise they might end being merged without a
> proper review.
> 
> In this particular case, we need to double-check if this won't cause
> any issues, in special with regards to media locks and mutexes.
> 
> I'll try to look on it after this merge window, as it is too late
> for it to be applied during this one.
> 
> Regards,
> Mauro

New drivers generally can be merged during the merge window,
especially early.  It's up to you though.
I can keep it in next for now, so it gets some coverage by
tools scanning that tree.


> > 
> > Signed-off-by: Alexandre Courbot 
> > Signed-off-by: Alexandre Courbot 
> > ---
> > This patch adds the virtio-media kernel driver. Virtio-media [1]
> > encapsulates the V4L2 structures and protocol to enable the
> > virtualization of host media devices into a guest. It's specification is
> > in the final stages [2] of being merged and the virtualization of
> > cameras and video accelerator devices has already been demonstrated
> > using crosvm [3] and QEmu. v4l2-compliance also passes on all tested
> > devices, which includes the "simple" virtual test device, proxied host
> > UVC and vivid devices, and the FFmpeg virtual decoder devices (refer to
> > [3] in order to test these if desired).
> > 
> > Virtio-media is merged in AOSP [4] and ChromeOS. Upstreaming of the
> > driver is overdue, but I hope we can start the review process and
> > converge into something that can be merged.
> > 
> > Limitations:
> > 
> > - The driver is currently only available to little-endian, 64-bit
> >   kernels. This is because some of the V4L2 structures used for
> >   communication between guest and host have a layout dependent on the
> >   architecture, and the virtio-media protocol is standardized on the
> >   little-endian 64-bit versions. This can be fixed with a conversion
> >   layer similar to the one used to convert 32-bit ioctls to their 64-bit
> >   counterpart.
> > - DMABUF support is currently missing. It should be implemented using
> >   virtio objects, with possible support for memfds using the
> >   SHARED_PAGES memory type.
> > - No support for the media API and requests. While the use-case for
> >   these is less important on virtual devices where we want to present an
> >   abstraction as high as possible to limit VM exits, they do exist and
> >   it would be nice to add behind a virtio feature bit.
> > - Locking in the driver is still very basic. This is something I want to
> >   improve before merging, but I didn't want to delay upstream review any
> >   further.
> > 
> > [1] https://github.com/chromeos/virtio-media
> > [2] 
> > https://lore.kernel.org/virtio-comment/20250304130134.1856056-1-aest...@redhat.com/
> > [3] https://github.com/chromeos/virtio-media/blob/main/TRY_IT_OUT.md
> > [4] https://android.googlesource.com/platform/external/virtio-media/
> > ---
> > Changes in v3:
> > - Rebased on top of v6.15-rc1 and removes obsolete control callbacks.
> > - Link to v2: 
> > https://lore.kernel.org/r/20250201-virtio-media-v2-1-ac8406814...@gmail.com
> > 
> > Changes in v2:
> > - Fixed kernel test robot and media CI warnings (ignored a few false
> >   positives).
> > - Changed in-driver email address to personal one since my Google one
> >   will soon become invalid.
> > - Link to v1: 
> > https://lore.kernel.org/r/20250123-virtio-media-v1-1-81e2549b8...@gmail.com
> > ---
> >  MAINTAINERS|6 +
> >  drivers/media/Kconfig  |   13 +
> >  drivers/media/Makefile |2 +
> >  drivers/media/virtio/Makefile  |9 +
> >  drivers/media/virtio/protocol.h   

[PATCH] virtio: document ENOSPC

2025-05-27 Thread Michael S. Tsirkin
drivers handle ENOSPC specially since it's an error one can
get from a working VQ. Document the semantics.

Reported-by: Parav Pandit 
Signed-off-by: Michael S. Tsirkin 
---
 drivers/virtio/virtio_ring.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index b784aab66867..97ab0cce527d 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -2296,6 +2296,10 @@ static inline int virtqueue_add(struct virtqueue *_vq,
  * at the same time (except where noted).
  *
  * Returns zero or a negative error (ie. ENOSPC, ENOMEM, EIO).
+ *
+ * NB: ENOSPC is a special code that is only returned on an attempt to add a
+ * buffer to a full VQ. It indicates that some buffers are outstanding and that
+ * the operation can be retried after some buffers have been used.
  */
 int virtqueue_add_sgs(struct virtqueue *_vq,
  struct scatterlist *sgs[],
-- 
MST




Re: [PATCH net-next v8] selftests/vsock: add initial vmtest.sh for vsock

2025-05-27 Thread Bobby Eshleman
On Mon, May 26, 2025 at 01:18:18PM +0200, Stefano Garzarella wrote:
> On Thu, May 22, 2025 at 09:59:07PM -0700, Bobby Eshleman wrote:
> > This commit introduces a new vmtest.sh runner for vsock.
> > 
> > It uses virtme-ng/qemu to run tests in a VM. The tests validate G2H,
> > H2G, and loopback. The testing tools from tools/testing/vsock/ are
> > reused. Currently, only vsock_test is used.
> > 
> > VMCI and hyperv support is included in the config file to be built with
> > the -b option, though not used in the tests.
> > 
> > Only tested on x86.
> > 
> > To run:
> > 
> >  $ make -C tools/testing/selftests TARGETS=vsock
> >  $ tools/testing/selftests/vsock/vmtest.sh
> > 
> > or
> > 
> >  $ make -C tools/testing/selftests TARGETS=vsock run_tests
> > 
> > Example runs (after make -C tools/testing/selftests TARGETS=vsock):
> > 
> > $ ./tools/testing/selftests/vsock/vmtest.sh
> > 1..3
> > ok 0 vm_server_host_client
> > ok 1 vm_client_host_server
> > ok 2 vm_loopback
> > SUMMARY: PASS=3 SKIP=0 FAIL=0
> > Log: /tmp/vsock_vmtest_m7DI.log
> > 
> > $ ./tools/testing/selftests/vsock/vmtest.sh vm_loopback
> > 1..1
> > ok 0 vm_loopback
> > SUMMARY: PASS=1 SKIP=0 FAIL=0
> > Log: /tmp/vsock_vmtest_a1IO.log
> > 
> > $ mkdir -p ~/scratch
> > $ make -C tools/testing/selftests install TARGETS=vsock 
> > INSTALL_PATH=~/scratch
> > [... omitted ...]
> > $ cd ~/scratch
> > $ ./run_kselftest.sh
> > TAP version 13
> > 1..1
> > # timeout set to 300
> > # selftests: vsock: vmtest.sh
> > # 1..3
> > # ok 0 vm_server_host_client
> > # ok 1 vm_client_host_server
> > # ok 2 vm_loopback
> > # SUMMARY: PASS=3 SKIP=0 FAIL=0
> > # Log: /tmp/vsock_vmtest_svEl.log
> > ok 1 selftests: vsock: vmtest.sh
> > 
> > Future work can include vsock_diag_test.
> > 
> > Because vsock requires a VM to test anything other than loopback, this
> > patch adds vmtest.sh as a kselftest itself. This is different than other
> > systems that have a "vmtest.sh", where it is used as a utility script to
> > spin up a VM to run the selftests as a guest (but isn't hooked into
> > kselftest).
> > 
> > Signed-off-by: Bobby Eshleman 
> > ---
> > Changes in v8:
> > - remove NIPA comment from commit msg
> > - remove tap_* functions and TAP_PREFIX
> > - add -b for building kernel
> > - Link to v7: 
> > https://lore.kernel.org/r/20250515-vsock-vmtest-v7-1-ba6fa86d6...@gmail.com
> > 
> > Changes in v7:
> > - fix exit code bug when ran is kselftest: use cnt_total instead of 
> > KSFT_NUM_TESTS
> > - updated commit message with updated output
> > - updated commit message with commands for installing/running as
> >  kselftest
> > - Link to v6: 
> > https://lore.kernel.org/r/20250515-vsock-vmtest-v6-1-9af1cc023...@gmail.com
> > 
> > Changes in v6:
> > - add make cmd in commit message in vmtest.sh example (Stefano)
> > - check nonzero size of QEMU_PIDFILE using -s conditional (Stefano)
> > - display log file path after tests so it is easier to find amongst other 
> > random names
> > - cleanup qemu pidfile if qemu is unable to remove it
> > - make oops/warning failures more obvious with 'FAIL' prefix in log
> >  (simply saying 'detected' wasn't clear enough to identify failing
> >  condition)
> > - Link to v5: 
> > https://lore.kernel.org/r/20250513-vsock-vmtest-v5-1-4e75c4a45...@gmail.com
> > 
> > Changes in v5:
> > - make log file a tmpfile (Paolo)
> > - make sure both default and user defined QEMU gets handled by the 
> > dependency check (Paolo)
> > - increased VM boot up timeout from 1m to 3m for slow hosts (Paolo)
> > - rename vm_setup -> vm_start (Paolo)
> > - derive wait_for_listener from selftests/net/net_helper.sh to removes ss 
> > usage
> > - Remove unused 'unset IFS' line (Paolo)
> > - leave space after variable declarations (Paolo)
> > - make QEMU_PIDFILE a tmp file (Paolo)
> > - make everything readonly that is only read (Paolo)
> > - source ktap_helpers.sh for KSFT_PASS and friends (Paolo)
> > - don't check for timeout util (Paolo)
> > - add missing usage string for -q qemu arg
> > - add tap prefix to SUMMARY line since it isn't part of TAP protocol
> > - exit with the correct status code based on failure/pass counts
> > - Link to v4: 
> > https://lore.kernel.org/r/20250507-vsock-vmtest-v4-1-6e2a97262...@gmail.com
> > 
> > Changes in v4:
> > - do not use special tab delimiter for help string parsing (Stefano + Paolo)
> > - fix paths for when installing kselftest and running out-of-tree (Paolo)
> > - change vng to using running kernel instead of compiled kernel (Paolo)
> > - use multi-line string for QEMU_OPTS (Stefano)
> > - change timeout to 300s (Paolo)
> > - skip if tools are not found and use kselftests status codes (Paolo)
> > - remove build from vmtest.sh (Paolo)
> > - change  -> SSH_HOST_PORT (Stefano)
> > - add tap-format output
> > - add vmtest.log to gitignore
> > - check for vsock_test binary and remind user to build it if missing
> > - create a proper build in makefile
> > - style fixes
> > - add ssh, timeout, and pkill to dependency check, just in ca

[PATCH v2 2/3] KVM: arm64: selftests: fix thread migration in arch_timer_edge_cases

2025-05-27 Thread Sebastian Ott
arch_timer_edge_cases tries to migrate itself across host cpus. Before
the first test it migrates to cpu 0 by setting up an affinity mask with
only bit 0 set. After that it looks for the next possible cpu in the
current affinity mask which still has only bit 0 set. So there is no
migration at all.

Fix this by reading the default mask at start and use this to find
the next cpu in each iteration.

Signed-off-by: Sebastian Ott 
---
 tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c 
b/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
index c4716e0c1438..a813b4c6c817 100644
--- a/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
+++ b/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
@@ -849,17 +849,17 @@ static void guest_code(enum arch_timer timer)
GUEST_DONE();
 }
 
+static cpu_set_t default_cpuset;
+
 static uint32_t next_pcpu(void)
 {
uint32_t max = get_nprocs();
uint32_t cur = sched_getcpu();
uint32_t next = cur;
-   cpu_set_t cpuset;
+   cpu_set_t cpuset = default_cpuset;
 
TEST_ASSERT(max > 1, "Need at least two physical cpus");
 
-   sched_getaffinity(0, sizeof(cpuset), &cpuset);
-
do {
next = (next + 1) % CPU_SETSIZE;
} while (!CPU_ISSET(next, &cpuset));
@@ -1046,6 +1046,8 @@ int main(int argc, char *argv[])
if (!parse_args(argc, argv))
exit(KSFT_SKIP);
 
+   sched_getaffinity(0, sizeof(default_cpuset), &default_cpuset);
+
if (test_args.test_virtual) {
test_vm_create(&vm, &vcpu, VIRTUAL);
test_run(vm, vcpu);
-- 
2.49.0




[PATCH v2 1/3] KVM: arm64: selftests: fix help text for arch_timer_edge_cases

2025-05-27 Thread Sebastian Ott
Fix the help text for arch_timer_edge_cases to show the correct
option for setting the wait time.

Signed-off-by: Sebastian Ott 
---
 tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c 
b/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
index a36a7e2db434..c4716e0c1438 100644
--- a/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
+++ b/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
@@ -986,7 +986,7 @@ static void test_print_help(char *name)
pr_info("\t-b: Test both physical and virtual timers (default: 
true)\n");
pr_info("\t-l: Delta (in ms) used for long wait time test (default: 
%u)\n",
 LONG_WAIT_TEST_MS);
-   pr_info("\t-l: Delta (in ms) used for wait times (default: %u)\n",
+   pr_info("\t-w: Delta (in ms) used for wait times (default: %u)\n",
WAIT_TEST_MS);
pr_info("\t-p: Test physical timer (default: true)\n");
pr_info("\t-v: Test virtual timer (default: true)\n");
-- 
2.49.0




Re: [PATCH v3] media: add virtio-media driver

2025-05-27 Thread Mauro Carvalho Chehab
Em Tue, 27 May 2025 10:23:32 -0400
"Michael S. Tsirkin"  escreveu:

> On Mon, May 26, 2025 at 02:13:16PM +0200, Mauro Carvalho Chehab wrote:
> > Hi Michael,
> > 
> > Em Sat, 12 Apr 2025 13:08:01 +0900
> > Alexandre Courbot  escreveu:
> >   
> > > Add the first version of the virtio-media driver.
> > > 
> > > This driver acts roughly as a V4L2 relay between user-space and the
> > > virtio virtual device on the host, so it is relatively simple, yet
> > > unconventional. It doesn't use VB2 or other frameworks typically used in
> > > a V4L2 driver, and most of its complexity resides in correctly and
> > > efficiently building the virtio descriptor chain to pass to the host,
> > > avoiding copies whenever possible. This is done by
> > > scatterlist_builder.[ch].
> > > 
> > > virtio_media_ioctls.c proxies each supported ioctl to the host, using
> > > code generated through macros for ioctls that can be forwarded directly,
> > > which is most of them.
> > > 
> > > virtio_media_driver.c provides the expected driver hooks, and support
> > > for mmapping and polling.
> > > 
> > >  This version supports MMAP buffers, while USERPTR buffers can also be
> > >  enabled through a driver option. DMABUF support is still pending.  
> > 
> > It sounds that you applied this one at the virtio tree, but it hasn't
> > being reviewed or acked by media maintainers.
> > 
> > Please drop it.
> > 
> > Alexandre,
> > 
> > Please send media patches to media maintainers, c/c other subsystem
> > maintainers, as otherwise they might end being merged without a
> > proper review.
> > 
> > In this particular case, we need to double-check if this won't cause
> > any issues, in special with regards to media locks and mutexes.
> > 
> > I'll try to look on it after this merge window, as it is too late
> > for it to be applied during this one.
> > 
> > Regards,
> > Mauro  
> 
> New drivers generally can be merged during the merge window,
> especially early. 

Sure, but this one was not reviewed or tested yet by media maintainers,
nor its submission came with the tests from the regression tool
we use (v4l2-compliance). In particular, we need to double-check
if it won't cause any issues with the complex set of mutexes and
spinlocks that we have within the core.

There is an additional concern related to V4L2: on media, only one
process is allowed to have exclusive streaming access to the
device: all other opens on the same device get permission denied
(by default - there is an optional ioctl that allows a process
to "abdicate" its streaming rights). We need to double-check how this
is implemented and how this would behavior when multiple VMs have
the driver installed and might try to use (or not), and how this
would affect the host access to the device.

There are also some coding style issues that cause our CI to
complain. Those are minor and could be fixed by a separate patch,
but better to have them placed altogether as otherwise our CI
will keep complaining about until the fix is merged.

On other words, this driver is not ready for merge yet.
We need some time to test and review it properly.

> It's up to you though.
> I can keep it in next for now, so it gets some coverage by
> tools scanning that tree.

Sure, feel free to keep it on next if you prefer so. Just
please don't submit it upstream while we don't review and
properly test it.

Thanks!
Mauro



[PATCH v2 0/3] KVM: arm64: selftests: arch_timer_edge_cases fixes

2025-05-27 Thread Sebastian Ott
Some small fixes for arch_timer_edge_cases that I stumbled upon
while debugging failures for this selftest on ampere-one.

Changes since v1: modified patch 3 based on suggestions from Marc.

I've done some tests with this on various machines - seems to be all
good, however on ampere-one I now hit this in 10% of the runs:
 Test Assertion Failure 
  arm64/arch_timer_edge_cases.c:481: timer_get_cntct(timer) >= DEF_CNT + 
(timer_get_cntfrq() * (uint64_t)(delta_2_ms) / 1000)
  pid=166657 tid=166657 errno=4 - Interrupted system call
 1  0x00404db3: test_run at arch_timer_edge_cases.c:933
 2  0x00401f9f: main at arch_timer_edge_cases.c:1062
 3  0xaedd625b: ?? ??:0
 4  0xaedd633b: ?? ??:0
 5  0x004020af: _start at ??:?
  timer_get_cntct(timer) >= DEF_CNT + msec_to_cycles(delta_2_ms)

This is not new, it was just hidden behind the other failure. I'll
try to figure out what this is about (seems to be independent of
the wait time)..


Sebastian Ott (3):
  KVM: arm64: selftests: fix help text for arch_timer_edge_cases
  KVM: arm64: selftests: fix thread migration in arch_timer_edge_cases
  KVM: arm64: selftests: arch_timer_edge_cases - determine effective counter 
width

 .../kvm/arm64/arch_timer_edge_cases.c | 37 ---
 1 file changed, 24 insertions(+), 13 deletions(-)


base-commit: 0ff41df1cb268fc69e703a08a57ee14ae967d0ca
-- 
2.49.0




Re: [PATCH v3] media: add virtio-media driver

2025-05-27 Thread Mauro Carvalho Chehab
Em Tue, 27 May 2025 23:03:39 +0900
Alexandre Courbot  escreveu:

> On Tue, May 27, 2025 at 10:35 PM Mauro Carvalho Chehab
>  wrote:
> >
> > Em Tue, 27 May 2025 22:21:42 +0900
> > Alexandre Courbot  escreveu:
> >  
> > > On Tue, May 27, 2025 at 6:13 PM Mauro Carvalho Chehab
> > >  wrote:  
> > > >
> > > > Em Tue, 27 May 2025 15:14:50 +0900
> > > > "Alexandre Courbot"  escreveu:
> > > >  
> > > > > Hi Mauro,
> > > > >
> > > > > On Mon May 26, 2025 at 9:13 PM JST, Mauro Carvalho Chehab wrote:  
> > > > > > Hi Michael,
> > > > > >
> > > > > > Em Sat, 12 Apr 2025 13:08:01 +0900
> > > > > > Alexandre Courbot  escreveu:
> > > > > >  
> > > > > >> Add the first version of the virtio-media driver.
> > > > > >>
> > > > > >> This driver acts roughly as a V4L2 relay between user-space and the
> > > > > >> virtio virtual device on the host, so it is relatively simple, yet
> > > > > >> unconventional. It doesn't use VB2 or other frameworks typically 
> > > > > >> used in
> > > > > >> a V4L2 driver, and most of its complexity resides in correctly and
> > > > > >> efficiently building the virtio descriptor chain to pass to the 
> > > > > >> host,
> > > > > >> avoiding copies whenever possible. This is done by
> > > > > >> scatterlist_builder.[ch].
> > > > > >>
> > > > > >> virtio_media_ioctls.c proxies each supported ioctl to the host, 
> > > > > >> using
> > > > > >> code generated through macros for ioctls that can be forwarded 
> > > > > >> directly,
> > > > > >> which is most of them.
> > > > > >>
> > > > > >> virtio_media_driver.c provides the expected driver hooks, and 
> > > > > >> support
> > > > > >> for mmapping and polling.
> > > > > >>
> > > > > >>  This version supports MMAP buffers, while USERPTR buffers can 
> > > > > >> also be
> > > > > >>  enabled through a driver option. DMABUF support is still pending. 
> > > > > >>  
> > > > > >
> > > > > > It sounds that you applied this one at the virtio tree, but it 
> > > > > > hasn't
> > > > > > being reviewed or acked by media maintainers.
> > > > > >
> > > > > > Please drop it.
> > > > > >
> > > > > > Alexandre,
> > > > > >
> > > > > > Please send media patches to media maintainers, c/c other subsystem
> > > > > > maintainers, as otherwise they might end being merged without a
> > > > > > proper review.  
> > > > >
> > > > > Sorry about that, I put everyone in "To:" without giving it a second
> > > > > thought.
> > > > >  
> > > > > >
> > > > > > In this particular case, we need to double-check if this won't cause
> > > > > > any issues, in special with regards to media locks and mutexes.  
> > > > >
> > > > > Agreed, I am not 100% confident about that part myself.
> > > > >  
> > > > > >
> > > > > > I'll try to look on it after this merge window, as it is too late
> > > > > > for it to be applied during this one.  
> > > > >
> > > > > Appreciate that - given the high traffic on the list I was worried 
> > > > > that
> > > > > this patch would eventually be overlooked. Not making it for this 
> > > > > merge
> > > > > window should not be a problem, so please take the time you need.  
> > > >
> > > > Provided that your patch was caught by patchwork, it won't be lost:
> > > > 
> > > > https://patchwork.linuxtv.org/project/linux-media/patch/20250412-virtio-media-v3-1-97dc94c18...@gmail.com/
> > > >
> > > > Please notice that our CI got a number of checkpatch issues there.
> > > > Please check and fix the non-false-positive ones.  
> > >
> > > Will do. The macro-related ones are false-positives AFAICT. Some of
> > > the "lines should not end with a '('" are actually the result of
> > > applying clang-format with the kernel-provided style...  
> >
> > I don't know any lint tool that honors kernel style. The best one
> > is checkpatch with the auto-correcting parameter in pedantic mode,
> > but still one needs to manually review its output.
> >  
> > >  
> > > >
> > > > Btw, I was looking at:
> > > >
> > > > https://github.com/chromeos/virtio-media
> > > >
> > > > (I'm assuming that this is the QEMU counterpart, right?)  
> > >
> > > crosvm actually, but QEMU support is also being worked on.  
> >
> > Do you have already QEMU patches? The best is to have the Kernel driver
> > submitted altogether with QEMU, as Kernel developers need it to do the
> > tests. In my case, I never use crosvm, and I don't have any Chromebook
> > anymore.  
> 
> IIRC Albert Esteve was working on this, maybe he can share the current status.

That would be nice.

> 
> Note that crosvm does not require a Chromebook, you can build and run
> it pretty easily on a regular PC. I have put together a document to
> help with that:
> 
> https://github.com/chromeos/virtio-media/blob/main/TRY_IT_OUT.md
> 
> It also shows how to proxy a host UVC camera into the guest and use
> some of the "fake" devices I talked about earlier.

Ok, I'll look on it, thanks for the hint!

> If following these
> steps is too much friction, just reading through the document should
> give you a decent idea of

Re: [PATCH v4 1/2] livepatch, x86/module: Generalize late module relocation locking.

2025-05-27 Thread Petr Mladek
On Thu 2025-05-22 20:52:04, Dylan Hatch wrote:
> Late module relocations are an issue on any arch that supports
> livepatch, so move the text_mutex locking to the livepatch core code.
> 
> Signed-off-by: Dylan Hatch 
> Acked-by: Song Liu 
> ---
>  arch/x86/kernel/module.c |  8 ++--
>  kernel/livepatch/core.c  | 18 +-
>  2 files changed, 15 insertions(+), 11 deletions(-)
> 
> --- a/arch/x86/kernel/module.c
> +++ b/arch/x86/kernel/module.c
> @@ -197,18 +197,14 @@ static int write_relocate_add(Elf64_Shdr *sechdrs,
>   bool early = me->state == MODULE_STATE_UNFORMED;
>   void *(*write)(void *, const void *, size_t) = memcpy;
>  
> - if (!early) {
> + if (!early)
>   write = text_poke;
> - mutex_lock(&text_mutex);
> - }
>  
>   ret = __write_relocate_add(sechdrs, strtab, symindex, relsec, me,
>  write, apply);
>  
> - if (!early) {
> + if (!early)
>   text_poke_sync();
> - mutex_unlock(&text_mutex);
> - }
>  
>   return ret;
>  }
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index 0e73fac55f8eb..9968441f73510 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -319,12 +320,19 @@ static int klp_write_section_relocs(struct module 
> *pmod, Elf_Shdr *sechdrs,
> sec, sec_objname);
>   if (ret)
>   return ret;
> -
> - return apply_relocate_add(sechdrs, strtab, symndx, secndx, 
> pmod);
>   }
>  
> - clear_relocate_add(sechdrs, strtab, symndx, secndx, pmod);
> - return 0;
> + if (!early)
> + mutex_lock(&text_mutex);

I understand why you do this but it opens some questions.

As this patch suggests, the "text_mutex" has been used to
sychronize apply_relocate_add() only on x86_64 so far.

s390x seems to rely on "s390_kernel_write_lock" taken by:

  + apply_relocate_add()
+ s390_kernel_write()
  + __s390_kernel_write()

And powerpc seems to rely on "pte" locking taken by

  + apply_relocate_add()
+ patch_instruction()
  + patch_mem()
+ __do_patch_mem_mm()
  + get_locked_pte()

I see two possibilities:

  1. Either this change makes a false feeling that "text_mutex"
 sychronizes apply_relocate_add() on all architextures.

 This does not seems to be the case on, for example, s390
 and powerpc.

 => The code is misleading and could lead to troubles.


   2. Or it actually provides some sychronization on all
  architectures, for example, against kprobe code.

  In this case, it might actually fix an existing race.
  It should be described in the commit message
  and nominated for backporting to stable.


I am sorry if this has already been discussed. But I have been
in Cc only for v3 and v4. And there is no changelog in
the cover letter.

> +
> + if (apply)
> + ret = apply_relocate_add(sechdrs, strtab, symndx, secndx, pmod);
> + else
> + clear_relocate_add(sechdrs, strtab, symndx, secndx, pmod);
> +
> + if (!early)
> + mutex_unlock(&text_mutex);
> + return ret;
>  }

Best Regards,
Petr



[RFC PATCH net-next v2 1/2] virtio-net: support zerocopy multi buffer XDP in mergeable

2025-05-27 Thread Bui Quang Minh
Currently, in zerocopy mode with mergeable receive buffer, virtio-net
does not support multi buffer but a single buffer only. This commit adds
support for multi mergeable receive buffer in the zerocopy XDP path by
utilizing XDP buffer with frags.

Signed-off-by: Bui Quang Minh 
---
 drivers/net/virtio_net.c | 123 +--
 1 file changed, 66 insertions(+), 57 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index e53ba600605a..a9558650f205 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -45,6 +45,8 @@ module_param(napi_tx, bool, 0644);
 #define VIRTIO_XDP_TX  BIT(0)
 #define VIRTIO_XDP_REDIR   BIT(1)
 
+#define VIRTNET_MAX_ZC_SEGS8
+
 /* RX packet size EWMA. The average packet size is used to determine the packet
  * buffer size when refilling RX rings. As the entire RX ring may be refilled
  * at once, the weight is chosen so that the EWMA will be insensitive to short-
@@ -1232,65 +1234,53 @@ static void xsk_drop_follow_bufs(struct net_device *dev,
}
 }
 
-static int xsk_append_merge_buffer(struct virtnet_info *vi,
-  struct receive_queue *rq,
-  struct sk_buff *head_skb,
-  u32 num_buf,
-  struct virtio_net_hdr_mrg_rxbuf *hdr,
-  struct virtnet_rq_stats *stats)
+static int virtnet_build_xsk_buff_mrg(struct virtnet_info *vi,
+ struct receive_queue *rq,
+ u32 num_buf,
+ struct xdp_buff *xdp,
+ struct virtnet_rq_stats *stats)
 {
-   struct sk_buff *curr_skb;
-   struct xdp_buff *xdp;
-   u32 len, truesize;
-   struct page *page;
+   unsigned int len;
void *buf;
 
-   curr_skb = head_skb;
+   if (num_buf < 2)
+   return 0;
+
+   while (num_buf > 1) {
+   struct xdp_buff *new_xdp;
 
-   while (--num_buf) {
buf = virtqueue_get_buf(rq->vq, &len);
-   if (unlikely(!buf)) {
-   pr_debug("%s: rx error: %d buffers out of %d missing\n",
-vi->dev->name, num_buf,
-virtio16_to_cpu(vi->vdev,
-hdr->num_buffers));
+   if (!unlikely(buf)) {
+   pr_debug("%s: rx error: %d buffers missing\n",
+vi->dev->name, num_buf);
DEV_STATS_INC(vi->dev, rx_length_errors);
-   return -EINVAL;
-   }
-
-   u64_stats_add(&stats->bytes, len);
-
-   xdp = buf_to_xdp(vi, rq, buf, len);
-   if (!xdp)
-   goto err;
-
-   buf = napi_alloc_frag(len);
-   if (!buf) {
-   xsk_buff_free(xdp);
-   goto err;
+   return -1;
}
 
-   memcpy(buf, xdp->data - vi->hdr_len, len);
-
-   xsk_buff_free(xdp);
+   new_xdp = buf_to_xdp(vi, rq, buf, len);
+   if (!new_xdp)
+   goto drop_bufs;
 
-   page = virt_to_page(buf);
+   /* In virtnet_add_recvbuf_xsk(), we ask the host to fill from
+* xdp->data - vi->hdr_len with both virtio_net_hdr and data.
+* However, only the first packet has the virtio_net_hdr, the
+* following ones do not. So we need to adjust the following
+* packets' data pointer to the correct place.
+*/
+   new_xdp->data -= vi->hdr_len;
+   new_xdp->data_end = new_xdp->data + len;
 
-   truesize = len;
+   if (!xsk_buff_add_frag(xdp, new_xdp))
+   goto drop_bufs;
 
-   curr_skb  = virtnet_skb_append_frag(head_skb, curr_skb, page,
-   buf, len, truesize);
-   if (!curr_skb) {
-   put_page(page);
-   goto err;
-   }
+   num_buf--;
}
 
return 0;
 
-err:
+drop_bufs:
xsk_drop_follow_bufs(vi->dev, rq, num_buf, stats);
-   return -EINVAL;
+   return -1;
 }
 
 static struct sk_buff *virtnet_receive_xsk_merge(struct net_device *dev, 
struct virtnet_info *vi,
@@ -1307,23 +1297,42 @@ static struct sk_buff *virtnet_receive_xsk_merge(struct 
net_device *dev, struct
num_buf = virtio16_to_cpu(vi->vdev, hdr->num_buffers);
 
ret = XDP_PASS;
+   if (virtnet_build_xsk_buff_mrg(vi, rq, num_buf, xdp, stats))
+   goto drop;
+
rcu_read_lock();
prog = rcu_dereference(rq->xdp_prog);
-   /* TODO: support multi buffer. */
-   

Re: [External] : Re: [PATCH 2/3] virtio-mem: fix multiple typos in struct comments and function docs

2025-05-27 Thread ALOK TIWARI




On 28-05-2025 00:42, David Hildenbrand wrote:



  /*
   * Test if we could add memory without creating too much offline 
memory -

- * to avoid running OOM if memory is getting onlined deferred.
+ * to avoid running OOM if memory is getting online deferred.


The system/user is onlining the memory, so the memory is getting "onlined"?

If it would be "getting online", wouldn't the memory start using the 
internet or sth. like that? :D



   */
  static bool virtio_mem_could_add_memory(struct virtio_mem *vm, 
uint64_t size)

  {





Thanks for the clarification—makes sense. I'll keep the original.

Thanks,
Alok



Re: [PATCH 2/3] virtio-mem: fix multiple typos in struct comments and function docs

2025-05-27 Thread David Hildenbrand




  /*
   * Test if we could add memory without creating too much offline memory -
- * to avoid running OOM if memory is getting onlined deferred.
+ * to avoid running OOM if memory is getting online deferred.


The system/user is onlining the memory, so the memory is getting "onlined"?

If it would be "getting online", wouldn't the memory start using the 
internet or sth. like that? :D



   */
  static bool virtio_mem_could_add_memory(struct virtio_mem *vm, uint64_t size)
  {



--
Cheers,

David / dhildenb




Re: [PATCH v4 1/5] ASoC: dt-bindings: qcom,sm8250: Add Fairphone 5 sound card

2025-05-27 Thread Rob Herring
On Wed, May 07, 2025 at 10:01:37AM +0200, Luca Weiss wrote:
> Document the bindings for the sound card on Fairphone 5 which uses the
> older non-audioreach audio architecture.
> 
> Acked-by: Rob Herring (Arm) 
> Signed-off-by: Luca Weiss 
> ---
>  Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 1 +
>  1 file changed, 1 insertion(+)

Once again, QCom .dts changes merged without bindings...

I've applied it.

Rob



Re: [PATCH RFC net-next v2] page_pool: import Jesper's page_pool benchmark

2025-05-27 Thread Mina Almasry
On Mon, May 26, 2025 at 5:51 AM Toke Høiland-Jørgensen  wrote:
> > Fast path results:
> > no-softirq-page_pool01 Per elem: 11 cycles(tsc) 4.368 ns
> >
> > ptr_ring results:
> > no-softirq-page_pool02 Per elem: 527 cycles(tsc) 195.187 ns
> >
> > slow path results:
> > no-softirq-page_pool03 Per elem: 549 cycles(tsc) 203.466 ns
> > ```
> >
> > Cc: Jesper Dangaard Brouer 
> > Cc: Ilias Apalodimas 
> > Cc: Jakub Kicinski 
> > Cc: Toke Høiland-Jørgensen 
> >
> > Signed-off-by: Mina Almasry 
>
> Back when you posted the first RFC, Jesper and I chatted about ways to
> avoid the ugly "load module and read the output from dmesg" interface to
> the test.
>

I agree the existing interface is ugly.

> One idea we came up with was to make the module include only the "inner"
> functions for the benchmark, and expose those to BPF as kfuncs. Then the
> test runner can be a BPF program that runs the tests, collects the data
> and passes it to userspace via maps or a ringbuffer or something. That's
> a nicer and more customisable interface than the printk output. And if
> they're small enough, maybe we could even include the functions into the
> page_pool code itself, instead of in a separate benchmark module?
>
> WDYT of that idea? :)

...but this sounds like an enormous amount of effort, for something
that is a bit ugly but isn't THAT bad. Especially for me, I'm not that
much of an expert that I know how to implement what you're referring
to off the top of my head. I normally am open to spending time but
this is not that high on my todolist and I have limited bandwidth to
resolve this :(

I also feel that this is something that could be improved post merge.
I think it's very beneficial to have this merged in some form that can
be improved later. Byungchul is making a lot of changes to these mm
things and it would be nice to have an easy way to run the benchmark
in tree and maybe even get automated results from nipa. If we could
agree on mvp that is appropriate to merge without too much scope creep
that would be ideal from my side at least.

-- 
Thanks,
Mina



[PATCH v3 1/6] scsi: Define MODULE_DEVICE_TABLE only if necessary

2025-05-27 Thread Alexey Gladkov
Define MODULE_DEVICE_TABLE only if a structure is defined for it.

drivers/scsi/BusLogic.c:3735:26: error: use of undeclared identifier 
'blogic_pci_tbl'
 3735 | MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);

Fixes: 1079a2d251f2 ("[SCSI] BusLogic: stop using check_region")
Cc: Khalid Aziz 
Cc: "James E.J. Bottomley" 
Cc: "Martin K. Petersen" 
Signed-off-by: Alexey Gladkov 
---
 drivers/scsi/BusLogic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index 1f100270cd38..8ce2ac9293a3 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -3731,8 +3731,8 @@ static const struct pci_device_id blogic_pci_tbl[] = {
{PCI_DEVICE(PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_FLASHPOINT)},
{0, },
 };
-#endif
 MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);
+#endif
 
 module_init(blogic_init);
 module_exit(blogic_exit);
-- 
2.49.0




[PATCH] rust: replace length checks with match

2025-05-27 Thread Tamir Duberstein
Use a match expression with slice patterns instead of length checks and
indexing. The result is more idiomatic, which is a better example for
future Rust code authors.

Signed-off-by: Tamir Duberstein 
---
 scripts/rustdoc_test_gen.rs | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/scripts/rustdoc_test_gen.rs b/scripts/rustdoc_test_gen.rs
index 1ca253594d38..a3dc251221e0 100644
--- a/scripts/rustdoc_test_gen.rs
+++ b/scripts/rustdoc_test_gen.rs
@@ -85,24 +85,25 @@ fn find_candidates(
 }
 }
 
-assert!(
-valid_paths.len() > 0,
-"No path candidates found for `{file}`. This is likely a bug in the 
build system, or some \
-files went away while compiling."
-);
-
-if valid_paths.len() > 1 {
-eprintln!("Several path candidates found:");
-for path in valid_paths {
-eprintln!("{path:?}");
+match valid_paths.as_slice() {
+[] => panic!(
+"No path candidates found for `{file}`. This is likely a bug in 
the build system, or \
+some files went away while compiling."
+),
+[valid_path] => {
+valid_path.to_str().unwrap()
+}
+valid_paths => {
+eprintln!("Several path candidates found:");
+for path in valid_paths {
+eprintln!("{path:?}");
+}
+panic!(
+"Several path candidates found for `{file}`, please resolve 
the ambiguity by \
+renaming a file or folder."
+);
 }
-panic!(
-"Several path candidates found for `{file}`, please resolve the 
ambiguity by renaming \
-a file or folder."
-);
 }
-
-valid_paths[0].to_str().unwrap()
 }
 
 fn main() {

---
base-commit: bfc3cd87559bc593bb32bb1482f9cae3308b6398
change-id: 20250527-idiomatic-match-slice-26a79d100e4d

Best regards,
-- 
Tamir Duberstein 




[PATCH v3] kselftest: x86: Improve MOV SS test result message

2025-05-27 Thread Brigham Campbell
Make test result message more descriptive and grammatically correct.

Signed-off-by: Brigham Campbell 
---
No changes in v3. I'm resending this patch to adjust patch format
suggestions made by Shuah.

 tools/testing/selftests/x86/mov_ss_trap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/x86/mov_ss_trap.c 
b/tools/testing/selftests/x86/mov_ss_trap.c
index f22cb6b382f9..d80033c0d7eb 100644
--- a/tools/testing/selftests/x86/mov_ss_trap.c
+++ b/tools/testing/selftests/x86/mov_ss_trap.c
@@ -269,6 +269,6 @@ int main()
);
}
 
-   printf("[OK]\tI aten't dead\n");
+   printf("[OK]\tkernel handled MOV SS without crashing test\n");
return 0;
 }
-- 
2.49.0




[PATCH V2 06/19] virtio_ring: switch to use vring_virtqueue for virtqueue_add variants

2025-05-27 Thread Jason Wang
Those variants are used internally so let's switch to use
vring_virtqueue as parameter to be consistent with other internal
virtqueue helpers.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 40 +---
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 8ee5393803f0..a808792ca86b 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -472,7 +472,7 @@ static unsigned int vring_unmap_one_split(const struct 
vring_virtqueue *vq,
return extra->next;
 }
 
-static struct vring_desc *alloc_indirect_split(struct virtqueue *_vq,
+static struct vring_desc *alloc_indirect_split(struct vring_virtqueue *vq,
   unsigned int total_sg,
   gfp_t gfp)
 {
@@ -501,7 +501,7 @@ static struct vring_desc *alloc_indirect_split(struct 
virtqueue *_vq,
return desc;
 }
 
-static inline unsigned int virtqueue_add_desc_split(struct virtqueue *vq,
+static inline unsigned int virtqueue_add_desc_split(struct vring_virtqueue *vq,
struct vring_desc *desc,
struct vring_desc_extra 
*extra,
unsigned int i,
@@ -509,11 +509,12 @@ static inline unsigned int 
virtqueue_add_desc_split(struct virtqueue *vq,
unsigned int len,
u16 flags, bool premapped)
 {
+   struct virtio_device *vdev = vq->vq.vdev;
u16 next;
 
-   desc[i].flags = cpu_to_virtio16(vq->vdev, flags);
-   desc[i].addr = cpu_to_virtio64(vq->vdev, addr);
-   desc[i].len = cpu_to_virtio32(vq->vdev, len);
+   desc[i].flags = cpu_to_virtio16(vdev, flags);
+   desc[i].addr = cpu_to_virtio64(vdev, addr);
+   desc[i].len = cpu_to_virtio32(vdev, len);
 
extra[i].addr = premapped ? DMA_MAPPING_ERROR : addr;
extra[i].len = len;
@@ -521,12 +522,12 @@ static inline unsigned int 
virtqueue_add_desc_split(struct virtqueue *vq,
 
next = extra[i].next;
 
-   desc[i].next = cpu_to_virtio16(vq->vdev, next);
+   desc[i].next = cpu_to_virtio16(vdev, next);
 
return next;
 }
 
-static inline int virtqueue_add_split(struct virtqueue *_vq,
+static inline int virtqueue_add_split(struct vring_virtqueue *vq,
  struct scatterlist *sgs[],
  unsigned int total_sg,
  unsigned int out_sgs,
@@ -536,7 +537,6 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
  bool premapped,
  gfp_t gfp)
 {
-   struct vring_virtqueue *vq = to_vvq(_vq);
struct vring_desc_extra *extra;
struct scatterlist *sg;
struct vring_desc *desc;
@@ -561,7 +561,7 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
head = vq->free_head;
 
if (virtqueue_use_indirect(vq, total_sg))
-   desc = alloc_indirect_split(_vq, total_sg, gfp);
+   desc = alloc_indirect_split(vq, total_sg, gfp);
else {
desc = NULL;
WARN_ON_ONCE(total_sg > vq->split.vring.num && !vq->indirect);
@@ -608,7 +608,7 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
/* Note that we trust indirect descriptor
 * table since it use stream DMA mapping.
 */
-   i = virtqueue_add_desc_split(_vq, desc, extra, i, addr, 
len,
+   i = virtqueue_add_desc_split(vq, desc, extra, i, addr, 
len,
 VRING_DESC_F_NEXT,
 premapped);
}
@@ -625,14 +625,14 @@ static inline int virtqueue_add_split(struct virtqueue 
*_vq,
/* Note that we trust indirect descriptor
 * table since it use stream DMA mapping.
 */
-   i = virtqueue_add_desc_split(_vq, desc, extra, i, addr, 
len,
+   i = virtqueue_add_desc_split(vq, desc, extra, i, addr, 
len,
 VRING_DESC_F_NEXT |
 VRING_DESC_F_WRITE,
 premapped);
}
}
/* Last one doesn't continue. */
-   desc[prev].flags &= cpu_to_virtio16(_vq->vdev, ~VRING_DESC_F_NEXT);
+   desc[prev].flags &= cpu_to_virtio16(vq->vq.vdev, ~VRING_DESC_F_NEXT);
if (!indirect && vring_need_unmap_buffer(vq, &extra[prev]))
vq->spli

[PATCH V2 05/19] virtio_ring: switch to use vring_virtqueue for virtqueue_kick_prepare variants

2025-05-27 Thread Jason Wang
Those variants are used internally so let's switch to use
vring_virtqueue as parameter to be consistent with other internal
virtqueue helpers.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index e7be480bee67..8ee5393803f0 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -713,9 +713,8 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
return -ENOMEM;
 }
 
-static bool virtqueue_kick_prepare_split(struct virtqueue *_vq)
+static bool virtqueue_kick_prepare_split(struct vring_virtqueue *vq)
 {
-   struct vring_virtqueue *vq = to_vvq(_vq);
u16 new, old;
bool needs_kick;
 
@@ -732,12 +731,12 @@ static bool virtqueue_kick_prepare_split(struct virtqueue 
*_vq)
LAST_ADD_TIME_INVALID(vq);
 
if (vq->event) {
-   needs_kick = vring_need_event(virtio16_to_cpu(_vq->vdev,
+   needs_kick = vring_need_event(virtio16_to_cpu(vq->vq.vdev,
vring_avail_event(&vq->split.vring)),
  new, old);
} else {
needs_kick = !(vq->split.vring.used->flags &
-   cpu_to_virtio16(_vq->vdev,
+   cpu_to_virtio16(vq->vq.vdev,
VRING_USED_F_NO_NOTIFY));
}
END_USE(vq);
@@ -1597,9 +1596,8 @@ static inline int virtqueue_add_packed(struct virtqueue 
*_vq,
return -EIO;
 }
 
-static bool virtqueue_kick_prepare_packed(struct virtqueue *_vq)
+static bool virtqueue_kick_prepare_packed(struct vring_virtqueue *vq)
 {
-   struct vring_virtqueue *vq = to_vvq(_vq);
u16 new, old, off_wrap, flags, wrap_counter, event_idx;
bool needs_kick;
union {
@@ -2454,8 +2452,8 @@ bool virtqueue_kick_prepare(struct virtqueue *_vq)
 {
struct vring_virtqueue *vq = to_vvq(_vq);
 
-   return vq->packed_ring ? virtqueue_kick_prepare_packed(_vq) :
-virtqueue_kick_prepare_split(_vq);
+   return vq->packed_ring ? virtqueue_kick_prepare_packed(vq) :
+virtqueue_kick_prepare_split(vq);
 }
 EXPORT_SYMBOL_GPL(virtqueue_kick_prepare);
 
-- 
2.31.1




[PATCH V2 08/19] virtio_ring: switch to use vring_virtqueue for enable_cb_prepare variants

2025-05-27 Thread Jason Wang
Those variants are used internally so let's switch to use
vring_virtqueue as parameter to be consistent with other internal
virtqueue helpers.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 4e70b7eb127f..8c18f3edda00 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -893,9 +893,8 @@ static void virtqueue_disable_cb_split(struct virtqueue 
*_vq)
}
 }
 
-static unsigned int virtqueue_enable_cb_prepare_split(struct virtqueue *_vq)
+static unsigned int virtqueue_enable_cb_prepare_split(struct vring_virtqueue 
*vq)
 {
-   struct vring_virtqueue *vq = to_vvq(_vq);
u16 last_used_idx;
 
START_USE(vq);
@@ -909,10 +908,10 @@ static unsigned int 
virtqueue_enable_cb_prepare_split(struct virtqueue *_vq)
vq->split.avail_flags_shadow &= ~VRING_AVAIL_F_NO_INTERRUPT;
if (!vq->event)
vq->split.vring.avail->flags =
-   cpu_to_virtio16(_vq->vdev,
+   cpu_to_virtio16(vq->vq.vdev,
vq->split.avail_flags_shadow);
}
-   vring_used_event(&vq->split.vring) = cpu_to_virtio16(_vq->vdev,
+   vring_used_event(&vq->split.vring) = cpu_to_virtio16(vq->vq.vdev,
last_used_idx = vq->last_used_idx);
END_USE(vq);
return last_used_idx;
@@ -1807,10 +1806,8 @@ static void virtqueue_disable_cb_packed(struct virtqueue 
*_vq)
}
 }
 
-static unsigned int virtqueue_enable_cb_prepare_packed(struct virtqueue *_vq)
+static unsigned int virtqueue_enable_cb_prepare_packed(struct vring_virtqueue 
*vq)
 {
-   struct vring_virtqueue *vq = to_vvq(_vq);
-
START_USE(vq);
 
/*
@@ -2568,8 +2565,8 @@ unsigned int virtqueue_enable_cb_prepare(struct virtqueue 
*_vq)
if (vq->event_triggered)
vq->event_triggered = false;
 
-   return vq->packed_ring ? virtqueue_enable_cb_prepare_packed(_vq) :
-virtqueue_enable_cb_prepare_split(_vq);
+   return vq->packed_ring ? virtqueue_enable_cb_prepare_packed(vq) :
+virtqueue_enable_cb_prepare_split(vq);
 }
 EXPORT_SYMBOL_GPL(virtqueue_enable_cb_prepare);
 
-- 
2.31.1




[PATCH V2 00/19] virtio_ring in order support

2025-05-27 Thread Jason Wang
Hello all:

This sereis tries to implement the VIRTIO_F_IN_ORDER to
virtio_ring. This is done by introducing virtqueue ops so we can
implement separate helpers for different virtqueue layout/features
then the in-order were implemented on top.

Tests shows 3%-5% imporvment with packed virtqueue PPS with KVM guest
testpmd on the host.

Changes since V1:

- use const global array of function pointers to avoid indirect
  branches to eliminate retpoline when mitigation is enabled
- fix used length calculation when processing used ids in a batch
- fix sparse warnings

Please review.

Thanks

Jason Wang (19):
  virtio_ring: rename virtqueue_reinit_xxx to virtqueue_reset_xxx()
  virtio_ring: switch to use vring_virtqueue in virtqueue_poll variants
  virtio_ring: unify logic of virtqueue_poll() and more_used()
  virtio_ring: switch to use vring_virtqueue for virtqueue resize
variants
  virtio_ring: switch to use vring_virtqueue for virtqueue_kick_prepare
variants
  virtio_ring: switch to use vring_virtqueue for virtqueue_add variants
  virtio: switch to use vring_virtqueue for virtqueue_add variants
  virtio_ring: switch to use vring_virtqueue for enable_cb_prepare
variants
  virtio_ring: use vring_virtqueue for enable_cb_delayed variants
  virtio_ring: switch to use vring_virtqueue for disable_cb variants
  virtio_ring: switch to use vring_virtqueue for detach_unused_buf
variants
  virtio_ring: use u16 for last_used_idx in virtqueue_poll_split()
  virtio_ring: introduce virtqueue ops
  virtio_ring: determine descriptor flags at one time
  virtio_ring: factor out core logic of buffer detaching
  virtio_ring: factor out core logic for updating last_used_idx
  virtio_ring: factor out split indirect detaching logic
  virtio_ring: factor out split detaching logic
  virtio_ring: add in order support

 drivers/virtio/virtio_ring.c | 896 ++-
 1 file changed, 684 insertions(+), 212 deletions(-)

-- 
2.31.1




[PATCH V2 02/19] virtio_ring: switch to use vring_virtqueue in virtqueue_poll variants

2025-05-27 Thread Jason Wang
Those variants are used internally so let's switch to use
vring_virtqueue as parameter to be consistent with other internal
virtqueue helpers.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index afdd51fc3c9c..9bc6c30458b5 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -915,11 +915,10 @@ static unsigned int 
virtqueue_enable_cb_prepare_split(struct virtqueue *_vq)
return last_used_idx;
 }
 
-static bool virtqueue_poll_split(struct virtqueue *_vq, unsigned int 
last_used_idx)
+static bool virtqueue_poll_split(struct vring_virtqueue *vq,
+unsigned int last_used_idx)
 {
-   struct vring_virtqueue *vq = to_vvq(_vq);
-
-   return (u16)last_used_idx != virtio16_to_cpu(_vq->vdev,
+   return (u16)last_used_idx != virtio16_to_cpu(vq->vq.vdev,
vq->split.vring.used->idx);
 }
 
@@ -1845,9 +1844,8 @@ static unsigned int 
virtqueue_enable_cb_prepare_packed(struct virtqueue *_vq)
return vq->last_used_idx;
 }
 
-static bool virtqueue_poll_packed(struct virtqueue *_vq, u16 off_wrap)
+static bool virtqueue_poll_packed(struct vring_virtqueue *vq, u16 off_wrap)
 {
-   struct vring_virtqueue *vq = to_vvq(_vq);
bool wrap_counter;
u16 used_idx;
 
@@ -2608,8 +2606,8 @@ bool virtqueue_poll(struct virtqueue *_vq, unsigned int 
last_used_idx)
return false;
 
virtio_mb(vq->weak_barriers);
-   return vq->packed_ring ? virtqueue_poll_packed(_vq, last_used_idx) :
-virtqueue_poll_split(_vq, last_used_idx);
+   return vq->packed_ring ? virtqueue_poll_packed(vq, last_used_idx) :
+virtqueue_poll_split(vq, last_used_idx);
 }
 EXPORT_SYMBOL_GPL(virtqueue_poll);
 
-- 
2.31.1




[PATCH V2 03/19] virtio_ring: unify logic of virtqueue_poll() and more_used()

2025-05-27 Thread Jason Wang
This patch unifies the logic of virtqueue_poll() and more_used() for
better code reusing and ease the future in order implementation.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 48 +++-
 1 file changed, 20 insertions(+), 28 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 9bc6c30458b5..633379b2dc42 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -802,12 +802,18 @@ static void detach_buf_split(struct vring_virtqueue *vq, 
unsigned int head,
}
 }
 
-static bool more_used_split(const struct vring_virtqueue *vq)
+static bool virtqueue_poll_split(const struct vring_virtqueue *vq,
+unsigned int last_used_idx)
 {
-   return vq->last_used_idx != virtio16_to_cpu(vq->vq.vdev,
+   return (u16)last_used_idx != virtio16_to_cpu(vq->vq.vdev,
vq->split.vring.used->idx);
 }
 
+static bool more_used_split(const struct vring_virtqueue *vq)
+{
+   return virtqueue_poll_split(vq, vq->last_used_idx);
+}
+
 static void *virtqueue_get_buf_ctx_split(struct virtqueue *_vq,
 unsigned int *len,
 void **ctx)
@@ -915,13 +921,6 @@ static unsigned int 
virtqueue_enable_cb_prepare_split(struct virtqueue *_vq)
return last_used_idx;
 }
 
-static bool virtqueue_poll_split(struct vring_virtqueue *vq,
-unsigned int last_used_idx)
-{
-   return (u16)last_used_idx != virtio16_to_cpu(vq->vq.vdev,
-   vq->split.vring.used->idx);
-}
-
 static bool virtqueue_enable_cb_delayed_split(struct virtqueue *_vq)
 {
struct vring_virtqueue *vq = to_vvq(_vq);
@@ -1711,16 +1710,20 @@ static inline bool is_used_desc_packed(const struct 
vring_virtqueue *vq,
return avail == used && used == used_wrap_counter;
 }
 
-static bool more_used_packed(const struct vring_virtqueue *vq)
+static bool virtqueue_poll_packed(const struct vring_virtqueue *vq, u16 
off_wrap)
 {
-   u16 last_used;
-   u16 last_used_idx;
-   bool used_wrap_counter;
+   bool wrap_counter;
+   u16 used_idx;
 
-   last_used_idx = READ_ONCE(vq->last_used_idx);
-   last_used = packed_last_used(last_used_idx);
-   used_wrap_counter = packed_used_wrap_counter(last_used_idx);
-   return is_used_desc_packed(vq, last_used, used_wrap_counter);
+   wrap_counter = off_wrap >> VRING_PACKED_EVENT_F_WRAP_CTR;
+   used_idx = off_wrap & ~(1 << VRING_PACKED_EVENT_F_WRAP_CTR);
+
+   return is_used_desc_packed(vq, used_idx, wrap_counter);
+}
+
+static bool more_used_packed(const struct vring_virtqueue *vq)
+{
+   return virtqueue_poll_packed(vq, READ_ONCE(vq->last_used_idx));
 }
 
 static void *virtqueue_get_buf_ctx_packed(struct virtqueue *_vq,
@@ -1844,17 +1847,6 @@ static unsigned int 
virtqueue_enable_cb_prepare_packed(struct virtqueue *_vq)
return vq->last_used_idx;
 }
 
-static bool virtqueue_poll_packed(struct vring_virtqueue *vq, u16 off_wrap)
-{
-   bool wrap_counter;
-   u16 used_idx;
-
-   wrap_counter = off_wrap >> VRING_PACKED_EVENT_F_WRAP_CTR;
-   used_idx = off_wrap & ~(1 << VRING_PACKED_EVENT_F_WRAP_CTR);
-
-   return is_used_desc_packed(vq, used_idx, wrap_counter);
-}
-
 static bool virtqueue_enable_cb_delayed_packed(struct virtqueue *_vq)
 {
struct vring_virtqueue *vq = to_vvq(_vq);
-- 
2.31.1




[PATCH V2 04/19] virtio_ring: switch to use vring_virtqueue for virtqueue resize variants

2025-05-27 Thread Jason Wang
Those variants are used internally so let's switch to use
vring_virtqueue as parameter to be consistent with other internal
virtqueue helpers.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 633379b2dc42..e7be480bee67 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -1216,11 +1216,10 @@ static struct virtqueue *vring_create_virtqueue_split(
return vq;
 }
 
-static int virtqueue_resize_split(struct virtqueue *_vq, u32 num)
+static int virtqueue_resize_split(struct vring_virtqueue *vq, u32 num)
 {
struct vring_virtqueue_split vring_split = {};
-   struct vring_virtqueue *vq = to_vvq(_vq);
-   struct virtio_device *vdev = _vq->vdev;
+   struct virtio_device *vdev = vq->vq.vdev;
int err;
 
err = vring_alloc_queue_split(&vring_split, vdev, num,
@@ -2183,11 +2182,10 @@ static struct virtqueue *vring_create_virtqueue_packed(
return vq;
 }
 
-static int virtqueue_resize_packed(struct virtqueue *_vq, u32 num)
+static int virtqueue_resize_packed(struct vring_virtqueue *vq, u32 num)
 {
struct vring_virtqueue_packed vring_packed = {};
-   struct vring_virtqueue *vq = to_vvq(_vq);
-   struct virtio_device *vdev = _vq->vdev;
+   struct virtio_device *vdev = vq->vq.vdev;
int err;
 
if (vring_alloc_queue_packed(&vring_packed, vdev, num, 
vring_dma_dev(vq)))
@@ -2805,9 +2803,9 @@ int virtqueue_resize(struct virtqueue *_vq, u32 num,
recycle_done(_vq);
 
if (vq->packed_ring)
-   err = virtqueue_resize_packed(_vq, num);
+   err = virtqueue_resize_packed(vq, num);
else
-   err = virtqueue_resize_split(_vq, num);
+   err = virtqueue_resize_split(vq, num);
 
return virtqueue_enable_after_reset(_vq);
 }
-- 
2.31.1




[PATCH V2 13/19] virtio_ring: introduce virtqueue ops

2025-05-27 Thread Jason Wang
This patch introduces virtqueue ops which is a set of the callbacks
that will be called for different queue layout or features. This would
help to avoid branches for split/packed and will ease the future
implementation like in order.

Note that in order to eliminate the indirect calls this patch uses
global array of const ops to allow compiler to avoid indirect
branches.

Tested with CONFIG_MITIGATION_RETPOLINE, no performance differences
were noticed.

Suggested-by: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 172 ++-
 1 file changed, 129 insertions(+), 43 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index b14bbb4d6713..af32d1a1a1db 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -67,6 +67,12 @@
 #define LAST_ADD_TIME_INVALID(vq)
 #endif
 
+enum vq_layout {
+   SPLIT = 0,
+   PACKED,
+   VQ_TYPE_MAX,
+};
+
 struct vring_desc_state_split {
void *data; /* Data for callback. */
 
@@ -159,12 +165,28 @@ struct vring_virtqueue_packed {
size_t event_size_in_bytes;
 };
 
+struct vring_virtqueue;
+
+struct virtqueue_ops {
+   int (*add)(struct vring_virtqueue *_vq, struct scatterlist *sgs[],
+  unsigned int total_sg, unsigned int out_sgs,
+  unsigned int in_sgs, void *data,
+  void *ctx, bool premapped, gfp_t gfp);
+   void *(*get)(struct vring_virtqueue *vq, unsigned int *len, void **ctx);
+   bool (*kick_prepare)(struct vring_virtqueue *vq);
+   void (*disable_cb)(struct vring_virtqueue *vq);
+   bool (*enable_cb_delayed)(struct vring_virtqueue *vq);
+   unsigned int (*enable_cb_prepare)(struct vring_virtqueue *vq);
+   bool (*poll)(const struct vring_virtqueue *vq, u16 last_used_idx);
+   void *(*detach_unused_buf)(struct vring_virtqueue *vq);
+   bool (*more_used)(const struct vring_virtqueue *vq);
+   int (*resize)(struct vring_virtqueue *vq, u32 num);
+   void (*reset)(struct vring_virtqueue *vq);
+};
+
 struct vring_virtqueue {
struct virtqueue vq;
 
-   /* Is this a packed ring? */
-   bool packed_ring;
-
/* Is DMA API used? */
bool use_dma_api;
 
@@ -180,6 +202,8 @@ struct vring_virtqueue {
/* Host publishes avail event idx */
bool event;
 
+   enum vq_layout layout;
+
/* Head of free buffer list. */
unsigned int free_head;
/* Number we've added since last sync. */
@@ -232,6 +256,12 @@ static void vring_free(struct virtqueue *_vq);
 
 #define to_vvq(_vq) container_of_const(_vq, struct vring_virtqueue, vq)
 
+
+static inline bool virtqueue_is_packed(const struct vring_virtqueue *vq)
+{
+   return vq->layout == PACKED;
+}
+
 static bool virtqueue_use_indirect(const struct vring_virtqueue *vq,
   unsigned int total_sg)
 {
@@ -422,7 +452,7 @@ static void virtqueue_init(struct vring_virtqueue *vq, u32 
num)
 {
vq->vq.num_free = num;
 
-   if (vq->packed_ring)
+   if (virtqueue_is_packed(vq))
vq->last_used_idx = 0 | (1 << VRING_PACKED_EVENT_F_WRAP_CTR);
else
vq->last_used_idx = 0;
@@ -1116,6 +1146,8 @@ static int vring_alloc_queue_split(struct 
vring_virtqueue_split *vring_split,
return 0;
 }
 
+static const struct virtqueue_ops split_ops;
+
 static struct virtqueue *__vring_new_virtqueue_split(unsigned int index,
   struct vring_virtqueue_split 
*vring_split,
   struct virtio_device *vdev,
@@ -1133,7 +1165,7 @@ static struct virtqueue 
*__vring_new_virtqueue_split(unsigned int index,
if (!vq)
return NULL;
 
-   vq->packed_ring = false;
+   vq->layout = SPLIT;
vq->vq.callback = callback;
vq->vq.vdev = vdev;
vq->vq.name = name;
@@ -2076,6 +2108,8 @@ static void virtqueue_reset_packed(struct vring_virtqueue 
*vq)
virtqueue_vring_init_packed(&vq->packed, !!vq->vq.callback);
 }
 
+static const struct virtqueue_ops packed_ops;
+
 static struct virtqueue *__vring_new_virtqueue_packed(unsigned int index,
   struct vring_virtqueue_packed 
*vring_packed,
   struct virtio_device *vdev,
@@ -2106,7 +2140,7 @@ static struct virtqueue 
*__vring_new_virtqueue_packed(unsigned int index,
 #else
vq->broken = false;
 #endif
-   vq->packed_ring = true;
+   vq->layout = PACKED;
vq->dma_dev = dma_dev;
vq->use_dma_api = vring_use_dma_api(vdev);
 
@@ -2194,6 +2228,39 @@ static int virtqueue_resize_packed(struct 
vring_virtqueue *vq, u32 num)
return -ENOMEM;
 }
 
+static const struct virtqueue_ops split_ops = {
+   .add = virtqueue_add_split,
+   .get = virtqueue_get_buf_ctx_split,
+   .kick_prepar

[PATCH V2 14/19] virtio_ring: determine descriptor flags at one time

2025-05-27 Thread Jason Wang
Let's determine the last descriptor by counting the number of sg. This
would be consistent with packed virtqueue implementation and ease the
future in-order implementation.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index af32d1a1a1db..d5e4d4cd2487 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -570,7 +570,7 @@ static inline int virtqueue_add_split(struct 
vring_virtqueue *vq,
struct vring_desc_extra *extra;
struct scatterlist *sg;
struct vring_desc *desc;
-   unsigned int i, n, avail, descs_used, prev, err_idx;
+   unsigned int i, n, c, avail, descs_used, err_idx;
int head;
bool indirect;
 
@@ -626,46 +626,47 @@ static inline int virtqueue_add_split(struct 
vring_virtqueue *vq,
return -ENOSPC;
}
 
+   c = 0;
for (n = 0; n < out_sgs; n++) {
+   sg = sgs[n];
for (sg = sgs[n]; sg; sg = sg_next(sg)) {
dma_addr_t addr;
u32 len;
+   u16 flags = 0;
 
if (vring_map_one_sg(vq, sg, DMA_TO_DEVICE, &addr, 
&len, premapped))
goto unmap_release;
 
-   prev = i;
+   if (++c != total_sg)
+   flags = VRING_DESC_F_NEXT;
+
/* Note that we trust indirect descriptor
 * table since it use stream DMA mapping.
 */
i = virtqueue_add_desc_split(vq, desc, extra, i, addr, 
len,
-VRING_DESC_F_NEXT,
+flags,
 premapped);
}
}
for (; n < (out_sgs + in_sgs); n++) {
for (sg = sgs[n]; sg; sg = sg_next(sg)) {
+   u16 flags = VRING_DESC_F_WRITE;
dma_addr_t addr;
u32 len;
 
if (vring_map_one_sg(vq, sg, DMA_FROM_DEVICE, &addr, 
&len, premapped))
goto unmap_release;
 
-   prev = i;
+   if (++c != total_sg)
+   flags |= VRING_DESC_F_NEXT;
+
/* Note that we trust indirect descriptor
 * table since it use stream DMA mapping.
 */
i = virtqueue_add_desc_split(vq, desc, extra, i, addr, 
len,
-VRING_DESC_F_NEXT |
-VRING_DESC_F_WRITE,
-premapped);
+flags, premapped);
}
}
-   /* Last one doesn't continue. */
-   desc[prev].flags &= cpu_to_virtio16(vq->vq.vdev, ~VRING_DESC_F_NEXT);
-   if (!indirect && vring_need_unmap_buffer(vq, &extra[prev]))
-   vq->split.desc_extra[prev & (vq->split.vring.num - 1)].flags &=
-   ~VRING_DESC_F_NEXT;
 
if (indirect) {
/* Now that the indirect table is filled in, map it. */
-- 
2.31.1




[PATCH V2 15/19] virtio_ring: factor out core logic of buffer detaching

2025-05-27 Thread Jason Wang
Factor out core logic of buffer detaching and leave the id population
to the caller so in order can just call the core logic.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index d5e4d4cd2487..1bdd332d515e 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -1669,8 +1669,8 @@ static bool virtqueue_kick_prepare_packed(struct 
vring_virtqueue *vq)
return needs_kick;
 }
 
-static void detach_buf_packed(struct vring_virtqueue *vq,
- unsigned int id, void **ctx)
+static void detach_buf_packed_in_order(struct vring_virtqueue *vq,
+  unsigned int id, void **ctx)
 {
struct vring_desc_state_packed *state = NULL;
struct vring_packed_desc *desc;
@@ -1681,8 +1681,6 @@ static void detach_buf_packed(struct vring_virtqueue *vq,
/* Clear data ptr. */
state->data = NULL;
 
-   vq->packed.desc_extra[state->last].next = vq->free_head;
-   vq->free_head = id;
vq->vq.num_free += state->num;
 
if (unlikely(vq->use_dma_api)) {
@@ -1719,6 +1717,17 @@ static void detach_buf_packed(struct vring_virtqueue *vq,
}
 }
 
+static void detach_buf_packed(struct vring_virtqueue *vq,
+ unsigned int id, void **ctx)
+{
+   struct vring_desc_state_packed *state = &vq->packed.desc_state[id];
+
+   vq->packed.desc_extra[state->last].next = vq->free_head;
+   vq->free_head = id;
+
+   return detach_buf_packed_in_order(vq, id, ctx);
+}
+
 static inline bool is_used_desc_packed(const struct vring_virtqueue *vq,
   u16 idx, bool used_wrap_counter)
 {
-- 
2.31.1




[PATCH V2 12/19] virtio_ring: use u16 for last_used_idx in virtqueue_poll_split()

2025-05-27 Thread Jason Wang
Use u16 for last_used_idx in virtqueue_poll_split() to align with the
spec.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 03b17bc275dd..b14bbb4d6713 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -801,7 +801,7 @@ static void detach_buf_split(struct vring_virtqueue *vq, 
unsigned int head,
 }
 
 static bool virtqueue_poll_split(const struct vring_virtqueue *vq,
-unsigned int last_used_idx)
+u16 last_used_idx)
 {
return (u16)last_used_idx != virtio16_to_cpu(vq->vq.vdev,
vq->split.vring.used->idx);
-- 
2.31.1




[PATCH V2 19/19] virtio_ring: add in order support

2025-05-27 Thread Jason Wang
This patch implements in order support for both split virtqueue and
packed virtqueue.

Benchmark with KVM guest + testpmd on the host shows:

For split virtqueue: no obvious differences were noticed

For packed virtqueue:

1) RX gets 3.1% PPS improvements from 6.3 Mpps to 6.5 Mpps
2) TX gets 4.6% PPS improvements from 8.6 Mpps to 9.0 Mpps

Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 423 +--
 1 file changed, 402 insertions(+), 21 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 27a9459a0555..21d456392ba0 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -70,11 +70,14 @@
 enum vq_layout {
SPLIT = 0,
PACKED,
+   SPLIT_IN_ORDER,
+   PACKED_IN_ORDER,
VQ_TYPE_MAX,
 };
 
 struct vring_desc_state_split {
void *data; /* Data for callback. */
+   u32 total_len;  /* Buffer Length */
 
/* Indirect desc table and extra table, if any. These two will be
 * allocated together. So we won't stress more to the memory allocator.
@@ -84,6 +87,7 @@ struct vring_desc_state_split {
 
 struct vring_desc_state_packed {
void *data; /* Data for callback. */
+   u32 total_len;  /* Buffer Length */
 
/* Indirect desc table and extra table, if any. These two will be
 * allocated together. So we won't stress more to the memory allocator.
@@ -206,6 +210,12 @@ struct vring_virtqueue {
 
/* Head of free buffer list. */
unsigned int free_head;
+
+   /* Head of the batched used buffers, vq->num means no batching */
+   unsigned int batch_head;
+
+   unsigned int batch_len;
+
/* Number we've added since last sync. */
unsigned int num_added;
 
@@ -256,10 +266,14 @@ static void vring_free(struct virtqueue *_vq);
 
 #define to_vvq(_vq) container_of_const(_vq, struct vring_virtqueue, vq)
 
-
 static inline bool virtqueue_is_packed(const struct vring_virtqueue *vq)
 {
-   return vq->layout == PACKED;
+   return vq->layout == PACKED || vq->layout == PACKED_IN_ORDER;
+}
+
+static inline bool virtqueue_is_in_order(const struct vring_virtqueue *vq)
+{
+   return vq->layout == SPLIT_IN_ORDER || vq->layout == PACKED_IN_ORDER;
 }
 
 static bool virtqueue_use_indirect(const struct vring_virtqueue *vq,
@@ -570,7 +584,7 @@ static inline int virtqueue_add_split(struct 
vring_virtqueue *vq,
struct vring_desc_extra *extra;
struct scatterlist *sg;
struct vring_desc *desc;
-   unsigned int i, n, c, avail, descs_used, err_idx;
+   unsigned int i, n, c, avail, descs_used, err_idx, total_len = 0;
int head;
bool indirect;
 
@@ -646,6 +660,7 @@ static inline int virtqueue_add_split(struct 
vring_virtqueue *vq,
i = virtqueue_add_desc_split(vq, desc, extra, i, addr, 
len,
 flags,
 premapped);
+   total_len += len;
}
}
for (; n < (out_sgs + in_sgs); n++) {
@@ -665,6 +680,7 @@ static inline int virtqueue_add_split(struct 
vring_virtqueue *vq,
 */
i = virtqueue_add_desc_split(vq, desc, extra, i, addr, 
len,
 flags, premapped);
+   total_len += len;
}
}
 
@@ -687,7 +703,12 @@ static inline int virtqueue_add_split(struct 
vring_virtqueue *vq,
vq->vq.num_free -= descs_used;
 
/* Update free pointer */
-   if (indirect)
+   if (virtqueue_is_in_order(vq)) {
+   vq->free_head += descs_used;
+   if (vq->free_head >= vq->split.vring.num)
+   vq->free_head -= vq->split.vring.num;
+   vq->split.desc_state[head].total_len = total_len;;
+   } else if (indirect)
vq->free_head = vq->split.desc_extra[head].next;
else
vq->free_head = i;
@@ -860,6 +881,14 @@ static bool more_used_split(const struct vring_virtqueue 
*vq)
return virtqueue_poll_split(vq, vq->last_used_idx);
 }
 
+static bool more_used_split_in_order(const struct vring_virtqueue *vq)
+{
+   if (vq->batch_head != vq->packed.vring.num)
+   return true;
+
+   return virtqueue_poll_split(vq, vq->last_used_idx);
+}
+
 static void *virtqueue_get_buf_ctx_split(struct vring_virtqueue *vq,
 unsigned int *len,
 void **ctx)
@@ -917,6 +946,73 @@ static void *virtqueue_get_buf_ctx_split(struct 
vring_virtqueue *vq,
return ret;
 }
 
+static void *virtqueue_get_buf_ctx_split_in_order(struct vring_virtqueue *vq,
+ unsigned int *len,
+   

[PATCH V2 18/19] virtio_ring: factor out split detaching logic

2025-05-27 Thread Jason Wang
This patch factors out the split core detaching logic that could be
reused by in order feature into a dedicated function.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 259380797ec4..27a9459a0555 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -804,8 +804,9 @@ static void detach_indirect_split(struct vring_virtqueue 
*vq,
vq->split.desc_state[head].indir_desc = NULL;
 }
 
-static void detach_buf_split(struct vring_virtqueue *vq, unsigned int head,
-void **ctx)
+static unsigned detach_buf_split_in_order(struct vring_virtqueue *vq,
+ unsigned int head,
+ void **ctx)
 {
struct vring_desc_extra *extra;
unsigned int i;
@@ -826,8 +827,6 @@ static void detach_buf_split(struct vring_virtqueue *vq, 
unsigned int head,
}
 
vring_unmap_one_split(vq, &extra[i]);
-   vq->split.desc_extra[i].next = vq->free_head;
-   vq->free_head = head;
 
/* Plus final descriptor */
vq->vq.num_free++;
@@ -836,6 +835,17 @@ static void detach_buf_split(struct vring_virtqueue *vq, 
unsigned int head,
detach_indirect_split(vq, head);
else if (ctx)
*ctx = vq->split.desc_state[head].indir_desc;
+
+   return i;
+}
+
+static void detach_buf_split(struct vring_virtqueue *vq, unsigned int head,
+void **ctx)
+{
+   unsigned int i = detach_buf_split_in_order(vq, head, ctx);
+
+   vq->split.desc_extra[i].next = vq->free_head;
+   vq->free_head = head;
 }
 
 static bool virtqueue_poll_split(const struct vring_virtqueue *vq,
-- 
2.31.1




[PATCH V2 17/19] virtio_ring: factor out split indirect detaching logic

2025-05-27 Thread Jason Wang
Factor out the split indirect descriptor detaching logic in order to
make it be reused by the in order support.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 63 
 1 file changed, 35 insertions(+), 28 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index e8e0d1204f52..259380797ec4 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -773,11 +773,42 @@ static bool virtqueue_kick_prepare_split(struct 
vring_virtqueue *vq)
return needs_kick;
 }
 
+static void detach_indirect_split(struct vring_virtqueue *vq,
+ unsigned int head)
+{
+   struct vring_desc_extra *extra = vq->split.desc_extra;
+   struct vring_desc *indir_desc =
+  vq->split.desc_state[head].indir_desc;
+   unsigned int j;
+   u32 len, num;
+
+   /* Free the indirect table, if any, now that it's unmapped. */
+   if (!indir_desc)
+   return;
+   len = vq->split.desc_extra[head].len;
+
+   BUG_ON(!(vq->split.desc_extra[head].flags &
+   VRING_DESC_F_INDIRECT));
+   BUG_ON(len == 0 || len % sizeof(struct vring_desc));
+
+   num = len / sizeof(struct vring_desc);
+
+   extra = (struct vring_desc_extra *)&indir_desc[num];
+
+   if (vq->use_dma_api) {
+   for (j = 0; j < num; j++)
+   vring_unmap_one_split(vq, &extra[j]);
+   }
+
+   kfree(indir_desc);
+   vq->split.desc_state[head].indir_desc = NULL;
+}
+
 static void detach_buf_split(struct vring_virtqueue *vq, unsigned int head,
 void **ctx)
 {
struct vring_desc_extra *extra;
-   unsigned int i, j;
+   unsigned int i;
__virtio16 nextflag = cpu_to_virtio16(vq->vq.vdev, VRING_DESC_F_NEXT);
 
/* Clear data ptr. */
@@ -801,34 +832,10 @@ static void detach_buf_split(struct vring_virtqueue *vq, 
unsigned int head,
/* Plus final descriptor */
vq->vq.num_free++;
 
-   if (vq->indirect) {
-   struct vring_desc *indir_desc =
-   vq->split.desc_state[head].indir_desc;
-   u32 len, num;
-
-   /* Free the indirect table, if any, now that it's unmapped. */
-   if (!indir_desc)
-   return;
-   len = vq->split.desc_extra[head].len;
-
-   BUG_ON(!(vq->split.desc_extra[head].flags &
-   VRING_DESC_F_INDIRECT));
-   BUG_ON(len == 0 || len % sizeof(struct vring_desc));
-
-   num = len / sizeof(struct vring_desc);
-
-   extra = (struct vring_desc_extra *)&indir_desc[num];
-
-   if (vq->use_dma_api) {
-   for (j = 0; j < num; j++)
-   vring_unmap_one_split(vq, &extra[j]);
-   }
-
-   kfree(indir_desc);
-   vq->split.desc_state[head].indir_desc = NULL;
-   } else if (ctx) {
+   if (vq->indirect)
+   detach_indirect_split(vq, head);
+   else if (ctx)
*ctx = vq->split.desc_state[head].indir_desc;
-   }
 }
 
 static bool virtqueue_poll_split(const struct vring_virtqueue *vq,
-- 
2.31.1




[PATCH V2 16/19] virtio_ring: factor out core logic for updating last_used_idx

2025-05-27 Thread Jason Wang
Factor out the core logic for updating last_used_idx to be reused by
the packed in order implementation.

Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 43 +---
 1 file changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 1bdd332d515e..e8e0d1204f52 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -1757,6 +1757,30 @@ static bool more_used_packed(const struct 
vring_virtqueue *vq)
return virtqueue_poll_packed(vq, READ_ONCE(vq->last_used_idx));
 }
 
+static void update_last_used_idx_packed(struct vring_virtqueue *vq,
+   u16 id, u16 last_used,
+   u16 used_wrap_counter)
+{
+   last_used += vq->packed.desc_state[id].num;
+   if (unlikely(last_used >= vq->packed.vring.num)) {
+   last_used -= vq->packed.vring.num;
+   used_wrap_counter ^= 1;
+   }
+
+   last_used = (last_used | (used_wrap_counter << 
VRING_PACKED_EVENT_F_WRAP_CTR));
+   WRITE_ONCE(vq->last_used_idx, last_used);
+
+   /*
+* If we expect an interrupt for the next entry, tell host
+* by writing event index and flush out the write before
+* the read in the next get_buf call.
+*/
+   if (vq->packed.event_flags_shadow == VRING_PACKED_EVENT_FLAG_DESC)
+   virtio_store_mb(vq->weak_barriers,
+   &vq->packed.vring.driver->off_wrap,
+   cpu_to_le16(vq->last_used_idx));
+}
+
 static void *virtqueue_get_buf_ctx_packed(struct vring_virtqueue *vq,
  unsigned int *len,
  void **ctx)
@@ -1800,24 +1824,7 @@ static void *virtqueue_get_buf_ctx_packed(struct 
vring_virtqueue *vq,
ret = vq->packed.desc_state[id].data;
detach_buf_packed(vq, id, ctx);
 
-   last_used += vq->packed.desc_state[id].num;
-   if (unlikely(last_used >= vq->packed.vring.num)) {
-   last_used -= vq->packed.vring.num;
-   used_wrap_counter ^= 1;
-   }
-
-   last_used = (last_used | (used_wrap_counter << 
VRING_PACKED_EVENT_F_WRAP_CTR));
-   WRITE_ONCE(vq->last_used_idx, last_used);
-
-   /*
-* If we expect an interrupt for the next entry, tell host
-* by writing event index and flush out the write before
-* the read in the next get_buf call.
-*/
-   if (vq->packed.event_flags_shadow == VRING_PACKED_EVENT_FLAG_DESC)
-   virtio_store_mb(vq->weak_barriers,
-   &vq->packed.vring.driver->off_wrap,
-   cpu_to_le16(vq->last_used_idx));
+   update_last_used_idx_packed(vq, id, last_used, used_wrap_counter);
 
LAST_ADD_TIME_INVALID(vq);
 
-- 
2.31.1




Re: [PATCH] rust: kunit: use crate-level mapping for `c_void`

2025-05-27 Thread Benno Lossin
On Tue May 27, 2025 at 3:51 PM CEST, Miguel Ojeda wrote:
> On Tue, May 27, 2025 at 2:06 PM Benno Lossin  wrote:
>>
>> We don't need to explicitly import it, as `c_void` is present in the
>> prelude since 3d5bef5d47c3 ("rust: add C FFI types to the prelude").
>
> Hmm... But the prelude isn't there yet in this patch, no? i.e. our
> prelude is (so far) not a "real prelude" that gets injected
> automatically. So I guess you mean importing the prelude instead.

Ah right it's only auto-imported in the doctests. Forgot that, would be
nice if it could be :)

> (It is imported in the KUnit series anyway, so it will llikely be
> there either way)

Oh yeah, it's in rust-next already :)

---
Cheers,
Benno



[PATCH net-next v9] selftests/vsock: add initial vmtest.sh for vsock

2025-05-27 Thread Bobby Eshleman
This commit introduces a new vmtest.sh runner for vsock.

It uses virtme-ng/qemu to run tests in a VM. The tests validate G2H,
H2G, and loopback. The testing tools from tools/testing/vsock/ are
reused. Currently, only vsock_test is used.

VMCI and hyperv support is included in the config file to be built with
the -b option, though not used in the tests.

Only tested on x86.

To run:

  $ make -C tools/testing/selftests TARGETS=vsock
  $ tools/testing/selftests/vsock/vmtest.sh

or

  $ make -C tools/testing/selftests TARGETS=vsock run_tests

Example runs (after make -C tools/testing/selftests TARGETS=vsock):

$ ./tools/testing/selftests/vsock/vmtest.sh
1..3
ok 0 vm_server_host_client
ok 1 vm_client_host_server
ok 2 vm_loopback
SUMMARY: PASS=3 SKIP=0 FAIL=0
Log: /tmp/vsock_vmtest_m7DI.log

$ ./tools/testing/selftests/vsock/vmtest.sh vm_loopback
1..1
ok 0 vm_loopback
SUMMARY: PASS=1 SKIP=0 FAIL=0
Log: /tmp/vsock_vmtest_a1IO.log

$ mkdir -p ~/scratch
$ make -C tools/testing/selftests install TARGETS=vsock INSTALL_PATH=~/scratch
 [... omitted ...]
$ cd ~/scratch
$ ./run_kselftest.sh
 TAP version 13
 1..1
 # timeout set to 300
 # selftests: vsock: vmtest.sh
 # 1..3
 # ok 0 vm_server_host_client
 # ok 1 vm_client_host_server
 # ok 2 vm_loopback
 # SUMMARY: PASS=3 SKIP=0 FAIL=0
 # Log: /tmp/vsock_vmtest_svEl.log
 ok 1 selftests: vsock: vmtest.sh

Future work can include vsock_diag_test.

Because vsock requires a VM to test anything other than loopback, this
patch adds vmtest.sh as a kselftest itself. This is different than other
systems that have a "vmtest.sh", where it is used as a utility script to
spin up a VM to run the selftests as a guest (but isn't hooked into
kselftest).

Signed-off-by: Bobby Eshleman 
---
Changes in v9:
- make kselftest build target depend on tools/testing/vsock sources (Stefano)
- add check_vng() for vng version checking (Stefano)
- add virtme_ssh_channel=tcp to kernel cmdline (Stefano)
- Link to v8: 
https://lore.kernel.org/r/20250522-vsock-vmtest-v8-1-367619bef...@gmail.com

Changes in v8:
- remove NIPA comment from commit msg
- remove tap_* functions and TAP_PREFIX
- add -b for building kernel
- Link to v7: 
https://lore.kernel.org/r/20250515-vsock-vmtest-v7-1-ba6fa86d6...@gmail.com

Changes in v7:
- fix exit code bug when ran is kselftest: use cnt_total instead of 
KSFT_NUM_TESTS
- updated commit message with updated output
- updated commit message with commands for installing/running as
  kselftest
- Link to v6: 
https://lore.kernel.org/r/20250515-vsock-vmtest-v6-1-9af1cc023...@gmail.com

Changes in v6:
- add make cmd in commit message in vmtest.sh example (Stefano)
- check nonzero size of QEMU_PIDFILE using -s conditional (Stefano)
- display log file path after tests so it is easier to find amongst other 
random names
- cleanup qemu pidfile if qemu is unable to remove it
- make oops/warning failures more obvious with 'FAIL' prefix in log
  (simply saying 'detected' wasn't clear enough to identify failing
  condition)
- Link to v5: 
https://lore.kernel.org/r/20250513-vsock-vmtest-v5-1-4e75c4a45...@gmail.com

Changes in v5:
- make log file a tmpfile (Paolo)
- make sure both default and user defined QEMU gets handled by the dependency 
check (Paolo)
- increased VM boot up timeout from 1m to 3m for slow hosts (Paolo)
- rename vm_setup -> vm_start (Paolo)
- derive wait_for_listener from selftests/net/net_helper.sh to removes ss usage 
- Remove unused 'unset IFS' line (Paolo)
- leave space after variable declarations (Paolo)
- make QEMU_PIDFILE a tmp file (Paolo)
- make everything readonly that is only read (Paolo)
- source ktap_helpers.sh for KSFT_PASS and friends (Paolo)
- don't check for timeout util (Paolo)
- add missing usage string for -q qemu arg
- add tap prefix to SUMMARY line since it isn't part of TAP protocol
- exit with the correct status code based on failure/pass counts
- Link to v4: 
https://lore.kernel.org/r/20250507-vsock-vmtest-v4-1-6e2a97262...@gmail.com

Changes in v4:
- do not use special tab delimiter for help string parsing (Stefano + Paolo)
- fix paths for when installing kselftest and running out-of-tree (Paolo)
- change vng to using running kernel instead of compiled kernel (Paolo)
- use multi-line string for QEMU_OPTS (Stefano)
- change timeout to 300s (Paolo)
- skip if tools are not found and use kselftests status codes (Paolo)
- remove build from vmtest.sh (Paolo)
- change  -> SSH_HOST_PORT (Stefano)
- add tap-format output
- add vmtest.log to gitignore
- check for vsock_test binary and remind user to build it if missing
- create a proper build in makefile
- style fixes
- add ssh, timeout, and pkill to dependency check, just in case
- fix numerical comparison in conditionals
- check qemu pidfile exists before proceeding (avoid wasting time waiting for 
ssh)
- fix tracking of pass/fail bug
- fix stderr redirection bug
- Link to v3: 
https://lore.kernel.org/r/20250428-vsock-vmtest-v3-1-181af6163...@gmail.com

Changes in v3:
- use common conditional syntax 

Re: [PATCH net-next v8] selftests/vsock: add initial vmtest.sh for vsock

2025-05-27 Thread Bobby Eshleman
On Tue, May 27, 2025 at 05:55:13PM +0200, Stefano Garzarella wrote:
> On Tue, May 27, 2025 at 07:30:29AM -0700, Bobby Eshleman wrote:
> > On Mon, May 26, 2025 at 01:18:18PM +0200, Stefano Garzarella wrote:
> > > On Thu, May 22, 2025 at 09:59:07PM -0700, Bobby Eshleman wrote:
> 
> Yes, that would be great, but anyway for now I would say let's go with this
> since we're supposed to support these current versions I guess, and this
> hack at the end I think is doable.
> 

sgtm!

> BTW, thanks again for this useful work!
> Stefano
> 

No problem, happy to help!

Best,
Bobby



[PATCH v2] selftests/seccomp: Improve error logging in get_proc_stat()

2025-05-27 Thread Sameeksha Sankpal
Use TH_LOG to report failure when reading /proc//stat in
get_proc_stat(), following kernel test framework conventions.

Previously, printf() was used which is discouraged.

Suggested-by: Kees Cook 

Signed-off-by: Sameeksha Sankpal 
---
v1 -> v2:
- Used TH_LOG instead of printf for error logging
- Moved variable declaration to the top of the function
- Applied review suggestion by Kees Cook

 tools/testing/selftests/seccomp/seccomp_bpf.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c 
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index d6a85d7b26da..0f12052ef1c7 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -4505,14 +4505,14 @@ static char get_proc_stat(struct __test_metadata 
*_metadata, pid_t pid)
char proc_path[100] = {0};
char status;
char *line;
+   int rc;
 
snprintf(proc_path, sizeof(proc_path), "/proc/%d/stat", pid);
ASSERT_EQ(get_nth(_metadata, proc_path, 3, &line), 1);
-   int rc = get_nth(_metadata, proc_path, 3, &line);
-   if (rc != 1) {
-   printf("[ERROR] user_notification_fifo: failed to read stat for 
PID %d (rc=%d)\n", pid, rc);
-   }
-   ASSERT_EQ(rc, 1);
+   rc = get_nth(_metadata, proc_path, 3, &line);
+ASSERT_EQ(rc, 1) {
+   TH_LOG("user_notification_fifo: failed to read stat for PID %d 
(rc=%d)", pid, rc);
+   }
status = *line;
free(line);
 
-- 
2.43.0




Re: [PATCH v2] selftests: net: fix spelling and grammar mistakes

2025-05-27 Thread Jakub Kicinski
On Fri, 23 May 2025 03:22:42 +0100 Praveen Balakrishnan wrote:
> Fix several spelling and grammatical mistakes in output messages from
> the net selftests to improve readability.
> 
> Only the message strings for the test output have been modified. No
> changes to the functional logic of the tests have been made.
> 
> Signed-off-by: Praveen Balakrishnan 

This does not apply cleanly any more.
Please wait until net-next re-opens after the merge window, 
rebase and repost:
https://netdev.bots.linux.dev/net-next.html
-- 
pw-bot: cr



Re: [PATCH net-next 1/3] net: devmem: support single IOV with sendmsg

2025-05-27 Thread Jakub Kicinski
On Tue, 20 May 2025 13:30:42 -0700 Stanislav Fomichev wrote:
> sendmsg() with a single iov becomes ITER_UBUF, sendmsg() with multiple
> iovs becomes ITER_IOVEC. iter_iov_len does not return correct
> value for UBUF, so teach to treat UBUF differently.

Looks like this has been merged (silently), thanks!



Re: [PATCH v3 7/6] scsi: Always define MODULE_DEVICE_TABLE

2025-05-27 Thread James Bottomley
On Tue, 2025-05-27 at 15:15 +0200, Alexey Gladkov wrote:
> Since MODULE_DEVICE_TABLE no longer depends on whether the module is
> built separately or compiled into the kernel, it now makes sense to
> always define DEVICE_TABLE. In this case, even if the module is in
> the
> kernel, correct module.builtin.modaliases will be generated.
> 
> Suggested-by: James Bottomley 
> Signed-off-by: Alexey Gladkov 
> ---
>  drivers/scsi/BusLogic.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
> index 8ce2ac9293a3..08e12a3d6703 100644
> --- a/drivers/scsi/BusLogic.c
> +++ b/drivers/scsi/BusLogic.c
> @@ -3715,7 +3715,6 @@ static void __exit blogic_exit(void)
>  
>  __setup("BusLogic=", blogic_setup);
>  
> -#ifdef MODULE
>  /*static const struct pci_device_id blogic_pci_tbl[] = {
>   { PCI_VENDOR_ID_BUSLOGIC,
> PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER,
>     PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> @@ -3732,7 +3731,6 @@ static const struct pci_device_id
> blogic_pci_tbl[] = {
>   {0, },
>  };
>  MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);
> -#endif

You don't need to do this in two steps.  The original problem of
defined but not used table stopped being a problem when the structure
was converted to static const over ten years ago (the compiler doesn't
warn about unused static consts).

Regards,

James




Re: [PATCH] fs/dax: Fix "don't skip locked entries when scanning entries"

2025-05-27 Thread Dan Williams
Alistair Popple wrote:
> Commit 6be3e21d25ca ("fs/dax: don't skip locked entries when scanning
> entries") introduced a new function, wait_entry_unlocked_exclusive(),
> which waits for the current entry to become unlocked without advancing
> the XArray iterator state.
> 
> Waiting for the entry to become unlocked requires dropping the XArray
> lock. This requires calling xas_pause() prior to dropping the lock
> which leaves the xas in a suitable state for the next iteration. However
> this has the side-effect of advancing the xas state to the next index.
> Normally this isn't an issue because xas_for_each() contains code to
> detect this state and thus avoid advancing the index a second time on
> the next loop iteration.
> 
> However both callers of and wait_entry_unlocked_exclusive() itself
> subsequently use the xas state to reload the entry. As xas_pause()
> updated the state to the next index this will cause the current entry
> which is being waited on to be skipped. This caused the following
> warning to fire intermittently when running xftest generic/068 on an XFS
> filesystem with FS DAX enabled:
> 
> [   35.067397] [ cut here ]
> [   35.068229] WARNING: CPU: 21 PID: 1640 at mm/truncate.c:89 
> truncate_folio_batch_exceptionals+0xd8/0x1e0
[..]
> 
> Fix this by using xas_reset() instead, which is equivalent in
> implementation to xas_pause() but does not advance the XArray state.
> 
> Fixes: 6be3e21d25ca ("fs/dax: don't skip locked entries when scanning 
> entries")
> Signed-off-by: Alistair Popple 
[..]
> 
> Hi Andrew,
> 
> Apologies for finding this so late in the cycle. This is a very
> intermittent issue for me, and it seems it was only exposed by a recent
> upgrade to my test machine/setup. The user visible impact is the same
> as for the original commit this fixes. That is possible file data
> corruption if a device has a FS DAX page pinned for DMA.
> 
> So in other words it means my original fix was not 100% effective.
> The issue that commit fixed has existed for a long time without being
> reported, so not sure if this is worth trying to get into v6.15 or not.
> 
> Either way I figured it would be best to send this ASAP, which means I
> am still waiting for a complete xfstest run to complete (although the
> failing test does now pass cleanly).
> ---
>  fs/dax.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index 676303419e9e..f8d8b1afd232 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -257,7 +257,7 @@ static void *wait_entry_unlocked_exclusive(struct 
> xa_state *xas, void *entry)
>   wq = dax_entry_waitqueue(xas, entry, &ewait.key);
>   prepare_to_wait_exclusive(wq, &ewait.wait,
>   TASK_UNINTERRUPTIBLE);
> - xas_pause(xas);
> + xas_reset(xas);
>   xas_unlock_irq(xas);
>   schedule();
>   finish_wait(wq, &ewait.wait);

This looks super-subtle, but so did the original fix commit 6be3e21d25ca
("fs/dax: don't skip locked entries when scanning entries"). The
resolution is the same to make sure the xarray state does not mistakenly
advance when the lock is dropped.

You can add:

Reviewed-by: Dan Williams 



Re: [PATCH net-next v2 6/8] net: devmem: ksft: add 5 tuple FS support

2025-05-27 Thread Stanislav Fomichev
On 05/23, Mina Almasry wrote:
> ncdevmem supports drivers that are limited to either 3-tuple or 5-tuple
> FS support, but the ksft is currently 3-tuple only. Support drivers that
> have 5-tuple FS supported by adding a ksft arg.
> 
> Signed-off-by: Mina Almasry 

Acked-by: Stanislav Fomichev 



Re: [PATCH net-next v2 4/8] net: devmem: ksft: add ipv4 support

2025-05-27 Thread Stanislav Fomichev
On 05/23, Mina Almasry wrote:
> ncdevmem supports both ipv4 and ipv6, but the ksft is currently
> ipv6-only. Propagate the ipv4 support to the ksft, so that folks that
> are limited to these networks can also test.
> 
> Signed-off-by: Mina Almasry 

Acked-by: Stanislav Fomichev 



Re: [PATCH 2/7] rust: kunit: support checked `-> Result`s in KUnit `#[test]`s

2025-05-27 Thread Miguel Ojeda
On Tue, May 6, 2025 at 8:33 AM David Gow  wrote:
>
> FWIW, having out-of-memory situations trigger a test failure is
> consistent with what other KUnit tests (written in C) do.
>
> There's both advantages and disadvantages to this: on the one hand,
> it's prone to false positives (as you mention), on the other, it
> catches cases where the test is using an unusually large amount of
> memory (which could indeed be a test issues).
>
> My go-to rule is that tests should fail if small allocations (which,
> in the normal course of events, _should_ succeed) fail, but if they
> have unusual resource requirements (beyond "enough memory for the
> system to run normally") these should be checked separately when the
> test starts.
>
> That being said, I definitely think that, by default, an `Err` return
> should map to a FAILED test result, as not all Err Results are a
> resource exhaustion issue, and we definitely don't want to mark a test
> as skipped if there's a real error occurring. If test authors wish to
> skip a test when an out-of-memory condition occurs, they probably
> should handle that explicitly. (But I'd not be opposed to helpers to
> make it easier.)

Yeah, agreed.

There may be value in differentiating errors coming from `?` vs.
`assert!`s -- i.e. the discussion in the other thread. It could even
be a different error state if that was valuable -- though I think over
complicating is not great either.

By the way, before I forget to write this down: I talked to Alice
about this back when this discussion happened and she suggested having
a `Result` that carries extra information -- the location. I was
worried about the added cost of doing that in all cases (i.e. for
every `Result` in the kernel), so I suggested doing that but opt-in,
i.e. with a Kconfig option that would be in e.g. the debug menu. Then
people could typically run their debug kernels and things like KUnit
with it enabled, but production kernels without it. Then later on, if
it proves useful for other things, we could try to figure out ways to
do it without too much cost.

Cheers,
Miguel



Re: [PATCH net-next v2 2/8] page_pool: fix ugly page_pool formatting

2025-05-27 Thread Stanislav Fomichev
On 05/23, Mina Almasry wrote:
> Minor cleanup; this line is badly formatted.
> 
> Signed-off-by: Mina Almasry 

Acked-by: Stanislav Fomichev 



Re: [PATCH net-next v2 1/8] net: devmem: move list_add to net_devmem_bind_dmabuf.

2025-05-27 Thread Stanislav Fomichev
On 05/23, Mina Almasry wrote:
> It's annoying for the list_add to be outside net_devmem_bind_dmabuf, but
> the list_del is in net_devmem_unbind_dmabuf. Make it consistent by
> having both the list_add/del be inside the net_devmem_[un]bind_dmabuf.
> 
> Cc: ap420...@gmail.com
> Signed-off-by: Mina Almasry 
> Tested-by: Taehee Yoo 

Acked-by: Stanislav Fomichev 



[PATCH 3/3] virtio_ring: Fix typos in comments and documentation

2025-05-27 Thread Alok Tiwari
Corrected several typos in virtio_ring.c for improved clarity and
consistency. Fixes include:
- "dind't" -> "didn't"
- "use" -> "uses" in DMA mapping context
- "can been used" -> "can be used"
- "buf size for sync" -> "buffer size to synchronize"

No functional changes.

Signed-off-by: Alok Tiwari 
---
 drivers/virtio/virtio_ring.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index b784aab66867..e1456ec0db7c 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -606,7 +606,7 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
 
prev = i;
/* Note that we trust indirect descriptor
-* table since it use stream DMA mapping.
+* table since it uses stream DMA mapping.
 */
i = virtqueue_add_desc_split(_vq, desc, extra, i, addr, 
len,
 VRING_DESC_F_NEXT,
@@ -623,7 +623,7 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
 
prev = i;
/* Note that we trust indirect descriptor
-* table since it use stream DMA mapping.
+* table since it uses stream DMA mapping.
 */
i = virtqueue_add_desc_split(_vq, desc, extra, i, addr, 
len,
 VRING_DESC_F_NEXT |
@@ -2438,7 +2438,7 @@ EXPORT_SYMBOL_GPL(virtqueue_add_inbuf_premapped);
  * virtqueue_dma_dev - get the dma dev
  * @_vq: the struct virtqueue we're talking about.
  *
- * Returns the dma dev. That can been used for dma api.
+ * Returns the dma dev. That can be used for dma api.
  */
 struct device *virtqueue_dma_dev(struct virtqueue *_vq)
 {
@@ -3225,7 +3225,7 @@ EXPORT_SYMBOL_GPL(virtqueue_dma_need_sync);
  * @_vq: the struct virtqueue we're talking about.
  * @addr: DMA address
  * @offset: DMA address offset
- * @size: buf size for sync
+ * @size: buffer size to synchronize
  * @dir: DMA direction
  *
  * Before calling this function, use virtqueue_dma_need_sync() to confirm that
@@ -3252,7 +3252,7 @@ 
EXPORT_SYMBOL_GPL(virtqueue_dma_sync_single_range_for_cpu);
  * @_vq: the struct virtqueue we're talking about.
  * @addr: DMA address
  * @offset: DMA address offset
- * @size: buf size for sync
+ * @size: buffer size to synchronize
  * @dir: DMA direction
  *
  * Before calling this function, use virtqueue_dma_need_sync() to confirm that
-- 
2.47.1




[PATCH 2/3] virtio-mem: fix multiple typos in struct comments and function docs

2025-05-27 Thread Alok Tiwari
Corrected several spelling mistakes in code comments, including:
- "bock" -> "block"
- "valued" -> "value"
- "actipn" -> "action"
- "accidentially" -> "accidentally"
- Improved grammar in a few places for clarity.

These changes are purely cosmetic and do not affect functionality.

Signed-off-by: Alok Tiwari 
---
 drivers/virtio/virtio_mem.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 56d0dbe62163..f318a2d3c885 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -164,7 +164,7 @@ struct virtio_mem {
unsigned long first_mb_id;
/* Id of the last usable memory block of this device. */
unsigned long last_usable_mb_id;
-   /* Id of the next memory bock to prepare when needed. */
+   /* Id of the next memory block to prepare when needed. 
*/
unsigned long next_mb_id;
 
/* The subblock size. */
@@ -209,7 +209,7 @@ struct virtio_mem {
unsigned long first_bb_id;
/* Id of the last usable big block of this device. */
unsigned long last_usable_bb_id;
-   /* Id of the next device bock to prepare when needed. */
+   /* Id of the next device block to prepare when needed. 
*/
unsigned long next_bb_id;
 
/* Summary of all big block states. */
@@ -240,7 +240,7 @@ struct virtio_mem {
/* An error occurred we cannot handle - stop processing requests. */
bool broken;
 
-   /* Cached valued of is_kdump_kernel() when the device was probed. */
+   /* Cached value of is_kdump_kernel() when the device was probed. */
bool in_kdump;
 
/* The driver is being removed. */
@@ -615,7 +615,7 @@ static int virtio_mem_sbm_sb_states_prepare_next_mb(struct 
virtio_mem *vm)
 
 /*
  * Test if we could add memory without creating too much offline memory -
- * to avoid running OOM if memory is getting onlined deferred.
+ * to avoid running OOM if memory is getting online deferred.
  */
 static bool virtio_mem_could_add_memory(struct virtio_mem *vm, uint64_t size)
 {
@@ -808,7 +808,7 @@ static int virtio_mem_sbm_try_remove_unplugged_mb(struct 
virtio_mem *vm,
 }
 
 /*
- * See virtio_mem_offline_and_remove_memory(): Try to offline and remove a
+ * See virtio_mem_offline_and_remove_memory(): Try to offline and remove
  * all Linux memory blocks covered by the big block.
  */
 static int virtio_mem_bbm_offline_and_remove_bb(struct virtio_mem *vm,
@@ -1080,7 +1080,7 @@ static int virtio_mem_memory_notifier_cb(struct 
notifier_block *nb,
atomic64_sub(size, &vm->offline_size);
/*
 * Start adding more memory once we onlined half of our
-* threshold. Don't trigger if it's possibly due to our actipn
+* threshold. Don't trigger if it's possibly due to our action
 * (e.g., us adding memory which gets onlined immediately from
 * the core).
 */
@@ -2124,7 +2124,7 @@ static int virtio_mem_sbm_unplug_request(struct 
virtio_mem *vm, uint64_t diff)
 * whole memory blocks along with metadata. We prioritize ZONE_MOVABLE
 * as it's more reliable to unplug memory and remove whole memory
 * blocks, and we don't want to trigger a zone imbalances by
-* accidentially removing too much kernel memory.
+* accidentally removing too much kernel memory.
 */
for (i = 0; i < ARRAY_SIZE(mb_states); i++) {
virtio_mem_sbm_for_each_mb_rev(vm, mb_id, mb_states[i]) {
-- 
2.47.1




[PATCH 1/3] virtio: Fix typo in register_virtio_device() doc comment

2025-05-27 Thread Alok Tiwari
Corrected "suceess" to "success" in the function documentation
for clarity.

Signed-off-by: Alok Tiwari 
---
 drivers/virtio/virtio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 95d5d7993e5b..2c022640ec4b 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -506,7 +506,7 @@ static int virtio_device_of_init(struct virtio_device *dev)
  * On error, the caller must call put_device on &@dev->dev (and not kfree),
  * as another code path may have obtained a reference to @dev.
  *
- * Returns: 0 on suceess, -error on failure
+ * Returns: 0 on success, -error on failure
  */
 int register_virtio_device(struct virtio_device *dev)
 {
-- 
2.47.1




[PATCH v3 7/6] scsi: Always define MODULE_DEVICE_TABLE

2025-05-27 Thread Alexey Gladkov
Since MODULE_DEVICE_TABLE no longer depends on whether the module is
built separately or compiled into the kernel, it now makes sense to
always define DEVICE_TABLE. In this case, even if the module is in the
kernel, correct module.builtin.modaliases will be generated.

Suggested-by: James Bottomley 
Signed-off-by: Alexey Gladkov 
---
 drivers/scsi/BusLogic.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index 8ce2ac9293a3..08e12a3d6703 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -3715,7 +3715,6 @@ static void __exit blogic_exit(void)
 
 __setup("BusLogic=", blogic_setup);
 
-#ifdef MODULE
 /*static const struct pci_device_id blogic_pci_tbl[] = {
{ PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER,
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
@@ -3732,7 +3731,6 @@ static const struct pci_device_id blogic_pci_tbl[] = {
{0, },
 };
 MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);
-#endif
 
 module_init(blogic_init);
 module_exit(blogic_exit);
-- 
2.49.0




Re: [PATCH net v2] vsock/test: Fix occasional failure in SOCK_STREAM SHUT_RD test

2025-05-27 Thread Konstantin Shkolnyy

On 26-May-25 08:55, Stefano Garzarella wrote:


BTW I think I already fixed the same issue in this series:
https://lore.kernel.org/netdev/20250514141927.159456-1-sgarz...@redhat.com/

Can you check it?


Yes, it looks like the same issue.




[PATCH v2 3/3] KVM: arm64: selftests: arch_timer_edge_cases - determine effective counter width

2025-05-27 Thread Sebastian Ott
arch_timer_edge_cases uses ~0 as the maximum counter value, however there's
no architectural guarantee that this is valid.

Figure out the effective counter width based on the effective frequency
like it's done by the kernel.

Note that the following subtest only worked since the counter initialized
with CVAL_MAX would instantly overflow (which is no longer the case):

test_set_cnt_after_cval_no_irq(timer, 0, DEF_CNT, CVAL_MAX, sm);

To fix this we could swap CVAL_MAX for 0 here but since that is already
done by test_move_counters_behind_timers() let's remove that subtest.

This also serves as a workaround for AC03_CPU_14 that led to the
following assertion failure on ampere-one machines:

 Test Assertion Failure 
  arm64/arch_timer_edge_cases.c:169: timer_condition == istatus
  pid=11236 tid=11236 errno=4 - Interrupted system call
 1  0x00404ce7: test_run at arch_timer_edge_cases.c:938
 2  0x00401ebb: main at arch_timer_edge_cases.c:1053
 3  0x9fa8625b: ?? ??:0
 4  0x9fa8633b: ?? ??:0
 5  0x00401fef: _start at ??:?
  0x1 != 0x0 (timer_condition != istatus)

Link: 
https://lore.kernel.org/kvmarm/ac1de1d2-ef2b-d439-dc48-8615e121b...@redhat.com
Link: 
https://amperecomputing.com/assets/AmpereOne_Developer_ER_v0_80_20240823_28945022f4.pdf
Signed-off-by: Sebastian Ott 
---
 .../kvm/arm64/arch_timer_edge_cases.c | 27 ---
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c 
b/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
index a813b4c6c817..1e3e36d869d4 100644
--- a/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
+++ b/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
@@ -22,7 +22,8 @@
 #include "gic.h"
 #include "vgic.h"
 
-static const uint64_t CVAL_MAX = ~0ULL;
+/* Depends on counter width. */
+static uint64_t CVAL_MAX;
 /* tval is a signed 32-bit int. */
 static const int32_t TVAL_MAX = INT32_MAX;
 static const int32_t TVAL_MIN = INT32_MIN;
@@ -30,8 +31,8 @@ static const int32_t TVAL_MIN = INT32_MIN;
 /* After how much time we say there is no IRQ. */
 static const uint32_t TIMEOUT_NO_IRQ_US = 5;
 
-/* A nice counter value to use as the starting one for most tests. */
-static const uint64_t DEF_CNT = (CVAL_MAX / 2);
+/* Counter value to use as the starting one for most tests. Set to CVAL_MAX/2 
*/
+static uint64_t DEF_CNT;
 
 /* Number of runs. */
 static const uint32_t NR_TEST_ITERS_DEF = 5;
@@ -732,12 +733,6 @@ static void test_move_counters_ahead_of_timers(enum 
arch_timer timer)
test_set_cnt_after_tval(timer, 0, tval, (uint64_t) tval + 1,
wm);
}
-
-   for (i = 0; i < ARRAY_SIZE(sleep_method); i++) {
-   sleep_method_t sm = sleep_method[i];
-
-   test_set_cnt_after_cval_no_irq(timer, 0, DEF_CNT, CVAL_MAX, sm);
-   }
 }
 
 /*
@@ -975,6 +970,8 @@ static void test_vm_create(struct kvm_vm **vm, struct 
kvm_vcpu **vcpu,
test_init_timer_irq(*vm, *vcpu);
vgic_v3_setup(*vm, 1, 64);
sync_global_to_guest(*vm, test_args);
+   sync_global_to_guest(*vm, CVAL_MAX);
+   sync_global_to_guest(*vm, DEF_CNT);
 }
 
 static void test_print_help(char *name)
@@ -1035,6 +1032,17 @@ static bool parse_args(int argc, char *argv[])
return false;
 }
 
+static void set_counter_defaults(void)
+{
+   const uint64_t MIN_ROLLOVER_SECS = 40ULL * 365 * 24 * 3600;
+   uint64_t freq = read_sysreg(CNTFRQ_EL0);
+   uint64_t width = ilog2(MIN_ROLLOVER_SECS * freq);
+
+   width = clamp(width, 56, 64);
+   CVAL_MAX = GENMASK_ULL(width - 1, 0);
+   DEF_CNT = CVAL_MAX / 2;
+}
+
 int main(int argc, char *argv[])
 {
struct kvm_vcpu *vcpu;
@@ -1047,6 +1055,7 @@ int main(int argc, char *argv[])
exit(KSFT_SKIP);
 
sched_getaffinity(0, sizeof(default_cpuset), &default_cpuset);
+   set_counter_defaults();
 
if (test_args.test_virtual) {
test_vm_create(&vm, &vcpu, VIRTUAL);
-- 
2.49.0




Re: [PATCH net-next v2 3/8] net: devmem: preserve sockc_err

2025-05-27 Thread Stanislav Fomichev
On 05/23, Mina Almasry wrote:
> Preserve the error code returned by sock_cmsg_send and return that on
> err.
> 
> Signed-off-by: Mina Almasry 

Acked-by: Stanislav Fomichev 



Re: [PATCH net-next v8] selftests/vsock: add initial vmtest.sh for vsock

2025-05-27 Thread Stefano Garzarella

On Tue, May 27, 2025 at 07:30:29AM -0700, Bobby Eshleman wrote:

On Mon, May 26, 2025 at 01:18:18PM +0200, Stefano Garzarella wrote:

On Thu, May 22, 2025 at 09:59:07PM -0700, Bobby Eshleman wrote:
> This commit introduces a new vmtest.sh runner for vsock.
>
> It uses virtme-ng/qemu to run tests in a VM. The tests validate G2H,
> H2G, and loopback. The testing tools from tools/testing/vsock/ are
> reused. Currently, only vsock_test is used.
>
> VMCI and hyperv support is included in the config file to be built with
> the -b option, though not used in the tests.
>
> Only tested on x86.
>
> To run:
>
>  $ make -C tools/testing/selftests TARGETS=vsock
>  $ tools/testing/selftests/vsock/vmtest.sh
>
> or
>
>  $ make -C tools/testing/selftests TARGETS=vsock run_tests
>
> Example runs (after make -C tools/testing/selftests TARGETS=vsock):
>
> $ ./tools/testing/selftests/vsock/vmtest.sh
> 1..3
> ok 0 vm_server_host_client
> ok 1 vm_client_host_server
> ok 2 vm_loopback
> SUMMARY: PASS=3 SKIP=0 FAIL=0
> Log: /tmp/vsock_vmtest_m7DI.log
>
> $ ./tools/testing/selftests/vsock/vmtest.sh vm_loopback
> 1..1
> ok 0 vm_loopback
> SUMMARY: PASS=1 SKIP=0 FAIL=0
> Log: /tmp/vsock_vmtest_a1IO.log
>
> $ mkdir -p ~/scratch
> $ make -C tools/testing/selftests install TARGETS=vsock INSTALL_PATH=~/scratch
> [... omitted ...]
> $ cd ~/scratch
> $ ./run_kselftest.sh
> TAP version 13
> 1..1
> # timeout set to 300
> # selftests: vsock: vmtest.sh
> # 1..3
> # ok 0 vm_server_host_client
> # ok 1 vm_client_host_server
> # ok 2 vm_loopback
> # SUMMARY: PASS=3 SKIP=0 FAIL=0
> # Log: /tmp/vsock_vmtest_svEl.log
> ok 1 selftests: vsock: vmtest.sh
>
> Future work can include vsock_diag_test.
>
> Because vsock requires a VM to test anything other than loopback, this
> patch adds vmtest.sh as a kselftest itself. This is different than other
> systems that have a "vmtest.sh", where it is used as a utility script to
> spin up a VM to run the selftests as a guest (but isn't hooked into
> kselftest).
>
> Signed-off-by: Bobby Eshleman 
> ---
> Changes in v8:
> - remove NIPA comment from commit msg
> - remove tap_* functions and TAP_PREFIX
> - add -b for building kernel
> - Link to v7: 
https://lore.kernel.org/r/20250515-vsock-vmtest-v7-1-ba6fa86d6...@gmail.com
>
> Changes in v7:
> - fix exit code bug when ran is kselftest: use cnt_total instead of 
KSFT_NUM_TESTS
> - updated commit message with updated output
> - updated commit message with commands for installing/running as
>  kselftest
> - Link to v6: 
https://lore.kernel.org/r/20250515-vsock-vmtest-v6-1-9af1cc023...@gmail.com
>
> Changes in v6:
> - add make cmd in commit message in vmtest.sh example (Stefano)
> - check nonzero size of QEMU_PIDFILE using -s conditional (Stefano)
> - display log file path after tests so it is easier to find amongst other 
random names
> - cleanup qemu pidfile if qemu is unable to remove it
> - make oops/warning failures more obvious with 'FAIL' prefix in log
>  (simply saying 'detected' wasn't clear enough to identify failing
>  condition)
> - Link to v5: 
https://lore.kernel.org/r/20250513-vsock-vmtest-v5-1-4e75c4a45...@gmail.com
>
> Changes in v5:
> - make log file a tmpfile (Paolo)
> - make sure both default and user defined QEMU gets handled by the dependency 
check (Paolo)
> - increased VM boot up timeout from 1m to 3m for slow hosts (Paolo)
> - rename vm_setup -> vm_start (Paolo)
> - derive wait_for_listener from selftests/net/net_helper.sh to removes ss 
usage
> - Remove unused 'unset IFS' line (Paolo)
> - leave space after variable declarations (Paolo)
> - make QEMU_PIDFILE a tmp file (Paolo)
> - make everything readonly that is only read (Paolo)
> - source ktap_helpers.sh for KSFT_PASS and friends (Paolo)
> - don't check for timeout util (Paolo)
> - add missing usage string for -q qemu arg
> - add tap prefix to SUMMARY line since it isn't part of TAP protocol
> - exit with the correct status code based on failure/pass counts
> - Link to v4: 
https://lore.kernel.org/r/20250507-vsock-vmtest-v4-1-6e2a97262...@gmail.com
>
> Changes in v4:
> - do not use special tab delimiter for help string parsing (Stefano + Paolo)
> - fix paths for when installing kselftest and running out-of-tree (Paolo)
> - change vng to using running kernel instead of compiled kernel (Paolo)
> - use multi-line string for QEMU_OPTS (Stefano)
> - change timeout to 300s (Paolo)
> - skip if tools are not found and use kselftests status codes (Paolo)
> - remove build from vmtest.sh (Paolo)
> - change  -> SSH_HOST_PORT (Stefano)
> - add tap-format output
> - add vmtest.log to gitignore
> - check for vsock_test binary and remind user to build it if missing
> - create a proper build in makefile
> - style fixes
> - add ssh, timeout, and pkill to dependency check, just in case
> - fix numerical comparison in conditionals
> - check qemu pidfile exists before proceeding (avoid wasting time waiting for 
ssh)
> - fix tracking of pass/fail bug
> - fix stderr redirection bug
> - Link to v3: 
https://lo

  1   2   >