linux-ext4 - Re: [PATCH 00/13] fs/dax: Fix FS DAX page reference counts

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: <667dca6259bc8_57ac2946e@dwillia2-xfh.jf.intel.com.notmuch>
Date: Thu, 27 Jun 2024 13:24:02 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Alistair Popple <apopple@...dia.com>, Dan Williams
	<dan.j.williams@...el.com>
CC: <vishal.l.verma@...el.com>, <dave.jiang@...el.com>, <logang@...tatee.com>,
	<bhelgaas@...gle.com>, <jack@...e.cz>, <jgg@...pe.ca>,
	<catalin.marinas@....com>, <will@...nel.org>, <mpe@...erman.id.au>,
	<npiggin@...il.com>, <dave.hansen@...ux.intel.com>, <ira.weiny@...el.com>,
	<willy@...radead.org>, <djwong@...nel.org>, <tytso@....edu>,
	<linmiaohe@...wei.com>, <david@...hat.com>, <peterx@...hat.com>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linuxppc-dev@...ts.ozlabs.org>,
	<nvdimm@...ts.linux.dev>, <linux-cxl@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>, <linux-mm@...ck.org>,
	<linux-ext4@...r.kernel.org>, <linux-xfs@...r.kernel.org>,
	<jhubbard@...dia.com>, <hch@....de>, <david@...morbit.com>
Subject: Re: [PATCH 00/13] fs/dax: Fix FS DAX page reference counts

Alistair Popple wrote:
> 
> Dan Williams <dan.j.williams@...el.com> writes:
> 
> > Alistair Popple wrote:
> >> FS DAX pages have always maintained their own page reference counts
> >> without following the normal rules for page reference counting. In
> >> particular pages are considered free when the refcount hits one rather
> >> than zero and refcounts are not added when mapping the page.
> >> 
> >> Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary
> >> mechanism for allowing GUP to hold references on the page (see
> >> get_dev_pagemap). However there doesn't seem to be any reason why FS
> >> DAX pages need their own reference counting scheme.
> >> 
> >> By treating the refcounts on these pages the same way as normal pages
> >> we can remove a lot of special checks. In particular pXd_trans_huge()
> >> becomes the same as pXd_leaf(), although I haven't made that change
> >> here. It also frees up a valuable SW define PTE bit on architectures
> >> that have devmap PTE bits defined.
> >> 
> >> It also almost certainly allows further clean-up of the devmap managed
> >> functions, but I have left that as a future improvment.
> >> 
> >> This is an update to the original RFC rebased onto v6.10-rc5. Unlike
> >> the original RFC it passes the same number of ndctl test suite
> >> (https://github.com/pmem/ndctl) tests as my current development
> >> environment does without these patches.
> >
> > Are you seeing the 'mmap.sh' test fail even without these patches?
> 
> No. But I also don't see it failing with these patches :)
> 
> For reference this is what I see on my test machine with or without:
> 
> [1/70] Generating version.h with a custom command
>  1/13 ndctl:dax / daxdev-errors.sh          SKIP             0.06s   exit status 77
>  2/13 ndctl:dax / multi-dax.sh              SKIP             0.05s   exit status 77
>  3/13 ndctl:dax / sub-section.sh            SKIP             0.14s   exit status 77

I really need to get this test built as a service as this shows a
pre-req is missing, and it's not quite fair to expect submitters to put
it all together.

>  4/13 ndctl:dax / dax-dev                   OK               0.02s
>  5/13 ndctl:dax / dax-ext4.sh               OK              12.97s
>  6/13 ndctl:dax / dax-xfs.sh                OK              12.44s
>  7/13 ndctl:dax / device-dax                OK              13.40s
>  8/13 ndctl:dax / revoke-devmem             FAIL             0.31s   (exit status 250 or signal 122 SIGinvalid)
> >>> TEST_PATH=/home/apopple/ndctl/build/test LD_LIBRARY_PATH=/home/apopple/ndctl/build/cxl/lib:/home/apopple/ndctl/build/daxctl/lib:/home/apopple/ndctl/build/ndctl/lib NDCTL=/home/apopple/ndctl/build/ndctl/ndctl MALLOC_PERTURB_=227 DATA_PATH=/home/apopple/ndctl/test DAXCTL=/home/apopple/ndctl/build/daxctl/daxctl /home/apopple/ndctl/build/test/revoke_devmem
> 
>  9/13 ndctl:dax / device-dax-fio.sh         OK              32.43s
> 10/13 ndctl:dax / daxctl-devices.sh         SKIP             0.07s   exit status 77
> 11/13 ndctl:dax / daxctl-create.sh          SKIP             0.04s   exit status 77
> 12/13 ndctl:dax / dm.sh                     FAIL             0.08s   exit status 1
> >>> MALLOC_PERTURB_=209 TEST_PATH=/home/apopple/ndctl/build/test LD_LIBRARY_PATH=/home/apopple/ndctl/build/cxl/lib:/home/apopple/ndctl/build/daxctl/lib:/home/apopple/ndctl/build/ndctl/lib NDCTL=/home/apopple/ndctl/build/ndctl/ndctl DATA_PATH=/home/apopple/ndctl/test DAXCTL=/home/apopple/ndctl/build/daxctl/daxctl /home/apopple/ndctl/test/dm.sh
> 
> 13/13 ndctl:dax / mmap.sh                   OK             107.57s

I need to think through why this one might false succeed, but that can
wait until we get this series reviewed. For now my failure is stable
which allows it to be bisected.

> 
> Ok:                 6   
> Expected Fail:      0   
> Fail:               2   
> Unexpected Pass:    0   
> Skipped:            5   
> Timeout:            0   
> 
> I have been using QEMU for my testing. Maybe I missed some condition in
> the unmap path though so will take another look.

I was able to bisect to:

[PATCH 10/13] fs/dax: Properly refcount fs dax pages

...I will prioritize that one in my review queue.