Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1317013

Re: [PATCH v12 10/20] dax: Replace XIP documentation with DAX documentation

From Matthew Wilcox <willy@linux.intel.com>
Newsgroups linux.kernel
Subject Re: [PATCH v12 10/20] dax: Replace XIP documentation with DAX documentation
Date 2016-01-25 18:00 +0100
Message-ID <qUSEG-6QD-21@gated-at.bofh.it> (permalink)
References <oeUAN-8oD-7@gated-at.bofh.it> <oeUAQ-8oD-59@gated-at.bofh.it> <qTsjg-I1-23@gated-at.bofh.it> <qTJDs-4tt-9@gated-at.bofh.it> <qUoQi-2yS-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sun, Jan 24, 2016 at 01:03:49AM -0800, Jared Hulbert wrote:
> I our defense we didn't know we were sinning at the time.

Fair enough.  Cache flushing is Hard.

> 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?

No, that part should be fine.  My concern is about write() calls to files
which are also mmaped.  See Documentation/cachetlb.txt around line 229,
starting with "There exists another whole class of cpu cache issues" ...

> What flushing functions would you call if you did have a cache page.

Well, that's the problem; they don't currently exist.

> 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?

The problem comes in dax_io() where the kernel stores to an alias of the
user address (or reads from an alias of the user address).  Theoretically,
we should flush user addresses before we read from the kernel's alias,
and flush the kernel's alias after we store to it.

But if we create a new address for the kernel to use which lands on the
same cache line as the user's address (and this is what SHMLBA is used
to indicate), there is no incoherency between the kernel's view and the
user's view.  And no new cache flushing API is needed.

Is that clearer?  I'm not always good at explaining these things in a
way which makes sense to other people :-(

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v12 10/20] dax: Replace XIP documentation with DAX documentation Jared Hulbert <jaredeh@gmail.com> - 2016-01-21 19:40 +0100
  RE: [PATCH v12 10/20] dax: Replace XIP documentation with DAX  documentation "Wilcox, Matthew R" <matthew.r.wilcox@intel.com> - 2016-01-22 14:10 +0100
    RE: [PATCH v12 10/20] dax: Replace XIP documentation with DAX  documentation Chris Brandt <Chris.Brandt@renesas.com> - 2016-01-22 14:50 +0100
      Re: [PATCH v12 10/20] dax: Replace XIP documentation with DAX  documentation Matthew Wilcox <willy@linux.intel.com> - 2016-01-22 15:40 +0100
    Re: [PATCH v12 10/20] dax: Replace XIP documentation with DAX documentation Jared Hulbert <jaredeh@gmail.com> - 2016-01-24 10:10 +0100
      Re: [PATCH v12 10/20] dax: Replace XIP documentation with DAX  documentation Matthew Wilcox <willy@linux.intel.com> - 2016-01-25 18:00 +0100
        Re: [PATCH v12 10/20] dax: Replace XIP documentation with DAX documentation Jared Hulbert <jaredeh@gmail.com> - 2016-01-25 22:20 +0100
          Re: [PATCH v12 10/20] dax: Replace XIP documentation with DAX documentation Jared Hulbert <jaredeh@gmail.com> - 2016-01-27 21:00 +0100

csiph-web