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
| ||
|
Date: Sat, 19 Dec 2015 10:37:46 -0800 From: Dan Williams <dan.j.williams@...el.com> To: Ross Zwisler <ross.zwisler@...ux.intel.com> Cc: "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@...ts.01.org" <linux-nvdimm@...ts.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 v5 4/7] dax: add support for fsync/sync On Fri, Dec 18, 2015 at 9:22 PM, Ross Zwisler <ross.zwisler@...ux.intel.com> wrote: > To properly handle fsync/msync in an efficient way DAX needs to track dirty > pages so it is able to flush them durably to media on demand. > > The tracking of dirty pages is done via the radix tree in struct > address_space. This radix tree is already used by the page writeback > infrastructure for tracking dirty pages associated with an open file, and > it already has support for exceptional (non struct page*) entries. We > build upon these features to add exceptional entries to the radix tree for > DAX dirty PMD or PTE pages at fault time. > > Signed-off-by: Ross Zwisler <ross.zwisler@...ux.intel.com> [..] > +static void dax_writeback_one(struct address_space *mapping, pgoff_t index, > + void *entry) > +{ > + struct radix_tree_root *page_tree = &mapping->page_tree; > + int type = RADIX_DAX_TYPE(entry); > + struct radix_tree_node *node; > + void **slot; > + > + if (type != RADIX_DAX_PTE && type != RADIX_DAX_PMD) { > + WARN_ON_ONCE(1); > + return; > + } > + > + spin_lock_irq(&mapping->tree_lock); > + /* > + * Regular page slots are stabilized by the page lock even > + * without the tree itself locked. These unlocked entries > + * need verification under the tree lock. > + */ > + if (!__radix_tree_lookup(page_tree, index, &node, &slot)) > + goto unlock; > + if (*slot != entry) > + goto unlock; > + > + /* another fsync thread may have already written back this entry */ > + if (!radix_tree_tag_get(page_tree, index, PAGECACHE_TAG_TOWRITE)) > + goto unlock; > + > + radix_tree_tag_clear(page_tree, index, PAGECACHE_TAG_TOWRITE); > + > + if (type == RADIX_DAX_PMD) > + wb_cache_pmem(RADIX_DAX_ADDR(entry), PMD_SIZE); > + else > + wb_cache_pmem(RADIX_DAX_ADDR(entry), PAGE_SIZE); Hi Ross, I should have realized this sooner, but what guarantees that the address returned by RADIX_DAX_ADDR(entry) is still valid at this point? I think we need to store the sector in the radix tree and then perform a new dax_map_atomic() operation to either lookup a valid address or fail the sync request. Otherwise, if the device is gone we'll crash, or write into some other random vmalloc address space. -- 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/
Powered by blists - more mailing lists