Re: oops in ext3_discard_reservation()

[Andrew Morton <akpm@osdl.org>]

Mingming Cao <cmm@us.ibm.com> wrote:
>
> > It died in rsv_is_empty(), accessing rsv->_rsv_end, because `block_i' has a
> > value of 0x00010000.
> > 
> > Looks like a bitflip.    How good is that hardware?
>
> I am not sure what is happening.

Sorry, I cc'ed you, then worked out what happened then forgot to un-cc you.
It looks like Mike's machine suffered a single-bit hardware error.

> Smells like another race between two
> reservation window freeing. I thought we have thought this through quite
> well last year but maybe not.:(
> 
> In general, the reservation window allocating and freeing should be
> protected by a semaphore, so that we will not run into the case where we
> are trying to free a window, while another thread is in the middle of
> window-freed-and-then-re-allocating. But in the path of
> ext3_delete_inode()->clear_inode()->ext3_clear_inode()-
> >ext3_discard_reservation(), since it's only called at the last input(),
> so this race seems not exists. 

Yes, it looks OK.

> But with the path of invalidate_inodes->dispose_list->clear_inode-
> >ext3_discard_inode, I guess it is still possible that another thread is
> in the middle of block allocation, who just freed the current window and
> is about to allocating a new window?

The inode shootdown logic is quite gruesome, but we'd have heard about it
if it was possible for block allocation to be happening while an inode has
I_FREEING set.  Various things in fs/inode.c would explode.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/