Messages in this thread | | | Date | Fri, 6 Oct 2006 19:33:11 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] VM: Fix the gfp_mask in invalidate_complete_page2 |
| |
On Fri, 06 Oct 2006 19:09:29 -0400 Steve Dickson <SteveD@redhat.com> wrote:
> > > > It's not 100% clear what the gfp_t _means_ in the try_to_release_page() > > context. Callees will rarely want to allocate memory (true?). So it > > conveys two concepts: > > > > a) can sleep. (__GFP_WAIT). That's fairly straightforward > > > > b) can take fs locks (__GFP_FS). This is less clear. By passing down > > __GFP_FS we're telling the callee that it's OK to take i_mutex, even > > lock_page(). That sounds pretty unsafe in this context, particularly > > the latter, as we're already holding a page lock. > > > > So perhaps the safer and more appropriate solution here is to pass in a > > bare __GFP_WAIT. > I agree... __GFP_WAIT does seem to be a bit more straightforward... > either way is find.. as long as it cause NFS to flush its pages...
Except NFS looks at __GFP_FS, so __GFP_WAIT won't help.
Oh well. Passing __GFP_FS in here sort-of implies that it's OK to run lock_page(), but if a ->releasepage() impementation tries to lock the page it's passed then it needs its head read.
I made it GFP_KERNEL. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |