Steve Dickson wrote:
> Andrew Morton wrote:
>>
>> This is our user's data we're talking about here.
> Point...
> 
>>
>> If that printk comes out then we need to fix the kernel so that it no
>> longer wants to print that printk.  We don't want to just hide it.
 >
> I'm concern about the printk popping when we are flushing the
> readdir cache (i.e. stale data) and either flooding the console
> to a ton a messages (basically bring a system to its knees for
> no good reason) or scaring the hell out people by saying we have a
> major problem when in reality we are just flushing stale data...
> 
> So I definitely agree the printk should be there and be on by default,
> but I so think it would be a good idea to have way to turn it off
> if need be...

[ Sorry for the attachment... anyone know how to include a diff inline 
with Thunderbird? ]

The attached patch is my suggestion for reporting the cache invalidation 
failure from within the NFS client.  Please review and comment.  My 
testing with this patch applied has not triggered a single message, but 
I haven't tried any memory exhaustion scenarios.

I honestly doubt that we will see log floods.  The original problem that 
was causing stale data to remain cached has been addressed.  The reclaim 
race will almost certainly be rare.