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;
Subject: Re: io-uring: KASAN failure, presumably
To:     Nadav Amit <nadav.amit@gmail.com>
Cc:     Pavel Begunkov <asml.silence@gmail.com>, io-uring@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <2C3AECED-1915-4080-B143-5BA4D76FB5CD@gmail.com>
 <859829f3-ecd0-0c01-21d4-28c17382aa52@kernel.dk>
 <C5C0EB71-B05E-4FE6-871D-900231F8454B@gmail.com>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <3c55f383-7574-8519-067d-cdf1a84ee95c@kernel.dk>
Date:   Sun, 12 Sep 2021 12:24:31 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <C5C0EB71-B05E-4FE6-871D-900231F8454B@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 9/12/21 12:21 PM, Nadav Amit wrote:
> 
> 
>> On Sep 12, 2021, at 11:15 AM, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 9/11/21 8:34 PM, Nadav Amit wrote:
>>> Hello Jens (& Pavel),
>>>
>>> I hope you are having a nice weekend. I ran into a KASAN failure in io-uring
>>> which I think is not "my fault".
>>>
>>> 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.
>>>
>>> The failure happens on my own custom kernel (do not try to correlate the line
>>> numbers). The gist of the splat is:
>>
>> 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.
>>
>> I'll ponder this a bit…
> 
> 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. 

Yes exactly, and hence why I think we need to tighten this check to only
be for bdev backed files.

> Perhaps EAGAIN is
> anyhow not the right return value (in my case). I am not sure any other
> “invalid" 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.

OK good, thanks for confirming!

-- 
Jens Axboe