assert in watch.c:404 around usb diag

[lynxis]

Hi,

I've ran into the assert() at watch.c:404.

        list_for_each_entry_safe(w, next, &aio_watches, node) {
                for (i = 0; i < count; i++) {
                        iocb = (struct iocb *)ev[i].obj;
                        if (iocb->aio_fildes == w->fd) {
                                assert(w->pending_aio); // <- here

                                if (ev[i].res == -EAGAIN)
                                        continue;

I was attached via usb on a oneplus 6t / postmarketos.

(gdb) bt
#0  __restore_sigs (set=set@entry=0xffffc502f430) at ./arch/aarch64/syscall_arch.h:48
#1  0x0000ffff82c89e6c in raise (sig=sig@entry=6) at src/signal/raise.c:11
#2  0x0000ffff82c58628 in abort () at src/exit/abort.c:11
#3  0x0000ffff82c586c4 in __assert_fail (expr=expr@entry=0xaaaabce291c6 "w->pending_aio", file=file@entry=0xaaaabce291b7 "router/watch.c",
    line=line@entry=404, func=func@entry=0xaaaabce29aa4 <__func__.0> "watch_handle_eventfd") at src/exit/assert.c:7
#4  0x0000aaaabce271ec in watch_handle_eventfd (evfd=32, ioctx=<optimized out>) at router/watch.c:404
#5  watch_run () at router/watch.c:494
#6  0x0000aaaabce22050 in main (argc=<optimized out>, argv=0xffffc502fb08) at router/diag.c:213
(gdb) frame 4
#4  0x0000aaaabce271ec in watch_handle_eventfd (evfd=32, ioctx=<optimized out>) at router/watch.c:404
404	in router/watch.c

The lines might not match exactly because this contains some logging patches (sorry for the mess in the git, but this is WIP: logging

(gdb) print(*w)
$6 = {fd = 5, cb = 0x0, data = 0xaaaabce40d80, queue = 0xaaaabce40d98, iocb = {aio_data = 0, aio_key = 0, aio_rw_flags = 0, aio_lio_opcode = 0, aio_reqprio = 0, aio_fildes = 0, aio_buf = 0, aio_nbytes = 0,
    aio_offset = 0, aio_reserved2 = 0, aio_flags = 0, aio_resfd = 0}, pending_aio = 0x0, is_write = false, flow = 0x0, aio_complete = 0xaaaabce262cc <diag_ffs_recv>, node = {prev = 0xffff82aa61c0,
    next = 0xaaaabce40080 <aio_watches>}}

It might be related to usb ffs if this is still valid.

I've used scat to talk to this endpoint, but it did not immediate happened.