Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp279092ybj; Fri, 8 May 2020 11:36:53 -0700 (PDT) X-Google-Smtp-Source: APiQypIfqSBMP1aYgrjNa227qT6OCZHFfEl3mpqDhVsrXet4DPi2t098a2lgheJI54nBYDXu7YD7 X-Received: by 2002:a05:6402:3046:: with SMTP id bu6mr3378712edb.106.1588963013316; Fri, 08 May 2020 11:36:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588963013; cv=none; d=google.com; s=arc-20160816; b=reCx/6+rGrJIe3Xc1Wb66LHx5PrX7bBtNAfiqlRp0SNcMnZ9l6AIUIA0WUNW/EKgXE KbJ2QZbflFwdyuCTMrMVRpD7/IhFbzzLkTx4aGh8K5Vg1fs7PsjMzYzuvjp/wf4IPl59 NMXwPad1uqDmsap3Du4bR2SwFwHO3SCgQNyPLlCx33fdfn2iy3MT9dEmVmVLdPi0OdTm pu/3ME7aq+Nn9escN3hlZTeCU5H20pBVfCcWbH8cPhwvXM8KUzxyra6Fz4B09dvQ1YPU z+/3rWE61EZGrCYvGLViZ9z1EE9LmYsvcdwcrd98GA+WM0grWiNBuWeuz2jsMFNKM590 V7Cw== 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=Eum9bjhCQUemh9iSZtdHJuvrUPzxWGTkZ4CcEro9n7E=; b=o3HiTVLzwoXHfiqETXzQtWwYbSUWqeOhMutFfyNBW58JsdrWhiqe+fcKhhkfscqCVa wlp/IZ1Q35ajr+9LXvcQeZGfHPox5YlTKg0FsznL5fDpjj5YeIesk9e13UrUaByu/GPR EhKEUxjp0CSY8cINnLV/fxvbUPZgaztr45GkuPIl0Q4Qd160mp1LA/qdoPDuOkg5X/Dj p0nzE6DOTQg9ikeXHncrWVhlcPic4GsST8nfLqFTVsq8Ek1BixsKm8+Zb7E7iFFwHImW 3lULSlDB9cSi35MjQDL8uvfENFWMUiImeFPOvCJnAiwNgl4pP06k7qsXbMffJPfCCbKs y/1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=jiNhQR7o; 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 27si1424288ejx.245.2020.05.08.11.36.30; Fri, 08 May 2020 11:36:53 -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=jiNhQR7o; 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 S1728066AbgEHScx (ORCPT + 99 others); Fri, 8 May 2020 14:32:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727984AbgEHScr (ORCPT ); Fri, 8 May 2020 14:32:47 -0400 Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5EFDDC061A0C for ; Fri, 8 May 2020 11:32:47 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id q13so2135203qtp.7 for ; Fri, 08 May 2020 11:32:47 -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=Eum9bjhCQUemh9iSZtdHJuvrUPzxWGTkZ4CcEro9n7E=; b=jiNhQR7oDFgCIaeq8w1kb7yBCUxXWI4PGAu8hvAJp/EDuZPdtqs0Kv0eQRCIbghrLr plx1VKm4Sw92oc+8T9hBnws9X3YpMutk37X+Z4vvHpsPuGw4ZF1Y2rPRjkD1agBRSLF1 kS797R/esbPerCLSlEDiYcRzyVwhJ24kA8ALmaEzLu9cjjv83Lmxp6XMkh3hMvNIqVEU XEuKmtJ486aKM1U5k7/+R0un2thzz8+m1v19Z7FPHL+BnJkUfBDg73JlyXZZ7nG9aKiE 94bS/k6zSEgO9ITOLKwSURZnE+flX89sr9YP4oD6ByysAzQdkJOyP+fRM8bipeTGLD/0 yqfw== 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=Eum9bjhCQUemh9iSZtdHJuvrUPzxWGTkZ4CcEro9n7E=; b=BLGC4k0d0lMRBmJTsMh3xjKPUBmkJDVCn6Y17g50gLf+49L5AnDoMF5bLQSgyL4on9 DVF94jY31oKr3vjEDpvBlea/6SZtpJSHJ16/HDqLVwodeihsHSPhCFxhj2fcqaTOl3lW 3MtsKloWybmf+fIBmbxuPdVm4i92MpU8+JKA0v9kd18QPZUY9ZZD4GqHEpmIzfQK0jhV 18cONVZEDN34rEAzou9jgBhlfQZQAmJfDmkqz2S0yVPqQUP+QhIC77iqozCQfaIfnQPd YloWpOkl/4FM5FWuzgvUSPK1l5HzgpXO2etHvDPqi5433dPUuxmc65fPeEic8xGOu6d/ CnwA== X-Gm-Message-State: AGi0Puad0fv3eNo09zDlt0y8yTl+kYJDSz9ht+JqsbODc5/kmgwtSs2p VJGb8kGBcRpBP+kfKDA6bb3iHw== X-Received: by 2002:aed:2442:: with SMTP id s2mr4367165qtc.153.1588962766615; Fri, 08 May 2020 11:32:46 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:2627]) by smtp.gmail.com with ESMTPSA id 10sm2348766qtp.4.2020.05.08.11.32.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2020 11:32:45 -0700 (PDT) From: Johannes Weiner To: Andrew Morton Cc: Alex Shi , Joonsoo Kim , 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 19/19] mm: memcontrol: update page->mem_cgroup stability rules Date: Fri, 8 May 2020 14:31:06 -0400 Message-Id: <20200508183105.225460-20-hannes@cmpxchg.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200508183105.225460-1-hannes@cmpxchg.org> References: <20200508183105.225460-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 Reviewed-by: Alex Shi Reviewed-by: Joonsoo Kim --- mm/memcontrol.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 491fdeec0ce4..865440e8438e 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.2