linux-kernel - Re: [PATCH 29/31] parisc: handle page-less SG entries

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]

Message-ID: <CAPcyv4idztwrtr5wBQkiTSNT8L3HWf8zk9webheQAmunLD7cBw@mail.gmail.com>
Date:	Fri, 14 Aug 2015 09:17:45 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	David Miller <davem@...emloft.net>
Cc:	Jej B <James.Bottomley@...senpartnership.com>,
	Christoph Hellwig <hch@....de>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	linux-mips@...ux-mips.org, linux-ia64@...r.kernel.org,
	linux-nvdimm <linux-nvdimm@...1.01.org>, dhowells@...hat.com,
	sparclinux@...r.kernel.org, egtvedt@...fundet.no,
	linux-arch@...r.kernel.org, linux-s390@...r.kernel.org,
	X86 ML <x86@...nel.org>, David Woodhouse <dwmw2@...radead.org>,
	hskinnemoen@...il.com, linux-xtensa@...ux-xtensa.org,
	grundler@...isc-linux.org, realmz6@...il.com,
	alex.williamson@...hat.com, linux-metag@...r.kernel.org,
	Jens Axboe <axboe@...nel.dk>, Michal Simek <monstr@...str.eu>,
	linux-parisc@...r.kernel.org, vgupta@...opsys.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-alpha@...r.kernel.org, linux-media@...r.kernel.org,
	linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH 29/31] parisc: handle page-less SG entries

On Thu, Aug 13, 2015 at 9:11 PM, David Miller <davem@...emloft.net> wrote:
> From: James Bottomley <James.Bottomley@...senPartnership.com>
>> At least on some PA architectures, you have to be very careful.
>> Improperly managed, multiple aliases will cause the system to crash
>> (actually a machine check in the cache chequerboard). For the most
>> temperamental systems, we need the cache line flushed and the alias
>> mapping ejected from the TLB cache before we access the same page at an
>> inequivalent alias.
>
> Also, I want to mention that on sparc64 we manage the cache aliasing
> state in the page struct.
>
> Until a page is mapped into userspace, we just record the most recent
> cpu to store into that page with kernel side mappings.  Once the page
> ends up being mapped or the cpu doing kernel side stores changes, we
> actually perform the cache flush.
>
> Generally speaking, I think that all actual physical memory the kernel
> operates on should have a struct page backing it.  So this whole
> discussion of operating on physical memory in scatter lists without
> backing page structs feels really foreign to me.

So the only way for page-less pfns to enter the system is through the
->direct_access() method provided by a pmem device's struct
block_device_operations.  Architectures that require struct page for
cache management to must disable ->direct_access() in this case.

If an arch still wants to support pmem+DAX then it needs something
like this patchset (feedback welcome) to map pmem pfns:

https://lkml.org/lkml/2015/8/12/970

Effectively this would disable ->direct_access() on /dev/pmem0, but
permit ->direct_access() on /dev/pmem0m.
--
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/