[Bug 217261] sys/aio/aio_test:aio_md_test fails semi-frequently with Jenkins with "aio_write failed: Operation not supported"

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217261

Ngie Cooper <ngie at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kib at FreeBSD.org

--- Comment #4 from Ngie Cooper <ngie at FreeBSD.org> ---
I'm pretty sure that this is happening due to r303154:

-       if (!enable_aio_unsafe)
+       safe = false;
+       if (fp->f_type == DTYPE_VNODE) {
+               vp = fp->f_vnode;
+               if (vp->v_type == VREG || vp->v_type == VDIR) {
+                       mp = fp->f_vnode->v_mount;
+                       if (mp == NULL || (mp->mnt_flag & MNT_LOCAL) != 0)
+                               safe = true;
+               }
+       }
+       if (!(safe || enable_aio_unsafe))

I'm not entirely sure that that commit accounted for these cases noted in
aio(4) (in particular, the second paragraph):

     Asynchronous I/O operations on some file descriptor types may block an
     AIO daemon indefinitely resulting in process and/or system hangs.
     Operations on these file descriptor types are considered "unsafe" and
     disabled by default.  They can be enabled by setting the
     vfs.aio.enable_unsafe sysctl node to a non-zero value.

     Asynchronous I/O operations on sockets, raw disk devices, and regular
     files on local filesystems do not block indefinitely and are always
     enabled.

VBLK and VSOCK doesn't seem to be handled appropriately. VCHR seems trickier to
handle, depending on the input device (pty's for instance could block).

The second paragraph is ambiguous too -- are block devices ok, but not
character devices, or vice versa, or are all forms ok?

-- 
You are receiving this mail because:
You are the assignee for the bug.