Hello, I was going through the code forward and backward and from the left to the right :) and the only way I see how this can happen is when quota file is on the different filesystem than it belongs too (actually nobody forbids it, even there is an optional parameter to usrquota mount option which specifies where is the quota file). But in that case it's rather trivial and I'd expect users would see the problem rather often. So Branko do you have quota files on the filesystem they belong to? Otherwise I really can't understand how this can happen - quota code obviously got correct file pointer so I guess it can't be corruption or something like that... especially when the pointer is setup once on quotaon() and then it's not touched. Also I can't imagine how dquot would get wrong superblock pointer... Honza > 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.) > -- Jan Kara <jack@suse.cz> SuSE CR Labs
