Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752614AbdHDRMK (ORCPT ); Fri, 4 Aug 2017 13:12:10 -0400 Received: from mail-lf0-f49.google.com ([209.85.215.49]:36869 "EHLO mail-lf0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752608AbdHDRMH (ORCPT ); Fri, 4 Aug 2017 13:12:07 -0400 MIME-Version: 1.0 X-Originating-IP: [108.49.102.27] In-Reply-To: <20170804075636.GD26029@dhcp22.suse.cz> References: <20170802105018.GA2529@dhcp22.suse.cz> <20170803081152.GC12521@dhcp22.suse.cz> <5aca0179-3b04-aa1a-58cd-668a04f63ae7@I-love.SAKURA.ne.jp> <20170803103337.GH12521@dhcp22.suse.cz> <201708031944.JCB39029.SJOOOLHFQFMVFt@I-love.SAKURA.ne.jp> <20170803110548.GK12521@dhcp22.suse.cz> <20170804075636.GD26029@dhcp22.suse.cz> From: Paul Moore Date: Fri, 4 Aug 2017 13:12:04 -0400 Message-ID: Subject: Re: suspicious __GFP_NOMEMALLOC in selinux To: Michal Hocko Cc: Tetsuo Handa , mgorman@suse.de, linux-kernel@vger.kernel.org, linux-mm@kvack.org, selinux@tycho.nsa.gov Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1624 Lines: 36 On Fri, Aug 4, 2017 at 3:56 AM, Michal Hocko wrote: > On Thu 03-08-17 14:17:26, Paul Moore wrote: >> On Thu, Aug 3, 2017 at 7:05 AM, Michal Hocko wrote: >> > On Thu 03-08-17 19:44:46, Tetsuo Handa wrote: > [...] >> >> When allocating thread is selected as an OOM victim, it gets TIF_MEMDIE. >> >> Since that function might be called from !in_interrupt() context, it is >> >> possible that gfp_pfmemalloc_allowed() returns true due to TIF_MEMDIE and >> >> the OOM victim will dip into memory reserves even when allocation failure >> >> is not a problem. >> > >> > Yes this is possible but I do not see any major problem with that. >> > I wouldn't add __GFP_NOMEMALLOC unless there is a real runaway of some >> > sort that could be abused. >> >> Adding __GFP_NOMEMALLOC would not hurt anything would it? > > I is not harmfull but I fail to see how it would be useful either and as > such it just adds a pointless gfp flag and confusion to whoever tries to > modify the code in future. Really the main purpose of __GFP_NOMEMALLOC > is to override the process scope PF_MEMALLOC. As such it is quite a hack > and the fewer users we have the better. Okay, that is a viable explanation for me. > Btw. Should I resend the patch or somebody will take it from this email > thread? No, unless your mailer mangled the patch I should be able to pull it from this thread. However, I'm probably going to let this sit until early next week on the odd chance that anyone else wants to comment on the flag choice. I'll send another reply once I merge the patch. -- paul moore www.paul-moore.com