[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+ZsKJ4EMKRgdFQzUjRJOE48=tTJzHf66-60PnVRj7pxvmNgVg@mail.gmail.com>
Date: Sun, 24 Jan 2016 01:03:49 -0800
From: Jared Hulbert <jaredeh@...il.com>
To: "Wilcox, Matthew R" <matthew.r.wilcox@...el.com>
Cc: Linux FS Devel <linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
Matthew Wilcox <willy@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Carsten Otte <cotte@...ibm.com>,
Chris Brandt <Chris.Brandt@...esas.com>
Subject: Re: [PATCH v12 10/20] dax: Replace XIP documentation with DAX documentation
I our defense we didn't know we were sinning at the time.
Can you walk me through the cache flushing hole? How is it okay on
X86 but not VIVT archs? I'm missing something obvious here.
I thought earlier that vm_insert_mixed() handled the necessary
flushing. Is that even the part you are worried about?
vm_insert_mixed()->insert_pfn()->update_mmu_cache() _should_ handle
the flush. Except of course now that I look at the ARM code it looks
like it isn't doing anything if !pfn_valid(). <sigh> I need to spend
some more time looking at this again.
What flushing functions would you call if you did have a cache page.
There are all kinds of cache flushing functions that work without a
struct page. If nothing else the specialized ASM instructions that do
the various flushes don't use struct page as a parameter. This isn't
the first I've run into the lack of a sane cache API. Grep for
inval_cache in the mtd drivers, should have been much easier. Isn't
the proper solution to fix update_mmu_cache() or build out a pageless
cache flushing API?
I don't get the explicit mapping solution. What are you mapping
where? What addresses would be SHMLBA? Phys, kernel, userspace?
Powered by blists - more mailing lists