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.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 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 1A4B2C432C2 for ; Tue, 24 Sep 2019 18:54:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A8221214AF for ; Tue, 24 Sep 2019 18:54:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="HjEtlvgN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A8221214AF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1EBD66B0006; Tue, 24 Sep 2019 14:54:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 19B8E6B0007; Tue, 24 Sep 2019 14:54:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08A4D6B0008; Tue, 24 Sep 2019 14:54:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id D65EF6B0006 for ; Tue, 24 Sep 2019 14:54:08 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 6DDD48243779 for ; Tue, 24 Sep 2019 18:54:08 +0000 (UTC) X-FDA: 75970714176.25.ocean86_24185116a4a07 X-HE-Tag: ocean86_24185116a4a07 X-Filterd-Recvd-Size: 5347 Received: from mail-qt1-f195.google.com (mail-qt1-f195.google.com [209.85.160.195]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Sep 2019 18:54:07 +0000 (UTC) Received: by mail-qt1-f195.google.com with SMTP id j31so3443736qta.5 for ; Tue, 24 Sep 2019 11:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=MiKqbwAmBQwaqsCthyRHLRDPP3OlLqhMZfYy8oltFLU=; b=HjEtlvgNgKCPbWWrJWjCX1t4Zg96frB5QVa695LGa3ORvGL/s+3Tdy9wIhdtrkBTAa KAAYG3Hu29lM7UFbyKQlqFfr6WepmmM9L/OF5BmJiPKQZYZ6H3WQdR9AHdm+Z/smsUaD hyIMqDLaHyVslCM4/lL+v+AVFwzb1qymMrEc1jT1LW2NVDERuGND1N7Yup+mLsYfHWyg 2ejFOrVFQj3+vXk+OFXOsDl0+2GVbeYGAWXphiAStbncWNtcqVqC4L7BRVIFFdsD1AgW ygt1GarYud5cFFl/NKFKyJh2nE8IrfxuwVGKtFaaGMSbHwL0Od05fN/gFlPUvIID4oYu PfGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=MiKqbwAmBQwaqsCthyRHLRDPP3OlLqhMZfYy8oltFLU=; b=HvsIoanXEFA05En1ULXZ+n3wOaXM+gketsjHQoUpX8wLLvSkDbZnt1xW7fP+widIZS odpMr7Ct5GWqBiSzwYB4Qn3kXsV0NPxXb5M2qfjBm6wmvBNwlv+LHLyH5FLodap3/ath HGugbSZpS4pToy6A8ejcz1mvylv2FZbn96vh8Umttwv3w/oYyBOLXCZtlrY2RsURMP1U sl+630CIso0k5LSkYs2mOcpmZSAycXK+nzZy6C1CPlgtX3ZmPGJ4d4iNfj8lsCIqL7HW qGYGA2Yd4FyZW3cXeVD5R3IZpu7guybGeGCGVYeoBaz7IHhDqxJrJp30ngaNSyZ9yaOT sUiQ== X-Gm-Message-State: APjAAAUPd2sZfKCPtHNzapdVa1nd8ZvDrQzcii9tv216NXGQoCfpK0/7 WJkxlr1cmr9RgInqZsCXVLHqKA== X-Google-Smtp-Source: APXvYqxh7GtANWCqEgywe7I/WDaQ+q/YbqyG5jNks7urqX5NR/xpoUtC5VBlMgz8P+gFHv3xF9QBmQ== X-Received: by 2002:aed:2448:: with SMTP id s8mr4529400qtc.173.1569351247227; Tue, 24 Sep 2019 11:54:07 -0700 (PDT) Received: from dhcp-41-57.bos.redhat.com (nat-pool-bos-t.redhat.com. [66.187.233.206]) by smtp.gmail.com with ESMTPSA id w6sm1371556qkj.136.2019.09.24.11.54.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Sep 2019 11:54:06 -0700 (PDT) Message-ID: <1569351244.5576.219.camel@lca.pw> Subject: Re: [PATCH v1] mm/memory_hotplug: Don't take the cpu_hotplug_lock From: Qian Cai To: Michal Hocko Cc: David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Oscar Salvador , Pavel Tatashin , Dan Williams , Thomas Gleixner Date: Tue, 24 Sep 2019 14:54:04 -0400 In-Reply-To: <20190924151147.GB23050@dhcp22.suse.cz> References: <20190924143615.19628-1-david@redhat.com> <1569337401.5576.217.camel@lca.pw> <20190924151147.GB23050@dhcp22.suse.cz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000019, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 ove= r there, as > > it right now read files under /sys/kernel/slab/ could trigger a possi= ble > > deadlock anyway. > >=20 >=20 > [...] > > [=C2=A0=C2=A0442.452090][ T5224] -> #0 (mem_hotplug_lock.rw_sem){++++= }: > > [=C2=A0=C2=A0442.459748][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0validate_chain+0xd10/0x2bcc > > [=C2=A0=C2=A0442.464883][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0__lock_acquire+0x7f4/0xb8c > > [=C2=A0=C2=A0442.469930][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0lock_acquire+0x31c/0x360 > > [=C2=A0=C2=A0442.474803][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0get_online_mems+0x54/0x150 > > [=C2=A0=C2=A0442.479850][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0show_slab_objects+0x94/0x3a8 > > [=C2=A0=C2=A0442.485072][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0total_objects_show+0x28/0x34 > > [=C2=A0=C2=A0442.490292][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0slab_attr_show+0x38/0x54 > > [=C2=A0=C2=A0442.495166][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0sysfs_kf_seq_show+0x198/0x2d4 > > [=C2=A0=C2=A0442.500473][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0kernfs_seq_show+0xa4/0xcc > > [=C2=A0=C2=A0442.505433][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0seq_read+0x30c/0x8a8 > > [=C2=A0=C2=A0442.509958][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0kernfs_fop_read+0xa8/0x314 > > [=C2=A0=C2=A0442.515007][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0__vfs_read+0x88/0x20c > > [=C2=A0=C2=A0442.519620][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0vfs_read+0xd8/0x10c > > [=C2=A0=C2=A0442.524060][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0ksys_read+0xb0/0x120 > > [=C2=A0=C2=A0442.528586][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0__arm64_sys_read+0x54/0x88 > > [=C2=A0=C2=A0442.533634][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0el0_svc_handler+0x170/0x240 > > [=C2=A0=C2=A0442.538768][ T5224]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=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 seem= s > bogus. Check 03afc0e25f7f ("slab: get_online_mems for kmem_cache_{create,destroy,shrink}"). It actually talk about the races du= ring memory as well cpu hotplug, so it might even that cpu_hotplug_lock remova= l is problematic?