Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 30 Apr 2012 10:25:32 +0900 | From | Minchan Kim <> | Subject | Re: [RFC] propagate gfp_t to page table alloc functions |
| |
On 04/27/2012 07:43 PM, David Rientjes wrote:
> 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.
-- Kind regards, Minchan Kim
| ![\](/images/icornerr.gif) |