Messages in this thread | | | Date | Fri, 27 Mar 2020 14:29:37 +0000 | From | Mark Rutland <> | Subject | Re: [PATCH] arm64: mmu: no write cache for O_SYNC flag |
| |
On Thu, Mar 26, 2020 at 09:36:25AM -0700, Li Wang wrote: > reproduce steps: > 1. > disable CONFIG_STRICT_DEVMEM in linux kernel > 2. > Process A gets a Physical Address of global variable by > "/proc/self/pagemap". > 3. > Process B writes a value to the same Physical Address by mmap(): > fd=open("/dev/mem",O_SYNC); > Virtual Address=mmap(fd);
Is this just to demonstrate the behaviour, or is this meant to be indicative of a real use-case? I'm struggling to see the latter.
> problem symptom: > after Process B write a value to the Physical Address, > Process A of the value of global variable does not change. > They both W/R the same Physical Address.
If Process A is not using the same attributes as process B, there is no guarantee of coherency. How did process A map this memory?
> technical reason: > Process B writing the Physical Address is by the Virtual Address, > and the Virtual Address comes from "/dev/mem" and mmap(). > In arm64 arch, the Virtual Address has write cache. > So, maybe the value is not written into Physical Address.
I don't think that's true. I think what's happening here is:
* Process A has a Normal WBWA Cacheable mapping. * Process B as a Normal Non-cacheable mapping. * Process B's write does not snoop any caches, and goes straight to memory. * Process A reads a value from cache, which does not include process B's write.
That's a natural result of using mismatched attributes, and is consistent with the O_SYNC flag meaning that the write "is transferred to the underlying hardware".
> > fix reason: > giving write cache flag in arm64 is in phys_mem_access_prot(): > ===== > arch/arm64/mm/mmu.c > phys_mem_access_prot() > { > if (!pfn_valid(pfn)) > return pgprot_noncached(vma_prot); > else if (file->f_flags & O_SYNC) > return pgprot_writecombine(vma_prot); > return vma_prot; > } > ==== > the other arch and the share function drivers/char/mem.c of phys_mem_access_prot() > does not add write cache flag. > So, removing the flag to fix the issue
This will change behaviour that other software may be relying upon, and as above I do not believe this actually solves the problem you describe.
Thanks, Mark.
> > Signed-off-by: Li Wang <li.wang@windriver.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: Will Deacon <will@kernel.org> > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm64/mm/mmu.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index 128f70852bf3..d7083965ca17 100644 > --- a/arch/arm64/mm/mmu.c > +++ b/arch/arm64/mm/mmu.c > @@ -81,8 +81,6 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn, > { > if (!pfn_valid(pfn)) > return pgprot_noncached(vma_prot); > - else if (file->f_flags & O_SYNC) > - return pgprot_writecombine(vma_prot); > return vma_prot; > } > EXPORT_SYMBOL(phys_mem_access_prot); > -- > 2.24.1 >
| |