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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 4E7B8C432C1 for ; Tue, 24 Sep 2019 15:11:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 15517214DA for ; Tue, 24 Sep 2019 15:11:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 15517214DA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8FA206B000E; Tue, 24 Sep 2019 11:11:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8ABC06B0266; Tue, 24 Sep 2019 11:11:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C2AE6B0269; Tue, 24 Sep 2019 11:11:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id 5C7AC6B000E for ; Tue, 24 Sep 2019 11:11:50 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 1AD305002 for ; Tue, 24 Sep 2019 15:11:50 +0000 (UTC) X-FDA: 75970153980.05.grass43_846100422ec2e X-HE-Tag: grass43_846100422ec2e X-Filterd-Recvd-Size: 2841 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Sep 2019 15:11:49 +0000 (UTC) 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 7DB58B048; Tue, 24 Sep 2019 15:11:48 +0000 (UTC) Date: Tue, 24 Sep 2019 17:11:47 +0200 From: Michal Hocko To: Qian Cai Cc: David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Oscar Salvador , Pavel Tatashin , Dan Williams , Thomas Gleixner Subject: Re: [PATCH v1] mm/memory_hotplug: Don't take the cpu_hotplug_lock Message-ID: <20190924151147.GB23050@dhcp22.suse.cz> References: <20190924143615.19628-1-david@redhat.com> <1569337401.5576.217.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1569337401.5576.217.camel@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) Content-Transfer-Encoding: quoted-printable 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 Tue 24-09-19 11:03:21, Qian Cai wrote: [...] > While at it, it might be a good time to rethink the whole locking over = there, as > it right now read files under /sys/kernel/slab/ could trigger a possibl= e > deadlock anyway. >=20 [...] > [=A0=A0442.452090][ T5224] -> #0 (mem_hotplug_lock.rw_sem){++++}: > [=A0=A0442.459748][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0validate_chain+0xd10/= 0x2bcc > [=A0=A0442.464883][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0__lock_acquire+0x7f4/= 0xb8c > [=A0=A0442.469930][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0lock_acquire+0x31c/0x= 360 > [=A0=A0442.474803][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0get_online_mems+0x54/= 0x150 > [=A0=A0442.479850][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0show_slab_objects+0x9= 4/0x3a8 > [=A0=A0442.485072][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0total_objects_show+0x= 28/0x34 > [=A0=A0442.490292][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0slab_attr_show+0x38/0= x54 > [=A0=A0442.495166][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0sysfs_kf_seq_show+0x1= 98/0x2d4 > [=A0=A0442.500473][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0kernfs_seq_show+0xa4/= 0xcc > [=A0=A0442.505433][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0seq_read+0x30c/0x8a8 > [=A0=A0442.509958][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0kernfs_fop_read+0xa8/= 0x314 > [=A0=A0442.515007][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0__vfs_read+0x88/0x20c > [=A0=A0442.519620][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0vfs_read+0xd8/0x10c > [=A0=A0442.524060][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0ksys_read+0xb0/0x120 > [=A0=A0442.528586][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0__arm64_sys_read+0x54= /0x88 > [=A0=A0442.533634][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0el0_svc_handler+0x170= /0x240 > [=A0=A0442.538768][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0el0_svc+0x8/0xc I believe the lock is not really needed here. We do not deallocated pgdat of a hotremoved node nor destroy the slab state because an existing slabs would prevent hotremove to continue in the first place. There are likely details to be checked of course but the lock just seems bogus. --=20 Michal Hocko SUSE Labs