search for: ext3_writepage

...65e58 fffffffc c9f65ee0 c95c4f3c c95c4f2c c95c4f1c c9f64000 Sep 21 23:10:05 devil kernel: Call Trace: [mpage_writepages+990/1971] [filemap_nopage+243/612] [do_no_page+617/784] [handle_mm_fault+149/360] [__set_page_dirty_buffers+344/404] Sep 21 23:10:05 devil kernel: [filemap_sync_pte+106/116] [ext3_writepages+31/48] [ext3_get_block+0/104] [do_writepages+24/44] [filemap_fdatawrite+93/112] [msync_interval+102/196] Sep 21 23:10:05 devil kernel: [sys_msync+169/250] [syscall_call+7/11] Sep 21 23:10:05 devil kernel: Sep 21 23:10:05 devil kernel: Code: 0f 0b 55 03 7a 24 2f c0 83 c4 14 6a 01 56 8b 44 24...

Hi Andrew, The patch below addresses the problem we were talking about earlier where ext3_writepage ends up accessing the inode after the page lock has been dropped (and hence at a point where it is possible for the inode to have been reclaimed.) Tested minimally (it builds and boots.) It makes ext3_journal_stop take an sb, not an inode, as its final parameter. It also sets sb->s_need_sync_...

...r in 2.4 than in 2.2, presumably because of better request merging. Much more work needs to go into benchmarking and performance tuning. - There's an issue with page_launder(): ext3_file_write() -> generic_file_write() -> __alloc_pages() -> page_launder() -> ext3_writepage() This is bad. It will cause ext3 to be reentered while it has a transaction open against a different fs. This will corrupt filesystems and can deadlock. Making ext3_file_write() set PF_MEMALLOC wasn't suitable. It easily causes 0-order allocation failures within generic_file_wri...

An ext3 patch for the latest Linus kernel is at http://www.uow.edu.au/~andrewm/linux/ext3/ The changes are quite small: - Tided up some code now that quotas in Linus and -ac kernels are synced up. - Fix a race which can cause a null-pointer deref in ext3_writepage(). This bug has been there for a long time, but only manifested in 2.3.13-pre for some reason. I've tested this pretty hard, every which way. It looks OK. There was a report against ext3-for-2.4.10 that mark_buffer_clean() was being called against an already-clean buffer. This has not b...

Hello, Stephen, It seem that in the presence of several jornalling file systems in the kernel some mechanism is needed for proper sharing of the ->journal_info pointer in the task_struct. One journalled file system can indirectly call another during page fault in copy_from_user, quota file modification, or __alloc_pages()->balance_classzone()->shrink_cache()->vm_writeback()

...al second try to mount puts the mount process into 'D' state (i.e. it never completes). Now System map shows the fault occurs in ext3_bmap: fffffc0000883c00 t ext3_commit_write fffffc0000883e60 t ext3_abort_write fffffc0000883f30 t ext3_bmap fffffc0000883fe0 t bget_one fffffc0000884000 t ext3_writepage fffffc0000884340 t ext3_readpage fffffc0000884380 t ext3_flushpage Disassembly of section .text: fffffc0000883f30 <ext3_bmap>: fffffc0000883f30: 34 00 bb 27 ldah gp,52(t12) fffffc0000883f34: 18 16 bd 23 lda gp,5656(gp) fffffc0000883f38: e0 ff de 23 lda...

...nel: Stack: c881f9b3 00000000 c0136eb8 009bfec8 c018c6e2 000000c8 c7de6000 c162412c kernel: c881e12a 00000000 009bfe3d c0353d44 0000000b c7dcdec0 c018ca54 c0353d44 kernel: c162412c 00000004 c1624124 c7de6000 c01275aa c162412c c1624134 c881e0c0 kernel: Call Trace: [<c881f9b3>] ext3_writepage_trans_blocks [ext3] 0xf Checked the mailing list archives... Any ideas? Steve