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=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 1FBA6C432BE for ; Mon, 30 Aug 2021 20:46:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8266360FC0 for ; Mon, 30 Aug 2021 20:46:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8266360FC0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 9EB638D0001; Mon, 30 Aug 2021 16:46:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99B806B0072; Mon, 30 Aug 2021 16:46:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8143E8D0001; Mon, 30 Aug 2021 16:46:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0188.hostedemail.com [216.40.44.188]) by kanga.kvack.org (Postfix) with ESMTP id 6D6656B0071 for ; Mon, 30 Aug 2021 16:46:18 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 274DD180ABF4A for ; Mon, 30 Aug 2021 20:46:18 +0000 (UTC) X-FDA: 78532929636.17.F7C55FF Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) by imf30.hostedemail.com (Postfix) with ESMTP id B0FD7E001982 for ; Mon, 30 Aug 2021 20:46:17 +0000 (UTC) Received: by mail-qv1-f46.google.com with SMTP id z2so9113339qvl.10 for ; Mon, 30 Aug 2021 13:46:17 -0700 (PDT) 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; bh=0pH8PpB5hRL0OIS0gYNC1zy+deykfUSq1lsoYqQwCuk=; b=P6vrQqD/yhdsLPcZ5aGOHX4wuGa0FHILa+hIjGDnI76PBMAAEggZdpfH+smLsaWsf3 j/ZSkZ+gU27/mSVxuPWWw5UfazmBBnsDrrJgbwohYdBGLSTEq2LIqbQExtCKTC/8YuNk BaykjXWWW1d1Sj4E/CPaayPEfGuDLBX6rnb0bybrdvBmpj6QU/aXgtpkUthfcRJUyOFC WmdnXEG7YvVuFy3P7+H+MsqmLtTHI5k8AtV476eIP3JS/JxV8mEvwJ2gOM2A1jj1B4lX WA1LRPjEVYaNCRN7W78bL3CAHzBwNSO2Tfpx87AQQb/76Xb0uTcv+kzxNQGmbPiaZ+00 n40Q== 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; bh=0pH8PpB5hRL0OIS0gYNC1zy+deykfUSq1lsoYqQwCuk=; b=bNAlrmyBBzIN+0PsG90hT82kgVfSWq2noWBTaWbiqP7pIUNYwVpAxMUwOn9usJ+2JZ CkUW9hrxWkiUUSmkfhXGPuL6up/UPdkXojAtQtL8wzkVTwY4phrbGeZTeA9D+5tDUtoV O5FG2EnLhmg6Fy1iYkkUccjeotErZeQa1yz4pgRaqVW5+8DcA2ZGcUIY39plgKt7Elol iqKcEipQWe29UFf9szvuXyXrHIdztRHD4G44wIjs+mriVWbfXaJoxGr581RitHKco5DU FW8tfIMeAymPL/8F9Pv7AF0YLKqJDDgwOh1FsnmaY241lZeAGR5gxlwBwf8mswGyMAUY uP9g== X-Gm-Message-State: AOAM5326E5T7NHPDtTKbLu0Up8vHXARoqCummNu7z15mZ8hlNbYPtyg+ RO5q7pnp+BqeuHNr+gB7/o4g5g== X-Google-Smtp-Source: ABdhPJwXkK+L51++yr7RM8pfNjFd4a3l9YJECfFVcwm5mFyXsdyoIfpnsPwInPzhRFXrfbg5ltm2MA== X-Received: by 2002:a0c:b356:: with SMTP id a22mr25367456qvf.7.1630356376930; Mon, 30 Aug 2021 13:46:16 -0700 (PDT) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id b15sm11962348qka.107.2021.08.30.13.46.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Aug 2021 13:46:16 -0700 (PDT) Date: Mon, 30 Aug 2021 16:48:03 -0400 From: Johannes Weiner To: Rik van Riel Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, stable@kernel.org, Michal Hocko , Chris Down Subject: Re: [PATCH] mm,vmscan: fix divide by zero in get_scan_count Message-ID: References: <20210826220149.058089c6@imladris.surriel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210826220149.058089c6@imladris.surriel.com> X-Rspamd-Queue-Id: B0FD7E001982 Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b="P6vrQqD/"; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf30.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.46 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-Rspamd-Server: rspam01 X-Stat-Signature: 4obi1bqief63dtzdmnb18ghjtjxzkgoh X-HE-Tag: 1630356377-351724 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, Aug 26, 2021 at 10:01:49PM -0400, Rik van Riel wrote: > Changeset f56ce412a59d ("mm: memcontrol: fix occasional OOMs due to > proportional memory.low reclaim") introduced a divide by zero corner > case when oomd is being used in combination with cgroup memory.low > protection. > > When oomd decides to kill a cgroup, it will force the cgroup memory > to be reclaimed after killing the tasks, by writing to the memory.max > file for that cgroup, forcing the remaining page cache and reclaimable > slab to be reclaimed down to zero. > > Previously, on cgroups with some memory.low protection that would result > in the memory being reclaimed down to the memory.low limit, or likely not > at all, having the page cache reclaimed asynchronously later. > > With f56ce412a59d the oomd write to memory.max tries to reclaim all the > way down to zero, which may race with another reclaimer, to the point of > ending up with the divide by zero below. > > This patch implements the obvious fix. > > Fixes: f56ce412a59d ("mm: memcontrol: fix occasional OOMs due to proportional memory.low reclaim") > Signed-off-by: Rik van Riel That took me a second. Before the patch, that sc->memcg_low_reclaim test was outside of that whole proportional reclaim branch. So if we were in low reclaim mode we wouldn't even check if a low setting is in place; if min is zero, we don't enter the proportional branch. Now we enter if low is set but ignored, and then end up with cgroup_size == min == 0 == divide by black hole. Good catch. Acked-by: Johannes Weiner > diff --git a/mm/vmscan.c b/mm/vmscan.c > index eeae2f6bc532..f1782b816c98 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2592,7 +2592,7 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, > cgroup_size = max(cgroup_size, protection); > > scan = lruvec_size - lruvec_size * protection / > - cgroup_size; > + (cgroup_size + 1); I have no overly strong preferences, but if Michal prefers max(), how about: cgroup_size = max3(cgroup_size, protection, 1); Or go back to not taking the branch in the first place when there is no protection in effect... diff --git a/mm/vmscan.c b/mm/vmscan.c index 6247f6f4469a..9c200bb3ae51 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2547,7 +2547,7 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, mem_cgroup_protection(sc->target_mem_cgroup, memcg, &min, &low); - if (min || low) { + if (min || (!sc->memcg_low_reclaim && low)) { /* * Scale a cgroup's reclaim pressure by proportioning * its current usage to its memory.low or memory.min