Re: crashing with ext3

["Stephen C. Tweedie" <sct redhat com>]

Hi Jan,

I've had three of these reports now within the past month.

On Wed, Jan 16, 2002 at 01:39:44PM +0100, Branko F. Graèner wrote:
> i'm using redhat 7.2 with ext3 as my primary fs on kernel 2.4.17 +
> grsecurity + acl

[ the others have been without any other patches on top of plain ext3]

> Jan 16 12:37:37 frost kernel: Assertion failure in journal_start() at
> transaction.c:225: "handle->h_transaction-
> >t_journal == journal"

Executive summary: during a delete, ext3 believes we end up writing a
dquot entry out to the wrong filesystem.

Does this ring any bells with you at all?  In the mean time, I'm
trying to reproduce it here.

The assert failure is invariably followed by a call trace looking like

 sys_unlink
 vfs_unlink
 d_delete
 iput
 ext3_delete_inode
 ext3_mark_inode_dirty
 ext3_mark_iloc_dirty
 ext3_free_inode
 dquot_drop
 dqput
 write_dquot
 do_get_write_access
 generic_file_write
 __mark_inode_dirty
 do_get_write_access
 ext3_dirty_inode

Translated, that means:

  we're doing an unlink; 
  we start a transaction inside ext3_delete_inode; 
  ext3 has already truncated the file back to zero, releasing all 
	used data blocks; 
  we have already marked the inode dirty (the ext3_mark_inode_dirty is
	just the remains of that call sitting on the stack);
  we have entered ext3_free_inode to release the inode itself;
  we have done the
	DQUOT_INIT(inode);
	DQUOT_FREE_INODE(inode);
  to update quota for the freed inode;
  we are trying to
	DQUOT_DROP(inode);
  to release the dquot struct and flush it to disk;
  dqput has called write_dquot to write the quota entry out;
  the generic_file_write into the quota file has tried to update the
	mtime and ctime timestamps;
  ext3_dirty_inode has been called to journal the timestamp update and
	has tried to start a new transaction;
  the journaling layer has BUG()ed because there is already a
	transaction open for the ext3_delete_inode (which is fine),
	but the new transaction is ON A DIFFERENT FILESYSTEM from the
	old one (which is really really bad news.)

Cheers,
 Stephen