Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 09 May 2017 20:58:39 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-testing@freebsd.org
Subject:   [Bug 217261] sys/aio/aio_test:aio_md_test fails semi-frequently with Jenkins with "aio_write failed: Operation not supported"
Message-ID:  <bug-217261-32464-BGH6cJ8FAm@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-217261-32464@https.bugs.freebsd.org/bugzilla/>
References:  <bug-217261-32464@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217261

Ngie Cooper <ngie@FreeBSD.org> changed:

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

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

-       if (!enable_aio_unsafe)
+       safe =3D false;
+       if (fp->f_type =3D=3D DTYPE_VNODE) {
+               vp =3D fp->f_vnode;
+               if (vp->v_type =3D=3D VREG || vp->v_type =3D=3D VDIR) {
+                       mp =3D fp->f_vnode->v_mount;
+                       if (mp =3D=3D NULL || (mp->mnt_flag & MNT_LOCAL) !=
=3D 0)
+                               safe =3D 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 trickie=
r 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?

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217261-32464-BGH6cJ8FAm>