On Mon, 5 Oct 2015 15:47:13 +0200 Michal Hocko <mho...@kernel.org> wrote:
> > The fourth best way of fixing this is a nasty short-term bodge, such a > > the one you just sent ;) But if we're going to do this, it should be > > the minimal bodge which fixes this deadlock. Is it possible to come up > > with a one-liner (plus suitable comment) to get us out of this mess? > > Yes I do agree that the fix I am proposing is short-term but this seems > like the easiest way to go for stable and older kernels that might be > affected. I thought your proposal for mapping_gfp_constraint was exactly > to have all such places annotated for an easier future transition to > something more reasonable. hm, OK, let's go that way. But I expect this mess will continue to float around for a long time - fixing it nicely will be somewhat intrusive. > > Longer-term I suggest we look at generalising the memalloc_noio_foo() > > stuff so as to permit callers to mask off (ie: zero) __GFP_ flags in > > callees. I have a suspicion we should have done this 15 years ago > > (which is about when I started wanting to do it). > > I am not sure memalloc_noio_foo is a huge win. It is an easy hack where > the whole allocation transaction is clear - like in the PM code. I am > not sure this is true also for the FS. mm.. I think it'll work out OK - a set/restore around particular callsites. It might get messy in core MM though. Do we apply current->mask at the very low levels of the page allocator? If so, that might muck up intermediate callers who are peeking into specific gfp_t flags. Perhaps it would be better to apply the mask at the highest possible level: wherever a function which was not passed a gfp_t decides to create one. Basically a grep for "GFP_". But then we need to decide *which* gfp_t-creators need the treatment. All of them (yikes) or is this mechanism only for called-via-address_space_operations code? That might work. Maybe it would be better to add the gfp_t argument to the address_space_operations. At a minimum, writepage(), readpage(), writepages(), readpages(). What a pickle. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
