Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1026523pxu; Wed, 2 Dec 2020 09:12:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJzjfiI+bD7op4JjBDzwEiyzdI+MSv7hFrhyK1Bpq1J6B408PNkAf9CBrdAb25mfRfPQ+U8C X-Received: by 2002:a50:8a8b:: with SMTP id j11mr949023edj.19.1606929160463; Wed, 02 Dec 2020 09:12:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606929160; cv=none; d=google.com; s=arc-20160816; b=u1IFJjHmpMQEQ65aKe86ByDAOVEGtP2rqvimHkoHgj2WDDL1L6zZZBkoHZz53RM6hc /sIOr+25yxs1SqHSxs1d3HujUv+CI8crHQWGhKfPGaP9PdLbqZZnLWcMycUPGkvHEhli lIlxLtEwGwR4ny+w2s08W946DWYJQ4GpDnsYxfqEmxJkEBtBadboW8srmr1eB/bP+qJJ Mwu9l9Cx7cokU0sPXuFK71B//B9uJnipl2FUZ5R2tIhWRhItJNzseym6J5Axf7Dq8rO7 FR4pJsCRh7ZSFS13z6/74R8cY2lJp9qlD6YOsGN+6CV8MVm9K4oBLe+4lVID7TS+8p5r WqKg== 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=OOE7GPO+wlJVaxwonKgGl4Lm29tGrBu8Wvm3PP4lG0U=; b=p/6jmm/XSJwuiZQN62H4DAzfCSpw6Rk7WfD8i8jPSmHaKkkLwXsc64JpG6yNCd7nDL 5slZnJXOsQxbyscdPR2tLIE8c0C9CJ1T65CZw2wC2hH6lk8Uru0weMCqY4mlf9e1nTvi rzCWTZd34VWbvxvDGKuyRefFUGKV9LjxqifQ/21VFgo6Qkace7eJVULXbWkMOtEkZspg 6u2QSYJ1OE+VUbOQOeK4BaRm/10XaI+SxMQa2dgddfKmmIaxjUkSZEkU0a9QhcqXMOOh Ubn7AIuQkyBm/VEWrnCQTtat8fuuoFFDeLNi9Um/ZHdxp4j9acoSzvvQiCBY4Z+5dAwd sumg== 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 e14si295440ejr.169.2020.12.02.09.12.10; Wed, 02 Dec 2020 09:12:40 -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 S2387464AbgLBRLd (ORCPT + 99 others); Wed, 2 Dec 2020 12:11:33 -0500 Received: from sandeen.net ([63.231.237.45]:56874 "EHLO sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728380AbgLBRLc (ORCPT ); Wed, 2 Dec 2020 12:11:32 -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 1EAB1146296; Wed, 2 Dec 2020 11:10:34 -0600 (CST) To: ira.weiny@intel.com, fstests@vger.kernel.org Cc: linux-kernel@vger.kernel.org, "Darrick J. Wong" , Dan Williams , Dave Chinner , Christoph Hellwig , "Theodore Y. Ts'o" , Jan Kara , Jeff Moyer , linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, Eric Sandeen , David Howells References: <20201202160701.1458658-1-ira.weiny@intel.com> From: Eric Sandeen Subject: Re: [RFC PATCH] common/rc: Fix _check_s_dax() for kernel 5.10 Message-ID: Date: Wed, 2 Dec 2020 11:10:50 -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: <20201202160701.1458658-1-ira.weiny@intel.com> 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/2/20 10:07 AM, ira.weiny@intel.com wrote: > From: Ira Weiny > > There is a conflict with the user visible statx bits 'mount root' and > 'dax'. The kernel is shifting the dax bit.[1] > > Adjust _check_s_dax() to use the new bit. > > [1] https://lore.kernel.org/lkml/3e28d2c7-fbe5-298a-13ba-dcd8fd504666@redhat.com/ > > Signed-off-by: Ira Weiny > > --- > > I'm not seeing an easy way to check for kernel version. It seems like that is > the right thing to do. So do I need to do that by hand or is that something > xfstests does not worry about? xfstests gets used on distro kernels too, so relying on kernel version isn't really something we can use to make determinations like this, unfortunately. Probably the best we can do is hope that the change makes it to stable and distro kernels quickly, and the old flag fades into obscurity. Maybe worth a comment in the test mentioning the SNAFU, though, for anyone investigating it when it fails on older kernels? > Ira > > --- > common/rc | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/common/rc b/common/rc > index b5a504e0dcb4..3d45e233954f 100644 > --- a/common/rc > +++ b/common/rc > @@ -3222,9 +3222,9 @@ _check_s_dax() > > local attributes=$($XFS_IO_PROG -c 'statx -r' $target | awk '/stat.attributes / { print $3 }') > if [ $exp_s_dax -eq 0 ]; then > - (( attributes & 0x2000 )) && echo "$target has unexpected S_DAX flag" > + (( attributes & 0x00200000 )) && echo "$target has unexpected S_DAX flag" > else > - (( attributes & 0x2000 )) || echo "$target doesn't have expected S_DAX flag" > + (( attributes & 0x00200000 )) || echo "$target doesn't have expected S_DAX flag" I suppose you could add a test for 0x2000 in this failure case, and echo "Is your kernel missing commit xxxxxx?" as another hint. -Eric > fi > } > >