Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp462850pxu; Tue, 1 Dec 2020 16:12:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJxvVGPqIbl+O3HgRjEPRaPW7kPMPm2NzbV2OIQkw67OE8OXmE46sT+qa8+xNwzDbTzVWUJB X-Received: by 2002:a17:907:2131:: with SMTP id qo17mr1887850ejb.546.1606867964151; Tue, 01 Dec 2020 16:12:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606867964; cv=none; d=google.com; s=arc-20160816; b=W2vIy//SE4MzSFHyVd3JQwk1qSP3Cw3fpTQt0ZMh6CFjqZbwx+gtAKW1weCCzEwy41 3BytxLLL/IGkgVveEr0cSiWD9sJexu4bDZ9uDXXSQv3kTi9LkEi9RlOXmpZW8ffUrkqJ l8NlxMHXhuo/cO3lsPGKSACwfe4bYYm16RF5IAY6hP/Cu5Zitt+cl8Auq+ILV5E3zmyI 8HA5l2botdtKk/ddUdUGGxOKLogFdI7ctzF7sKE2qKZtR2VjMGalqEE43YQJFUXaGmoX ogLj2WzD6iSW8e1BQzfM713FyWjr0IucIvajJfA7WhXox9pXLFKci/bI/p+UJVNYPF/C KLeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to; bh=hN6kXdZZKLMFf53NgzYX/N39KLwhkqhzdSXxVwFNEGA=; b=P8xEWL7Tf+dezMH01KQsuDjDuOdi5EY6VOLrRnadtmGq8M5TugUBAt9vhj+Vz/MhgL /e64YKzHg4z821AO9G2H3nhCjxzUJnZ4diT99rIQ2jll4ZUOl2NZZ2D5gpZ/ux6FzD4Q RFO2hgaifTfL9kpQjVfX9u9y+ktq2xCUXDQiEe1P+uyZ+3XTowy6xiVZPbuFIzueajml tgwMOkHyddgoxtR/f5RgxyOT+Dqj5qrOmrKLiK5eBIwfaC2vAMX4BJcwhQK/+ThddU8v T9kFmlMn73OeG6NkMpnm1rlvfBVS4G+vLdKUJUBhHia37wwHS5BIWRvo7eUXCup2IF6D /0qQ== 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 bl4si1091770ejb.79.2020.12.01.16.12.09; Tue, 01 Dec 2020 16:12:44 -0800 (PST) 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 S1727234AbgLBAMH (ORCPT + 99 others); Tue, 1 Dec 2020 19:12:07 -0500 Received: from sandeen.net ([63.231.237.45]:35898 "EHLO sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726011AbgLBAMG (ORCPT ); Tue, 1 Dec 2020 19:12:06 -0500 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 2799D146284; Tue, 1 Dec 2020 18:11:09 -0600 (CST) To: Linus Torvalds , David Howells Cc: Eric Sandeen , Miklos Szeredi , Ira Weiny , linux-fsdevel , linux-man , Linux Kernel Mailing List , xfs , Ext4 Developers List , Xiaoli Feng References: <05a0f4fd-7f62-8fbc-378d-886ccd5b3f11@redhat.com> <300456.1606856642@warthog.procyon.org.uk> From: Eric Sandeen Subject: Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to filesystems Message-ID: <421cb25d-ca52-0a08-e535-5f650dda8d93@sandeen.net> Date: Tue, 1 Dec 2020 18:11:24 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 12/1/20 4:09 PM, Linus Torvalds wrote: > So basically, the thing that argues against this patch is that it > seems to just duplicate things inside filesystems, when the VFS layter > already has the information. > > Now, if the VFS information was possibly stale or wrong, that woudl be > one thing. But then we'd have other and bigger problems elsewhere as > far as I can tell. > > IOW - make generic what can be made generic, and try to avoid having > filesystems do their own thing. > > [ Replace "filesystems" by "architectures" or whatever else, this is > obviously not a filesystem-specific rule in general. ] > > And don't get me wrong - I don't _hate_ the patch, and I don't care > _that_ deeply, but it just doesn't seem to make any sense to me. My > initial query was really about "what am I missing - can you please > flesh out the commit message because I don't understand what's wrong". Backing way up, my motivation was: Only the filesystem can appropriately set the statx->attributes_mask, so it has to be done there. Since that has to be done in the filesystem, set the actual attribute flag adjacent to it, as is done for ~every other flag. *shrug* In any case I resent the flag value clash fix on a separate thread as V2, hopefully that one is straightforward enough to go in. Thanks, -Eric