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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA42FC5478C for ; Mon, 26 Feb 2024 07:16:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2D8C6B016B; Mon, 26 Feb 2024 02:16:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EDDE26B016C; Mon, 26 Feb 2024 02:16:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCC976B016D; Mon, 26 Feb 2024 02:16:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CF54F6B016B for ; Mon, 26 Feb 2024 02:16:22 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4874A1C06ED for ; Mon, 26 Feb 2024 07:16:22 +0000 (UTC) X-FDA: 81833096604.21.2C3BB55 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id 9E5D520008 for ; Mon, 26 Feb 2024 07:16:19 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=I1rcZf1X; spf=pass (imf03.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708931779; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Mq2RceVVA9AoNvo7Bvq6SKMYQsbJMTamI62PWAO4Sx8=; b=hUi18wa644yHua26Ncl0HGsK9b0sQMQyqhxtbcQA/9DMsWjUnO4RKbouTczzFltKaqgcuP NfyztoWwhj9+l9HRExmZ7c47YCmFa8hvrBJCDfTCq1sCy+sLgGLa48k58SNQgbKbGgFNrS leW6ea0C1Ofa1hdAiYvqva/VICYk4k4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708931779; a=rsa-sha256; cv=none; b=At2GwL4cufOngwZoRVxApm4oh+Usng0d82qMHITLy8eow617CiEEGfUeqYdHlzlrdlaz6u MsZyzmlM9ikGV9EELlBJVwj1cgDb0OfisYGIDNZ9cfijC5M/TkRD1YABavuuUnWFKsOk1P 4e2nAtyYmtzolvRZSpilTCBHkOw78tY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=I1rcZf1X; spf=pass (imf03.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 918C96066F; Mon, 26 Feb 2024 07:16:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE762C433F1; Mon, 26 Feb 2024 07:16:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1708931778; bh=2RlYg33BiX3NtOsnhjj8RG35wYd23faEZA9/J7KHbxQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=I1rcZf1XGpMfTaBMYLeAoV171MgKE7m65z3JRw0SEcLJ55iYD094dU3ftd7qu+Agr 4VwA93Kx7VlL7e5sNXNEyCO093O3vbnt+ry+xgxcxSMqRjCJIlZ/Oqx6V40OD+orGJ kz+zTkP1eGflBYXA22cnP2SsmKicWPey+bHi6ag8= Date: Mon, 26 Feb 2024 08:16:10 +0100 From: Greg KH To: "GONG, Ruiqi" Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , cgroups@vger.kernel.org, linux-mm@kvack.org, Wang Weiyang , Xiu Jianfeng Subject: Re: [PATCH stable 4.19] mm: memcontrol: switch to rcu protection in drain_all_stock() Message-ID: <2024022601-flavorful-gerbil-da52@gregkh> References: <20240226030140.129822-1-gongruiqi1@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240226030140.129822-1-gongruiqi1@huawei.com> X-Rspamd-Queue-Id: 9E5D520008 X-Rspam-User: X-Stat-Signature: fuu8go6zkt5nrqmudk6jtwz5kngq3ozk X-Rspamd-Server: rspam03 X-HE-Tag: 1708931779-194083 X-HE-Meta: U2FsdGVkX1+FsO3ix4WO05Dtcnh4WLM80LLK22jrnO9dI4mFB27kSeU5Cgj+vKDEJHTgrisUULXQbcnFadIo3KR8N6j49Vg3M4clEO5w3Nv4GYQrOm0YhwrSHgZyTA4lI9OA0TQtiEhxK1HUZNthX6iORllng/zfJv4mUkr8OhwWZy/c4/3kSi3Nmw3wCTRQMNv1bJ0foN7eGlQPWMST/90xgURnctdCnPWcvWFvMeFvB8loT2VNizjD7ePthpB0Y5re+f1ybCjcPeR/tmlmIQMtNFgrjt8ZD3bg8usATmyc8zT96zBkLBwlkNVhoVCnCs57CRhz9t7xW52KEw5+qGaWK/e05L466jqk1iz4FpWyHchRd+lqp7KSuDaX4iOlADDui+7f0TTXM1mYrtaOdL5rjiSrbz68AbaUu4XiPV+JzgDPyiZK0buAN6Y4KzjU7dYLlgpxQq20Y/J8+wvRRGWEIV3REWrXxtw1rF+HaxFbyoGW7lG/NBOYZfMcikGKaKf78dp9Ya5LQiaYhNy5iZIIMmTHQjxOHF8H4Bx8hBYKMoUFaZKAixIO6NiHIwlLuPTUZnXpl/jYmTyPEQ3QXeP7InxeObLyEZXBkYqF6c1JIyotoIkEQBC/9hZEp4kiKUUnSkiefXjjjlCYL3QVPN6Rnj/DZrkQwn481FbkAiKhCxnKFYIhL3UE8P83p7szggHqtwV0h09qQYfnHf9NFFKl/IzLj6DBZH+qtMpUr4/bIcRy/LKuUPWVlWzEogWiSlHObQKrX9Grmib18M3jruhkRDaddK0e2nurqFqwpeFVaKHUf4s0qENYK3gnLyiPRh3oSLTWnmEvdO4GVrMQaIR4XniQlI/0ZXTm/z8t6WDPQ3yamE5HOxPU0pabyylrhISU6NHPj15IjGJXRyh1AsKDg+Kp42K3pqBnZzcSxSE4JohWqs0vnrgJXU703fw6P6iH456ybfjgUlp+MuH ROA== 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: List-Subscribe: List-Unsubscribe: On Mon, Feb 26, 2024 at 11:01:40AM +0800, GONG, Ruiqi wrote: > From: Roman Gushchin > > commit e1a366be5cb4f849ec4de170d50eebc08bb0af20 upstream. > > Commit 72f0184c8a00 ("mm, memcg: remove hotplug locking from try_charge") > introduced css_tryget()/css_put() calls in drain_all_stock(), which are > supposed to protect the target memory cgroup from being released during > the mem_cgroup_is_descendant() call. > > However, it's not completely safe. In theory, memcg can go away between > reading stock->cached pointer and calling css_tryget(). > > This can happen if drain_all_stock() races with drain_local_stock() > performed on the remote cpu as a result of a work, scheduled by the > previous invocation of drain_all_stock(). > > The race is a bit theoretical and there are few chances to trigger it, but > the current code looks a bit confusing, so it makes sense to fix it > anyway. The code looks like as if css_tryget() and css_put() are used to > protect stocks drainage. It's not necessary because stocked pages are > holding references to the cached cgroup. And it obviously won't work for > works, scheduled on other cpus. > > So, let's read the stock->cached pointer and evaluate the memory cgroup > inside a rcu read section, and get rid of css_tryget()/css_put() calls. > > Link: http://lkml.kernel.org/r/20190802192241.3253165-1-guro@fb.com > Signed-off-by: Roman Gushchin > Acked-by: Michal Hocko > Cc: Hillf Danton > Cc: Johannes Weiner > Cc: Vladimir Davydov > Signed-off-by: Andrew Morton > Signed-off-by: Linus Torvalds > Cc: stable@vger.kernel.org # 4.19 > Fixes: cdec2e4265df ("memcg: coalesce charging via percpu storage") > Signed-off-by: GONG, Ruiqi > --- > > This patch [1] fixed a UAF problem in drain_all_stock() existed prior to > 5.9, and following discussions [2] mentioned that the fix depends on an > RCU read protection to stock->cached (introduced in 5.4), which doesn't > existed in 4.19. So backport this part to 4.19 as well. Now queued up, thanks. greg k-h