linux-kernel - Re: [PATCH v2] nd_blk: add support for "read flush" DSM flag

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, 20 Aug 2015 10:08:06 -0600
From:	Ross Zwisler <ross.zwisler@...ux.intel.com>
To:	Will Deacon <will.deacon@....com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Borislav Petkov <bp@...e.de>, Christoph Hellwig <hch@....de>,
	Christoph Jaeger <cj@...ux.com>,
	Dan Streetman <ddstreet@...e.org>,
	Dan Williams <dan.j.williams@...el.com>,
	Ingo Molnar <mingo@...hat.com>,
	Juergen Gross <jgross@...e.com>, Len Brown <lenb@...nel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Thierry Reding <treding@...dia.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Toshi Kani <toshi.kani@...com>,
	Vishal Verma <vishal.l.verma@...el.com>,
	Yalin Wang <Yalin.Wang@...ymobile.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-nvdimm@...1.01.org" <linux-nvdimm@...1.01.org>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v2] nd_blk: add support for "read flush" DSM flag

On Thu, 2015-08-20 at 11:21 +0100, Will Deacon wrote:
> On Wed, Aug 19, 2015 at 11:48:04PM +0100, Ross Zwisler wrote:
> > Add support for the "read flush" _DSM flag, as outlined in the DSM spec:
> > 
> > http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
> > 
> > This flag tells the ND BLK driver that it needs to flush the cache lines
> > associated with the aperture after the aperture is moved but before any
> > new data is read.  This ensures that any stale cache lines from the
> > previous contents of the aperture will be discarded from the processor
> > cache, and the new data will be read properly from the DIMM.  We know
> > that the cache lines are clean and will be discarded without any
> > writeback because either a) the previous aperture operation was a read,
> > and we never modified the contents of the aperture, or b) the previous
> > aperture operation was a write and we must have written back the dirtied
> > contents of the aperture to the DIMM before the I/O was completed.
> 
> Is this operation expected to be implemented as a destructive invalidation
> (i.e. discarding any dirty lines from the cache) or also a writeback of any
> dirtylines as part of the invalidation?
> 
> If its the former, we might want to give it a scarier name to ensure that
> it doesn't grow users outside of NVDIMM scenarios, since "flush" is used
> elsewhere for things like flush_dcache_page.

It is the latter - there will be a writeback of any dirty lines as part of the
invalidation.  The real thing I'm looking for is a forced invalidation
(including writeback, if needed), even on architectures that are cache
coherent.  This is useful when the device can change the data at that memory
location, but not as part of a normal DMA operation that would keep the cache
coherent.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/