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 678AAC433FE for ; Fri, 24 Sep 2021 07:55:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 539BA60F39 for ; Fri, 24 Sep 2021 07:55:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244502AbhIXH4r (ORCPT ); Fri, 24 Sep 2021 03:56:47 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:58268 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244495AbhIXH4o (ORCPT ); Fri, 24 Sep 2021 03:56:44 -0400 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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