Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp521423imm; Fri, 17 Aug 2018 01:58:59 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzgqyzwnkKmcs4/ZpqU06M/RIjMSy0hdy/NaRE2lg23fHNPZWfBTtdwFRm5VJSOe151CEC9 X-Received: by 2002:a63:4e25:: with SMTP id c37-v6mr32032715pgb.6.1534496339174; Fri, 17 Aug 2018 01:58:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534496339; cv=none; d=google.com; s=arc-20160816; b=YtSQNH9QHjRlHTy+LEWvxAqKdxBcumXosZ61IdZMq0fBJjYMwG/FJVmfUK3TG8WdGz +OW+4s5/yQVffSzVsROqLqWM2kFNw1BhvjA5iIT+DxGQ8T6Wc4TPFtiXVmNEx8BDxZvd 6pXCo+902eoqLt+wF4MM0q4ngWXsT56j5zmifP0eUvGECq58TUFpKr3PmAQ1vgF3tnoM k7wL8BSPvan6SbbVbF2gdeWvI9aadV9XtfOwgsfFV2pWtErqRq68NM7ZbAuAtLr7Vccf k0Syqoxqlk4FcIARV9Q4WX2tk5Se6Ku9flu/cWsgDSarlYvpyKmQ9gpOEWVFYjWUbE5M fQQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:arc-authentication-results; bh=qN7LXQBlLNpyqGffdPWbl3TeOZdOe0gwIS3nQf9dr40=; b=IdDv7M2RAGwopelOJdvZFBU9780NQTbkxMGTxeQD5iMfH1A6JGEXsqpNHl8G1PL+uJ 53XnrXbSZb4tVKvqPDTP9q8ppWw4l4wUL219wRrj/Rt6LsMbxWWNoIT+PYAjUsgl1Pgc KSb+mjqJYPgsch/CypgbQNPLj7Gnx46k99A0/NI2M5RRPjc8OQY8ZHie/WSiDN+wuLpt AHB1ouDOLOp4AiPWChdSkuLcUJEZS9VP59Y4u2iHpZv+GJcthDJNgcRzpbzksTS2fIDP 9ypDXbCMHMiXJIclAtTpacwBGQM8nhfETwgzKijtEWcVcPqafK14CoYfre5K9Qy4mN7s 0pNw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d11-v6si1703541plr.261.2018.08.17.01.58.44; Fri, 17 Aug 2018 01:58:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726541AbeHQMAL (ORCPT + 99 others); Fri, 17 Aug 2018 08:00:11 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:38762 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726213AbeHQMAL (ORCPT ); Fri, 17 Aug 2018 08:00:11 -0400 Received: by mail-oi0-f68.google.com with SMTP id v8-v6so12828637oie.5; Fri, 17 Aug 2018 01:57:37 -0700 (PDT) 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=qN7LXQBlLNpyqGffdPWbl3TeOZdOe0gwIS3nQf9dr40=; b=SM3TQOqKbNwNU+z00gFi++fa4BACJkcvSFA5Jo+anKKFLxKVLkurko3qAAS5Bb9a8a k680PhRr1LFydV/PAECfHdqrwCVIgaLEXFodpjEIezzcBMZ01w3VUgNh3/a3mr521pFf tpEbBspVw51yEcvnQyjeoGhwISZh34FccP8KGNXspY3tZdoDkNp286ftEjM+j2NRz8cr B1Yy1JZMf1h7wfF67axEs743+fku/09VJM79yTkHUQXws40QGwns58bWp7qXDpatVNu6 vA8jaiA/lp3XVigI/PhFaAlrdz+GkQ1A5A41zaopUTRAfX9SKH69U/Zu1aNo/d8EMoYS jp+g== X-Gm-Message-State: AOUpUlGN3M1PfaapqkoaDwAjBIObSe6+o6qnf6WEOxA/SB8riebn/ccv VrPXdonWc1xpcQJGqxN3SJ6tfHASSxU1sm9a+Dg= X-Received: by 2002:aca:b885:: with SMTP id i127-v6mr1634635oif.180.1534496256599; Fri, 17 Aug 2018 01:57:36 -0700 (PDT) MIME-Version: 1.0 References: <20180817075901.4608-1-david@redhat.com> <20180817075901.4608-2-david@redhat.com> <20180817084146.GB14725@kroah.com> In-Reply-To: <20180817084146.GB14725@kroah.com> From: "Rafael J. Wysocki" Date: Fri, 17 Aug 2018 10:57:25 +0200 Message-ID: Subject: Re: [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug To: Greg Kroah-Hartman Cc: David Hildenbrand , Linux Kernel Mailing List , Linux Memory Management List , linuxppc-dev , ACPI Devel Maling List , devel@linuxdriverproject.org, linux-s390@vger.kernel.org, xen-devel@lists.xenproject.org, Andrew Morton , Michal Hocko , Vlastimil Babka , Dan Williams , Pavel Tatashin , osalvador@suse.de, Vitaly Kuznetsov , Martin Schwidefsky , Heiko Carstens , kys@microsoft.com, haiyangz@microsoft.com, sthemmin@microsoft.com, Benjamin Herrenschmidt , Paul Mackerras , "Rafael J. Wysocki" , Len Brown , David Rientjes Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 17, 2018 at 10:41 AM Greg Kroah-Hartman wrote: > > On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote: > > From: Vitaly Kuznetsov > > > > Well require to call add_memory()/add_memory_resource() with > > device_hotplug_lock held, to avoid a lock inversion. Allow external modules > > (e.g. hv_balloon) that make use of add_memory()/add_memory_resource() to > > lock device hotplug. > > > > Signed-off-by: Vitaly Kuznetsov > > [modify patch description] > > Signed-off-by: David Hildenbrand > > --- > > drivers/base/core.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c > > index 04bbcd779e11..9010b9e942b5 100644 > > --- a/drivers/base/core.c > > +++ b/drivers/base/core.c > > @@ -700,11 +700,13 @@ void lock_device_hotplug(void) > > { > > mutex_lock(&device_hotplug_lock); > > } > > +EXPORT_SYMBOL_GPL(lock_device_hotplug); > > > > void unlock_device_hotplug(void) > > { > > mutex_unlock(&device_hotplug_lock); > > } > > +EXPORT_SYMBOL_GPL(unlock_device_hotplug); > > If these are going to be "global" symbols, let's properly name them. > device_hotplug_lock/unlock would be better. Well, device_hotplug_lock is the name of the lock itself. :-) > But I am _really_ nervous about letting stuff outside of the driver core mess > with this, as people better know what they are doing. > > Can't we just "lock" the memory stuff instead? Why does the entirety of > the driver core need to be messed with here? Because, in general, memory hotplug and hotplug of devices are not independent. CPUs and memory may only be possible to take away together and that may be the case for other devices too (say, it wouldn't be a good idea to access a memory block that has just gone away from a device, for DMA and the like). That's why device_hotplug_lock was introduced in the first place. That said I agree that exporting this to drivers doesn't feel particularly safe.