linux-kernel - Re: [PATCH v2 02/10] block: add helpers for accessing a bio

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:	Fri, 8 May 2015 08:59:10 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>
Cc:	Jens Axboe <axboe@...nel.dk>, Boaz Harrosh <boaz@...xistor.com>,
	Rik van Riel <riel@...hat.com>,
	"Theodore Ts'o" <tytso@....edu>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Mike Snitzer <snitzer@...hat.com>, Chris Mason <clm@...com>,
	Neil Brown <neilb@...e.de>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Julia Lawall <Julia.Lawall@...6.fr>,
	Mel Gorman <mgorman@...e.de>,
	Matthew Wilcox <willy@...ux.intel.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Jan Kara <jack@...e.cz>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Christoph Hellwig <hch@....de>,
	Alasdair Kergon <agk@...hat.com>
Subject: Re: [PATCH v2 02/10] block: add helpers for accessing a bio_vec page

On Wed, May 6, 2015 at 1:05 PM, Dan Williams <dan.j.williams@...el.com> wrote:
> In preparation for converting struct bio_vec to carry a __pfn_t instead
> of struct page.
>
> This change is prompted by the desire to add in-kernel DMA support
> (O_DIRECT, hierarchical storage, RDMA, etc) for persistent memory which
> lacks struct page coverage.
>
> Alternatives:
>
> 1/ Provide struct page coverage for persistent memory in DRAM.  The
>    expectation is that persistent memory capacities make this untenable
>    in the long term.
>
> 2/ Provide struct page coverage for persistent memory with persistent
>    memory.  While persistent memory may have near DRAM performance
>    characteristics it may not have the same write-endurance of DRAM.
>    Given the update frequency of struct page objects it may not be
>    suitable for persistent memory.
>
> 3/ Dynamically allocate struct page.  This appears to be on the order
>    of the complexity of converting code paths to use __pfn_t references
>    instead of struct page, and the amount of setup required to establish
>    a valid struct page reference is mostly wasted when the only usage in
>    the block stack is to perform a page_to_pfn() conversion for
>    dma-mapping.  Instances of kmap() / kmap_atomic() usage appear to be
>    the only occasions in the block stack where struct page is
>    non-trivially used.  A new kmap_atomic_pfn_t() is proposed to handle
>    those cases.
>
> Generated with the following semantic patch:
>
> // bv_page.cocci: convert usage of ->bv_page to use set/get helpers
> // usage: make coccicheck COCCI=bv_page.cocci MODE=patch

Now that it looks like this patchset can move forward, what do about
this one?  Run the Coccinelle script late in the merge window to catch
all the new bv_page usages targeted for 4.2-rc1?
--
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/