Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp865482ybc; Tue, 12 Nov 2019 10:22:24 -0800 (PST) X-Google-Smtp-Source: APXvYqyzEO/Ul4E4YlZpa3Oe0fM018zp44HojCpRcj2XiVPrZBs6JxSdpbuMhrNoN3oH2hVbFh9G X-Received: by 2002:a50:9a85:: with SMTP id p5mr34418080edb.223.1573582944250; Tue, 12 Nov 2019 10:22:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573582944; cv=none; d=google.com; s=arc-20160816; b=xOAaEd07V7uk9MywR7kZPS3KyGkjXZvCNU4vUkDeFhlJttsb0JCii+HI4d666A3ts5 wLUMP3A5mhoY1ktQroqUQ+VTVVPo1S1CGTJ9Ais/rjtJmyjqrEmk3IyTNs5rskABbnlU ECvFmvjFf1hkTqOLexI22XLqIqKpGwYpmzDeSmmNbwn+chahJOHRn2xXGV5uBVqgdZfk ioHBwqQnAdSSwxpbHYYbIbxc2GN5TCBGsN98jHh0zHXcamL6I1Ttz2lnJIPxzINBDexe 6IinKQ+fA/Nbk2GiDSLcFjqYl0fiXvMSpPB4sVIApn+tC4S0Uu5CVdc0u+gKTrWIyVeL COlg== 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; bh=w8YEl8DjjpzVT+jv1JTvmwB07dFEMqomlwwTe3310pY=; b=dFgBEwC99hHVEOBiysje+l0M6++32DwNrtL9vJ7mkP9AUjJ94Sy/PDLeVDBGYyVKwZ oPRDzBteKg1E9HP7g/YEjITz25uwdSHGUhrlNUZhXPnrqgQhBctk9I4RWOwpDDvByw5C /bZxH1duVVSgSA2nCLd/DdzYkCD6BQhFdRfCcj1EA1fjrbaJDkRXzP8FFT6fHKN7KlrW jM/yfN4l3qhQw5m+PNcJqFs1V25aEL7Qr3BTsOV24+E2TVBGNY8ZbNqyX9JNsPph8PbR S/cKugYcv9NPzslWPvfDtkTH/Gum7M4jKGuVHhpj4OoMtrJa4LdKqLrz2+AVK2+O2shu hmDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=KGZv5hfK; 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=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e11si530948eje.376.2019.11.12.10.21.59; Tue, 12 Nov 2019 10:22:24 -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=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=KGZv5hfK; 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=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727298AbfKLSUU (ORCPT + 99 others); Tue, 12 Nov 2019 13:20:20 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:33728 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727036AbfKLSUT (ORCPT ); Tue, 12 Nov 2019 13:20:19 -0500 Received: by mail-qt1-f193.google.com with SMTP id y39so20843443qty.0 for ; Tue, 12 Nov 2019 10:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=w8YEl8DjjpzVT+jv1JTvmwB07dFEMqomlwwTe3310pY=; b=KGZv5hfKhSeMlIk3qURodC/bAqExsgUF/6lSCR5KsnlI2hk1Vvt1Ez2XgZxpFXA6M5 8NVnX35tumAMf8vnwXOFXvzbSO92tizrnnR0oG2BuR4cvUtk5ck7y7zDzOFViLG0BLii LlqvsQXofXqmA6yYdPv+ou1g+Dj4+W+uI7q/VBfOGf1zGxNnhbdp7/C+cgP1Pchyt/Fa nm4DL5uBVj/MkkJRMhVmzu8uNlKaGah+hX5o7Ukk+f2wXdl67Dpk/sfK9/hOPNH1GcT5 IyMHcklOBzKmgmgdX/rKt3LxiEfgOiElsQ7rJpf5BAx81/PxDpbMsgGNxbZOrH/gntTJ PSOQ== 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=w8YEl8DjjpzVT+jv1JTvmwB07dFEMqomlwwTe3310pY=; b=fjwGfs6dAFX7VvuTLsPeo1kVWdnK/5HfSLpF7Jb6mzD48qXqPHhxUv51JiNUlYp3rs 9PqCZxTw9DEoMUe2+pO77AZod2QjisoLfoX6C9UzQabxWUvzqWlYUvZTdBNhvh8+U42s 1eEc2EKtNZmTuVWzlyKU2MvWsuX56KYHqqIyq73T2ruAZYHqUt0kjjm4YF9VyEyl1hXI m889E+mP8hqglExc6DYZJBH+m2NE3W2BDee//TYwQnot7lRqO9s4hQ+v4alD1tt5pZKr DcvaLE+2M5Bebd2+aV7tXa9LKcXzc+JvESE8XlIgAVZfrp587pT2RfLGt1lmN2+/9ebe bUDg== X-Gm-Message-State: APjAAAXY3APz0xwIs7YNHDh04j3g2BuCZ6eNEjHuz4GZdXjzbPGRY8HZ XLwVvn/Ul0q3JWC7eZhXoy+IRw== X-Received: by 2002:aed:24c1:: with SMTP id u1mr33987362qtc.29.1573582818867; Tue, 12 Nov 2019 10:20:18 -0800 (PST) Received: from localhost ([2620:10d:c091:500::aa8c]) by smtp.gmail.com with ESMTPSA id k27sm8179165qkj.30.2019.11.12.10.20.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Nov 2019 10:20:18 -0800 (PST) Date: Tue, 12 Nov 2019 13:20:17 -0500 From: Johannes Weiner To: Michal Hocko Cc: Chris Down , Qian Cai , akpm@linux-foundation.org, guro@fb.com, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH -next] mm/vmscan: fix an undefined behavior for zone id Message-ID: <20191112182017.GB179587@cmpxchg.org> References: <20191108204407.1435-1-cai@lca.pw> <64E60F6F-7582-427B-8DD5-EF97B1656F5A@lca.pw> <20191111130516.GA891635@chrisdown.name> <20191111131427.GB891635@chrisdown.name> <20191111132812.GK1396@dhcp22.suse.cz> <20191112145942.GA168812@cmpxchg.org> <20191112152750.GA512@dhcp22.suse.cz> <20191112161658.GF168812@cmpxchg.org> <20191112163156.GB512@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191112163156.GB512@dhcp22.suse.cz> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 12, 2019 at 05:31:56PM +0100, Michal Hocko wrote: > On Tue 12-11-19 11:16:58, Johannes Weiner wrote: > > On Tue, Nov 12, 2019 at 04:27:50PM +0100, Michal Hocko wrote: > > > lruvec_lru_size is explicitly documented to use MAX_NR_ZONES for all > > > LRUs and git grep says there are more instances outside of > > > get_scan_count. So all of them have to be fixed. > > > > Which ones? > > > > [hannes@computer linux]$ git grep lruvec_lru_size > > include/linux/mmzone.h:extern unsigned long lruvec_lru_size(struct lruvec *lruvec, enum lru_list lru, int zone_idx); > > mm/vmscan.c: * lruvec_lru_size - Returns the number of pages on the given LRU list. > > mm/vmscan.c:unsigned long lruvec_lru_size(struct lruvec *lruvec, enum lru_list lru, int zone_idx) > > mm/vmscan.c: anon = lruvec_lru_size(lruvec, LRU_ACTIVE_ANON, MAX_NR_ZONES - 1) + > > mm/vmscan.c: lruvec_lru_size(lruvec, LRU_INACTIVE_ANON, MAX_NR_ZONES - 1); > > mm/vmscan.c: file = lruvec_lru_size(lruvec, LRU_ACTIVE_FILE, MAX_NR_ZONES - 1) + > > mm/vmscan.c: lruvec_lru_size(lruvec, LRU_INACTIVE_FILE, MAX_NR_ZONES - 1); > > mm/vmscan.c: lruvec_size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx); > > [hannes@computer linux]$ > > I have checked the Linus tree but now double checked with the current > next > $ git describe next/master > next-20191112 > $ git grep "lruvec_lru_size.*MAX_NR_ZONES" next/master > next/master:mm/vmscan.c: lruvec_lru_size(lruvec, inactive_lru, MAX_NR_ZONES), inactive, > next/master:mm/vmscan.c: lruvec_lru_size(lruvec, active_lru, MAX_NR_ZONES), active, > next/master:mm/vmscan.c: anon = lruvec_lru_size(lruvec, LRU_ACTIVE_ANON, MAX_NR_ZONES) + > next/master:mm/vmscan.c: lruvec_lru_size(lruvec, LRU_INACTIVE_ANON, MAX_NR_ZONES); > next/master:mm/vmscan.c: file = lruvec_lru_size(lruvec, LRU_ACTIVE_FILE, MAX_NR_ZONES) + > next/master:mm/vmscan.c: lruvec_lru_size(lruvec, LRU_INACTIVE_FILE, MAX_NR_ZONES); > next/master:mm/workingset.c: active_file = lruvec_lru_size(lruvec, LRU_ACTIVE_FILE, MAX_NR_ZONES); > > are there any changes which didn't make it to linux next yet? Aaahh, that makes sense. I was looking at the latest mmots which has - mm: vmscan: detect file thrashing at the reclaim root - mm: vmscan: enforce inactive:active ratio at the reclaim root Those replace the inactive_is_low and the workingset callsites with the recursive lruvec_page_state(). It looks like that isn't in next - and while I hope it'll make it into 5.5, it might not. So we need a fix that considers the other callsites as well. Qian's patches that Andrew already has will be good then, as it reduces the churn to those other callsites that are in flux. We can clean things up when the dust settles.