lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 06 Oct 2006 18:16:30 -0400 From: Trond Myklebust <Trond.Myklebust@...app.com> To: Steve Dickson <SteveD@...hat.com> Cc: Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] VM: Fix the gfp_mask in invalidate_complete_page2 On Fri, 2006-10-06 at 17:49 -0400, Steve Dickson wrote: > Trond Myklebust wrote: > > If try_to_release_page() is called with a zero gfp mask, then the > > filesystem is effectively denied the possibility of sleeping while > > attempting to release the page. There doesn't appear to be any valid > > reason why this should be banned, given that we're not calling this from > > a memory allocation context. > > > > For this reason, change the gfp_mask argument of the call to GFP_KERNEL. > > > > Note: I am less sure of what the callers of invalidate_complete_page() > > require, and so this patch does not touch that mask. > > > > Signed-off-by: Trond Myklebust <Trond.Myklebust@...app.com> > > --- > > diff --git a/mm/truncate.c b/mm/truncate.c > > index f4edbc1..49c1ffd 100644 > > --- a/mm/truncate.c > > +++ b/mm/truncate.c > > @@ -302,7 +302,7 @@ invalidate_complete_page2(struct address > > if (page->mapping != mapping) > > return 0; > > > > - if (PagePrivate(page) && !try_to_release_page(page, 0)) > > + if (PagePrivate(page) && !try_to_release_page(page, GFP_KERNEL)) > > return 0; > > > > write_lock_irq(&mapping->tree_lock); > Well I was using mapping_gfp_mask(mapping) as the argument to > try_to_release_page() which also worked... but isn't this > just plugging one of many holes? Yeah using mapping_gfp_mask(mapping) sounds like a better option. ...and yes, there are other callers that need to be audited. I'm particularly curious about the effect of the call in block_invalidatepage() on XFS, which has a similar test to ours. The call in fallback_migrate_page() should probably be using mapping_gfp_mask() too. > Meaning try_to_release_page is called > from a number of places with a zero gfp_mask so shouldn't those > also be fixed as well OR removed the gfp_mask as an argument as the > comment at the top of try_to_release_page() alludes to? Nope. In order to make it work correctly with NFS and XFS, all calls to try_to_release_page() would have to be allowed to be blocking. The problem is that shrink_page_list() still wants to call try_to_release_page() from a memory allocation context. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists