From nobody Mon Feb 9 06:02:05 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1604421837; cv=none; d=zohomail.com; s=zohoarc; b=R/u+KrilP1YRY6/fd8YTxjLmHa3HBw12VjByjqUXaeUIj2djM+4S/NEo1m7bGr+s0qRtrZLz0p/W+CXtP2Eu259cyUX2jsjcSlCp8aLN/L8aP9G552kFLmGzDrbVFsmgVrTtRo9ySxZ60kECOvn/gMX/QI/G7N6kvBRLS6HvP+I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1604421837; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=mererF9HuyYNHimsOEPiQGenYCAMq3ZydrAziKY9gY8=; b=MzcSjqd1AXe9tYOUyYMm0vAs0XsTgiP/lPI1Sh2V+L7VzHf4mgvf4xZg2Z2N4aULvPzughHij/t7s0RdWhmlIefNrvhVTngZrEfzoC4sNlj+qy6jf8MRfT/EF9svUjxwsdMr8GRG7QC678gM1RLL+VBL1mI3mPpg7uVgdA72XHk= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1604421837519603.9282173832728; Tue, 3 Nov 2020 08:43:57 -0800 (PST) Received: from localhost ([::1]:54466 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZzPY-00076v-Fu for importer@patchew.org; Tue, 03 Nov 2020 11:43:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45108) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZzNX-0005Ck-BQ for qemu-devel@nongnu.org; Tue, 03 Nov 2020 11:41:51 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:31310) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kZzNT-0000us-Un for qemu-devel@nongnu.org; Tue, 03 Nov 2020 11:41:51 -0500 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-341-cD6dB4IUO-yg3Vp-FC25XQ-1; Tue, 03 Nov 2020 11:41:45 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3304010A0B80 for ; Tue, 3 Nov 2020 16:41:44 +0000 (UTC) Received: from localhost (unknown [10.40.195.44]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6938221E99; Tue, 3 Nov 2020 16:41:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1604421706; 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; bh=mererF9HuyYNHimsOEPiQGenYCAMq3ZydrAziKY9gY8=; b=gBpIkUQLqiV6LWEbcOCy2CVtuUHTQPh/jiz6aKd3jWZsGj6UADRP95bd6EwA5J6d/8erMQ U7F8lqrPssNrJC/Xl6y3xGDG+GM3JA9+qgL/qmWB4rHZL3gyNAYy1WZGq8Su53yJFMKvYY YWLYvXijWayKZRdGhw7gtnRPCOvWdyM= X-MC-Unique: cD6dB4IUO-yg3Vp-FC25XQ-1 From: Max Reitz To: qemu-devel@nongnu.org Subject: [PATCH for-5.2] virtiofsd: Announce submounts even without statx() Date: Tue, 3 Nov 2020 17:41:35 +0100 Message-Id: <20201103164135.169325-1-mreitz@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=216.205.24.124; envelope-from=mreitz@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/03 00:03:41 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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: virtio-fs@redhat.com, Miklos Szeredi , "Dr . David Alan Gilbert" , Stefan Hajnoczi , Max Reitz Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" Contrary to what the check (and warning) in lo_init() claims, we can announce submounts just fine even without statx() -- the check is based on comparing both the mount ID and st_dev of parent and child. Without statx(), we will not have the mount ID; but we always have st_dev. The only problems we have (without statx() and its mount ID) are: (1) Mounting the same device twice may lead to both trees being treated as exactly the same tree by virtiofsd. But that is a problem that is completely independent of mirroring host submounts in the guest. Both submount roots will still show the FUSE_SUBMOUNT flag, because their st_dev still differs from their respective parent. (2) There is only one exception to (1), and that is if you mount a device inside a mount of itself: Then, its st_dev will be the same as that of its parent, and so without a mount ID, virtiofsd will not be able to recognize the nested mount's root as a submount. However, thanks to virtiofsd then treating both trees as exactly the same tree, it will be caught up in a loop when the guest tries to examine the nested submount, so the guest will always see nothing but an ELOOP there. Therefore, this case is just fully broken without statx(), whether we check for submounts (based on st_dev) or not. All in all, checking for submounts works well even without comparing the mount ID (i.e., without statx()). The only concern is an edge case that, without statx() mount IDs, is utterly broken anyway. Thus, drop said check in lo_init(). Reported-by: Miklos Szeredi Signed-off-by: Max Reitz Reviewed-by: Dr. David Alan Gilbert --- tools/virtiofsd/passthrough_ll.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough= _ll.c index ec1008bceb..6c64b03f1a 100644 --- a/tools/virtiofsd/passthrough_ll.c +++ b/tools/virtiofsd/passthrough_ll.c @@ -610,14 +610,6 @@ static void lo_init(void *userdata, struct fuse_conn_i= nfo *conn) "does not support it\n"); lo->announce_submounts =3D false; } - -#ifndef CONFIG_STATX - if (lo->announce_submounts) { - fuse_log(FUSE_LOG_WARNING, "lo_init: Cannot announce submounts, th= ere " - "is no statx()\n"); - lo->announce_submounts =3D false; - } -#endif } =20 static void lo_getattr(fuse_req_t req, fuse_ino_t ino, --=20 2.26.2