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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 105D6C433F5 for ; Tue, 7 Dec 2021 10:55:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A2F96B00B3; Tue, 7 Dec 2021 05:55:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 452BC6B00B4; Tue, 7 Dec 2021 05:55:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 342126B00B5; Tue, 7 Dec 2021 05:55:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0071.hostedemail.com [216.40.44.71]) by kanga.kvack.org (Postfix) with ESMTP id 25E226B00B3 for ; Tue, 7 Dec 2021 05:55:30 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id DCA9B83C42 for ; Tue, 7 Dec 2021 10:55:19 +0000 (UTC) X-FDA: 78890691558.13.B0126D2 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf14.hostedemail.com (Postfix) with ESMTP id 5A2966001982 for ; Tue, 7 Dec 2021 10:55:19 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 5B2B921B3D; Tue, 7 Dec 2021 10:55:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1638874518; 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=1fS/vZbZh9msdrSxyTZbVy9qyqqHF1IQgs77NLVOK1g=; b=DcexllzdzIygPzm1O6ITBxn1OVM+v/TKIxjtMcpFIznmSgUaeV4pTJXNKnZkJ1tTMETZve xX061YO4S/dImpkuT/1mTniO7Q8+kHa1mZum0h/5kjY/heaFyCk+TOkFGG1k+GV5fC1wtk k4EDDXtg2uQraU/aB/8LV3m6IHkD2PI= 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 relay2.suse.de (Postfix) with ESMTPS id 2AC0EA3B83; Tue, 7 Dec 2021 10:55:18 +0000 (UTC) Date: Tue, 7 Dec 2021 11:55:17 +0100 From: Michal Hocko To: David Hildenbrand , Nico Pache , Rafael Aquini Cc: Yang Shi , Kirill Tkhai , Linux Kernel Mailing List , Linux MM , Andrew Morton , Shakeel Butt , Roman Gushchin , Vlastimil Babka , Vladimir Davydov , raquini@redhat.com Subject: Re: [RFC PATCH 2/2] mm/vmscan.c: Prevent allocating shrinker_info on offlined nodes Message-ID: References: <20211206033338.743270-1-npache@redhat.com> <20211206033338.743270-3-npache@redhat.com> <24b4455c-aff9-ca9f-e29f-350833e7a0d1@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 9spzxid778twtqi9d4rmd3gh1rbpdtnq Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Dcexllzd; spf=pass (imf14.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-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 5A2966001982 X-HE-Tag: 1638874519-809353 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 Mon 06-12-21 20:01:34, David Hildenbrand wrote: [...] > Yes, that's what I refer to as fixing it in the caller -- similar to > [1]. Michals point is to not require such node_online() checks at all, > neither in the caller nor in the buddy. > > I see 2 options short-term > > 1) What we have in [1]. > 2) What I proposed in [2], fixing it for all such instances until we > have something better. > > Long term I tend to agree that what Michal proposes is better. > > Short term I tend to like [2], because it avoids having to mess with all > such instances to eventually get it right and the temporary overhead > until we have the code reworked should be really negligible ... I do dislike both but if I were to chose which to chose between the two then 2 is surely more targeted. We really do not want to spread this into bulk/pcp or whatever other allocator there is. The problem is that somebody might still try to access NODE_DATA (e.g. via a helper that hides that fact). Anyway, I am not sure whether authors of the patch can reproduce the problem and whether they can run a testing code on their machine. If yes it would be great to try with http://lkml.kernel.org/r/Ya89aqij6nMwJrIZ@dhcp22.suse.cz that I have just sent. > [1] https://lkml.kernel.org/r/20211108202325.20304-1-amakhalov@vmware.com > [2] > https://lkml.kernel.org/r/51c65635-1dae-6ba4-daf9-db9df0ec35d8@redhat.com > > -- > Thanks, > > David / dhildenb -- Michal Hocko SUSE Labs