From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id C23B96B0005 for ; Wed, 27 Apr 2016 09:07:15 -0400 (EDT) Received: by mail-wm0-f72.google.com with SMTP id s63so38493679wme.2 for ; Wed, 27 Apr 2016 06:07:15 -0700 (PDT) Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com. [74.125.82.66]) by mx.google.com with ESMTPS id ko8si4296059wjc.212.2016.04.27.06.07.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Apr 2016 06:07:14 -0700 (PDT) Received: by mail-wm0-f66.google.com with SMTP id w143so12835393wmw.3 for ; Wed, 27 Apr 2016 06:07:14 -0700 (PDT) Date: Wed, 27 Apr 2016 15:07:12 +0200 From: Michal Hocko Subject: Re: [PATCH 1.2/2] mm: introduce memalloc_nofs_{save,restore} API Message-ID: <20160427130712.GK2179@dhcp22.suse.cz> References: <1461671772-1269-2-git-send-email-mhocko@kernel.org> <1461758075-21815-1-git-send-email-mhocko@kernel.org> <1461758075-21815-2-git-send-email-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1461758075-21815-2-git-send-email-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Cc: Andrew Morton , Dave Chinner , Theodore Ts'o , Chris Mason , Jan Kara , ceph-devel@vger.kernel.org, cluster-devel@redhat.com, linux-nfs@vger.kernel.org, logfs@logfs.org, xfs@oss.sgi.com, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mtd@lists.infradead.org, reiserfs-devel@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, linux-f2fs-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, LKML On Wed 27-04-16 13:54:35, Michal Hocko wrote: > From: Michal Hocko > Ups missed Dave's note about: > GFP_NOFS context is used for the following 4 reasons currently > - to prevent from deadlocks when the lock held by the allocation > context would be needed during the memory reclaim > - to prevent from stack overflows during the reclaim because > the allocation is performed from a deep context already > - to prevent lockups when the allocation context depends on > other reclaimers to make a forward progress indirectly > - just in case because this would be safe from the fs POV - silence lockdep false positives -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org