From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751891AbdJEKtY (ORCPT ); Thu, 5 Oct 2017 06:49:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:38373 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751412AbdJEKtW (ORCPT ); Thu, 5 Oct 2017 06:49:22 -0400 Date: Thu, 5 Oct 2017 12:49:18 +0200 From: Michal Hocko To: Tetsuo Handa Cc: Johannes Weiner , Andrew Morton , Alan Cox , Christoph Hellwig , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed" Message-ID: <20171005104918.zguzsw3mh2oqytx6@dhcp22.suse.cz> References: <20171003225504.GA966@cmpxchg.org> <20171004185813.GA2136@cmpxchg.org> <20171004185906.GB2136@cmpxchg.org> <20171004153245.2b08d831688bb8c66ef64708@linux-foundation.org> <20171004231821.GA3610@cmpxchg.org> <20171005075704.enxdgjteoe4vgbag@dhcp22.suse.cz> <55d8bf19-3f29-6264-f954-8749ea234efd@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55d8bf19-3f29-6264-f954-8749ea234efd@I-love.SAKURA.ne.jp> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 05-10-17 19:36:17, Tetsuo Handa wrote: > On 2017/10/05 16:57, Michal Hocko wrote: > > On Wed 04-10-17 19:18:21, Johannes Weiner wrote: > >> On Wed, Oct 04, 2017 at 03:32:45PM -0700, Andrew Morton wrote: > > [...] > >>> You don't think they should be backported into -stables? > >> > >> Good point. For this one, it makes sense to CC stable, for 4.11 and > >> up. The second patch is more of a fortification against potential > >> future issues, and probably shouldn't go into stable. > > > > I am not against. It is true that the memory reserves depletion fix was > > theoretical because I haven't seen any real life bug. I would argue that > > the more robust allocation failure behavior is a stable candidate as > > well, though, because the allocation can fail regardless of the vmalloc > > revert. It is less likely but still possible. > > > > I don't want this patch backported. If you want to backport, > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way. > > On 2017/10/04 17:33, Michal Hocko wrote: > > Now that we have cd04ae1e2dc8 ("mm, oom: do not rely on TIF_MEMDIE for > > memory reserves access") the risk of the memory depletion is much > > smaller so reverting the above commit should be acceptable. > > Are you aware that stable kernels do not have cd04ae1e2dc8 ? yes > We added fatal_signal_pending() check inside read()/write() loop > because one read()/write() request could consume 2GB of kernel memory. yes, because this is easily trigerable by userspace. > What if there is a kernel module which uses vmalloc(1GB) from some > ioctl() for legitimate reason? You are going to allow such vmalloc() > calls to deplete memory reserves completely. Do you have any specific example in mind? If yes we can handle it. -- Michal Hocko SUSE Labs