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 X-Spam-Level: X-Spam-Status: No, score=-5.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57114C433E1 for ; Mon, 18 May 2020 22:05:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 171A0206D4 for ; Mon, 18 May 2020 22:05:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="NZSy1xkt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 171A0206D4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 943FB900003; Mon, 18 May 2020 18:05:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F34A900002; Mon, 18 May 2020 18:05:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E1DA900003; Mon, 18 May 2020 18:05:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0177.hostedemail.com [216.40.44.177]) by kanga.kvack.org (Postfix) with ESMTP id 677AE900002 for ; Mon, 18 May 2020 18:05:13 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1F3004427 for ; Mon, 18 May 2020 22:05:13 +0000 (UTC) X-FDA: 76831221306.07.place45_4a979b5768007 X-HE-Tag: place45_4a979b5768007 X-Filterd-Recvd-Size: 4610 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Mon, 18 May 2020 22:05:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589839511; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iZK8o0/YgEUO016TV6TQ7POrns9r3ptB7P38AZfbfLY=; b=NZSy1xktGmA8/pvmLb1i6powT+xv0TGvezpc0H74gC44w6M8NODwNdePpXz2dkxQ3CaMZf Gq21MUedJoQ+8jF2gGhCn43bTYX8V7g4FHvtaG7alTkY/GiIW9RosDXlRrR+D3/yAR7sbc ZsbodOYiyP+FVm24gXngS/PGuNYKML0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-366-jiqD3ErjMku290OgbMSPcA-1; Mon, 18 May 2020 18:05:09 -0400 X-MC-Unique: jiqD3ErjMku290OgbMSPcA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BCE021800704; Mon, 18 May 2020 22:05:06 +0000 (UTC) Received: from llong.remote.csb (ovpn-114-131.rdu2.redhat.com [10.10.114.131]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2EB1C5C1B2; Mon, 18 May 2020 22:05:00 +0000 (UTC) Subject: Re: [PATCH v2 3/4] mm/slub: Fix another circular locking dependency in slab_attr_store() To: Qian Cai Cc: Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Johannes Weiner , Michal Hocko , Vladimir Davydov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Juri Lelli References: <20200427235621.7823-4-longman@redhat.com> From: Waiman Long Organization: Red Hat Message-ID: <638f59c0-60f1-2279-fea6-28b2980720f4@redhat.com> Date: Mon, 18 May 2020 18:05:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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: On 5/16/20 10:19 PM, Qian Cai wrote: > >> On Apr 27, 2020, at 7:56 PM, Waiman Long wrote: >> >> It turns out that switching from slab_mutex to memcg_cache_ids_sem in >> slab_attr_store() does not completely eliminate circular locking dependency >> as shown by the following lockdep splat when the system is shut down: >> >> [ 2095.079697] Chain exists of: >> [ 2095.079697] kn->count#278 --> memcg_cache_ids_sem --> slab_mutex >> [ 2095.079697] >> [ 2095.090278] Possible unsafe locking scenario: >> [ 2095.090278] >> [ 2095.096227] CPU0 CPU1 >> [ 2095.100779] ---- ---- >> [ 2095.105331] lock(slab_mutex); >> [ 2095.108486] lock(memcg_cache_ids_sem); >> [ 2095.114961] lock(slab_mutex); >> [ 2095.120649] lock(kn->count#278); >> [ 2095.124068] >> [ 2095.124068] *** DEADLOCK *** > Can you show the full splat? > >> To eliminate this possibility, we have to use trylock to acquire >> memcg_cache_ids_sem. Unlikely slab_mutex which can be acquired in >> many places, the memcg_cache_ids_sem write lock is only acquired >> in memcg_alloc_cache_id() to double the size of memcg_nr_cache_ids. >> So the chance of successive calls to memcg_alloc_cache_id() within >> a short time is pretty low. As a result, we can retry the read lock >> acquisition a few times if the first attempt fails. >> >> Signed-off-by: Waiman Long > The code looks a bit hacky and probably not that robust. Since it is the shutdown path which is not all that important without lockdep, maybe you could drop this single patch for now until there is a better solution? That is true. Unlike using the slab_mutex, the chance of failing to acquire a read lock on memcg_cache_ids_sem is pretty low. Maybe just print_once a warning if that happen. Thanks, Longman