Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3509346yba; Mon, 29 Apr 2019 03:46:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqxqrBIYo9rLEFcFGne/3QztIlivMd7wtpVRMbBBLPfUvSG866N5gmUJVnn1Y0vWwMUrv77R X-Received: by 2002:a63:514f:: with SMTP id r15mr19942788pgl.450.1556534783591; Mon, 29 Apr 2019 03:46:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556534783; cv=none; d=google.com; s=arc-20160816; b=UMxWXdsLIuQSzZwwryLMcoz8oTtHwI4lPpKeVv+8aYQsX2O3cZKBum972DoFr8PloX q8vkyBtkE5JnFD4q+MDJA3RQ2Wmd4HU/yODExBCN2G3dYkdiDrzUQW0n3XYrXSZ0LnO1 T/bMknLJbEinbHwk+BpBkvqubh6KFGfCuPOpkPUwwNjnoor2V8TVwGgk+h2nWbmcWujz wF4hgqlH+MCuh0Tgzl0BTtiAOgqBD2bmhKfPi1iNwG2FIxZ7eccJ4zIHZTaJqdouGMe6 D6K5s0fxsJY3TtuMPrbsb3NTEPf+63uG230wdRe5ynMfHcPKctsm5GXllXF6M076RDJt eYqg== 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; bh=yPAqHgLHcEmij8WPte118wLaMPgpUVAlo/nltH8Lk1Q=; b=M1xlANeHOMN7Y5Mn4GAq+szBvDOMBPa78g38JHBZUcZJNlZPJhv3Oa1drfA86ryHRi a/AvqdYlQXDyogCBDlVUk5U4qUBHQjk9dfV+BpEpZnHdV98czfN47gMXoIKc54rCbr6X SCSXcZUTdGzhXsf7JlEo5/s67pYQ5y7amtkd4aLSeGmAmMXqlyHBMyD+fATHoLTg8dlb ZtPycKRL86HV12L7hjq9n1I0V9TXX5a0f550njpVo0pbhwso4ucNR6Bdho+8RIuMlUI8 VznBii3+BQ4rT8RUiY3ivMZ9fO23yg1pZvMFAIIBBVMgyntdlmH4H2ISapBi4MGu9gqP swlA== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3si33705740pfc.92.2019.04.29.03.46.06; Mon, 29 Apr 2019 03:46:23 -0700 (PDT) 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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727921AbfD2Knk (ORCPT + 99 others); Mon, 29 Apr 2019 06:43:40 -0400 Received: from mx2.suse.de ([195.135.220.15]:37492 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727868AbfD2Kna (ORCPT ); Mon, 29 Apr 2019 06:43:30 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 27A74AB9D; Mon, 29 Apr 2019 10:43:29 +0000 (UTC) Date: Mon, 29 Apr 2019 12:43:26 +0200 From: Michal Hocko To: Jiri Slaby Cc: Johannes Weiner , Vladimir Davydov , cgroups@vger.kernel.org, mm , Linux kernel mailing list , Raghavendra K T Subject: Re: memcg causes crashes in list_lru_add Message-ID: <20190429104326.GG21837@dhcp22.suse.cz> References: <2cbfb8dc-31f0-7b95-8a93-954edb859cd8@suse.cz> <359d98e6-044a-7686-8522-bdd2489e9456@suse.cz> <20190429104051.GF21837@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190429104051.GF21837@dhcp22.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 29-04-19 12:40:51, Michal Hocko wrote: > On Mon 29-04-19 12:09:53, Jiri Slaby wrote: > > On 29. 04. 19, 11:25, Jiri Slaby wrote:> memcg_update_all_list_lrus > > should take care about resizing the array. > > > > It should, but: > > [ 0.058362] Number of physical nodes 2 > > [ 0.058366] Skipping disabled node 0 > > > > So this should be the real fix: > > --- linux-5.0-stable1.orig/mm/list_lru.c > > +++ linux-5.0-stable1/mm/list_lru.c > > @@ -37,11 +37,12 @@ static int lru_shrinker_id(struct list_l > > > > static inline bool list_lru_memcg_aware(struct list_lru *lru) > > { > > - /* > > - * This needs node 0 to be always present, even > > - * in the systems supporting sparse numa ids. > > - */ > > - return !!lru->node[0].memcg_lrus; > > + int i; > > + > > + for_each_online_node(i) > > + return !!lru->node[i].memcg_lrus; > > + > > + return false; > > } > > > > static inline struct list_lru_one * > > > > > > > > > > > > Opinions? > > Please report upstream. This code here is there for quite some time. > I do not really remember why we do have an assumption about node 0 > and why it hasn't been problem until now. Humm, I blame jet-lag. I was convinced that this is an internal email. Sorry about the confusion. Anyway, time to revisit 145949a1387ba. CCed Raghavendra. -- Michal Hocko SUSE Labs