| 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
| ||
|
Message-ID: <gqwlb6ept22edcuiwwzxkboeioin6l4afemn3lenbduuwbb357@tnkceo5764vf>
Date: Thu, 8 Jan 2026 09:59:08 -0600
From: John Groves <John@...ves.net>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: Miklos Szeredi <miklos@...redi.hu>,
Dan Williams <dan.j.williams@...el.com>, Bernd Schubert <bschubert@....com>,
Alison Schofield <alison.schofield@...el.com>, John Groves <jgroves@...ron.com>,
Jonathan Corbet <corbet@....net>, Vishal Verma <vishal.l.verma@...el.com>,
Dave Jiang <dave.jiang@...el.com>, Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>,
Alexander Viro <viro@...iv.linux.org.uk>, David Hildenbrand <david@...nel.org>,
Christian Brauner <brauner@...nel.org>, "Darrick J . Wong" <djwong@...nel.org>,
Randy Dunlap <rdunlap@...radead.org>, Jeff Layton <jlayton@...nel.org>,
Amir Goldstein <amir73il@...il.com>, Stefan Hajnoczi <shajnocz@...hat.com>,
Joanne Koong <joannelkoong@...il.com>, Josef Bacik <josef@...icpanda.com>,
Bagas Sanjaya <bagasdotme@...il.com>, Chen Linxuan <chenlinxuan@...ontech.com>,
James Morse <james.morse@....com>, Fuad Tabba <tabba@...gle.com>,
Sean Christopherson <seanjc@...gle.com>, Shivank Garg <shivankg@....com>,
Ackerley Tng <ackerleytng@...gle.com>, Gregory Price <gourry@...rry.net>,
Aravind Ramesh <arramesh@...ron.com>, Ajay Joshi <ajayjoshi@...ron.com>, venkataravis@...ron.com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, nvdimm@...ts.linux.dev,
linux-cxl@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH V3 04/21] dax: Add dax_operations for use by fs-dax on
fsdev dax
On 26/01/08 11:50AM, Jonathan Cameron wrote:
> On Wed, 7 Jan 2026 09:33:13 -0600
> John Groves <John@...ves.net> wrote:
>
> > From: John Groves <John@...ves.net>
> >
> Hi John
>
> The description should generally make sense without the title.
> Sometimes that means more or less repeating the title.
>
> A few other things inline.
Will do
>
> > * These methods are based on pmem_dax_ops from drivers/nvdimm/pmem.c
> > * fsdev_dax_direct_access() returns the hpa, pfn and kva. The kva was
> > newly stored as dev_dax->virt_addr by dev_dax_probe().
> > * The hpa/pfn are used for mmap (dax_iomap_fault()), and the kva is used
> > for read/write (dax_iomap_rw())
> > * fsdev_dax_recovery_write() and dev_dax_zero_page_range() have not been
> > tested yet. I'm looking for suggestions as to how to test those.
> > * dax-private.h: add dev_dax->cached_size, which fsdev needs to
> > remember. The dev_dax size cannot change while a driver is bound
> > (dev_dax_resize returns -EBUSY if dev->driver is set). Caching the size
> > at probe time allows fsdev's direct_access path can use it without
> > acquiring dax_dev_rwsem (which isn't exported anyway).
> >
> > Signed-off-by: John Groves <john@...ves.net>
>
> > diff --git a/drivers/dax/fsdev.c b/drivers/dax/fsdev.c
> > index c5c660b193e5..9e2f83aa2584 100644
> > --- a/drivers/dax/fsdev.c
> > +++ b/drivers/dax/fsdev.c
> > @@ -27,6 +27,81 @@
> > * - No mmap support - all access is through fs-dax/iomap
> > */
> >
> > +static void fsdev_write_dax(void *pmem_addr, struct page *page,
> > + unsigned int off, unsigned int len)
> > +{
> > + while (len) {
> > + void *mem = kmap_local_page(page);
>
> I guess it's pretty simple, but do we care about HIGHMEM for this
> new feature? Maybe it's just easier to support it than argue about it however ;)
I think this compiles to zero overhead, and is an established pattern -
but I'm ok following a consensus elsewhere...
>
> > + unsigned int chunk = min_t(unsigned int, len, PAGE_SIZE - off);
> > +
> > + memcpy_flushcache(pmem_addr, mem + off, chunk);
> > + kunmap_local(mem);
> > + len -= chunk;
> > + off = 0;
> > + page++;
> > + pmem_addr += chunk;
> > + }
> > +}
> > +
> > +static long __fsdev_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
> > + long nr_pages, enum dax_access_mode mode, void **kaddr,
> > + unsigned long *pfn)
> > +{
> > + struct dev_dax *dev_dax = dax_get_private(dax_dev);
> > + size_t size = nr_pages << PAGE_SHIFT;
> > + size_t offset = pgoff << PAGE_SHIFT;
> > + void *virt_addr = dev_dax->virt_addr + offset;
> > + phys_addr_t phys;
> > + unsigned long local_pfn;
> > +
> > + WARN_ON(!dev_dax->virt_addr);
> > +
> > + phys = dax_pgoff_to_phys(dev_dax, pgoff, nr_pages << PAGE_SHIFT);
>
> Use size given you already computed it.
Not sure I follow. nr_pages is the size of the access or fault, not the size
of the device.
>
> > +
> > + if (kaddr)
> > + *kaddr = virt_addr;
> > +
> > + local_pfn = PHYS_PFN(phys);
> > + if (pfn)
> > + *pfn = local_pfn;
> > +
> > + /*
> > + * Use cached_size which was computed at probe time. The size cannot
> > + * change while the driver is bound (resize returns -EBUSY).
> > + */
> > + return PHYS_PFN(min_t(size_t, size, dev_dax->cached_size - offset));
>
> Is the min_t() needed? min() is pretty good at picking right types these days.
Changed to min()
>
> > +}
> > +
> > +static int fsdev_dax_zero_page_range(struct dax_device *dax_dev,
> > + pgoff_t pgoff, size_t nr_pages)
> > +{
> > + void *kaddr;
> > +
> > + WARN_ONCE(nr_pages > 1, "%s: nr_pages > 1\n", __func__);
> > + __fsdev_dax_direct_access(dax_dev, pgoff, 1, DAX_ACCESS, &kaddr, NULL);
> > + fsdev_write_dax(kaddr, ZERO_PAGE(0), 0, PAGE_SIZE);
> > + return 0;
> > +}
> > +
> > +static long fsdev_dax_direct_access(struct dax_device *dax_dev,
> > + pgoff_t pgoff, long nr_pages, enum dax_access_mode mode,
> > + void **kaddr, unsigned long *pfn)
> > +{
> > + return __fsdev_dax_direct_access(dax_dev, pgoff, nr_pages, mode,
> > + kaddr, pfn);
>
> Alignment in this file is a bit random, but I'd at least align this one
> after the (
Done, thanks!
John
Powered by blists - more mailing lists