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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 35DF6C352A5 for ; Mon, 10 Feb 2020 22:03:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E6E892082F for ; Mon, 10 Feb 2020 22:03:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="EiMzX6xa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E6E892082F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 614D26B0185; Mon, 10 Feb 2020 17:03:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 59ECB6B0187; Mon, 10 Feb 2020 17:03:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48E4F6B0188; Mon, 10 Feb 2020 17:03:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id 2CFD06B0185 for ; Mon, 10 Feb 2020 17:03:46 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D26FE40C0 for ; Mon, 10 Feb 2020 22:03:45 +0000 (UTC) X-FDA: 76475595210.19.flock67_20cd4c934e72c X-HE-Tag: flock67_20cd4c934e72c X-Filterd-Recvd-Size: 2885 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Mon, 10 Feb 2020 22:03:45 +0000 (UTC) Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3540E2072C; Mon, 10 Feb 2020 22:03:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581372224; bh=UUTRHGYX5Gx7HdAuoYfSUCQ6fV6AewQgS0GTXzRvYbA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=EiMzX6xacbdgDIdrOR4rPBw7e3hOiBVLqbLd2STaa6oVxWlXX6W630LvynFODzTgn QwAQNc8nn4ZyKYac/RJCM0iZ6cYHHZvbOLhUOrKhwaQk9faF8n6WuCoUAFLd8xU6/e Vjl+1FjdFuyYVA0XxS4zZtRKmTCepjsYdbr8YRbI= Date: Mon, 10 Feb 2020 14:03:43 -0800 From: Andrew Morton To: Waiman Long Cc: Peter Zijlstra , Ingo Molnar , Will Deacon , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 3/3] mm/slub: Fix potential deadlock problem in slab_attr_store() Message-Id: <20200210140343.09ac0f5d841a0c9ed5034107@linux-foundation.org> In-Reply-To: <20200210204651.21674-4-longman@redhat.com> References: <20200210204651.21674-1-longman@redhat.com> <20200210204651.21674-4-longman@redhat.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Mon, 10 Feb 2020 15:46:51 -0500 Waiman Long wrote: > In order to fix this circular lock dependency problem, we need to do a > mutex_trylock(&slab_mutex) in slab_attr_store() for CPU0 above. A simple > trylock, however, is easy to fail causing user dissatisfaction. So the > new mutex_timed_lock() function is now used to do a trylock with a > 100ms timeout. > > ... > > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -5536,7 +5536,12 @@ static ssize_t slab_attr_store(struct kobject *kobj, > if (slab_state >= FULL && err >= 0 && is_root_cache(s)) { > struct kmem_cache *c; > > - mutex_lock(&slab_mutex); > + /* > + * Timeout after 100ms > + */ > + if (mutex_timed_lock(&slab_mutex, 100) < 0) > + return -EBUSY; > + Oh dear. Surely there's a better fix here. Does slab really need to hold slab_mutex while creating that sysfs file? Why? If the issue is two threads trying to create the same sysfs file (unlikely, given that both will need to have created the same cache) then can we add a new mutex specifically for this purpose? Or something else.