2020-12-03 08:18:33

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH] common/rc: Fix _check_s_dax()

On Wed, Dec 02, 2020 at 01:41:45PM -0800, [email protected] wrote:
> From: Ira Weiny <[email protected]>
>
> There is a conflict with the user visible statx bits 'mount root' and
> 'dax'. The kernel is changing the dax bit to correct this conflict.[1]
>
> Adjust _check_s_dax() to use the new bit. Because DAX tests do not run
> on root mounts, STATX_ATTR_MOUNT_ROOT should always be 0, therefore we
> can allow either bit to indicate DAX and cover any kernel which may be
> running.
>
> [1] https://lore.kernel.org/lkml/[email protected]/
>
> Signed-off-by: Ira Weiny <[email protected]>
> ---
>
> I went ahead and used Christoph's suggestion regarding using both bits.

That wasn't my suggestion. I think we should always error out when
the bit value shared with STATX_ATTR_MOUNT_ROOT is seen. Because that
means the kernel is not using or fixed ABI we agreed to use going
forward.


2020-12-03 17:58:31

by Eric Sandeen

[permalink] [raw]
Subject: Re: [PATCH] common/rc: Fix _check_s_dax()



On 12/3/20 2:15 AM, Christoph Hellwig wrote:
> On Wed, Dec 02, 2020 at 01:41:45PM -0800, [email protected] wrote:
>> From: Ira Weiny <[email protected]>
>>
>> There is a conflict with the user visible statx bits 'mount root' and
>> 'dax'. The kernel is changing the dax bit to correct this conflict.[1]
>>
>> Adjust _check_s_dax() to use the new bit. Because DAX tests do not run
>> on root mounts, STATX_ATTR_MOUNT_ROOT should always be 0, therefore we
>> can allow either bit to indicate DAX and cover any kernel which may be
>> running.
>>
>> [1] https://lore.kernel.org/lkml/[email protected]/
>>
>> Signed-off-by: Ira Weiny <[email protected]>
>> ---
>>
>> I went ahead and used Christoph's suggestion regarding using both bits.
>
> That wasn't my suggestion. I think we should always error out when
> the bit value shared with STATX_ATTR_MOUNT_ROOT is seen. Because that
> means the kernel is not using or fixed ABI we agreed to use going
> forward.

*nod* and my suggestion was to explicitly test for the old/wrong value and
offer the test-runner a hint about why it may have been set (missing the
fix commit), but we should still ultimately fail the test when it is seen.

-Eric