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=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 1C424C2D0DB for ; Fri, 24 Jan 2020 18:05:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D96842072C for ; Fri, 24 Jan 2020 18:05:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="JPa2uVHT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D96842072C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 73D0B6B0005; Fri, 24 Jan 2020 13:05:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6EE316B0006; Fri, 24 Jan 2020 13:05:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DCA66B0007; Fri, 24 Jan 2020 13:05:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id 465DF6B0005 for ; Fri, 24 Jan 2020 13:05:05 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id CC8AB181AEF10 for ; Fri, 24 Jan 2020 18:05:04 +0000 (UTC) X-FDA: 76413304128.12.rock68_f164b2f83948 X-HE-Tag: rock68_f164b2f83948 X-Filterd-Recvd-Size: 4795 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Jan 2020 18:05:03 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id g15so2482282otp.3 for ; Fri, 24 Jan 2020 10:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jRTNXnXM7oz5Drw0JUEzLHf8Tl/lM2SK6ojzvbVm3Do=; b=JPa2uVHTQnO/DXnNRVd8XmoPi8VpJuIDhI+MwREr6Mb8Ij5HVUDpA6TxomyZ+Lff6W Y0DI9Cm0csX4gVNf0fT2szWUMfB8PaOM+JHgiQ6lHgp2HYGhZ1FLuEQr0mFTp/UHZGEJ 4+wmRzEAsVw/5tyikkUBaJSaYwn1dj9gvK9c5x/AxAQpvh0podrIffNwzqKp0EkArmJ1 oMwVvXtqQAlFZUlPokk+ed89Py3Hp2N12VOLnaJO0t5fYarr08YbsRzuILrxgeCojT/8 rcUiO4nPjlpm1y4ofxPB9A4MFUjfm6TIH4pRlXvUZhWjjbyJWGoW4+7jNw2e/p4KVf8Q t5qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jRTNXnXM7oz5Drw0JUEzLHf8Tl/lM2SK6ojzvbVm3Do=; b=uGtTP837o3SYcGsI4D+GI/Raaf6GBXGDIPd620gGZjsC7hzfQs6vCDuctCOeKoGFKt +9E/xuu4bZfZOsdjC1YKaaYtcl69ZTZ3qwTRIzolPamqTxwYxE3wrHObgbNNQxfoowu3 dpsM7HPfhpxNfK8DczDamjoKyRYVtYLo7f2GhBdl+p2zRZ/mPGBWrr2uJp0SAE+2Xn6e qyAP7QLN4ksI74iKlLydEElQop9JbeGU5Hg8RXJqbCfsS94nnRAcHbhyoFTT3/EnuOre JGBR7u6jcbRIgwP/cQvtl4VG0j16Ud3zNbtsxfozDQymZLljhWuCUAWtan+LK2TWttTZ TuEg== X-Gm-Message-State: APjAAAVlTfR8S0pj9f5+VuSIqsFfsAJvj0pONqRAfnBFnei58woafSGS /Cup78MBN+pHXVkjAE4kNQAJeXsXuiZuvYtFoL/luw== X-Google-Smtp-Source: APXvYqzFJoNGdvBkNazI2Gmjmm0Jg7CrgLUOGYJxHStstoF4GHQEZ08I0ffdQ1SOyeaigHkZmgGXPCfxHkNpYgjxS48= X-Received: by 2002:a9d:68d3:: with SMTP id i19mr3393231oto.71.1579889102817; Fri, 24 Jan 2020 10:05:02 -0800 (PST) MIME-Version: 1.0 References: <4d0334e2-c4e7-6d3f-99ba-2ca0495e1549@redhat.com> <64902066-51dd-9693-53fc-4a5975c58409@redhat.com> <516aa930-9b64-b377-557c-5413ed9fe336@redhat.com> <20200124124512.GT29276@dhcp22.suse.cz> In-Reply-To: <20200124124512.GT29276@dhcp22.suse.cz> From: Dan Williams Date: Fri, 24 Jan 2020 10:04:52 -0800 Message-ID: Subject: Re: [PATCH] mm/memory_hotplug: Fix remove_memory() lockdep splat To: Michal Hocko Cc: David Hildenbrand , Andrew Morton , stable , Vishal Verma , Pavel Tatashin , Dave Hansen , Linux MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" 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 Fri, Jan 24, 2020 at 4:56 AM Michal Hocko wrote: > > On Fri 10-01-20 13:27:24, Dan Williams wrote: > > On Fri, Jan 10, 2020 at 9:42 AM David Hildenbrand wrote: > [...] > > > For your reference (roughly 5 months ago, so not that old) > > > > > > https://lkml.kernel.org/r/20190724143017.12841-1-david@redhat.com > > > > Oh, now I see the problem. You need to add that lock so far away from > > the __add_memory() to avoid lock inversion problems with the > > acpi_scan_lock. The organization I was envisioning would not work > > without deeper refactoring. > > Sorry to come back to this late. Has this been resolved? The mem_hotplug_lock lockdep splat fix in this patch has not landed. David and I have not quite come to consensus on how to resolve online racing removal. IIUC David wants that invalidation to be pages_correctly_probed(), I would prefer it to be directly tied to the object, struct memory_block, that remove_memory_block_devices() has modified, mem->section_count = 0. ...or are you referring to the discussion about acpi_scan_lock()? I came around to agreeing with your position that documenting was better than adding superfluous locking especially because the acpi_scan_lock() is take so far away from where the device_hotplug lock is needed.