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 9D8A6C282DD for ; Fri, 10 Jan 2020 17:33:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 62F6420842 for ; Fri, 10 Jan 2020 17:33:48 +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="pDxzWr7J" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 62F6420842 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 312528E0005; Fri, 10 Jan 2020 12:33:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C32D8E0001; Fri, 10 Jan 2020 12:33:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D8808E0005; Fri, 10 Jan 2020 12:33:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id 07B9C8E0001 for ; Fri, 10 Jan 2020 12:33:48 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id B7C9B5854 for ; Fri, 10 Jan 2020 17:33:47 +0000 (UTC) X-FDA: 76362422094.08.burn26_5b421648b843e X-HE-Tag: burn26_5b421648b843e X-Filterd-Recvd-Size: 4392 Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Fri, 10 Jan 2020 17:33:46 +0000 (UTC) Received: by mail-oi1-f196.google.com with SMTP id i1so2512069oie.8 for ; Fri, 10 Jan 2020 09:33:46 -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=ksl+vJ81uwWzx8tmYMkSddxoxlD6SBF31Vqw/Cm4F+4=; b=pDxzWr7JwNvVuHmgOkjXvIPc55f0Lxat/iHEV3kBknVGkWuYT//7MLvF/rGm1UEw13 xgDXvajUgFSkVn/Mowb0vgHH2bwIAwKnEETTxzK1eXw7e84VJbxaQcyW4S5wirg+EJxh H6xgxHjXMbk/cX6gJ0jpb3sUmn3n47ozfND3hrv3kd4iGvakcCkAdAC4c8X2NAxPcxWM vu+CPR26ON3H+Y2xutoAt1P1ZqvPtWYDDXfH3/sJMxDa0JrFdbXujOl0sL3cFN/9T3wS u0YArVRLEqfFQG7ig9QV4Bp1mClj87MvFdBC14326lSfQKSOZJERsfaU5JA3e3JgzIOA j8cA== 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=ksl+vJ81uwWzx8tmYMkSddxoxlD6SBF31Vqw/Cm4F+4=; b=XX7lnR7Q5au2MhNMKnfTaMW84Shnw6Qz54vaAcuy4NNPqTcQJlHefepYpcFb16hi6s sLxYbzdZrFFhz3FFu1aZ4y5TaWSeWvmx/G6tKGqukTOYoL3sudxh3Io1IRPgG4lnZ2Td k9wXoOaohZy3AU9MpoNxZ3ShY6jrBafiJgw6pgj+LRdTVS6B1hZ2jmoJiEfOdCNfrBtD Jg+tiMyxOkQ4FYCYGfur3iZrGwEEMqLpS5BAX0oP0/7bxTjhaeG6uFf1R1AqUIYeIzSo AyU7OcYSXKtRX99N+LXBCg+xDGgyRuEfDCNaEU9CUxuiI+iJ2WSjVP2p+bETAcunXRhg WNnQ== X-Gm-Message-State: APjAAAUBjMch4W7LdJ+cMaOpIELhbO8G52Hrq9i28YtmY29NqAN8TSdN szXGwJqgH89F20XGUV5nfkXTxByj7dHOtiWRmzqhYA== X-Google-Smtp-Source: APXvYqzhq0ZmPdm2FvbVqqhxRBWJSuPUXMhdMbWwgHAHxrtLp0P4UgLsD45jDwlWNkJLZu30q0SN2uRTJVQPKboYUDo= X-Received: by 2002:aca:4c9:: with SMTP id 192mr3272786oie.105.1578677626092; Fri, 10 Jan 2020 09:33:46 -0800 (PST) MIME-Version: 1.0 References: <157863061737.2230556.3959730620803366776.stgit@dwillia2-desk3.amr.corp.intel.com> <4d0334e2-c4e7-6d3f-99ba-2ca0495e1549@redhat.com> In-Reply-To: From: Dan Williams Date: Fri, 10 Jan 2020 09:33:35 -0800 Message-ID: Subject: Re: [PATCH] mm/memory_hotplug: Fix remove_memory() lockdep splat To: David Hildenbrand Cc: Andrew Morton , stable , Vishal Verma , Pavel Tatashin , Michal Hocko , 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 10, 2020 at 9:29 AM David Hildenbrand wrote: [..] > > So then the comment is actively misleading for that case. I would > > expect an explicit _unlocked path for that case with a comment about > > why it's special. Is there already a comment to that effect somewhere? > > > > __add_memory() - the locked variant - is called from the same ACPI location > either locked or unlocked. I added a comment back then after a longe > discussion with Michal: > > drivers/acpi/scan.c: > /* > * Although we call __add_memory() that is documented to require the > * device_hotplug_lock, it is not necessary here because this is an > * early code when userspace or any other code path cannot trigger > * hotplug/hotunplug operations. > */ > > > It really is a special case, though. That's a large comment block when we could have just taken the lock. There's probably many other code paths in the kernel where some locks are not necessary before userspace is up, but the code takes the lock anyway to minimize the code maintenance burden. Is there really a compelling reason to be clever here?