Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752906AbdHBKuW (ORCPT ); Wed, 2 Aug 2017 06:50:22 -0400 Received: from mx2.suse.de ([195.135.220.15]:38732 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751154AbdHBKuV (ORCPT ); Wed, 2 Aug 2017 06:50:21 -0400 Date: Wed, 2 Aug 2017 12:50:18 +0200 From: Michal Hocko To: Jeff Vander Stoep Cc: Paul Moore , linux-mm@kvack.org, LKML Subject: suspicious __GFP_NOMEMALLOC in selinux Message-ID: <20170802105018.GA2529@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 724 Lines: 18 Hi, while doing something completely unrelated to selinux I've noticed a really strange __GFP_NOMEMALLOC usage pattern in selinux, especially GFP_ATOMIC | __GFP_NOMEMALLOC doesn't make much sense to me. GFP_ATOMIC on its own allows to access memory reserves while the later flag tells we cannot use memory reserves at all. The primary usecase for __GFP_NOMEMALLOC is to override a global PF_MEMALLOC should there be a need. It all leads to fa1aa143ac4a ("selinux: extended permissions for ioctls") which doesn't explain this aspect so let me ask. Why is the flag used at all? Moreover shouldn't GFP_ATOMIC be actually GFP_NOWAIT. What makes this path important to access memory reserves? Thanks -- Michal Hocko SUSE Labs