On Tue, Dec 22, 2015 at 02:44:40PM -0800, Andrew Morton wrote:
> On Fri, 18 Dec 2015 22:22:14 -0700 Ross Zwisler
> <ross.zwisler@xxxxxxxxxxxxxxx> wrote:
>
> > The function __arch_wb_cache_pmem() was already an internal implementation
> > detail of the x86 PMEM API, but this functionality needs to be exported as
> > part of the general PMEM API to handle the fsync/msync case for DAX mmaps.
> >
> > One thing worth noting is that we really do want this to be part of the
> > PMEM API as opposed to a stand-alone function like clflush_cache_range()
> > because of ordering restrictions. By having wb_cache_pmem() as part of the
> > PMEM API we can leave it unordered, call it multiple times to write back
> > large amounts of memory, and then order the multiple calls with a single
> > wmb_pmem().
> >
> > @@ -138,7 +139,7 @@ static inline void arch_clear_pmem(void __pmem *addr,
> > size_t size)
> > else
> > memset(vaddr, 0, size);
> >
> > - __arch_wb_cache_pmem(vaddr, size);
> > + arch_wb_cache_pmem(addr, size);
> > }
> >
>
> reject. I made this
>
> arch_wb_cache_pmem(vaddr, size);
>
> due to Dan's
> http://www.ozlabs.org/~akpm/mmots/broken-out/pmem-dax-clean-up-clear_pmem.patch
The first argument seems wrong to me - in arch_clear_pmem() 'addr' and 'vaddr'
are the same address, with the only difference being 'addr' has the __pmem
annotation.
As of this patch arch_wb_cache_pmem() follows the lead of the rest of the
exported PMEM API functions and takes an argument that has the __pmem
annotation, so I believe it should be:
arch_wb_cache_pmem(addr, size);
Without this I think you'll get a sparse warning.
This will be fixed up in the next version of my series which build upon Dan's
patches.
|