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 X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0753C433DF for ; Mon, 12 Oct 2020 07:25:35 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 25DF020790 for ; Mon, 12 Oct 2020 07:25:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZH/GiPnA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 25DF020790 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:51850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kRsD7-00020q-Ml for qemu-devel@archiver.kernel.org; Mon, 12 Oct 2020 03:25:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38988) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRsAV-0007iG-3t for qemu-devel@nongnu.org; Mon, 12 Oct 2020 03:22:51 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:22231) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kRsAP-00089v-HH for qemu-devel@nongnu.org; Mon, 12 Oct 2020 03:22:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602487363; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=tt3UUWell3QFwPX1hW/d+EUaBj/+RtQU+l2uV56Tn5M=; b=ZH/GiPnAc8f2shewuXm9DtR349+EIqQsNOD2q4XZp6+VnKqs/Kd0sGqNKziG0J+TQPGX0b /KZItEcE1ehs8EIs+4qbs3mb4TDgZudzHk8QHPi7uhdZ/eaUX+E7JRELOKyWG8x5iBmyLV NlQKzpxfOfZH+SwXXJv6Bp4XW+3JWBo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-354-4P1rfSskMP6ENlCqqDVuGA-1; Mon, 12 Oct 2020 03:22:37 -0400 X-MC-Unique: 4P1rfSskMP6ENlCqqDVuGA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D801D57052; Mon, 12 Oct 2020 07:22:35 +0000 (UTC) Received: from dresden.str.redhat.com (unknown [10.40.193.240]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2925C5C22B; Mon, 12 Oct 2020 07:22:33 +0000 (UTC) Subject: Re: Which qemu change corresponds to RedHat bug 1655408 To: Jakob Bohm References: <2d9c8525-470f-a4e5-5d71-895046e2d782@wisemo.com> <653b9595-ae60-181a-2975-2e351ade9788@redhat.com> <43072820-c04f-b706-4b37-2d2e37e8499f@wisemo.com> <0c76d4c9-a203-8bc3-e367-b198efe819d9@redhat.com> <7d9328d2-69b6-5bb4-405d-5756e14688ec@wisemo.com> <81886f9a-91b1-a398-b5a1-44be5bcf6eb3@redhat.com> <829eb784-76ce-7638-1380-4f718b059f92@wisemo.com> From: Max Reitz Autocrypt: addr=mreitz@redhat.com; prefer-encrypt=mutual; keydata= mQENBFXOJlcBCADEyyhOTsoa/2ujoTRAJj4MKA21dkxxELVj3cuILpLTmtachWj7QW+TVG8U /PsMCFbpwsQR7oEy8eHHZwuGQsNpEtNC2G/L8Yka0BIBzv7dEgrPzIu+W3anZXQW4702+uES U29G8TP/NGfXRRHGlbBIH9KNUnOSUD2vRtpOLXkWsV5CN6vQFYgQfFvmp5ZpPeUe6xNplu8V mcTw8OSEDW/ZnxJc8TekCKZSpdzYoxfzjm7xGmZqB18VFwgJZlIibt1HE0EB4w5GsD7x5ekh awIe3RwoZgZDLQMdOitJ1tUc8aqaxvgA4tz6J6st8D8pS//m1gAoYJWGwwIVj1DjTYLtABEB AAG0HU1heCBSZWl0eiA8bXJlaXR6QHJlZGhhdC5jb20+iQFTBBMBCAA9AhsDBQkSzAMABQsJ CAcCBhUICQoLAgQWAgMBAh4BAheABQJVzie5FRhoa3A6Ly9rZXlzLmdudXBnLm5ldAAKCRD0 B9sAYdXPQDcIB/9uNkbYEex1rHKz3mr12uxYMwLOOFY9fstP5aoVJQ1nWQVB6m2cfKGdcRe1 2/nFaHSNAzT0NnKz2MjhZVmcrpyd2Gp2QyISCfb1FbT82GMtXFj1wiHmPb3CixYmWGQUUh+I AvUqsevLA+WihgBUyaJq/vuDVM1/K9Un+w+Tz5vpeMidlIsTYhcsMhn0L9wlCjoucljvbDy/ 8C9L2DUdgi3XTa0ORKeflUhdL4gucWoAMrKX2nmPjBMKLgU7WLBc8AtV+84b9OWFML6NEyo4 4cP7cM/07VlJK53pqNg5cHtnWwjHcbpGkQvx6RUx6F1My3y52vM24rNUA3+ligVEgPYBuQEN BFXOJlcBCADAmcVUNTWT6yLWQHvxZ0o47KCP8OcLqD+67T0RCe6d0LP8GsWtrJdeDIQk+T+F xO7DolQPS6iQ6Ak2/lJaPX8L0BkEAiMuLCKFU6Bn3lFOkrQeKp3u05wCSV1iKnhg0UPji9V2 W5eNfy8F4ZQHpeGUGy+liGXlxqkeRVhLyevUqfU0WgNqAJpfhHSGpBgihUupmyUg7lfUPeRM DzAN1pIqoFuxnN+BRHdAecpsLcbR8sQddXmDg9BpSKozO/JyBmaS1RlquI8HERQoe6EynJhd 64aICHDfj61rp+/0jTIcevxIIAzW70IadoS/y3DVIkuhncgDBvGbF3aBtjrJVP+5ABEBAAGJ ASUEGAEIAA8FAlXOJlcCGwwFCRLMAwAACgkQ9AfbAGHVz0CbFwf9F/PXxQR9i4N0iipISYjU sxVdjJOM2TMut+ZZcQ6NSMvhZ0ogQxJ+iEQ5OjnIputKvPVd5U7WRh+4lF1lB/NQGrGZQ1ic alkj6ocscQyFwfib+xIe9w8TG1CVGkII7+TbS5pXHRxZH1niaRpoi/hYtgzkuOPp35jJyqT/ /ELbqQTDAWcqtJhzxKLE/ugcOMK520dJDeb6x2xVES+S5LXby0D4juZlvUj+1fwZu+7Io5+B bkhSVPb/QdOVTpnz7zWNyNw+OONo1aBUKkhq2UIByYXgORPFnbfMY7QWHcjpBVw9MgC4tGeF R4bv+1nAMMxKmb5VvQCExr0eFhJUAHAhVg== Message-ID: Date: Mon, 12 Oct 2020 09:22:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <829eb784-76ce-7638-1380-4f718b059f92@wisemo.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mreitz@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=63.128.21.124; envelope-from=mreitz@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/12 02:58:41 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: John Snow , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel , Qemu-block , qemu-discuss@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 10.10.20 00:54, Jakob Bohm wrote: [...] > Theoretically, locking on a raw file needs to be protocol-compatible > with loop-mounting the same raw file, so if the loop driver doesn't > probe those magic byte offsets to prevent out-of-order block writes, > then there is little point for the qemu raw driver to do so. > > This applies to both the loop driver in the host kernel and the loop > driver on any other machine with file share access to the sane image > file. The file access locks aren’t meant to prevent arbitrary other programs from accessing those specific few bytes, but to prevent concurrently running qemu processes from accessing the image. That’s why qemu doesn’t lock the whole image file, but only a small and very specific set of bytes. The problem we originally faced was that some people would run qemu-img to modify qcow2 images while a VM was running, leading to metadata corruption and thus data loss. This is the main reason the locks were introduced. However, the problem isn’t limited to qcow2 images. Even for raw images, we generally have to prevent e.g. concurrent writes to the image (from other VMs that might want to use that image) because the guest won’t be able to deal with that. Hence why we take locks even on non-qcow2 images. > As for upgrading, I will try newer kernels packaged for the Debian > version used, once the current large batch job has completed, but I > doubt it will make much difference given the principles I just stated. I’m not sure whether I understood your paragraphs above wrong, but I don’t see how they explain why the bug would appear (i.e., why qemu would fail taking the file lock). It only seems to explain why it seems superfluous for qemu to take locks when the loop driver will be the only concurrent user of the image (presumably because the loop driver just doesn’t take any locks; which means that qemu should be able to). Max