> You can get a missed flush from
> 
> 	bit == 0
> 	flush cache
> 
> 				modify page
> 				bit = 0
> 
> 	bit = 1
> 
> unless this is protected from some outer lock of which 
> I am not aware.
The page is question is one which is mapped (is being mapped) into a
process's address space with execute permission.  If the page is part
of the page cache for a file, then I would have thought that attempts
to write to the page would return an ETXTBSY error.  If the page is a
private page (private COW or anonymous page) then I don't see where
the kernel would be modifying the page.  If it is already mapped into
another process's address space with a shared writable mapping, and
that process is writing to the page, then it is up to the user-level
stuff to do the necessary cache-flushing.
So I think it's OK at the moment, but I agree it does look like a race
waiting to happen.
For alpha, the thing that my patch does that might hurt is the change
from flush_icache_page to flush_icache_range in kernel/ptrace.c.  Any
comment on that?
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/