[linuxsh-dev] Caches question

[NIIBE Y. <gn...@ch...>]

Sorry Stuart.  Your analysis is right.  I'm always wrong. :-)

NIIBE Yutaka wrote:
 > Stuart Menefy wrote:
 >  > I've been battling against a problem for a couple of days now, which looks
 >  > like a 'generic' kernel problem, but it like to run it past you first.
 > 
 > I know the battle is quite annoying...
 > 
 >  > Note this is on an SH4, so to some extent we have to regard the cache
 >  > as virtual.
 > 
 > More specifically, SH-4 has virtually tagged and physically indexed
 > cache system.  I think that MIPS R4000 has same system.
 > 
 > Generally speaking, I don't think we need flush at the time of EXIT.
 > We can postpone the flush at the time of reuse of the physical memory
 > (or if the memory is overwritten, we don't need to flush them).
 > 
 >  > As far as I can tell, the exact problem I have is this
 >  >  - a page is allocated and mapped into a process's address space
 >  >    (I think its part of the stack) and is written to. The written
 >  >    data ends up in the cache as normal.
 >  >  - the process then exits, and all the pages are freed.
 >  >  - later another process executes a fork, and so the kernel needs to
 >  >    allocate a page for the child process's pgd, and picks
 >  >    the page which was previously part of the first processes stack
 >  >  - the pgd for the child process is copied from the parent to the child
 >  >    into the newly allocated page
 >  >  - as part of duplicating the memory map for the child a
 >  >    flush_cache_mm is called, which results in the entire cache being
 >  >    flushed, including the data which was cached right at the beginning
 >  >    of this description. This overwrites the pgd with garbage, and later
 >  >    causes errors to be reported.
 > 
 > I think that this (corrupt of the pgd) can't be happened in this
 > sequence.  The page allocated for PGD is initialized by get_pgd_slow
 > (overwritten).

Sorry, I misunderstood.  The currupts will occur, when the page was
mapped to the user space and there's cache alias.

I checked the code, the page allocation code does not include any
cache flush.

Hence, your patch is the right solution.
--