Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp848801pxb; Thu, 15 Apr 2021 08:02:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzH2+bSLbcU84YYEdZnAA/r/gR2weLq9S/4wdMFDsoh0RqyqTuBeLEfioY6AuSyJxvYlmY+ X-Received: by 2002:a63:1716:: with SMTP id x22mr3905161pgl.261.1618498952815; Thu, 15 Apr 2021 08:02:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618498952; cv=none; d=google.com; s=arc-20160816; b=JvZOIBM+lpc/sbUw4kcqWLPIPpjF6dhp+vGGhc3UzeQFHVa6SBWxQsNidzP+uFk1sO Jme7tgnwfXj43A+Z/cCT3PBi6LxJ2SvAv0uh8WGLz08u0XeD2hNWoX1fnck8mOe2B2q8 oDGvKhxK4yyDE9rFvGv9wL0/wlwqALqm2s0UO2gGrJdjJR+HTFlNZenbQAgBumiOYTs6 O69NjCpaN39v3eEHp54hOFJnYnAg14W04OjHN3LXs1ZgUlha+a5pVSqbjcV/P+HKpN5I dzR+xkPjwhv6/4M43gSRe8k4vhTf6Fhee2290mo77resCihuF6FkicheF1P2dOW+021G CRfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=TMhFW4RCmHn2Rcd5XzRY+CHpi4JwTwXIlSHDSmi02SM=; b=drUV0o9D7Rk4KJdWDM4LuL5QkZthPRafyuHudy7QwVv9d4zjGJlm88Y/sovrhnjNB9 1o2FQFUh+TeBinn0HqQZ8dzyIBy9apHE0tUkvct1NpkUFy0kXvdQbqK6irmXqog40plg +KyVxpnEWkJOiycdcyA3pgsiBnU5SMHijZ4ATO8N8HwDJkxdNtZY+B05cyTZ6moFxeU7 87AUyB6OdGK4a8hIywMbEP2S9zn/Jqn+5FzRBEIJNHDi7jcY6ZR10PitirpGC9plNrjr rgEIGOh4H/USAHSBcP+gOJhLbhSFefWnGjSPR38oWMgxcDUawAEtbXbrC0vo9qYyVLns ajUw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g1si3438909pjm.65.2021.04.15.08.02.14; Thu, 15 Apr 2021 08:02:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234308AbhDOPBa (ORCPT + 99 others); Thu, 15 Apr 2021 11:01:30 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:53899 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S234884AbhDOPAG (ORCPT ); Thu, 15 Apr 2021 11:00:06 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 13FExS1V031149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Apr 2021 10:59:29 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 547EE15C3B35; Thu, 15 Apr 2021 10:59:28 -0400 (EDT) Date: Thu, 15 Apr 2021 10:59:28 -0400 From: "Theodore Ts'o" To: Christian Brauner Cc: Christoph Hellwig , Eryu Guan , Christian Brauner , fstests@vger.kernel.org, linux-ext4@vger.kernel.org, "Darrick J . Wong" , David Howells , Amir Goldstein Subject: Re: [PATCH -RFC] ext4: add feature file to advertise that ext4 supports idmapped mounts Message-ID: References: <20210411151249.6y34x7yatqtpcvi6@wittgenstein> <20210411151857.wd6gd46u53vlh2xv@wittgenstein> <20210411153223.vhcegiklrwoczy55@wittgenstein> <20210412115426.a4bzsx4cp7jhx2ou@wittgenstein> <20210415055408.GA8947@lst.de> <20210415074921.cf5uv4xehlctvtvv@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210415074921.cf5uv4xehlctvtvv@wittgenstein> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Apr 15, 2021 at 09:49:21AM +0200, Christian Brauner wrote: > Harsh words. :) > Christoph's right though I think for the xfstests we don't need it and > we're covered with what we have in the version I sent out last Sunday. Sorry, I had missed your v13 patch set and that it had included tests for the existence of idmapped. I had sent out the RFC patch because I was under the impression that we hadn't made forward progress on testing for the support idmapped mounts. If we have a way of doing this, and you're comfortable that it is reliable (e.g., that a bug might cause the test to be skipped because it thinks the file system doesn't support idmapped mount, when really it was caused by a regression), and I'm happy to just rely on the method you've used in the v13 fstests patch set. That being said, I still think it would be helpful to have a VFS-standard way for userspace to be able to test for the presence of a particular kernel feature/capability without having to do a test mount, possibly requiring setting up a test user_ns, etc., etc. But that isn't as urgent as making sure we can easily the feature without needing manual customization of the test suite as file systems add support for the feature, or as the feature gets backported to enterprise distro kernels. Cheers, - Ted