Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp4075321ybz; Mon, 20 Apr 2020 15:14:37 -0700 (PDT) X-Google-Smtp-Source: APiQypIllS2/taeBbBAslfzrYfMdP+NmvgQFYzc1opFBHoJAgLfd9XY6roSivSsX6Bf5Z9ZA+Pqy X-Received: by 2002:a17:906:5e45:: with SMTP id b5mr17663298eju.0.1587420877339; Mon, 20 Apr 2020 15:14:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587420877; cv=none; d=google.com; s=arc-20160816; b=OnVQD0qCQpl/WxTH9KE+3KbXi88JIYtgvVergnh8ZubBfnh7tX1HZHq4hymmfz8CKp /A0nE+GJxbF+b3j5gEdhqMq2q1rG0WDxgomj/Lat2Krl2ZbzR1CtO6V6QfDIRHhMJSl1 mG8bWjzkL9mnqZA7zAecBRoIM20bkvYTWqTc4ZDl9e0KWl5ZsdPqBMbKmCS5IRrCzH4Y OdDL+z5Fp/RVAxd57Mb7B2dzaaplulotVdFHBwkMNdO3VFCY2F8PzKPifiKprYPbQMQQ Ik0jiX1inefLSVfzu3Z4+SOdhmcMdBJoA6lnt1FdPzN3LgKOmd/pXYhtP8lS9VGTtrZ1 29XA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=mru2mqYssRMwFvfM60SVK8LHEOtTvwZ9sk9Ozs6ntCE=; b=hHROMkQrL79BQDSvqACfx8EHJicAf8uXJRVaFO1mbtLhQ+YJ0MR1b+2kZAXep025e6 194465kIofTu5c3/zZIzdnVAE/3MxhCXviO5UgSX6yFpKLoTJQ7Nc3OuqyffK7bvPmrQ 5ZpdeRnoPjY4kGSDAOgTHPYWa5YjATgWvQ+yvq31H+J2YgG42LIcL8r+Y2t0OEJt0Y4Y A27hKUGEkLOQGjIZTdG9FsDefIZdTjpk6U+ghvEC2ACO39pK8dF6GzF2yjVTw8J0HhUD bN9TjyiXHJwY7xWEyOz5nJFiLh07+rWTBXrm+G2aa5MoDRRaBzY9XGTn29/Q2JctgiZB E4RQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=jbzqhoEM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id df22si498161edb.272.2020.04.20.15.14.14; Mon, 20 Apr 2020 15:14:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=jbzqhoEM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728451AbgDTWMR (ORCPT + 99 others); Mon, 20 Apr 2020 18:12:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728430AbgDTWMQ (ORCPT ); Mon, 20 Apr 2020 18:12:16 -0400 Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A19BC061A0C for ; Mon, 20 Apr 2020 15:12:16 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id g74so12521193qke.13 for ; Mon, 20 Apr 2020 15:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=mru2mqYssRMwFvfM60SVK8LHEOtTvwZ9sk9Ozs6ntCE=; b=jbzqhoEM5d7NDzw3vfdtgPSSoDlrWCej+05GdZmq+IawnWaqCKW0HH/bet3KzfXkzI X40GyZbo6g+QTskRmkxQ4BoKE1dowe9171ocp8SAujcL5g1va70+O2r6uieOwu60OKv8 2iBVNUCDBAtCC17cBY5xLP4VqdlKXcG9yz2XzIA5GCVzfi2UTnZy+eQnY/ovTSS3Cfgi LSZ9xrD0VnTnru809Wm7EHvlmTJ7PAPtjZB29vsCjFkd2c0vuv7jfoYdDviMy/qWaLjt yW2FMnGLHwetNA39YeYWTBk6TaxRFtCzGlSWHqLRh9vgdXbHPv8ItR6ybXmvfQgCLRiO 5F6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=mru2mqYssRMwFvfM60SVK8LHEOtTvwZ9sk9Ozs6ntCE=; b=inDFBZZo35MlqqS3J+QIvPQFR9/CQ6bKJP6NXqtZ3L3JWdKZKfOvG5EXtMopE1H0jw PmqS/odralzv2Itphr/RlIdPN5ME+yHHWkUlmrefig6zpWU7U0ptBFlQp8Igs2qFpKUR otD3tA9A1MXgyp+hZx0jBqZXwq+mRF22haJHXTql8gyrwrzvzCpjClG2+arrzqGqyrae zbIb3Mbjj+S3iedaOV4sxqDyRgVmU1lNRumitQClNTxBDr4wRkx1RDc+3RViXRHN7EFM iGnvjNaXYl756aqwQYImNkiUZZcGRf0ZSskVygTYm+P0nFrm555C0M9QpKMEtsUYDCmr yXUA== X-Gm-Message-State: AGi0PubUoqcIXdoNchEv1KSulCOka5pMBP852WAGpiWylYa67scszcc8 bfoPI618K1GxvAlaD9MlZnHJ/w== X-Received: by 2002:a37:6587:: with SMTP id z129mr18837123qkb.437.1587420735277; Mon, 20 Apr 2020 15:12:15 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:e6b6]) by smtp.gmail.com with ESMTPSA id i56sm521733qte.6.2020.04.20.15.12.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2020 15:12:14 -0700 (PDT) From: Johannes Weiner To: Joonsoo Kim , Alex Shi Cc: Shakeel Butt , Hugh Dickins , Michal Hocko , "Kirill A. Shutemov" , Roman Gushchin , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 18/18] mm: memcontrol: update page->mem_cgroup stability rules Date: Mon, 20 Apr 2020 18:11:26 -0400 Message-Id: <20200420221126.341272-19-hannes@cmpxchg.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200420221126.341272-1-hannes@cmpxchg.org> References: <20200420221126.341272-1-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The previous patches have simplified the access rules around page->mem_cgroup somewhat: 1. We never change page->mem_cgroup while the page is isolated by somebody else. This was by far the biggest exception to our rules and it didn't stop at lock_page() or lock_page_memcg(). 2. We charge pages before they get put into page tables now, so the somewhat fishy rule about "can be in page table as long as it's still locked" is now gone and boiled down to having an exclusive reference to the page. Document the new rules. Any of the following will stabilize the page->mem_cgroup association: - the page lock - LRU isolation - lock_page_memcg() - exclusive access to the page Signed-off-by: Johannes Weiner --- mm/memcontrol.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index a8cce52b6b4d..7b63260c9b57 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1201,9 +1201,8 @@ int mem_cgroup_scan_tasks(struct mem_cgroup *memcg, * @page: the page * @pgdat: pgdat of the page * - * This function is only safe when following the LRU page isolation - * and putback protocol: the LRU lock must be held, and the page must - * either be PageLRU() or the caller must have isolated/allocated it. + * This function relies on page->mem_cgroup being stable - see the + * access rules in commit_charge(). */ struct lruvec *mem_cgroup_page_lruvec(struct page *page, struct pglist_data *pgdat) { @@ -2605,18 +2604,12 @@ static void commit_charge(struct page *page, struct mem_cgroup *memcg) { VM_BUG_ON_PAGE(page->mem_cgroup, page); /* - * Nobody should be changing or seriously looking at - * page->mem_cgroup at this point: - * - * - the page is uncharged - * - * - the page is off-LRU - * - * - an anonymous fault has exclusive page access, except for - * a locked page table + * Any of the following ensures page->mem_cgroup stability: * - * - a page cache insertion, a swapin fault, or a migration - * have the page locked + * - the page lock + * - LRU isolation + * - lock_page_memcg() + * - exclusive reference */ page->mem_cgroup = memcg; } -- 2.26.0