From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Gaughen Subject: Re: BUG in reiserfs_write_full_page(). Date: Fri, 18 Jul 2003 11:42:33 -0700 Message-ID: <3F183F99.7080405@polyserve.com> References: <3F1712F6.7080204@polyserve.com> <1058477610.4012.333.camel@tiny.suse.com> <3F171ABF.6080601@polyserve.com> <1058534583.7878.351.camel@tiny.suse.com> <16151.63980.766223.769053@laputa.namesys.com> <1058536844.7878.371.camel@tiny.suse.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <1058536844.7878.371.camel@tiny.suse.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Chris Mason Cc: Nikita Danilov , reiserfs-list@namesys.com Chris Mason wrote: >On Fri, 2003-07-18 at 09:45, Nikita Danilov wrote: > > >> > >> > But, we shouldn't have to. Other parts of the OS should be protecting >> > us from a writepage being called at this time, which is why the bug is >> > there. Someone did a non GFP_NOFS allocation with a transaction >> >>__bread()->__getblk()->__find_get_block()->find_get_page() allocates >>page with bdev->bd_inode->i_mapping->gfp_flags, which is GFP_USER, that >>includes GFP_FS. >> >> > >You're in 2.5 land ;-) There seem to be a few problems there, I've got >an oops in find_inode and a deadlock under load, but I still need to >read the (huge) sysrq-t to figure things out. > But, in 2.4, the page fault handling code also gets the gfp_mask from the inode's address_space gfp_mask (in ->page_cache_read()->page_cache_alloc()). It looks like clean_inode() sets the gfp_mask to GFP_HIGHUSER, which also includes GFP_FS, and unless I am missing something, I don't see that GFP_FS is ever cleared in this case. -Mike