On Wed, 2007-05-16 at 22:39 +1000, Nick Piggin wrote: > > ======================= > > BUG: at /local/xslaby/xxx/mm/page-writeback.c:829 > > __set_page_dirty_nobuffers() > > [<c010531e>] dump_trace+0x1ce/0x200 > > [<c010536a>] show_trace_log_lvl+0x1a/0x30 > > [<c0106012>] show_trace+0x12/0x20 > > [<c0106086>] dump_stack+0x16/0x20 > > [<c015566d>] __set_page_dirty_nobuffers+0x11d/0x130 > > [<f8b1fc5b>] nfs_updatepage+0x7b/0x200 [nfs] > > [<f8b156df>] nfs_commit_write+0x2f/0x50 [nfs] > > [<c0150911>] generic_file_buffered_write+0x2a1/0x660 > > [<c0150f52>] __generic_file_aio_write_nolock+0x282/0x520 > > [<c0151252>] generic_file_aio_write+0x62/0xd0 > > [<f8b15def>] nfs_file_write+0xef/0x1c0 [nfs] > > [<c01715e0>] do_sync_write+0xd0/0x110 > > [<c0171e04>] vfs_write+0x94/0x130 > > [<c017248d>] sys_write+0x3d/0x70 > > [<c01040e8>] syscall_call+0x7/0xb > > [<b7eb7b3e>] 0xb7eb7b3e > > ======================= > > This one is NFS, setting the page dirty while it is not uptodate. Trond, > is this because NFS keeps track of dirty regions of the page with private > data? It might make sense to avoid this warning if PagePrivate is set... > would that fix the NFS case?
Ah... You put an extra WARN_ON(!PageUptodate(page)). err=-ENOCOFFEE, I missed that... So yes, in order to avoid having to read the page in when we just want to write data, NFS does this kind of tracking. I dunno if your fix to change it to !PagePrivate(page) && !PageUptodate(page) is right though. It will indeed fix the NFS case, but the block system uses PagePrivate() pretty extensively for its own nefarious ends (tracking page buffers). Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
