Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3040547ybi; Sun, 28 Jul 2019 23:41:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqy7v+7TT2rTZ9X9HFXhXphMQK7I/knKUmB0GMh0yeSVNx4z7yKN/z9iWYdUjkF87q+ZenfA X-Received: by 2002:a17:902:b20c:: with SMTP id t12mr109317379plr.285.1564382484460; Sun, 28 Jul 2019 23:41:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564382484; cv=none; d=google.com; s=arc-20160816; b=ebPCgAF9uHERiN7pnoUitJkHhK9aeMDfXQgmSkcIRCHL8xh+VHOFLP/xq9CP2wMV4e 3+3HJGXgu9+qmO2jPmDiDgkkshiISOJbM4lYDKIAjnzpIIKHK13Z0xQhVrXgc+zj0Ekk cpurDkSVAU4BobsTJGbKh9rR6VF16a3dGWo2qdXyQZXWmYrc783fP57K8NObo4tluxYS WOB35UBxf4nJz16yrHSZ2eAvFmPISDvgByXlTCvsGEfIv+hZpAIuF9qYZNJaorznVHw+ A+2opX7eylL2HMbQQqqVysl8UppPYeAQSC9Y2VUt5LN+IqnyZSpgQnh1ymADnMRImA8e 9RVg== 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; bh=K6g8++WH41POG/ZREs7EijTLSEFeYIMBi5pbvJlxPvQ=; b=liNXWY+1SGB6ikWC2TWwOqdOBSvuINzpWINgVDxbMmgg0gdr76x8+f/oCVFWIjE86n SJWKFlE5ylHQx5kx6lWn9iy0PvJG3PHA2LcJt6aXKbtjXyKJ4DcQDV/Qyk6RA87/Vu0y uov6USnFUC7KRhxthqbrgkR+07iFBmfBu95yiqa0d0XyY5OCAyr/Oaxh6HyeQKITtx1u zrpYbBmYTf+myApa/TfIWidiGX6D04n/76ldLu+kk7c9RVl/5mJXcRPm6tx75x24cINn n1FcoXhs2pliQpZxmavChjntXHk87Tryy/0OvGnNh06zbOkcp+sIhzr84ozZ/wNCtspd m2WQ== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g2si30823288pfq.160.2019.07.28.23.41.08; Sun, 28 Jul 2019 23:41:24 -0700 (PDT) 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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726748AbfG2GZD (ORCPT + 99 others); Mon, 29 Jul 2019 02:25:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:47252 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725934AbfG2GZC (ORCPT ); Mon, 29 Jul 2019 02:25:02 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 765A3ADFC; Mon, 29 Jul 2019 06:25:01 +0000 (UTC) Date: Mon, 29 Jul 2019 08:25:00 +0200 From: Michal Hocko To: Miles Chen Cc: Johannes Weiner , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, wsd_upstream@mediatek.com Subject: Re: [PATCH v2] mm: memcontrol: fix use after free in mem_cgroup_iter() Message-ID: <20190729062500.GB9330@dhcp22.suse.cz> References: <20190726021247.16162-1-miles.chen@mediatek.com> <20190726124933.GN6142@dhcp22.suse.cz> <20190726125533.GO6142@dhcp22.suse.cz> <1564184878.19817.5.camel@mtkswgap22> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1564184878.19817.5.camel@mtkswgap22> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat 27-07-19 07:47:58, Miles Chen wrote: > On Fri, 2019-07-26 at 14:55 +0200, Michal Hocko wrote: [...] > > > I am sorry, I didn't get to comment an earlier version but I am > > > wondering whether it makes more sense to do and explicit invalidation. > > > > > I think we should keep the original v2 version, the reason is the > !use_hierarchy does not imply we can reach root_mem_cgroup: > > cd /sys/fs/cgroup/memory/0 > mkdir 1 > cd /sys/fs/cgroup/memory/0/1 > echo 1 > memory.use_hierarchy // only 1 and its children has > use_hierarchy set > mkdir 2 > > rmdir 2 // parent_mem_cgroup(2) goes up to 1 You are right I have missed this case. I am not sure anybody is using layout like that but your fix is more robust and catches that case as well. Acked-by: Michal Hocko -- Michal Hocko SUSE Labs