Eric,

I've attached a patch file which rolls up a set of patches to dcache.c 
along with a few changed I made to locking symantics.  So far a 2.6.16 
(+ -mm2) with the patch applied survives the harshest testing I can 
throw at it!

Note that I've also made some minor changes to exit.c [preempt 
disable/enable during task exit] and truncate.c [BUG_ON check of 
'private' page].  The testing I've done is with a kernel built without 
preemption, and one built with voluntary preemption.  A kernel built 
with forced preemption and with spinlock debugging enabled did NOT work 
very well!!!  Also, the performance of a kernel  built with voluntary 
preemption and with the cond_resched_lock() calls in dcache.c was 
surprisingly *BAD*, with the system going into a wheel-spin for a long 
period [high system cpu of 87%+] when I fired up a number of large 
cpu+memory hungry tasks.  This might need to be looked at more closely?!

Eric W. Biederman wrote:

>I have tried to reproduce this.  The circumstances weren't the most
>controlled but they did overlap with what you described and I haven't seen
>anything.
>
>So I am guessing that you are having memory corruption from some source.
>Either bad ram or a bad module.
>
>I'm off on vacation for a week, so I won't be able to follow up.
>
>
>Eric
>  
>