linux-kernel - Re: [RFC PATCH 0/7] evacuate struct page from the block layer

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:	Sun, 22 Mar 2015 19:06:58 +0200
From:	Boaz Harrosh <boaz@...xistor.com>
To:	Rik van Riel <riel@...hat.com>,
	Matthew Wilcox <willy@...ux.intel.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	axboe@...nel.dk, linux-nvdimm@...1.01.org,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	linux-raid@...r.kernel.org, mgorman@...e.de, hch@...radead.org,
	linux-fsdevel@...r.kernel.org,
	"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [RFC PATCH 0/7] evacuate struct page from the block layer

On 03/20/2015 11:08 PM, Rik van Riel wrote:
> On 03/20/2015 04:31 PM, Matthew Wilcox wrote:
<>
>> There's a lot of code out there that relies on struct page being PAGE_SIZE
>> bytes.  I'm cool with replacing 'struct page' with 'struct superpage'
>> [1] in the biovec and auditing all of the code which touches it ... but
>> that's going to be a lot of code!  I'm not sure it's less code than
>> going directly to 'just do I/O on PFNs'.
> 
> Totally agreed here. I see absolutely no advantage to teaching the
> IO layer about a "struct superpage" when it could operate on PFNs
> just as easily.
> 

Or teaching 'struct page' to be variable length, This is already so at
bio and sg level so you fixed nothing.

Moving to pfn's only means that all this unnamed code above that
"relies on struct page being PAGE_SIZE" is now not allowed to
interfaced with bio and sg list. Which in current code and in Dan's patches
means two tons of BUG_ONS and return -ENOTSUPP . For all these
subsystems below the bio and sglist that operate on page_structs

Say the "relies on struct page being PAGE_SIZE" is such an hard
work, which is not at all at the bio and sg-list level, will
it not be worth while fixing this instead of alienating the all
Kernel from the IO subsystem.

But I believe it is the much much smaller change? Specially considering
Networking, RDMA shared memory ...

Cheers
Boaz

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