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 0B70AC432C2 for ; Wed, 25 Sep 2019 10:03:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B246B21D7A for ; Wed, 25 Sep 2019 10:03:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B246B21D7A 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 1B4A06B0274; Wed, 25 Sep 2019 06:03:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 163DC6B0276; Wed, 25 Sep 2019 06:03:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07A776B0277; Wed, 25 Sep 2019 06:03:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0096.hostedemail.com [216.40.44.96]) by kanga.kvack.org (Postfix) with ESMTP id DBB1F6B0274 for ; Wed, 25 Sep 2019 06:03:20 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 9D492824CA35 for ; Wed, 25 Sep 2019 10:03:20 +0000 (UTC) X-FDA: 75973005360.09.soup50_7475604d1d907 X-HE-Tag: soup50_7475604d1d907 X-Filterd-Recvd-Size: 3764 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Wed, 25 Sep 2019 10:03:20 +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 52C46B114; Wed, 25 Sep 2019 10:03:18 +0000 (UTC) Date: Wed, 25 Sep 2019 12:03:16 +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: <20190925100316.GI23050@dhcp22.suse.cz> References: <20190924143615.19628-1-david@redhat.com> <1569337401.5576.217.camel@lca.pw> <20190924151147.GB23050@dhcp22.suse.cz> <1569351244.5576.219.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1569351244.5576.219.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 14:54:04, Qian Cai wrote: > On Tue, 2019-09-24 at 17:11 +0200, Michal Hocko wrote: > > 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 o= ver there, as > > > it right now read files under /sys/kernel/slab/ could trigger a pos= sible > > > deadlock anyway. > > >=20 > >=20 > > [...] > > > [=A0=A0442.452090][ T5224] -> #0 (mem_hotplug_lock.rw_sem){++++}: > > > [=A0=A0442.459748][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0validate_chain+0x= d10/0x2bcc > > > [=A0=A0442.464883][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0__lock_acquire+0x= 7f4/0xb8c > > > [=A0=A0442.469930][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0lock_acquire+0x31= c/0x360 > > > [=A0=A0442.474803][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0get_online_mems+0= x54/0x150 > > > [=A0=A0442.479850][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0show_slab_objects= +0x94/0x3a8 > > > [=A0=A0442.485072][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0total_objects_sho= w+0x28/0x34 > > > [=A0=A0442.490292][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0slab_attr_show+0x= 38/0x54 > > > [=A0=A0442.495166][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0sysfs_kf_seq_show= +0x198/0x2d4 > > > [=A0=A0442.500473][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0kernfs_seq_show+0= xa4/0xcc > > > [=A0=A0442.505433][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0seq_read+0x30c/0x= 8a8 > > > [=A0=A0442.509958][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0kernfs_fop_read+0= xa8/0x314 > > > [=A0=A0442.515007][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0__vfs_read+0x88/0= x20c > > > [=A0=A0442.519620][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0vfs_read+0xd8/0x1= 0c > > > [=A0=A0442.524060][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0ksys_read+0xb0/0x= 120 > > > [=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+0= x170/0x240 > > > [=A0=A0442.538768][ T5224]=A0=A0=A0=A0=A0=A0=A0=A0el0_svc+0x8/0xc > >=20 > > 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= . > >=20 > > There are likely details to be checked of course but the lock just se= ems > > bogus. >=20 > Check 03afc0e25f7f ("slab: get_online_mems for > kmem_cache_{create,destroy,shrink}"). It actually talk about the races = during > memory as well cpu hotplug, so it might even that cpu_hotplug_lock remo= val is > problematic? I have to refresh my memory there but the changlog claims: "To avoid issues like that we should hold get/put_online_mems() during the whole kmem cache creation/destruction/shrink paths" and show_slab_objects doesn't fall into any of those categories. Anyway this seems unrelated to the original thread so I would recommend discussing in its own thread for clarity. --=20 Michal Hocko SUSE Labs