From: Michal Hocko <mhocko@kernel.org> To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Johannes Weiner <hannes@cmpxchg.org>, Andrew Morton <akpm@linux-foundation.org>, Alan Cox <alan@llwyncelyn.cymru>, Christoph Hellwig <hch@lst.de>, 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" Date: Thu, 5 Oct 2017 12:49:18 +0200 [thread overview] Message-ID: <20171005104918.zguzsw3mh2oqytx6@dhcp22.suse.cz> (raw) In-Reply-To: <55d8bf19-3f29-6264-f954-8749ea234efd@I-love.SAKURA.ne.jp> 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
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Johannes Weiner <hannes@cmpxchg.org>, Andrew Morton <akpm@linux-foundation.org>, Alan Cox <alan@llwyncelyn.cymru>, Christoph Hellwig <hch@lst.de>, 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" Date: Thu, 5 Oct 2017 12:49:18 +0200 [thread overview] Message-ID: <20171005104918.zguzsw3mh2oqytx6@dhcp22.suse.cz> (raw) In-Reply-To: <55d8bf19-3f29-6264-f954-8749ea234efd@I-love.SAKURA.ne.jp> 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 -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-10-05 10:49 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-10-03 22:55 tty crash due to auto-failing vmalloc Johannes Weiner 2017-10-03 22:55 ` Johannes Weiner 2017-10-03 23:51 ` Alan Cox 2017-10-03 23:51 ` Alan Cox 2017-10-04 8:33 ` Michal Hocko 2017-10-04 8:33 ` Michal Hocko 2017-10-04 18:58 ` Johannes Weiner 2017-10-04 18:58 ` Johannes Weiner 2017-10-04 18:59 ` [PATCH 1/2] Revert "vmalloc: back off when the current task is killed" Johannes Weiner 2017-10-04 18:59 ` Johannes Weiner 2017-10-04 20:49 ` Tetsuo Handa 2017-10-04 20:49 ` Tetsuo Handa 2017-10-04 21:00 ` Johannes Weiner 2017-10-04 21:00 ` Johannes Weiner 2017-10-04 21:42 ` Tetsuo Handa 2017-10-04 21:42 ` Tetsuo Handa 2017-10-04 23:21 ` Johannes Weiner 2017-10-04 23:21 ` Johannes Weiner 2017-10-04 22:32 ` Andrew Morton 2017-10-04 22:32 ` Andrew Morton 2017-10-04 23:18 ` Johannes Weiner 2017-10-04 23:18 ` Johannes Weiner 2017-10-05 7:57 ` Michal Hocko 2017-10-05 7:57 ` Michal Hocko 2017-10-05 10:36 ` Tetsuo Handa 2017-10-05 10:36 ` Tetsuo Handa 2017-10-05 10:49 ` Michal Hocko [this message] 2017-10-05 10:49 ` Michal Hocko 2017-10-07 2:21 ` Tetsuo Handa 2017-10-07 2:21 ` Tetsuo Handa 2017-10-07 2:51 ` Johannes Weiner 2017-10-07 2:51 ` Johannes Weiner 2017-10-07 4:05 ` Tetsuo Handa 2017-10-07 4:05 ` Tetsuo Handa 2017-10-07 7:59 ` Michal Hocko 2017-10-07 7:59 ` Michal Hocko 2017-10-07 9:57 ` Tetsuo Handa 2017-10-07 9:57 ` Tetsuo Handa 2017-10-05 6:49 ` Vlastimil Babka 2017-10-05 6:49 ` Vlastimil Babka 2017-10-05 7:54 ` Michal Hocko 2017-10-05 7:54 ` Michal Hocko 2017-10-04 18:59 ` [PATCH 2/2] tty: fall back to N_NULL if switching to N_TTY fails during hangup Johannes Weiner 2017-10-04 18:59 ` Johannes Weiner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20171005104918.zguzsw3mh2oqytx6@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=alan@llwyncelyn.cymru \ --cc=hannes@cmpxchg.org \ --cc=hch@lst.de \ --cc=kernel-team@fb.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=penguin-kernel@I-love.SAKURA.ne.jp \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.