On 2/8/08, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Fri, Feb 08, 2008 at 01:18:37PM +0100, Vegard Nossum wrote: > > On 2/8/08, Andi Kleen <[EMAIL PROTECTED]> wrote: > > > Your assumption that only the string instructions can take > > > multiple page faults seems a little dangerous too. > > > > Yes, this is true. I cannot guarantee that there are no other > > instructions that could access more than one memory location but only > > take one page fault. However, since the kernel does boot, we at least > > know that these instructions are not very frequently used. (If you > > know of any other instructions we might be missing, I'll be happy to > > know about it!) > > Pretty much all in the right circumstances. > > e.g. consider a segment reload in tracked memory. > > Also there are various instructions which do all kinds of complicated > things internally; like IRET or INT: often with many memory accesses. > Just page through a instruction manual and look at the pseudo code > describing what the various instructions do.
Yes, this is true. Then our task is to make sure that this memory is never allocated from tracked caches. We do have some changes in this area, for instance we never track task structs. Keep in mind that only slab objects are tracked currently, so things like stacks never catch page faults. I am not sure if this is exactly what you had in mind, but I don't know other kernel code very well enough to come up with perhaps more relevant examples :-) For now, I am simply assuming that we never load task segments, GDTs, LDTs, or paging structures from tracked memory (e.g. regular kmalloc()). > > There is also the point that if kmemcheck doesn't handle all the > > faulting addresses, it will simply fault again and again, without > > making any progress. I mean, it won't go unnoticed for very long :-) > > > > This is also why we depend on M386 and !X86_GENERIC, to avoid those > > MMX, etc. instructions, as we have no support for those currently > > I would not expect problems from MMX/SSE here (except for the generic > ones all instructions have) The problem with these instructions is not that they take page faults, but that kmemcheck doesn't know how to handle them. Kmemcheck needs to parse the instruction stream at EIP to determine what addresses were accessed, their size, and the type (read or write). This can be done currently with surprisingly little amounts of code. But AFAIK the format for MMX and SSE is different from the "regular" instructions, and so I don't know how to parse them. But this is something we can look at later. Vegard PS: Thanks for telling me about how change_page_attr() was wrong in kmemcheck v2. A lot of things were simply wrong in v2, but hopefully they are better now :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
