From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4D30C433EF for ; Tue, 5 Jul 2022 22:53:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229995AbiGEWxN (ORCPT ); Tue, 5 Jul 2022 18:53:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229994AbiGEWxK (ORCPT ); Tue, 5 Jul 2022 18:53:10 -0400 Received: from gw2.atmark-techno.com (gw2.atmark-techno.com [35.74.137.57]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0745F337 for ; Tue, 5 Jul 2022 15:53:08 -0700 (PDT) Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by gw2.atmark-techno.com (Postfix) with ESMTPS id 28F6920CF3 for ; Wed, 6 Jul 2022 07:53:08 +0900 (JST) Received: by mail-pj1-f72.google.com with SMTP id u13-20020a17090a4bcd00b001eefd8fa171so8034736pjl.2 for ; Tue, 05 Jul 2022 15:53:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tFRngjx0G+BZ60t1jmhrF4wtc8rPFWnQu2MVKcY0EpQ=; b=70hsJLOjfCAMwfurCQwF/XjOP4J8FMVyLyRTfKHcBPNJim/PsVWm5VLQ3gLPAa6a8j cuFRR9E74XANVouSXpwYl/1QHCjd91OOm0cOl0K8hZ7197hqAc2HocRuhhOg5mfQvOn2 d0mrfMk/j6wgb0gU7PXVohewqOfJMwW8Lrp1LZ9QcGUcQUwEkynY2EkYEyLDSWWBwUBB Qrj6JcJcT7PcQ9vIrZL7rWjSk38tpE4TNJ8Y35fLHire5fR02ID+MU67ws4hE7Ul/eJX Kcs+qMioM9bMjciPfYiylY1AI9Rlcel0v+T1wE2kjBfMrBkn9NwITQsT3sG2qsvh99TE rmzA== X-Gm-Message-State: AJIora+2K/p6Mun25omkmn0+9YLQSIoR7CAJdMGaf8Qc/RVauZObKn4r p28vIOIJEfEd7Tns/8tGeuzSJTwbWM5atLh5P/YdsEvRFJO1cqiQjUFrZE+NlCGTUyI6O3eNNOg Av0+28+cjwKCa6l53g5v8 X-Received: by 2002:a17:902:d48a:b0:16b:f0be:4e15 with SMTP id c10-20020a170902d48a00b0016bf0be4e15mr6319005plg.155.1657061587213; Tue, 05 Jul 2022 15:53:07 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v2HoMVKLOO/ikgjMgiFEEWpkCT3RdVr6ejaBU1aeirFrwWCEHisk1J+5k1+ZgwhoPkseEeKA== X-Received: by 2002:a17:902:d48a:b0:16b:f0be:4e15 with SMTP id c10-20020a170902d48a00b0016bf0be4e15mr6318970plg.155.1657061586839; Tue, 05 Jul 2022 15:53:06 -0700 (PDT) Received: from pc-zest.atmarktech (145.82.198.104.bc.googleusercontent.com. [104.198.82.145]) by smtp.gmail.com with ESMTPSA id x2-20020a170902b40200b001675d843332sm23797882plr.63.2022.07.05.15.53.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jul 2022 15:53:06 -0700 (PDT) Received: from martinet by pc-zest.atmarktech with local (Exim 4.95) (envelope-from ) id 1o8rPk-004lid-U7; Wed, 06 Jul 2022 07:53:04 +0900 Date: Wed, 6 Jul 2022 07:52:54 +0900 From: Dominique Martinet To: Stefan Hajnoczi Cc: Jens Axboe , Stefano Garzarella , Aarushi Mehta , Julia Suvorova , Kevin Wolf , Hanna Reitz , qemu-block@nongnu.org, qemu-devel@nongnu.org, Filipe Manana , io-uring@vger.kernel.org Subject: Re: [PATCH v2] io_uring: fix short read slow path Message-ID: References: <20220629044957.1998430-1-dominique.martinet@atmark-techno.com> <20220630010137.2518851-1-dominique.martinet@atmark-techno.com> <20220630154921.ekl45dzer6x4mkvi@sgarzare-redhat> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org Stefan Hajnoczi wrote on Tue, Jul 05, 2022 at 02:28:08PM +0100: > > The older kernel I have installed right now is 5.16 and that can > > reproduce it -- I'll give my laptop some work over the weekend to test > > still maintained stable branches if that's useful. > > Linux 5.16 contains commit 9d93a3f5a0c ("io_uring: punt short reads to > async context"). The comment above QEMU's luring_resubmit_short_read() > claims that short reads are a bug that was fixed by Linux commit > 9d93a3f5a0c. > > If the comment is inaccurate it needs to be fixed. Maybe short writes > need to be handled too. > > I have CCed Jens and the io_uring mailing list to clarify: > 1. Are short IORING_OP_READV reads possible on files/block devices? > 2. Are short IORING_OP_WRITEV writes possible on files/block devices? Jens replied before me, so I won't be adding much (I agree with his reply -- linux tries hard to avoid short reads but we should assume they can happen) In this particular case it was another btrfs bug with O_DIRECT and mixed compression in a file, that's been fixed by this patch: https://lore.kernel.org/all/20220630151038.GA459423@falcondesktop/ queued here: https://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git/commit/?h=dio_fixes&id=b3864441547e49a69d45c7771aa8cc5e595d18fc It should be backported to 5.10, but the problem will likely persist in 5.4 kernels if anyone runs on that as the code changed enough to make backporting non-trivial. So, WRT that comment, we probably should remove the reference to that commit and leave in that they should be very rare but we need to handle them anyway. For writes in particular, I haven't seen any and looking at the code qemu would blow up that storage (IO treated as ENOSPC would likely mark disk read-only?) It might make sense to add some warning message that it's what happened so it'll be obvious what needs doing in case anyone falls on that but I think the status-quo is good enough here. -- Dominique