On Tue, 3 Nov 2026 at 17:32, Eric Farman <[email protected]> wrote: > > > > On 11/2/26 10:48 AM, Eric Farman wrote: > > > > > > On 10/28/26 1:16 PM, Michael S. Tsirkin wrote: > >> From: Vladimir Sementsov-Ogievskiy <[email protected]> > >> > >> We have .initialized in EventNotifier to track was it actually > >> initialized, and we have a comment that @fd passed to > >> event_notifier_init_fd() must be an eventfd object. > >> > >> Still, there are two specific users, which ignore these things, > >> and use -1 as specific value storing in notifier, to mark it > >> "uninitialized". > >> > >> Let's make strict API: > >> > >> - store only valid FDs in initialized notifier > >> - _set() asserts that passed fd is valid > >> - _get() asserts that notifier is initialized (actually, except > >> the two specific cases we rework, all other callers are not > >> prepared to notifier being uninitialized when _get() is called. > >> In this case _get() returns 0 (which is a valid fd), and caller > >> will mistakenly use it, which is worse than abort()) > > > > Well, there are other cases that would require rework not addressed > > here, as this commit breaks (at least) vhost-vsock-ccw and virtio-net- > > ccw (for vhost=on) on an s390x host. I'll look into that, but was not > > prepared for such a late surprise. > > I sent a fix [0] for the assertion that shows up with this particular > patch in some of the common configurations, but it still leaves VDPA > broken on s390x (which was also working before this commit). So, not a > good idea. > > I just posted a variation [1] of that which restores VDPA functionality. > Would that be doable? Or can we get the assertions here removed until we > can adhere to the API restriction?
If this change regressed something, and we don't have an immediately obvious fix for that, we should probably revert this change. Can we do that without too much trouble? thanks -- PMM
