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 04E6DC3525A for ; Wed, 26 Jan 2022 01:22:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 828326B0075; Tue, 25 Jan 2022 20:22:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7AD376B007B; Tue, 25 Jan 2022 20:22:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64EBD6B007D; Tue, 25 Jan 2022 20:22:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id 4F1326B0075 for ; Tue, 25 Jan 2022 20:22:17 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D522F18440491 for ; Wed, 26 Jan 2022 01:22:16 +0000 (UTC) X-FDA: 79070687472.15.4FBFF1F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 6E11B180006 for ; Wed, 26 Jan 2022 01:22:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643160135; 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: in-reply-to:in-reply-to:references:references; bh=GZ3Dedx2+qAhxuYqUMOz36xfZAcdnnXf1bRw8z3k2mE=; b=ApEcHLaOGH94xdcDXDNN9blh0UELTwq9QoRH15krese2YeVr9RzDG9KBFx04lZHmNAneyT vjVGzoQwBRNA5oyqtyd5qpENkxLvyXfpJtJMiT+YQDrqDA5oL/5rhLa5MwCY/D0lPVnJyT h8SNIQXui0XDhvohTBXadYSTqstrHxI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-65-_ehUbgIuM2uPWicB98SjDQ-1; Tue, 25 Jan 2022 20:22:10 -0500 X-MC-Unique: _ehUbgIuM2uPWicB98SjDQ-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 C25B62F25; Wed, 26 Jan 2022 01:22:08 +0000 (UTC) Received: from localhost (ovpn-12-215.pek2.redhat.com [10.72.12.215]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B3F66B1882; Wed, 26 Jan 2022 01:22:07 +0000 (UTC) Date: Wed, 26 Jan 2022 09:22:04 +0800 From: Baoquan He To: Andrew Morton Cc: David Hildenbrand , linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Vivek Goyal , Dave Young , "Paul E. McKenney" , Josh Triplett , Peter Zijlstra , Boqun Feng Subject: Re: [PATCH v2] proc/vmcore: fix possible deadlock on concurrent mmap and read Message-ID: <20220126012204.GA2086@MiWiFi-R3L-srv> References: <20220119193417.100385-1-david@redhat.com> <20220125170900.472fdb649312e77a4a60d9da@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220125170900.472fdb649312e77a4a60d9da@linux-foundation.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Rspamd-Queue-Id: 6E11B180006 X-Rspam-User: nil Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ApEcHLaO; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf16.hostedemail.com: domain of bhe@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=bhe@redhat.com X-Stat-Signature: 9eeu31oe3ka4n4ambj56baot87hr3kxq X-Rspamd-Server: rspam08 X-HE-Tag: 1643160136-622845 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 01/25/22 at 05:09pm, Andrew Morton wrote: > On Wed, 19 Jan 2022 20:34:17 +0100 David Hildenbrand wrote: > > > Lockdep noticed that there is chance for a deadlock if we have > > concurrent mmap, concurrent read, and the addition/removal of a > > callback. > > > > As nicely explained by Boqun: > > > > " > > Lockdep warned about the above sequences because rw_semaphore is a fair > > read-write lock, and the following can cause a deadlock: > > > > TASK 1 TASK 2 TASK 3 > > ====== ====== ====== > > down_write(mmap_lock); > > down_read(vmcore_cb_rwsem) > > down_write(vmcore_cb_rwsem); // blocked > > down_read(vmcore_cb_rwsem); // cannot get the lock because of the fairness > > down_read(mmap_lock); // blocked > > I'm wondering about cc:stable. It's hard to believe that this is > likely to be observed in real life. But the ongoing reports of lockdep > splats will be irritating. This is reported by Redhat CKI on Fedora ARK kernel. That kernel enables many debug feature by default, that's why lockdep detected that. Usually kdump kernel add 'nr_cpus=1' by default in our distros, so it won't hurt. It may cause lock issue in theory, so should be false positive warning. Since it has Fixes tag, cc:stable should be OK.