From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.ebner@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id C175C791F7 for <pve-devel@lists.proxmox.com>; Fri, 1 Jul 2022 14:30:49 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id AF3989B6B for <pve-devel@lists.proxmox.com>; Fri, 1 Jul 2022 14:30:19 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Fri, 1 Jul 2022 14:30:17 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 8FFD940BDF for <pve-devel@lists.proxmox.com>; Fri, 1 Jul 2022 14:30:17 +0200 (CEST) Message-ID: <11f2d69d-58d9-2876-c689-2a7664811793@proxmox.com> Date: Fri, 1 Jul 2022 14:30:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20220701083939.38155-1-f.ebner@proxmox.com> <c06aefdd-c0aa-2937-3907-52e70143c13e@proxmox.com> From: Fabian Ebner <f.ebner@proxmox.com> In-Reply-To: <c06aefdd-c0aa-2937-3907-52e70143c13e@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.047 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH qemu] add patch fixing io_uring short read slow path X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Fri, 01 Jul 2022 12:30:49 -0000 Am 01.07.22 um 13:53 schrieb Thomas Lamprecht: > How likely is this to trigger? Did you came across such events or is this a backport > for the sake of being cautious? > > Mostly asking because 7.0 is already on staging, so it'd be good to know if we should > add another 6.0 release between (a bit of an hassle but possible due it not having yet > seen any public repo), or if there isn't as much time pressure and we can just roll it > out with the slower rollout of QEMU 7.0. I didn't run into this recently. I do remember that I wondered about a luring_resubmit_short_read trace for one VM while looking at the LVM+io_uring issues a year ago, but IIRC that one behaved a bit differently - got a weird GRUB error rather than the hang reported in the forum, which I was able to reproduce with another VM then. But maybe this was actually the root cause for these issues? Would have to find a reproducer again to see if the patch fixes it. v1 of the patch mentions: > Normally recent versions of linux will not issue short reads, > but apparently btrfs with O_DIRECT (cache=none) does. but might not be the only situation. I tried a bit with a VM with an image on BTRFS, but didn't manage to have the call show up in a trace. So I can't really tell how likely. It can happen with BTRFS, it could happen with LVM in the past (we don't allow io_uring+LVM currently). I'd say since there is a big unknown, it might be worth a backport.