linux-kernel - Re: [PATCH v3 00/11] 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: <20150523143257.GA19676@lst.de>
Date:	Sat, 23 May 2015 16:32:57 +0200
From:	Christoph Hellwig <hch@....de>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	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>, j.glisse@...il.com,
	mingo@...nel.org, Alasdair Kergon <agk@...hat.com>,
	linux-arch@...r.kernel.org, linux-nvdimm@...ts.01.org, hch@....de,
	mgorman@...e.de, Matthew Wilcox <willy@...ux.intel.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>, riel@...hat.com,
	david@...morbit.com, Tejun Heo <tj@...nel.org>, axboe@...nel.dk,
	Theodore Ts'o <tytso@....edu>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Julia Lawall <Julia.Lawall@...6.fr>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	linux-fsdevel@...r.kernel.org, akpm@...ux-foundation.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v3 00/11] evacuate struct page from the block layer,
	introduce __pfn_t

I don't like this series at all, it does too much and too little at
the same time.

There's three totally different parts to it that are mixed up:

 (1) cleanups to use accessors for struct scatterlist instead of exposing
     the intricate details of chained S/G list to users
 (2) a switch of struct scatterlist to store a PFN instead of a page
 (3) switch struct bio_vec to store a struct PFN instead of a page

(1) are pretty obvious cleanups, and they should have been submited
separately long time ago.

(2) seems like a good idea, but only when done properly, that is a full
conversion to it.  Not a you need a config option, in which case maybe
some architectures and can sometimes deal with it if they driver says:
meh, okay.

Given that nature of SGLs most consumer want a physical address anyway,
and it shouldn't be a problem to convert all others that need a kernel
mapping to proper helpers.

(3) I'm not sure about in it's current form.  The bio_vec sees all kinds
of highlevel use and we need to be a lot more careful about it, due to
the way we e.g. use the in the iov_iter based read/write interfaces.

It could be that pfn_t based approach there makes sense, but only if
we ensure all consumer can always handle them.

Because of that I'd suggest you try to get (1) and (2) done properly
first, at that point we'll have how we can do (3) without causing 
a big mess.

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