search for: generic_file_write

Hi, I've noticed what seems to be a bug in the SMBfs page write code. It seems that the code in generic_file_write has changed fairly recently, and it is now a bug for the 'updatepage' code to clear the page lock and serve the wait queue. Unfortunately nobody seems to have removed the call to 'smb_unlock_page(page)' in 'smb_writepage_sync'. Would people who've been seeing problems...

...95a120 c0157be8 c11c7c00 00000001 c01601ae c1788480 c1cdf8b0 Jan 16 12:37:38 frost kernel: 00000000 c3bfbe00 c3d57000 00000001 c014160e c3bfbe00 00000000 00000020 Jan 16 12:37:38 frost kernel: Call Trace: [ext3_dirty_inode+88/208] [do_get_write_access+1198/1232] [__mark_inod e_dirty+46/128] [generic_file_write+836/1696] [do_get_write_access+1198/1232] Jan 16 12:37:38 frost kernel: Call Trace: [<c0157be8>] [<c01601ae>] [<c014160e>] [<c0126494>] [<c01601ae>] Jan 16 12:37:38 frost kernel: [write_dquot+165/256] [dqput+124/240] [dquot_drop+62/80] [ext3_free_inode+230/1 040] [e...

Hi everyone, The Linux Coda drivers and the ext3 patches don't seem to get along very well, at least in Linux 2.4.7. I've got a stock 2.4.7 kernel with a patch applied to the USB drivers (for a sony digital camera; see http://www.sujal.net/tech/linux/ just a change in unusual_devs.h). After I applied the ext3 patches from http://www.uow.edu.au/~andrewm/linux/ext3/ . Basically,

...e+310/1520] generic_file_buffered_write+0x136/0x5f0 [current_fs_time+85/112] current_fs_time+0x55/0x70 [inode_update_time+75/192] inode_update_time+0x4b/0xc0 [__generic_file_aio_write_nolock+675/1232] __generic_file_aio_write_nolock+0x2a3/0x4d0 [sys_recvfrom+233/256] sys_recvfrom+0xe9/0x100 [__generic_file_write_nolock+145/192] __generic_file_write_nolock+0x91/0xc0 [scheduler_tick+338/784] scheduler_tick+0x152/0x310 [timer_interrupt+322/592] timer_interrupt+0x142/0x250 [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 [generic_file_write+58/192] generic_file_write+0x3a/0xc0 [sys_recv+5...

...gt;NIP; c003bb34 <unmap_underlying_metadata+e4/15c> <===== Trace; c003bb34 <unmap_underlying_metadata+e4/15c> Trace; c003beb0 <__block_prepare_write+f4/224> Trace; c003c6fc <block_prepare_write+34/68> Trace; d21cf3dc <END_OF_CODE+12000dcc/????> Trace; c002a52c <generic_file_write+418/618> Trace; d21cce00 <END_OF_CODE+11ffe7f0/????> Trace; c0038854 <sys_write+c8/114> Trace; c0003f5c <ret_from_syscall_1+0/b4> Trace; 00000000 Before first symbol Trace; 10002018 Before first symbol Trace; 100019a8 Before first symbol Trace; 10001b54 Before first symbol Trac...

...mode has been significantly improved by this change. ext3 in general seems faster 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 s...

...66e6>] [<c0136a34>] [<c0106ffb>] Code: 0f 0b 83 c4 14 ff 43 08 eb 65 6a 01 68 f0 00 00 00 6a 14 68 >>EIP; c0165908 <journal_start+58/d0> <===== Trace; c016080e <ext3_dirty_inode+6e/100> Trace; c014b58e <__mark_inode_dirty+2e/a0> Trace; c012ae2d <generic_file_write+33d/780> Trace; c0130b83 <add_to_swap_cache+63/b0> Trace; c012db40 <do_ccupdate_local+0/40> Trace; c015060b <write_dquot+ab/100> Trace; c0150a50 <dqput+70/d0> Trace; c015196b <dquot_drop+3b/50> Trace; c014c03a <clear_inode+7a/100> Trace; c014b44f <destroy_i...

...t;c014a349>] block_prepare_write [kernel] 0x39 (0xdb5c7eb4)) [<f885c660>] ext3_get_block [ext3] 0x0 (0xdb5c7ec8)) [<f885cc43>] ext3_prepare_write [ext3] 0xa3 (0xdb5c7ed4)) [<f885c660>] ext3_get_block [ext3] 0x0 (0xdb5c7ee4)) [<c013636d>] generic_file_write [kernel] 0x44d (0xdb5c7f04)) [<f885a089>] ext3_file_write [ext3] 0x39 (0xdb5c7f74)) [<c0146e93>] sys_write [kernel] 0xa3 (0xdb5c7f94)) [<c0109537>] system_call [kernel] 0x33 (0xdb5c7fc0)) Code: Bad EIP value....

Hello. On a server running 2.4.25, I have the two following errors in the kernel logfile: Unexpected dirty buffer encountered at do_get_write_access:618 (08:11 blocknr 920707) Unexpected dirty buffer encountered at do_get_write_access:618 (08:11 blocknr 920707) Should I worry about them (disk failure, filesystem damage) ? Thanks. As an addition what does the pair '08:11' means ? Is

...2340 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 00 8b 43 14 39 f0 74 29 85 c0 74 this apeared in our log after that the load went up to 120 (is isposible?) th...

...95a120 c0157be8 c11c7c00 00000001 c01601ae c1788480 c1cdf8b0 Jan 16 12:37:38 frost kernel: 00000000 c3bfbe00 c3d57000 00000001 c014160e c3bfbe00 00000000 00000020 Jan 16 12:37:38 frost kernel: Call Trace: [ext3_dirty_inode+88/208] [do_get_write_access+1198/1232] [__mark_inod e_dirty+46/128] [generic_file_write+836/1696] [do_get_write_access+1198/1232] Jan 16 12:37:38 frost kernel: Call Trace: [<c0157be8>] [<c01601ae>] [<c014160e>] [<c0126494>] [<c01601ae>] Jan 16 12:37:38 frost kernel: [write_dquot+165/256] [dqput+124/240] [dquot_drop+62/80] [ext3_free_inode+230/1 040] [e...

...3:10 kernel: [<d401f963>] ext3_setattr [ext3] 0x1c3 18:03:10 kernel: [<d401d810>] ext3_get_block [ext3] 0x0 18:03:10 kernel: [<c01281db>] do_generic_file_read [kernel] 0x2c3 18:03:10 kernel: [<c0149359>] notify_change [kernel] 0x5d 18:03:10 kernel: [<c012a2aa>] generic_file_write [kernel] 0x5c2 18:03:10 kernel: [<c01348ce>] do_truncate [kernel] 0x46 18:03:10 kernel: [<c0134bd1>] sys_ftruncate [kernel] 0x12d 18:03:10 kernel: [<c01085f7>] system_call [kernel] 0x33 I noticed that an fsck hadn't been done for months, so I did one with this result, i...

...n to merge it a few days hence. Most ext3 work at present is concentrating on -ac kernels. The change rate in Linus' kernels seems to have slowed now, so we'll try to get a 2.4.11 version of ext3 ready for next week. There is a core kernel change in this diff which should be described: generic_file_write() has been altered so that it always calls commit_write(), even if the copy_from_user() faulted. This change is already present in Linus' kernel - it is a generic bugfix which prevents leakage of stale disk data in rare circumstances. lo_send() has also been changed so that it too calls commit...

...00012e 084291c4 c012c0de Jun 19 09:43:26 ldu506 kernel: ffffffff 00000000 0000012e f7b35c2c c277aa90 00000000 0000011b d4327cec Jun 19 09:43:26 ldu506 kernel: Call Trace: [<f8866d60>] journal_dirty_sync_data [ext3] 0x0 (0xf5e5dee4)) Jun 19 09:43:26 ldu506 kernel: [<c01364f5>] generic_file_write [kernel] 0x5d5 (0xf5e5df04)) Jun 19 09:43:26 ldu506 kernel: [<c012c0de>] futex_wait [kernel] 0x10e (0xf5e5df1c)) Jun 19 09:43:26 ldu506 kernel: [<f8864089>] ext3_file_write [ext3] 0x39 (0xf5e5df74)) Jun 19 09:43:26 ldu506 kernel: [<c0146e93>] sys_write [kernel] 0xa3 (0xf5e5df9...

...01 c2099900 00000000 0000050c 00000000 c28b7f54 00000513 00000000 c28d5000 c2e7d7c0 00000200 00000000 Call Trace: [tvecs+35755/73400] [tvecs+36079/73400] [__block_prepare_write+238/544] [cont_prepare_write+473/736] [fat_get_block+0/288] [fat_prepare_write+38/48] [fat_get_block+0/288] [generic_file_write+929/1344] [default_fat_file_write+34/96] [fat_file_write+45/64] [sys_write+214/256] [system_call+52/64] [startup_32+43/310] Code: 0f 0b 83 c4 0c b8 fb ff ff ff 5b 5e 5f 5d 83 c4 04 c3 8b 86 [extract from /usr/src/linux/fs/fat/file.c ] [snip] 68: if (!(iblock<<9 != MSDOS_I(inode)->mmu_priv...

...l: [<d481238d>] journal_start_R79e68e08 [jbd] 0x7d (0xcabafea8)) Feb 4 23:57:37 mail kernel: [<d4822efe>] ext3_prepare_write [ext3] 0x7e (0xcabafeb8)) Feb 4 23:57:37 mail kernel: [<d4822a20>] ext3_get_block [ext3] 0x0 (0xcabafec8)) Feb 4 23:57:37 mail kernel: [<c012c98d>] generic_file_write [kernel] 0x4cd (0xcabafeec)) Feb 4 23:57:37 mail kernel: [<c01158db>] __wake_up [kernel] 0x3b (0xcabaff3c)) Feb 4 23:57:37 mail kernel: [<d4820b02>] ext3_file_write [ext3] 0x22 (0xcabaff5c)) Feb 4 23:57:37 mail kernel: [<c013a036>] sys_write [kernel] 0x96 (0xcabaff7c)) Feb 4 2...

...3:10 kernel: [<d401f963>] ext3_setattr [ext3] 0x1c3 18:03:10 kernel: [<d401d810>] ext3_get_block [ext3] 0x0 18:03:10 kernel: [<c01281db>] do_generic_file_read [kernel] 0x2c3 18:03:10 kernel: [<c0149359>] notify_change [kernel] 0x5d 18:03:10 kernel: [<c012a2aa>] generic_file_write [kernel] 0x5c2 18:03:10 kernel: [<c01348ce>] do_truncate [kernel] 0x46 18:03:10 kernel: [<c0134bd1>] sys_ftruncate [kernel] 0x12d 18:03:10 kernel: [<c01085f7>] system_call [kernel] 0x33 I noticed that an fsck hadn't been done for months, so I did one with this result, i...

...__jbd_kmalloc+39/160] [block_prepare_write+29/64] [ext3_get_block+0/96] [ext3_prepare_write+124/288] Apr 17 21:40:13 mofo kernel: [<c0150189>] [<c012f126>] [<c015e757>] [<c012f9ad>] [<c0150130>] [<c01505dc>] Apr 17 21:40:13 mofo kernel: [ext3_get_block+0/96] [generic_file_write+1185/1760] [ext3_file_write+31/176] [sys_write+149/240] [schedule+786/832] [system_call+51/56] Apr 17 21:40:13 mofo kernel: [<c0150130>] [<c0122b91>] [<c014e13f>] [<c012ce25>] [<c0110222>] [<c0106d83>] Apr 17 21:40:13 mofo kernel: Apr 17 21:40:13 mofo kernel: C...

Hello, I have today released an initial version of extended attributes and access control lists for ext3 (patch against the 2.4.13-ac3 kernel). Eric Jarman <ejarman@acm.org> has contributed a lot to this effort. Since I'm not very much into the innards of ext3, can some of you please take a look at the patch, and see whether it contains any flaws (and tell me which flaws)? Thanks! The

...;[jbd]__ksymtab_journal_enable_debug+1f/28> Trace; f88b4ff4 <[jbd]__ksymtab_journal_ack_err+0/8> Trace; f88b5da0 <[jbd]__kstrtab_journal_enable_debug+811/5be5> Trace; f88c4bc0 <[ext3]ext3_dirty_inode+160/180> Trace; c0157ff5 <__mark_inode_dirty+b5/4e0> Trace; c0131f7a <generic_file_write+2ba/2bb0> Trace; c01de57f <scsi_io_completion+16f/850> Trace; c0138bb5 <free_pages+535/27c0> Trace; f88bf0c9 <[ext3]ext3_file_write+39/d0> Trace; c015e991 <seq_printf+f01/a9c0> Trace; c015ee7c <seq_printf+13ec/a9c0> Trace; c015ff11 <seq_printf+2481/a9c0> Trace...