[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <39c5d7b8da489a1f802960fa575d904ddc2ab9eb.camel@fb.com>
Date: Fri, 22 Apr 2022 09:58:29 +0000
From: Dylan Yudaken <dylany@...com>
To: "axboe@...nel.dk" <axboe@...nel.dk>
CC: Kernel Team <Kernel-team@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"io-uring@...r.kernel.org" <io-uring@...r.kernel.org>,
"asml.silence@...il.com" <asml.silence@...il.com>
Subject: Re: [PATCH 6/6] io_uring: allow NOP opcode in IOPOLL mode
On Thu, 2022-04-21 at 17:33 -0600, Jens Axboe wrote:
> On Thu, Apr 21, 2022 at 3:17 AM Dylan Yudaken <dylany@...com> wrote:
> >
> > This is useful for tests so that IOPOLL can be tested without
> > requiring
> > files. NOP is acceptable in IOPOLL as it always completes
> > immediately.
>
> This one actually breaks two liburing test cases (link and defer)
> that
> assume NOP on IOPOLL will return -EINVAL. Not a huge deal, but we do
> need to figure out how to make them reliably -EINVAL in a different
> way then.
>
> Maybe add a nop_flags to the usual flags spot in the sqe, and define
> a flag that says NOP_IOPOLL or something. Require this flag set for
> allowing NOP on iopoll. That'd allow testing, but still retain the
> -EINVAL behavior if not set.
>
> Alternatively, modify test cases...
>
> I'll drop this one for now, just because it fails the regression
> tests.
>
That's fine - sorry I didn't notice that. I think fixing the tests is
the better approach here. It should be easy to get an -EINVAL from it.
Powered by blists - more mailing lists