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]

Message-ID: <550EECD2.4000604@plexistor.com>
Date:	Sun, 22 Mar 2015 18:24:50 +0200
From:	Boaz Harrosh <boaz@...xistor.com>
To:	Matthew Wilcox <willy@...ux.intel.com>,
	Rik van Riel <riel@...hat.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 10:31 PM, Matthew Wilcox wrote:
<>
> 
> There's a lot of code out there that relies on struct page being PAGE_SIZE
> bytes.  

Not so much really. Not at the lower end of the stack. You can actually feed
a 
	vp = kmalloc(64K);
	bv_page = virt_to_page(vp)
	bv_len = 64k

And feed that to an hard drive. It works.

The only last stronghold of PAGE_SIZE is at the page-cache and page-fault
granularity where the minimum is the better. But it should not be hard
to clean up the lower end of the stack. Even introduce a:
	page_size(page)

You will find that every subsystem that can work with a sub-page size
similar to above bv_len. Will also work well with bigger than PAGE_SIZE
bv_len equivalent.

Only the BUG_ONs need to convert to page_size(page) instead of PAGE_SIZE

> 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'.
> 

struct page already knows how to be a super-page. with the THP mechanics.
All a page_size(page) needs is a call to its section, we do not need any
added storage at page-struct. (And we can cache this as a flag we actually
already have a flag)

It looks like you are very trigger happy to change
	"biovec and auditing all of the code which touches it"

I believe long long term your #1b is the correct "full audit" path:

	Page Is the virtual-2-page-2-physical descriptor + state.
	It is variable size
 
> [1] Please, somebody come up with a better name!

sure struct page *page.

The one to kill is PAGE_SIZE. In most current code it can just be MIN_PAGE_SIZE
and CACHE_PAGE_SIZE == MIN_PAGE_SIZE. Only novelty is enhance of the split_huge_page
in the case of "page-fault-granularity".

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