Re: 2.4.23aa1 ext3 oops

[Jamie Clark <jclark@metaparadigm.com>]

David Woodhouse wrote:

>On Thu, 2003-12-11 at 10:33 +0800, Jamie Clark wrote:
>  
>
>>After a quick browse of the assembler output the zeroing would appear to 
>>be part of the list_del inline, and edi seems to equate to &sb. 
>>    
>>
>Seems reasonable. It does look like something's stomped on sb->s_dirty.
>  
>
>>__mark_inode_dirty() does not appear to take sb_lock before adding to 
>>the s_dirty list. Could that be the culprit?
>>    
>>
>
>I don't think so; it's holding the inode_lock which should be
>sufficient. Besides -- in practice all updates to the 4-byte pointer
>sb->s_dirty.next are going to be atomic, and there's no reason _ever_
>for it to be set to d7ffbc08. It's hard to see how a simple locking
>problem is going to cause such a thing.
>  
>
True.  I confess I didn't think too hard after narrowing down where it 
tripped up.

>How repeatable is this? 
>
The first oops ocurred after 4 or 5 days. My second run crashed in the 
first night, this time in filemap.c: precheck_file_write().
This oops seemed to be at or near the first dereference of inode, before 
the f_flags test.

        /* FIXME: this is for backwards compatibility with 2.4 */
        if (!S_ISBLK(inode->i_mode) && (file->f_flags & O_APPEND))
                *ppos = pos = inode->i_size;

 >>EIP; c01306fb <precheck_file_write+53/1f8>   <=====
Trace; c01308f8 <generic_file_write_nolock+58/4c8>
Trace; c013108f <generic_file_write+13f/158>
Trace; c016f3a7 <ext3_file_write+23/bc>
Trace; c0140e57 <sys_write+8f/100>
Trace; c0107133 <system_call+33/38>

>Can you turn on slab poisoning?
>  
>
Is CONFIG_DEBUG_SLAB all that I need?

I'm currently running 2.4.23aa1 with the inode.c patch reversions as 
Marcelo first suggested. When (IF) that crashes, or if I can get the 
test running on another SMP box I will revert to 2.4.23 + the qla2300 
driver that I need for the fibre-channel array.

-Jamie