Received: by 10.223.176.5 with SMTP id f5csp2596566wra; Mon, 29 Jan 2018 00:28:27 -0800 (PST) X-Google-Smtp-Source: AH8x225etL2hgKOtdMfhOEYi5/jammGLwmlopj5nUQUAHgeLTSxVTDEwBMlFZbcifBW22AW/VJar X-Received: by 10.101.80.204 with SMTP id s12mr4082833pgp.185.1517214506898; Mon, 29 Jan 2018 00:28:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517214506; cv=none; d=google.com; s=arc-20160816; b=Uhscznlmi+DCgsc2fpCx6UnL+ardu4MPQXOsjix+YO6bV+Zz97TyV/dfwruqbjHNIN bxrlk53+piLG0Asorw6pm5vNEExV5ZsLUqcvJQGpjQ7lLDymE3wC1dhxKVAOJxn4cM09 pozQGB/bP5iOevv92K0jTPwefSqvB8cXUR02uj8y9dMT7AY1setTMVrXzaK/gdTzbsMj CpRTZD7iaaAPRs05pc9ElU1nytdftA0Q4SVfJqxstqait2ftQCJDZrRTKTKMgadPfbyb KXmcoBHbjmgjedOHJi+il/tFWCrnHn7TRRj7DlAzGUO7qxFOLu96y9gCWLfwuwo+fSjC N7SA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=9ZnRyGcww8mBasWlpc2XOhGqAfigre8kgqjiwTfUAZc=; b=c+9zyk4cm1U52wTeFnpgcPDgEouM7HzeCDIVlSt6TLrKNtwojHAoEGnjW9aOBkn18u uvX4FM+N10qIa0IBakO2GUMNsvhTaAbm4HH8AsaTmWmvZ1wPqItXsQ2vXe2Vn2A6Gw6h Xzblq1a3hYoc4Zb7Qymc14YfqDbBEfWYpeqDkeFB367BBWk/VfN+c/4xU8yvIxVMmAZU DR4ub0g6+oIt1wCWLoo7Vc/NDnObvRQBY4MmbQnzIkZxpBP4wFrynnMyenOu7iELCs6+ v8IQZUl89pTsGpt5WTi01/yGwc+et+0RrAqPrMjp1D4QLVBNRhC3x2fMg2GwceNAudtb OfHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=g7pwcxBz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e4si11412883pfb.84.2018.01.29.00.28.12; Mon, 29 Jan 2018 00:28:26 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=g7pwcxBz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751575AbeA2I0z (ORCPT + 99 others); Mon, 29 Jan 2018 03:26:55 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:37224 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751537AbeA2I0w (ORCPT ); Mon, 29 Jan 2018 03:26:52 -0500 Received: by mail-wm0-f67.google.com with SMTP id v71so31928140wmv.2 for ; Mon, 29 Jan 2018 00:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=9ZnRyGcww8mBasWlpc2XOhGqAfigre8kgqjiwTfUAZc=; b=g7pwcxBzIF5G8bCCAUaDDwA9iz+9l4CUWUyzzWdM7tBqwov6gEF+gZVOLsDqM6W+yy X2PR6nX0Pwse//beNNU546jTIRr/yjazl6T5FK7Bd8Od6V+TyDznzgn1/0uQULTUDvzb v13Sif0eKvGNxnKvnOCJjL3GpVyQj2DPdGSwGMHhvdp1Wkz9kUuVyLTeGlnICS+hgB3O U6Fa0z3ulCfwhNBJx7+VqSmb/yeD5aKfd8vG+PCIzdzRIAXvPrO6f7cO8QexnFP7w6hi tIgLwoqGdOtcsgihiR64walXbu6jSEen+b9pzcyeZLXg2cYEhXN9hDM/yljswIiqGpkI xj1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=9ZnRyGcww8mBasWlpc2XOhGqAfigre8kgqjiwTfUAZc=; b=Y+WrwXVZ4c5caTPqjxwR2D3YasYQhDL5k4MJ2YBwZGVwBKTF3VFSF230eP3BbEb3jZ LXaAuPva3+KWsAUq6u49thW1JgUuRB0tA8YNc7x/8GY4HAiXPo1RxomWKF/V0ZvARou2 9f9xW70AiAv1yOt/+AwTvDnSSVTnyeRMCmR5zwGp3dslyY5Byb6Gor0zgFUgzd+0ZrXJ TRzITVEaB07LGp+0v87S5TDPfhTfg9tyvBujzCDP8Itpr8CEE8krPnqpqwIbDXB+sp4y pKID3PzUtN9IM4ukzGDTvY3kZFe1VKuZvV5Su1DDgALUOgk796TadvNfbeEvsJMprFgz RaDw== X-Gm-Message-State: AKwxyteHTidg8JS8zR/qFmFFt1QivVcNKjUxbmwsPpt1hGHMCd5D/uHF GNI+S5cXDFyA04NyaC/qLLzddg== X-Received: by 10.80.217.202 with SMTP id x10mr39964821edj.118.1517214411521; Mon, 29 Jan 2018 00:26:51 -0800 (PST) Received: from node.shutemov.name (mm-144-88-44-37.mgts.dynamic.pppoe.byfly.by. [37.44.88.144]) by smtp.gmail.com with ESMTPSA id f55sm6595832ede.77.2018.01.29.00.26.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 00:26:50 -0800 (PST) Received: by node.shutemov.name (Postfix, from userid 1000) id 88D37648D520; Mon, 29 Jan 2018 11:26:49 +0300 (+03) Date: Mon, 29 Jan 2018 11:26:49 +0300 From: "Kirill A. Shutemov" To: Florian Westphal Cc: Tetsuo Handa , davem@davemloft.net, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, aarcange@redhat.com, yang.s@alibaba-inc.com, mhocko@suse.com, syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org, mingo@kernel.org, linux-mm@kvack.org, rientjes@google.com, akpm@linux-foundation.org, guro@fb.com, kirill.shutemov@linux.intel.com Subject: Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2) Message-ID: <20180129082649.sysf57wlp7i7ltb2@node.shutemov.name> References: <001a1144b0caee2e8c0563d9de0a@google.com> <201801290020.w0T0KK8V015938@www262.sakura.ne.jp> <20180129072357.GD5906@breakpoint.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180129072357.GD5906@breakpoint.cc> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 29, 2018 at 08:23:57AM +0100, Florian Westphal wrote: > > vmalloc() once became killable by commit 5d17a73a2ebeb8d1 ("vmalloc: back > > off when the current task is killed") but then became unkillable by commit > > b8c8a338f75e052d ("Revert "vmalloc: back off when the current task is > > killed""). Therefore, we can't handle this problem from MM side. > > Please consider adding some limit from networking side. > > I don't know what "some limit" would be. I would prefer if there was > a way to supress OOM Killer in first place so we can just -ENOMEM user. Just supressing OOM kill is a bad idea. We still leave a way to allocate arbitrary large buffer in kernel. -- Kirill A. Shutemov