linux-kernel - Re: [PATCH v6 2/7] dax: support dirty DAX entries in radix tree

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: <CAPcyv4hUfQVff60JiN7=gQTEFeRf7FRnobwbT84dTLvW2jdfvg@mail.gmail.com>
Date:	Thu, 31 Dec 2015 14:08:36 -0800
From:	Dan Williams <dan.j.williams@...el.com>
To:	Bob Liu <bob.liu@...cle.com>
Cc:	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	"Theodore Ts'o" <tytso@....edu>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Dave Chinner <david@...morbit.com>,
	Ingo Molnar <mingo@...hat.com>, Jan Kara <jack@...e.com>,
	Jeff Layton <jlayton@...chiereds.net>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-ext4 <linux-ext4@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux MM <linux-mm@...ck.org>,
	linux-nvdimm <linux-nvdimm@...1.01.org>, X86 ML <x86@...nel.org>,
	XFS Developers <xfs@....sgi.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matthew Wilcox <matthew.r.wilcox@...el.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v6 2/7] dax: support dirty DAX entries in radix tree

On Wed, Dec 30, 2015 at 7:28 PM, Bob Liu <bob.liu@...cle.com> wrote:
>
> On 12/31/2015 04:39 AM, Dan Williams wrote:
>> On Wed, Dec 30, 2015 at 12:02 AM, Bob Liu <bob.liu@...cle.com> wrote:
>>> Hi Ross,
>>>
>>> On 12/24/2015 03:39 AM, Ross Zwisler wrote:
>>>> Add support for tracking dirty DAX entries in the struct address_space
>>>> radix tree.  This tree is already used for dirty page writeback, and it
>>>> already supports the use of exceptional (non struct page*) entries.
>>>>
>>>> In order to properly track dirty DAX pages we will insert new exceptional
>>>> entries into the radix tree that represent dirty DAX PTE or PMD pages.
>>>
>>> I may get it wrong, but there is "struct page" for persistent memory after
>>> "[PATCH v4 00/18]get_user_pages() for dax pte and pmd mappings".
>>> So why not just add "struct page" to radix tree directly just like normal page cache?
>>>
>>> Then we don't need to deal with any exceptional entries and special writeback.
>>
>> That "struct page" is optional and fsync/msync needs to operate in its absence.
>>
>
> Any special reason or scenario that "struct page" should not be enabled?
> I didn't see any disadvantages if always enable "struct page" by force when using DAX model for pmem.
> The benefits would be things can be more simple and less potential bugs because of smaller patches.
>

We can't enable struct page coverage by default.

The persistent memory capacity may be too large to allocate the memmap
array from DRAM.  Allocating it from pmem reduces the size of the
device and we can't have a block device change sizes just by booting a
different kernel (any kernel less than 4.5).  So, enabling struct page
must be an explicit action.

> Happy New Year!

Happy New Year!
--
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/