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]
Date: Thu, 11 Apr 2024 10:56:35 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>, Dan Williams <dan.j.williams@...el.com>
CC: Alistair Popple <apopple@...dia.com>, <linux-mm@...ck.org>,
	<david@...morbit.com>, <jhubbard@...dia.com>, <rcampbell@...dia.com>,
	<willy@...radead.org>, <linux-fsdevel@...r.kernel.org>, <jack@...e.cz>,
	<djwong@...nel.org>, <hch@....de>, <david@...hat.com>,
	<ruansy.fnst@...itsu.com>, <nvdimm@...ts.linux.dev>,
	<linux-xfs@...r.kernel.org>, <linux-ext4@...r.kernel.org>,
	<jglisse@...hat.com>
Subject: Re: [RFC 00/10] fs/dax: Fix FS DAX page reference counts

Jason Gunthorpe wrote:
> On Thu, Apr 11, 2024 at 10:28:56AM -0700, Dan Williams wrote:
> > 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.
> > 
> > This is fair. However, for anyone coming in fresh to this situation
> > maybe some more "how we get here" history helps. That longer story is
> > here:
> > 
> > http://lore.kernel.org/all/166579181584.2236710.17813547487183983273.stgit@dwillia2-xfh.jf.intel.com/
> 
> This never got merged? :(

Yeah... I got hung up on the "allocation" API to take ZONE_DEVICE pages
from recfount 0 to 1 and then never circled back.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ