linux-kernel - Re: [PATCH] xfs: fail dax mount if reflink is enabled on a partition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <384341d2-876d-2e61-d791-bad784d3add4@fujitsu.com>
Date:   Wed, 2 Nov 2022 05:17:18 +0000
From:   "ruansy.fnst@...itsu.com" <ruansy.fnst@...itsu.com>
To:     "Darrick J. Wong" <djwong@...nel.org>,
        Dave Chinner <david@...morbit.com>
CC:     Dan Williams <dan.j.williams@...el.com>,
        "yangx.jy@...itsu.com" <yangx.jy@...itsu.com>,
        "Yasunori Gotou (Fujitsu)" <y-goto@...itsu.com>,
        Brian Foster <bfoster@...hat.com>,
        "hch@...radead.org" <hch@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-xfs@...r.kernel.org" <linux-xfs@...r.kernel.org>,
        "nvdimm@...ts.linux.dev" <nvdimm@...ts.linux.dev>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "zwisler@...nel.org" <zwisler@...nel.org>,
        Jeff Moyer <jmoyer@...hat.com>,
        "dm-devel@...hat.com" <dm-devel@...hat.com>,
        "toshi.kani@....com" <toshi.kani@....com>,
        Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH] xfs: fail dax mount if reflink is enabled on a partition


在 2022/11/2 8:45, Darrick J. Wong 写道:
> On Sun, Oct 30, 2022 at 05:31:43PM +0800, Shiyang Ruan wrote:
>>
>>
>> 在 2022/10/28 9:37, Dan Williams 写道:
>>> Darrick J. Wong wrote:
>>>> [add tytso to cc since he asked about "How do you actually /get/ fsdax
>>>> mode these days?" this morning]
>>>>
>>>> On Tue, Oct 25, 2022 at 10:56:19AM -0700, Darrick J. Wong wrote:
>>>>> On Tue, Oct 25, 2022 at 02:26:50PM +0000, ruansy.fnst@...itsu.com wrote:
>>
>> ...skip...
>>
>>>>>
>>>>> Nope.  Since the announcement of pmem as a product, I have had 15
>>>>> minutes of acces to one preproduction prototype server with actual
>>>>> optane DIMMs in them.
>>>>>
>>>>> I have /never/ had access to real hardware to test any of this, so it's
>>>>> all configured via libvirt to simulate pmem in qemu:
>>>>> https://lore.kernel.org/linux-xfs/YzXsavOWMSuwTBEC@magnolia/
>>>>>
>>>>> /run/mtrdisk/[gh].mem are both regular files on a tmpfs filesystem:
>>>>>
>>>>> $ grep mtrdisk /proc/mounts
>>>>> none /run/mtrdisk tmpfs rw,relatime,size=82894848k,inode64 0 0
>>>>>
>>>>> $ ls -la /run/mtrdisk/[gh].mem
>>>>> -rw-r--r-- 1 libvirt-qemu kvm 10739515392 Oct 24 18:09 /run/mtrdisk/g.mem
>>>>> -rw-r--r-- 1 libvirt-qemu kvm 10739515392 Oct 24 19:28 /run/mtrdisk/h.mem
>>>>
>>>> Also forgot to mention that the VM with the fake pmem attached has a
>>>> script to do:
>>>>
>>>> ndctl create-namespace --mode fsdax --map dev -e namespace0.0 -f
>>>> ndctl create-namespace --mode fsdax --map dev -e namespace1.0 -f
>>>>
>>>> Every time the pmem device gets recreated, because apparently that's the
>>>> only way to get S_DAX mode nowadays?
>>>
>>> If you have noticed a change here it is due to VM configuration not
>>> anything in the driver.
>>>
>>> If you are interested there are two ways to get pmem declared the legacy
>>> way that predates any of the DAX work, the kernel calls it E820_PRAM,
>>> and the modern way by platform firmware tables like ACPI NFIT. The
>>> assumption with E820_PRAM is that it is dealing with battery backed
>>> NVDIMMs of small capacity. In that case the /dev/pmem device can support
>>> DAX operation by default because the necessary memory for the 'struct
>>> page' array for that memory is likely small.
>>>
>>> Platform firmware defined PMEM can be terabytes. So the driver does not
>>> enable DAX by default because the user needs to make policy choice about
>>> burning gigabytes of DRAM for that metadata, or placing it in PMEM which
>>> is abundant, but slower. So what I suspect might be happening is your
>>> configuration changed from something that auto-allocated the 'struct
>>> page' array, to something that needed those commands you list above to
>>> explicitly opt-in to reserving some PMEM capacity for the page metadata.
>>
>> I am using the same simulation environment as Darrick's and Dave's and have
>> tested many times, but still cannot reproduce the failed cases they
>> mentioned (dax+non_reflink mode, currently focuing) until now. Only a few
>> cases randomly failed because of "target is busy". But IIRC, those failed
>> cases you mentioned were failed with dmesg warning around the function
>> "dax_associate_entry()" or "dax_disassociate_entry()". Since I cannot
>> reproduce the failure, it hard for me to continue sovling the problem.
> 
> FWIW things have calmed down as of 6.1-rc3 -- if I disable reflink,
> fstests runs without complaint.  Now it only seems to be affecting
> reflink=1 filesystems. >
>> And how is your recent test?  Still failed with those dmesg warnings? If so,
>> could you zip the test result and send it to me?
> 
> https://djwong.org/docs/kernel/daxbad.zip

Thanks for your info!


(To Dave) I need your recent test result too.  If cases won't fail when 
reflink disabled, I'll focusing on solving the warning when reflink enabled.


--
Thanks,
Ruan.

> 
> --D
> 
>>
>>
>> --
>> Thanks,
>> Ruan