From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AE3FC433EF for ; Fri, 24 Sep 2021 07:55:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2CF5061242 for ; Fri, 24 Sep 2021 07:55:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2CF5061242 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A27216B006C; Fri, 24 Sep 2021 03:55:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D6686B0071; Fri, 24 Sep 2021 03:55:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C58C6B0073; Fri, 24 Sep 2021 03:55:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id 801D96B006C for ; Fri, 24 Sep 2021 03:55:13 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2670E30141 for ; Fri, 24 Sep 2021 07:55:13 +0000 (UTC) X-FDA: 78621706506.19.E0CD843 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf19.hostedemail.com (Postfix) with ESMTP id 8B5C5B0000AC for ; Fri, 24 Sep 2021 07:55:12 +0000 (UTC) Received: from relay1.suse.de (relay1.suse.de [149.44.160.133]) by smtp-out1.suse.de (Postfix) with ESMTP id 41DDE22416; Fri, 24 Sep 2021 07:55:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1632470111; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6+5dT0e/LVnNHHcl0ABQyeUOLyC28rt8o7MtGQJ16Wk=; b=KWiNL3UHQbuoAkuBsiy3YSQftN/E2jhVDCGJVJ4SuDi14ga6EYTPLdskYk6XwXRICZFsXG bEWK+3mJ2tb2wipT9UFRw4dJv04b+FFJK7rjY3eOiFx60uVYVav5B3hKKV06bppDfRyf6C q8TEmpzdS0lmOTDDH+ryD1WOMtFlK0k= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay1.suse.de (Postfix) with ESMTPS id C507B25CCD; Fri, 24 Sep 2021 07:55:10 +0000 (UTC) Date: Fri, 24 Sep 2021 09:55:08 +0200 From: Michal Hocko To: Vasily Averin Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , Tetsuo Handa , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@openvz.org Subject: Re: [PATCH mm] vmalloc: back off when the current task is OOM-killed Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 8B5C5B0000AC X-Stat-Signature: e7g573p8pynh9dw19z3ntani4zfgpqgg Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=KWiNL3UH; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1632470112-372559 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu 23-09-21 09:49:57, Vasily Averin wrote: [...] > I'm agree that vmalloc callers should expect and handle single vnalloc failures. > I think it is acceptable to enable fatal_signal_pending check to quickly > detect such kind of iussues. > However fatal_signal_pending check can cause serial vmalloc failures > and I doubt it is acceptable. > > Rollback after failed vmalloc can call new vmalloc calls that will be failed too, > even properly handled such serial failures can cause troubles. Could you be more specific? Also how would this be any different from similar failures for an oom victim? Except that the later is less likely so (as already mentioend) any potential bugs would be just lurking there for a longer time. > Hypothetically, cancelled vmalloc called inside some filesystem's transaction > forces its rollback, that in own turn it can call own vmalloc. Do you have any specific example? > Any failures on this path can break the filesystem. > I doubt it is acceptable, especially for non-OOM fatal signals. > On the other hand I cannot say that it is a 100% bug. > > Another scenario: > as you know failed vmalloc calls pr_warn. According message should be sent > to remote terminal or netconsole. I'm not sure about execution context, > however if this is done in task context it may call vmalloc either in terminal > or in network subsystems. Even handled, such failures are not fatal, > but this behaviour is at least unexpected. I do not think we want to shape the vmalloc bahavior based on printk/console behavior. > Should we perhaps interrupt the first vmalloc only? This doesn't make much sense to me TBH. It doesn't address the very problem you are describing in the changelog. -- Michal Hocko SUSE Labs