> Alas, I thought about this some more. And one piece of code needs to> be fixed for this invariant about the semaphore being held in the> fault processing code paths to be true everywhere... ptrace()...

Yep --- I was just about to reply to your last mail with this point whenI got your follow-up. I've also had one report that the writable cachedpage reports started when debugging an electric-fenced binary undergdb. Has anyody seen these vm messages who has definitely NOT beenrunning gdb?

There's also the point that the whole swapout code munges page tableswithout ever taking the mm semaphore, but that case ought to beprotected by the combination of (a) having the kernel spinlock and (b)never stalling between starting a vma walk and modifying the pte. (Theswapout code is pretty paranoid about this.) However, I'm notabsolutely 100% sure that we don't have any unfortunate races left bythis exception. (For example, do we ever protect a vma by the mmsemaphore without also doing a lock_kernel()?)

--Stephen

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.edu