Messages in this thread | | | Date | Mon, 5 Oct 2015 12:29:36 -0700 | From | Andrew Morton <> | Subject | Re: linux-next: kernel BUG at mm/slub.c:1447! |
| |
On Mon, 5 Oct 2015 15:47:13 +0200 Michal Hocko <mhocko@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.
| |