search for: ext3_mark_inode_dirty

A change was made to ext3 in 2.4.20-pre9 which will cause the filesystem to run ext3_mark_inode_dirty() against a freed inode. This will occur when an application attempts to add a new file/directory to the filesystem and encounters space or inode exhaustion. The results of this are unpredictable. Usually, nothing happens. But it can cause random memory corruption on SMP, and the kernel will cr...

...2001 +++ fs/ext3/namei.c Mon Mar 19 22:53:40 2001 @@ -985,6 +985,13 @@ new_dir->i_version = ++global_event; /* + * Like most other Unix systems, set the ctime for inodes on a + * rename. + */ + old_inode->i_ctime = CURRENT_TIME; + ext3_mark_inode_dirty(old_inode); + + /* * ok, that's it */ --

...ss+118} <ffffffff801fb88e>{do_get_write_access+94} <ffffffff80185d1f>{__getblk+47} <ffffffff80195170>{filldir+0} <ffffffff801fbf69>{journal_get_write_access+41} <ffffffff801ec41c>{ext3_reserve_inode+write+76} <ffffffff80195170>{filldir+0} <ffffffff801ec4d8>{ext3_mark_inode_dirty+56} <ffffffff801fa9e5>{journal_start_229} <ffffffff801ee571>{ext3_dirty_inode+113} <ffffffff801a5604>{__mark_inode_dirty+52} <ffffffff8019bd2b>{update_atime+123} <ffffffff80195016>{vfs_readdir+166} <ffffffff801952e2>{syst_getdents+130} <ffffffff8019465e>{...

...qput+124/240] [dquot_drop+62/80] [ext3_free_inode+230/1 040] [ext3_mark_iloc_dirty+36/80] [ext3_mark_iloc_dirty+53/80] Jan 16 12:37:38 frost kernel: [<c0145ac5>] [<c0145ebc>] [<c0146dbe>] [<c0153aa6>] [<c0157a74>] [<c0157a85>] Jan 16 12:37:38 frost kernel: [ext3_mark_inode_dirty+39/64] [ext3_delete_inode+187/272] [ext3_delete_inode+0/ 272] [ext3_delete_inode+0/272] [iput+246/496] [d_delete+76/112] Jan 16 12:37:38 frost kernel: [<c0157b77>] [<c0154beb>] [<c0154b30>] [<c0154b30>] [<c01428e6>] [<c0140f7c>] Jan 16 12:37:38 frost kernel:...

...288 <b0103f76> die+0x263/0x288 <b011533a> do_page_fault+0x441/0x526 <b0114ef9> do_page_fault+0x0/0x526 <b01036f7> error_code+0x4f/0x54 <f0872d73> ext3_xattr_delete_inode+0x5/0xab [ext3] <f0865bcb> ext3_free_inode+0x92/0x2c7 [ext3] <f08666ee> ext3_mark_inode_dirty+0x20/0x27 [ext3] <f08687dd> ext3_delete_inode+0xa3/0xba [ext3] <f086873a> ext3_delete_inode+0x0/0xba [ext3] <b016809c> generic_delete_inode+0x9e/0x101 <b0167b87> iput+0x5e/0x60 <b0166d66> dput+0xfe/0x116 <b0160a4f> sys_renameat+0x15f/0x1b9 <b01b...

...c2e67e84 c0171046 c2e67f40 00000000 c2e67f40 c016aa53 ca55a3c4 c2e67f40 00000000 c2e67e84 c9fa8ac0 ca55a3c4 c2e67f40 c016aac1 ca55a3c4 c9fa8ac0 Call Trace: [<c0171046>] journal_get_write_access+0xb/0x2d [<c016aa53>] ext3_reserve_inode_write+0x33/0x89 [<c016aac1>] ext3_mark_inode_dirty+0x18/0x31 [<c017082b>] journal_start+0x7f/0xa9 [<c016ab26>] ext3_dirty_inode+0x4c/0x5f [<c0156c20>] __mark_inode_dirty+0x24/0xce [<c01527d2>] inode_setattr+0x118/0x123 [<c016a951>] ext3_setattr+0xc9/0x104 [<c0152903>] notify_change+0xda/0x143 [<c013c6b9...

...f5a2e9a0 e5fa9640 f6b55fa4 c01662b8 f75da800 e5fa9640 f75da800 c01615da Jul 4 20:53:14 localhost kernel: e5fa9640 f5a2e9a0 f6b55efc 00000000 e5fa9640 f5a2e9a0 f6d2ff80 f33b9380 Jul 4 20:53:14 localhost kernel: Call Trace: [ext3_reserve_inode_write+50/172] [start_this_handle+284/352] [ext3_mark_inode_dirty+26/52] [ext3_dirty_inode+163/276] [__mark_inode_dirty+50/188] Jul 4 20:53:14 localhost kernel: [update_atime+75/80] [link_path_walk+2038/2328] [path_walk+26/28] [__user_walk+53/80] [sys_stat64+25/112] [system_call+51/56] Jul 4 20:53:14 localhost kernel: Jul 4 20:53:14 localhost kernel: Cod...

...c952c200 c9a27a98 c952c400 c909dd80 c01695df c8d57b04 Call Trace: [<c0172487>] journal_get_write_access+0x53/0x78 [<c01695df>] ext3_do_update_inode+0x21f/0x3e0 [<c0169b15>] ext3_reserve_inode_write+0x31/0xb0 [<c0169ab5>] ext3_mark_iloc_dirty+0x21/0x50 [<c0169bbd>] ext3_mark_inode_dirty+0x29/0x34 [<c0169c9b>] ext3_dirty_inode+0xd3/0x14c [<c0154809>] __mark_inode_dirty+0x39/0xec [<c014fab4>] update_atime+0x8c/0x98 [<c0145b74>] link_path_walk+0x698/0x8c0 [<c0169ca7>] ext3_dirty_inode+0xdf/0x14c [<c0147e53>] vfs_follow_link+0x12f/0x1a4 [<...

...9>] __getblk+0x25/0x22c Jan 8 05:20:01 localhost kernel: [<ffffffff88032d01>] :jbd:journal_get_write_access+0x22/0x33 Jan 8 05:20:01 localhost kernel: [<ffffffff8804dc75>] :ext3:ext3_reserve_inode_write+0x38/0x90 Jan 8 05:20:01 localhost kernel: [<ffffffff8804dcee>] :ext3:ext3_mark_inode_dirty+0x21/0x3c Jan 8 05:20:01 localhost kernel: [<ffffffff88050b14>] :ext3:ext3_dirty_inode+0x63/0x7b Jan 8 05:20:01 localhost kernel: [<ffffffff8001349c>] __mark_inode_dirty+0x29/0x16e Jan 8 05:20:01 localhost kernel: [<ffffffff8804b5f5>] :ext3:ext3_new_blocks+0x567/0x693 Jan 8...

...c015ff39>] [<c01599fe>] [<c0159e56>] [<c0159f59>] [<c015a039>] STACK TRACE FOR TASK: 0xe7ede000 (sendmail) 0 do_get_write_access+340 [0xc015fb48] 1 journal_get_write_access+52 [0xc015ff34] 2 ext3_do_update_inode+469 [0xc01599f9] 3 ext3_mark_iloc_dirty+29 [0xc0159e51] 4 ext3_mark_inode_dirty+36 [0xc0159f54] 5 ext3_dirty_inode+208 [0xc015a034] 6 __mark_inode_dirty+44 [0xc01464e4] 7 update_atime+70 [0xc0147a22] 8 do_generic_file_read+1105 [0xc012674d] 9 generic_file_read+124 [0xc0126a10] 10 sys_read+141 [0xc0133305] 11 system_call+44 [0xc0106e48] ebx: 00000004 ecx: 0810dc38 edx: 0000...

...95ec c43b92e0 cbf7bcc0 00000003 c6ca9c64 c238d8a8 c6ca9b40 Jun 29 11:30:05 ns kernel: 00000498 c015368f c70c2340 c3ad95a0 c47dbefc 00000000 c70c2340 00000498 Jun 29 11:30:05 ns kernel: Call Trace: [journal_dirty_metadata+324/356] [ext3_do_update_inode+763/920] [ext3_mark_iloc_dirty+33/72] [ext3_mark_inode_dirty+41/52] [ext3_dirty_inode+134/196] Jun 29 11:30:05 ns kernel: [__mark_inode_dirty+46/120] [generic_file_write+808/1864] [do_getitimer+156/164] [ext3_file_write+70/76] [sys_write+146/224] [system_call+51/56] Jun 29 11:30:05 ns kernel: Jun 29 11:30:05 ns kernel: Code: 0f 0b 83 c4 14 90 8d 74 26...

...qput+124/240] [dquot_drop+62/80] [ext3_free_inode+230/1 040] [ext3_mark_iloc_dirty+36/80] [ext3_mark_iloc_dirty+53/80] Jan 16 12:37:38 frost kernel: [<c0145ac5>] [<c0145ebc>] [<c0146dbe>] [<c0153aa6>] [<c0157a74>] [<c0157a85>] Jan 16 12:37:38 frost kernel: [ext3_mark_inode_dirty+39/64] [ext3_delete_inode+187/272] [ext3_delete_inode+0/ 272] [ext3_delete_inode+0/272] [iput+246/496] [d_delete+76/112] Jan 16 12:37:38 frost kernel: [<c0157b77>] [<c0154beb>] [<c0154b30>] [<c0154b30>] [<c01428e6>] [<c0140f7c>] Jan 16 12:37:38 frost kernel:...

I had the following spat out by syslog on my (2.4.18-pre7-ac3) mailer / web server: Assertion failure in do_get_write_access() at transaction.c:611: "!(((jh2bh(jh))->b_state & (1UL << BH_Lock)) != 0)" One of its partitions froze hard--I've rebooted it, and I have an oops which the BUG() triggered which won't decode at the moment, but I'll sort that one out

...0000000000000001 ffffffffa00528c2 00000100447c2ce8 000001007c18fc38 Dec 18 03:18:09 data3 kernel: 0000010024e32820 000001011cd75240 Dec 18 03:18:09 data3 kernel: Call Trace:<ffffffffa00528c2>{:ext3:ext3_mark_iloc_dirty+740} Dec 18 03:18:09 data3 kernel: <ffffffffa0052a14>{:ext3:ext3_mark_inode_dirty+65} Dec 18 03:18:10 data3 kernel: <ffffffffa003c4c6>{:jbd:journal_start+223} <ffffffffa0054726>{:ext3:ext3_dirty_inode+99} Dec 18 03:18:10 data3 kernel: <ffffffff8018fef0>{__mark_inode_dirty+40} <ffffffff80189748>{inode_update_time+182} Dec 18 03:18:10 data3 kernel: <ffff...

...1 kernel: [<f8870c79>] ext3_do_update_inode+0x2fb/0x322 [ext3] May 19 09:56:38 spf1 kernel: [<f8836d2d>] journal_get_write_access+0x25/0x2c [jbd] May 19 09:56:38 spf1 kernel: [<f8870f28>] ext3_mark_iloc_dirty+0x10/0x18 [ext3] May 19 09:56:38 spf1 kernel: [<f8870fe4>] ext3_mark_inode_dirty+0x33/0x3a [ext3] May 19 09:56:38 spf1 kernel: [<f886e658>] ext3_splice_branch+0xeb/0x18c [ext3] May 19 09:56:38 spf1 kernel: [<f8836cec>] do_get_write_access+0x54f/0x56b [jbd] May 19 09:56:38 spf1 kernel: [<c0154c35>] __find_get_block+0xb5/0xbe May 19 09:56:38 spf1 kernel: [...

Hello, Over the last month or so, I've noticed the following error showing up repeatedly in my system logs under kernel 2.4.18-ac3 and more recently under 2.4.19-rc1: EXT3-fs error (device ide0(3,3)) in ext3_new_inode: error 28 I've now been able to capture the following Oops before the system went down entirely: Assertion failure in do_get_write_access() at transaction.c:611:

...ff80019d4f>] __getblk+0x25/0x22c May 2 22:48:20 vmail kernel: [<ffffffff88031d0e>] :jbd:journal_get_write_access+0x22/0x33 May 2 22:48:20 vmail kernel: [<ffffffff8804dd3b>] :ext3:ext3_reserve_inode_write+0x38/0x90 May 2 22:48:20 vmail kernel: [<ffffffff8804ddb4>] :ext3:ext3_mark_inode_dirty+0x21/0x3c May 2 22:48:20 vmail kernel: [<ffffffff88050d39>] :ext3:ext3_dirty_inode+0x63/0x7b May 2 22:48:20 vmail kernel: [<ffffffff80013d53>] __mark_inode_dirty+0x29/0x16e May 2 22:48:20 vmail kernel: [<ffffffff80016642>] __generic_file_aio_write_nolock+0x28a/0x3b6 May...

...ad8de0 c3b68920 Jun 15 13:15:34 pc kernel: c3cdbef8 c0a6f9c0 c0152701 c3ad8de0 c0a6f9c0 c3cdbef8 c3cdbef8 c0a6f9c0 Jun 15 13:15:34 pc kernel: c0152809 c3ad8de0 c0a6f9c0 c3cdbef8 00000000 c3ad8de0 c0a6f9c0 c3b68920 Jun 15 13:15:34 pc kernel: Call Trace: [ext3_mark_iloc_dirty+33/80] [ext3_mark_inode_dirty+41/52] [ext3_dirty_inode+195/260] [__mark_inode_dirty+46/140] [generic_file_write+828/1824] Jun 15 13:15:34 pc kernel: [ext3_file_write+34/156] [sys_write+150/240] [system_call+51/64] Jun 15 13:15:34 pc kernel: Jun 15 13:15:34 pc kernel: Code: 8b 04 11 89 04 16 83 c2 04 49 79 f4 8b 44 24 14 50 8b...

Has anyone tried LFS (ie >2G files support) and Ext3 together? Are there good reasons why this should/should not work? I see the RH enterprise kernel patch set specifically does not attempt both lfs and ext3, but the lfs patches themselves touch some reasonably localised parts of ext2, so I would hope (without having dived in there to test), that the ext3 changes would mirror that