Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: io-uring: KASAN failure, presumably
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <859829f3-ecd0-0c01-21d4-28c17382aa52@kernel.dk>
Date:   Sun, 12 Sep 2021 11:21:55 -0700
Cc:     Pavel Begunkov <asml.silence@gmail.com>, io-uring@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5C0EB71-B05E-4FE6-871D-900231F8454B@gmail.com>
References: <2C3AECED-1915-4080-B143-5BA4D76FB5CD@gmail.com>
 <859829f3-ecd0-0c01-21d4-28c17382aa52@kernel.dk>
To:     Jens Axboe <axboe@kernel.dk>
Precedence: bulk


> On Sep 12, 2021, at 11:15 AM, Jens Axboe <axboe@kernel.dk> wrote:
>=20
> On 9/11/21 8:34 PM, Nadav Amit wrote:
>> Hello Jens (& Pavel),
>>=20
>> I hope you are having a nice weekend. I ran into a KASAN failure in =
io-uring
>> which I think is not "my fault".
>>=20
>> The failure does not happen very infrequently, so my analysis is =
based on
>> reading the code. IIUC the failure, then I do not understand the code =
well
>> enough, as to say I do not understand how it was supposed to work. I =
would
>> appreciate your feedback.
>>=20
>> The failure happens on my own custom kernel (do not try to correlate =
the line
>> numbers). The gist of the splat is:
>=20
> I think this is specific to your use case, but I also think that we
> should narrow the scope for this type of REQ_F_REISSUE trigger. It
> really should only happen on bdev backed regular files, where we =
cannot
> easily pass back congestion. For that case, the completion for this is
> called while we're in ->write_iter() for example, and hence there is =
no
> race here.
>=20
> I'll ponder this a bit=E2=80=A6

I see what you are saying. The assumption is that write_iter() is =
setting
REQ_F_REISSUE, which is not the case in my use-case. Perhaps EAGAIN is
anyhow not the right return value (in my case). I am not sure any other
=E2=80=9Cinvalid" use-case exists, but some documentation/assertion(?) =
can help.

I changed the return error-codes and check that the issue is not
triggered again.

Thanks, as usual, for the quick response.=