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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 BE4D4C64E8A for ; Wed, 2 Dec 2020 08:04:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8B9592222C for ; Wed, 2 Dec 2020 08:04:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387745AbgLBIEi (ORCPT ); Wed, 2 Dec 2020 03:04:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39512 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387539AbgLBIEh (ORCPT ); Wed, 2 Dec 2020 03:04:37 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 627A0C0613CF; Wed, 2 Dec 2020 00:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=uDBxn7MSIWHkb+0YhIz9IAuuaks9YFfm8h/fjLDE0Gg=; b=DyLJfLwoYd7AJsMsJ639+D7rFC Sv0fi5GI4grXGVtC7zThS3idLOU7j3eFG72t5458yA/ypko/CVOG9EQItQ3aTWtAnaVjpAL0XMBFc RVtS8VFzkZzU3vlIDnAWIEjmz2zBRrOvSSYWjAAdnF6YsCwV/kyyIks3+xXDTS5rIviQupaKv97yT BSZ5/jVWJmUOyFshZNHwobY6eYHKamM7Wrj2m7vdE1lrNEeo5LzhRd4xL6BkcF2tRqk8EQpwCjrB/ jxhn7CbHD1jY3FYNnP7CqomcGEvAuFc4bJ929jRjgb7kd0aNwH2Ax+ylhqS4e0yPsNZZeopdj3+7J v1AbBNiA==; Received: from hch by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkN70-0004Jt-2u; Wed, 02 Dec 2020 08:03:42 +0000 Date: Wed, 2 Dec 2020 08:03:42 +0000 From: Christoph Hellwig To: Linus Torvalds Cc: Eric Sandeen , Dave Chinner , "Darrick J. Wong" , Eric Sandeen , Miklos Szeredi , Ira Weiny , David Howells , linux-fsdevel , linux-man , Linux Kernel Mailing List , xfs , Ext4 Developers List , Xiaoli Feng Subject: Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to filesystems Message-ID: <20201202080342.GB15726@infradead.org> References: <05a0f4fd-7f62-8fbc-378d-886ccd5b3f11@redhat.com> <20201201173905.GI143045@magnolia> <20201201205243.GK2842436@dread.disaster.area> <9ab51770-1917-fc05-ff57-7677f17b6e44@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 01, 2020 at 02:12:19PM -0800, Linus Torvalds wrote: > On Tue, Dec 1, 2020 at 2:03 PM Eric Sandeen wrote: > > > > That's why I was keen to just add DAX unconditionally at this point, and if we want > > to invent/refine meanings for the mask, we can still try to do that? > > Oh Gods. Let's *not* make this some "random filesystem choice" where > now semantics depends on what some filesystem decided to do, and > different filesystems have very subtly different semantics. > > This all screams "please keep this in the VFS layer" so that we at > least have _one_ place where these kinds of decisions are made. > > I suspect very very few people actually end up caring about any of the > STATX flags at all, of course. The fact that the DAX one was > apparently entirely the wrong bit argues that this isn't all that > important. Agreed. That whole support interface is just weird. But the only thing that remotely makes (a little bit of) sense is to just set all bits known about by this particular kernel in the VFS. Everything else is going to be a complete mess.