linux-kernel - dax alignment problem on arm64 (and other achitectures)

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] [day] [month] [year] [list]

Date: Wed, 26 Jun 2024 00:20:38 -0700
From: Shyam Saini <shyamsaini@...ux.microsoft.com>
To: dan.j.williams@...el.com
Cc: akpm@...ux-foundation.org,
	david@...hat.com,
	iamjoonsoo.kim@....com,
	james.morse@....com,
	jgg@...pe.ca,
	jmorris@...ei.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	maz@...nel.org,
	mhocko@...e.com,
	osalvador@...e.de,
	pasha.tatashin@...een.com,
	sashal@...nel.org,
	tyhicks@...ux.microsoft.com,
	vbabka@...e.cz,
	will.deacon@....com,
	code@...icks.com,
	srivatsa@...il.mit.edu,
	apais@...ux.microsoft.com,
	vijayb@...ux.microsoft.com,
	tballasi@...ux.microsoft.com,
	bboscaccy@...ux.microsoft.com
Subject: dax alignment problem on arm64 (and other achitectures)

Hi Dan,

Restarting this thread to get more insights about dax alignment problem.
So having a devdax pmem of size 128M is [1] not usable and entire memory
is wasted? For 256M size devdax pmem, again 126M seems to be wasted and
only 128M can be hot added/removed. This was observed on ARM64 platform.

do we have any potential or existing solution for this problem ?

> >
> > > Since we last talked about this the enabling for EFI "Special Purpose"
> > > / Soft Reserved Memory has gone upstream and instantiates device-dax
> > > instances for address ranges marked with EFI_MEMORY_SP attribute.
> > > Critically this way of declaring device-dax removes the consideration
> > > of it as persistent memory and as such no metadata reservation. So, if
> > > you are willing to maintain the metadata external to the device (which
> > > seems reasonable for your environment) and have your platform firmware
> > > / kernel command line mark it as EFI_CONVENTIONAL_MEMORY +
> > > EFI_MEMORY_SP, then these reserve-free dax-devices will surface.
> >
> > Hi Dan,
> >
> > This is cool. Does it allow conversion between devdax and fsdax so DAX
> > aware filesystem can be installed and data can be put there to be
> > preserved across the reboot?
> >
> 
> It does not because it's not "pmem" by this designation.
> 
> Instead if you want fsdax, zero metadata on the device, and the
> ability to switch from fsdax to devdax I think that could be achieved
> with a new sysfs attribute at the region-device level. Currently the
> mode of a namespace with no metadata on it defaults to "raw" mode
> where "raw" treats the pmem as a persistent memory block device with
> no DAX capability. There's no reason the default could instead be
> devdax with pages mapped.
> 
> Something like:
> ndctl disable-region region0
> echo 1 > /sys/bus/nd/devices/region0/pagemap
> echo devdax > /sys/bus/nd/devices/region0/raw_default

this interface file seems to be not available

can we use sub-section hotplug feature here, there aren't much details available
about using that, is it via sysfs ?

I appreciate your help and guidance on this.

Thanks,
Shyam

[1] https://elixir.bootlin.com/linux/v6.10-rc5/source/drivers/dax/kmem.c#L102