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.8 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 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 34275C8300F for ; Tue, 1 Dec 2020 20:05:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BDAAD20870 for ; Tue, 1 Dec 2020 20:05:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="f+XordXx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730573AbgLAUF5 (ORCPT ); Tue, 1 Dec 2020 15:05:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730553AbgLAUF5 (ORCPT ); Tue, 1 Dec 2020 15:05:57 -0500 Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C86CAC0613D6 for ; Tue, 1 Dec 2020 12:05:16 -0800 (PST) Received: by mail-lf1-x144.google.com with SMTP id v14so6961424lfo.3 for ; Tue, 01 Dec 2020 12:05:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HEphcGQwY2jeNYDME47hDdQV9bR2WcuThTyY8CTMagA=; b=f+XordXx1HtHQauAu4wnySGZ7GOsfsrQOPdsZpcQHvfL87zHN51ik0PwYfToHQidR0 PlZ/E4mqzBriHmbzSkQser0B1m99iGnRC3rEB7nXytmUcWTvmQp/DGH5GienWzwN/RKd ej/bdilwW2TBGDr+jCbzKtRZ0888o0ynwCvig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HEphcGQwY2jeNYDME47hDdQV9bR2WcuThTyY8CTMagA=; b=VGRtLB0S6/e2CoJ0D3F86FwLBwGygtg8dfJ4PhuAb7xX6ZhQj4Q36N6RCWbNVKy9ET KPNu7BRLabqNeLJTNTv/T3a54UGEhJ/fn0a6lt/FY8pH76H0SArvtbAWi/IZkEwMQu74 HRKQnW8sX2LbZIvF63KqsPH9BeDKqKkFxJl0zQ+/Yl9rMbBet0uyVYQ1HXhTKJtWq/IW TWY8jVA+5Wpr6X1k+3gpvTp0/tvgRCP0Wy2kuGnA0wRB2VCKbBo32HmQmFXdh9ntzoy2 K/5X+KRiNSzz1v/NTjrPe7IIL2IuANHAwdvIGtm/P59YPOezn3hMdag4SOdyX4z2vG4f 9wKQ== X-Gm-Message-State: AOAM533oS8Kr19jm8+NZHQ0QfPLmahFBSJzOjyDy8CYo99/18HBOuZGJ 6ezs918A6D8VO0y9NvHM+AljbRTdbOcAcw== X-Google-Smtp-Source: ABdhPJxLZG4feQQtBAYAIp/ku7wQwO4KlrhEatYialHWvo/prWavbxSBg3jfkhAZ085f2WlvLrGUsQ== X-Received: by 2002:a19:8883:: with SMTP id k125mr1927962lfd.10.1606853114434; Tue, 01 Dec 2020 12:05:14 -0800 (PST) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id o26sm71932ljj.93.2020.12.01.12.05.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Dec 2020 12:05:14 -0800 (PST) Received: by mail-lf1-f54.google.com with SMTP id u19so6919331lfr.7 for ; Tue, 01 Dec 2020 12:05:13 -0800 (PST) X-Received: by 2002:a19:5003:: with SMTP id e3mr1997442lfb.148.1606853112635; Tue, 01 Dec 2020 12:05:12 -0800 (PST) MIME-Version: 1.0 References: <05a0f4fd-7f62-8fbc-378d-886ccd5b3f11@redhat.com> In-Reply-To: <05a0f4fd-7f62-8fbc-378d-886ccd5b3f11@redhat.com> From: Linus Torvalds Date: Tue, 1 Dec 2020 12:04:56 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to filesystems To: Eric Sandeen Cc: Miklos Szeredi , Ira Weiny , David Howells , linux-fsdevel , linux-man , Linux Kernel Mailing List , xfs , Ext4 Developers List , Xiaoli Feng Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, Dec 1, 2020 at 8:59 AM Eric Sandeen wrote: > > It's a bit odd to set STATX_ATTR_DAX into the statx attributes in the VFS; > while the VFS can detect the current DAX state, it is the filesystem which > actually sets S_DAX on the inode, and the filesystem is the place that > knows whether DAX is something that the "filesystem actually supports" [1] > so that the statx attributes_mask can be properly set. > > So, move STATX_ATTR_DAX attribute setting to the individual dax-capable > filesystems, and update the attributes_mask there as well. I'm not really understanding the logic behind this. The whole IS_DAX(inode) thing exists in various places outside the low-level filesystem, why shouldn't stat() do this? If IS_DAX() is incorrect, then we have much bigger problems than some stat results. We have core functions like generic_file_read_iter() etc all making actual behavioral judgements on IS_DAX(). And if IS_DAX() is correct, then why shouldn't this just be done in generic code? Why move it to every individual filesystem? Linus