> On Fri, 27 Apr 2012, Minchan Kim wrote:> >>> Maybe a per-thread_info variant of gfp_allowed_mask? So Andrew's >>> set_current_gfp() becomes set_current_gfp_allowed() that does>>>>>> void set_current_gfp_allowed(gfp_t gfp_mask)>>> {>>> current->gfp_allowed = gfp_mask & gfp_allowed_mask;>>> }>>>>>> and then the page allocator does>>>>>> gfp_mask &= current->gfp_allowed;>>>>>> rather than how it currently does>>>>>> gfp_mask &= gfp_allowed_mask;>>>>>> and then the caller of set_current_gfp_allowed() cleans up with >>> set_current_gfp_allowed(__GFP_BITS_MASK).>>> > [trimmed the newsgroups from the reply, not sure what the point is?]> >> Caller should restore old gfp_mask instead of __GFP_BITS_MASK in case of>> nesting.And how do we care of atomic context?>>> > Eek, I'm hoping these aren't going to be nested but sure that seems > appropraite if they are. (I'm also hoping these will only be either > __GFP_HIGH or __GFP_BITS_MASK and no other combinations.)> > Forcing atomic context would just be set_current_gfp_allowed(__GFP_HIGH).

I mean it's not legal to access _current_ in atomic context so that(gfp_mask &= current->gfp_allowed in page allocator) shouldn't.