Re: testing pmdval/pteval page presence bit

[Jeremy Fitzhardinge]

Pekka Paalanen wrote:
> This is good to know. So far these are kernel mappings, as they are all
> created by ioremap*(), but there are plans to extend mmiotrace to
> trace IO-mappings accessed from user space. Do you have hints for that?
>   

Set _PAGE_PROTNONE, which will make the kernel logically treat it as a 
present pte with no page permissions, which is what you're doing.  Bear 
in mind that _PAGE_PROTNONE is overloaded with _PAGE_GLOBAL, so you'll 
need to make sure you restore that properly too (kernel mappings are 
generally global).

On the other hand, I assume you intercept mmiotrace faults fairly early 
in the fault handler, so that path shouldn't ever see an unexpected 
not-present pte.  But other code, like mprotect, mlock, etc, may inspect 
those ptes and get a nasty surprise if it sees them non-present.

(What happens if someone uses mprotect on a mapping that mmiotrace has 
made non-present?)

> OTOH, we are always dealing with PCI IO-mem-mappings, so would those ever
> be not present, excluding the mmiotrace case?
>
> Well, Stuart already found out that the kernel ioremap*()'ed pages might
> not really be present, there are some fixes coming up to mmiotrace to
> cope with that. The plan is to restore the state of the pte like it was
> before mmiotrace cleared the _PAGE_PRESENT flag, and if the same
> instruction and address faults again, fall through to the normal page
> fault handling. How can/will this fail? And if it is a user page?
>   

My main concern is non-fault handler code which looks at ptes.  How will 
it know what its looking at if mmiotrace has fiddled with the state?

   J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/