lkml.org 
[lkml]   [2020]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] mm/page_alloc.c: avoid inheritting current's flags when invoked in interrupt
From
Date


On 9/16/20 9:17 AM, Andrew Morton wrote:
> On Tue, 15 Sep 2020 15:56:35 +0800 <yanfei.xu@windriver.com> wrote:
>
>> From: Yanfei Xu <yanfei.xu@windriver.com>
>>
>> alloc_mask shouldn't inherit the current task's flags when
>> __alloc_pages_nodemask is invoked in interrupt.
>>
>> ...
>>
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -4889,7 +4889,8 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid,
>> * from a particular context which has been marked by
>> * memalloc_no{fs,io}_{save,restore}.
>> */
>> - alloc_mask = current_gfp_context(gfp_mask);
>> + if (!in_interrupt())
>> + alloc_mask = current_gfp_context(gfp_mask);
>> ac.spread_dirty_pages = false;
>>
>> /*
>
> hm, yes, and perhaps other callsites in page_alloc.c.
>
> I assume this doesn't actually make any runtime difference? Because
> gfp_mask in interrupt contexts isn't going to have __GFP_IO or __GFP_FS
> anyway.
>
Thanks for your reply!

Yes, It doesn't make any runtime difference. Theoretically, GPF_ATOMIC
or GFP_NOWAIT should be used in interrupt context for allocate pages, so
that gfp_mask isn't going to have __GFP_IO or __GFP_FS.

But if somebody use wrong gfp_masks, __GFP_IO or __GFP_FS will be
introduced, with the process interrupted has PF_MEMALLOC_NOIO or
PF_MEMALLOC_NOFS, current_gfp_context may help to hide these wrong
usages. I don't think it is the original purpose of that piece of
codes.

And how about add BUG_ON or WARN_ON to figure out the situation which
introduce __GFP_IO or __GFP_FS in interrupt context?

Regards,
Yanfei

\
 
 \ /
  Last update: 2020-09-16 05:48    [W:0.049 / U:13.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site