Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1117123pxb; Thu, 28 Jan 2021 08:22:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJwaSZJ14KyzgEhO8lmaKMB+WCnK8V3/BrmJwb8uwuUINoPHApEo8UKCViYkKB+nZuOhSGwE X-Received: by 2002:a05:6402:1819:: with SMTP id g25mr361989edy.46.1611850973076; Thu, 28 Jan 2021 08:22:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611850973; cv=none; d=google.com; s=arc-20160816; b=aT5AmY3GdlsgY7l4T9C0mhFPfPr8iQ55p25lV0VfOiu805sDAfJyRNISKQFRDxNknn KguNsLRf5zkklejlxe7p12P0h7pamj7VpGUJewMFoXTwUXbAVsebiMl+oeTHGCZQvveG BlaJkwA6ypvNkgwimISemE0U2UfSZ4dGd9HbTwOgOjWP7Hy2eMyzUQgZaUOhoU2Vxcd0 K5Kzr5ydDyjGW5Uf5BT6NRO4arnPvyDZH7w4cdWlWnVY5tknBoc873qh51rlo9cswH3B SaZuwd7t+TuDURtKCQINhI0rVT6NF5embi1qAkvY2yEjWXu13143DmltBwqnKjnuWgfI ChuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=vikF6v6g7MrQqmlV2qbeqHg89yqp/+SCPnO0JBg1yKw=; b=Vxh/GGgTXtH8akorJ1gYHwLMjHh1pdSZjjwyCHJuKKOerJoWk1v1Ky98kg3vsaYBOj zdeGLI9OqBMQlml02Kw9OWc4is7t+jAfS/9mPF5lEzu1F+wWE/jZOlTjzV52k2Lk8t/U t0aZeCPU/EGkue4E5RXKLZLBuUGZabWym+OzThmIGFrnVgERYeIe0yOu7w05zMvH3Z1G 3O7CzJFkmJknpiEZKBtA6CxICbJicrMKK6ZeIwjwNUN2cHX1F5P5+ojT+D98ZbXgdSFr zOtCH6PmOZFLLYLDRIQ6AY2CoAvQzg11PrlTNMCWg2slJojhJmluMs7o1ztsQWMLsVPY kJaA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mp28si2940255ejc.284.2021.01.28.08.22.26; Thu, 28 Jan 2021 08:22:53 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232369AbhA1QUD (ORCPT + 99 others); Thu, 28 Jan 2021 11:20:03 -0500 Received: from mx2.suse.de ([195.135.220.15]:50626 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232213AbhA1QTx (ORCPT ); Thu, 28 Jan 2021 11:19:53 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 317F2AD24; Thu, 28 Jan 2021 16:19:09 +0000 (UTC) Subject: Re: [v5 PATCH 03/11] mm: vmscan: use shrinker_rwsem to protect shrinker_maps allocation To: Yang Shi , guro@fb.com, ktkhai@virtuozzo.com, shakeelb@google.com, david@fromorbit.com, hannes@cmpxchg.org, mhocko@suse.com, akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210127233345.339910-1-shy828301@gmail.com> <20210127233345.339910-4-shy828301@gmail.com> From: Vlastimil Babka Message-ID: <73c724ba-a1ef-a862-4c31-153d92826f8d@suse.cz> Date: Thu, 28 Jan 2021 17:19:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <20210127233345.339910-4-shy828301@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/28/21 12:33 AM, Yang Shi wrote: > Since memcg_shrinker_map_size just can be changed under holding shrinker_rwsem > exclusively, the read side can be protected by holding read lock, so it sounds > superfluous to have a dedicated mutex. > > Kirill Tkhai suggested use write lock since: > > * We want the assignment to shrinker_maps is visible for shrink_slab_memcg(). > * The rcu_dereference_protected() dereferrencing in shrink_slab_memcg(), but > in case of we use READ lock in alloc_shrinker_maps(), the dereferrencing > is not actually protected. > * READ lock makes alloc_shrinker_info() racy against memory allocation fail. > alloc_shrinker_info()->free_shrinker_info() may free memory right after > shrink_slab_memcg() dereferenced it. You may say > shrink_slab_memcg()->mem_cgroup_online() protects us from it? Yes, sure, > but this is not the thing we want to remember in the future, since this > spreads modularity. > > And a test with heavy paging workload didn't show write lock makes things worse. > > Signed-off-by: Yang Shi Acked-by: Vlastimil Babka