On Tue, Nov 11, 2025 at 10:09:48AM -0700, Alex Williamson wrote: > On Tue, 11 Nov 2025 06:52:02 -0800 > Alex Mastro <[email protected]> wrote: > > diff --git a/tools/testing/selftests/vfio/lib/vfio_pci_device.c > > b/tools/testing/selftests/vfio/lib/vfio_pci_device.c > > index a381fd253aa7..7a523e3f2dce 100644 > > --- a/tools/testing/selftests/vfio/lib/vfio_pci_device.c > > +++ b/tools/testing/selftests/vfio/lib/vfio_pci_device.c > > @@ -29,6 +29,173 @@ > > VFIO_ASSERT_EQ(__ret, 0, "ioctl(%s, %s, %s) returned %d\n", #_fd, #_op, > > #_arg, __ret); \ > > } while (0) > > > > +static struct vfio_info_cap_header *next_cap_hdr(void *buf, size_t bufsz, > > + size_t *cap_offset) > > +{ > > + struct vfio_info_cap_header *hdr; > > + > > + if (!*cap_offset) > > + return NULL; > > + > > + VFIO_ASSERT_LT(*cap_offset, bufsz); > > + VFIO_ASSERT_GE(bufsz - *cap_offset, sizeof(*hdr)); > > + > > + hdr = (struct vfio_info_cap_header *)((u8 *)buf + *cap_offset); > > + > > + if (hdr->next) > > + VFIO_ASSERT_GT(hdr->next, *cap_offset); > > This might be implementation, but I don't think it's a requirement. > The vfio capability chains are based on PCI capabilities, which have no > ordering requirement. Thanks,
My main interest was to enforce that the chain doesn't contain a cycle, and checking for monotonically increasing cap offset was the simplest way I could think of to guarantee such. If there isn't such a check, and kernel vends a malformed cycle-containing chain, chain traversal would infinite loop. Given the location of this test code coupled to the kernel tree, do you think such assumptions about implementation still reach too far? If yes, I can either remove this check, or try to make cycle detection more relaxed about offsets potentially going backwards. > Alex > > > + > > + *cap_offset = hdr->next; > > + > > + return hdr; > > +}
