linux-kernel - Re: [PATCH v2 00/10] evacuate struct page from the block layer, introduce __pfn

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]

Message-ID: <20150507175230.GB21781@gmail.com>
Date:	Thu, 7 May 2015 19:52:30 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Boaz Harrosh <boaz@...xistor.com>, Jan Kara <jack@...e.cz>,
	Mike Snitzer <snitzer@...hat.com>, Neil Brown <neilb@...e.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Chris Mason <clm@...com>, Paul Mackerras <paulus@...ba.org>,
	"H. Peter Anvin" <hpa@...or.com>, Christoph Hellwig <hch@....de>,
	Alasdair Kergon <agk@...hat.com>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Mel Gorman <mgorman@...e.de>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Rik van Riel <riel@...hat.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Jens Axboe <axboe@...nel.dk>, Theodore Ts'o <tytso@....edu>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Julia Lawall <Julia.Lawall@...6.fr>, Tejun Heo <tj@...nel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 00/10] evacuate struct page from the block layer,
 introduce __pfn_t


* Dan Williams <dan.j.williams@...el.com> wrote:

> > That looks like a layering violation and a mistake to me. If we 
> > want to do direct (sector_t -> sector_t) IO, with no serialization 
> > worries, it should have its own (simple) API - which things like 
> > hierarchical RAID or RDMA APIs could use.
> 
> I'm wrapped around the idea that __pfn_t *is* that simple api for 
> the tiered storage driver use case. [...]

I agree. (see my previous mail)

> [...] For RDMA I think we need struct page because I assume that 
> would be coordinated through a filesystem an truncate() is back in 
> play.

So I don't think RDMA is necessarily special, it's just a weirdly 
programmed DMA request:

 - If it is used internally by an exclusively managed complex storage
   driver, then it can use low level block APIs and pfn_t.

 - If RDMA is exposed all the way to user-space (do we have such 
   APIs?), allowing users to initiate RDMA IO into user buffers, then 
   (the user visible) buffer needs struct page backing. (which in turn 
   will then at some lower level convert to pfns.)

   That's true for both regular RAM pages and mmap()-ed persistent RAM 
   pages as well.

Thanks,

	Ingo
--
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/