From patchwork Thu Dec 6 00:26:21 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wei Yang X-Patchwork-Id: 10715153 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 70F031057 for ; Thu, 6 Dec 2018 00:26:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5EF8A2DAA3 for ; Thu, 6 Dec 2018 00:26:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 50D602DAC6; Thu, 6 Dec 2018 00:26:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2C0782DAA3 for ; Thu, 6 Dec 2018 00:26:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C9B26B771A; Wed, 5 Dec 2018 19:26:34 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 228946B771B; Wed, 5 Dec 2018 19:26:34 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A1D66B771C; Wed, 5 Dec 2018 19:26:34 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by kanga.kvack.org (Postfix) with ESMTP id B56AB6B771A for ; Wed, 5 Dec 2018 19:26:33 -0500 (EST) Received: by mail-pl1-f199.google.com with SMTP id h10so16036353plk.12 for ; Wed, 05 Dec 2018 16:26:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:from:to:cc:subject:date :message-id:in-reply-to:references; bh=Q+ykiBMRTkCeImqS+tC78J5Rh8XlO4UH5sOpHLm2riY=; b=IT2kbKwmPuBDMmv9U60MFerfD096zE+PbMqVtReeSBqGEEB6HiHLkRGz62k2p0m5P1 iL/vHyyXVozACt1oU1XXiSMGDayRd5SPgSsxLPwcelv+WM2ufMTAKDqVfRviAwmNDCdJ eaXejBzNQOZ+kYaUp9RmtwURs9CzV1GQwSk969DLl/L13pjZMwbYTR6APzmGHidTtxg0 IvbdbVxvVa/XqkdvKS5ZVgTftDoJj8Qlh/sVVzSdJGGsG8hXF4N0qisWJ45CbLSWOqCg dzYjx4K9CcZnIZCMuqehOsea7bJ3HgdBXoqvs0V8H4QOLm7Fc9SygyblTi+gH58CT4Si ZlLw== X-Gm-Message-State: AA+aEWY6pB/wX5Y7VZqMqYroPjxZspjemRLq1upnbtnxCLtyEnI4IBpy KWUWp8cNfUPRAUm+jZN5yMBXFVP2788aUUpeGb766OH6jwNqyRHFaDGvvX1yQRTP58xPw7iyj+u lJVjmUgHKz3tds/PhWcNMsGtVSvRgnXGICLGkDS7iUI2KyJ0XJKsjk6ZvyJCsGY0W14Cph8AMTA Nrp7cYd9iyXVBRb8TqQ7Kk1w4R3VoUINoFhorsFOZSCg0IJPgm9vCxcXbXQH5edU8brTnK+VgHE og+oTOLIaM107zEuIZSq4yAYptPiDMEHML+Jv75XPzM/q7bQd94AWb812+XlOkDZUW7k5F/Y3WK aUudKapD50sEk26iw0v1W9ZyI6iqJmP7DzWonn7fsmjHFDbMER0CgHOpAEVkj4P2pLVCqBg/3N5 J X-Received: by 2002:a62:cf02:: with SMTP id b2mr27518852pfg.183.1544055993265; Wed, 05 Dec 2018 16:26:33 -0800 (PST) X-Received: by 2002:a62:cf02:: with SMTP id b2mr27518807pfg.183.1544055992247; Wed, 05 Dec 2018 16:26:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544055992; cv=none; d=google.com; s=arc-20160816; b=ueeTFDqUS29KRSta3+1qp7WFtV3TdoSLKxGWol7sLsy160aU2YYf/N8H9ZqmgCrWYw rOaD5FgB5mO2ZVXmwTU6paLON8uNDPgQvo/xH66TVQTjlRbFYRh8314VDOW6dZrAoYFj UN0+W8k9zwO7j69/RHI7QSrGLhc87ITLsxjHTWsnD9JPKzYfS2lxCtNezYHMagO8IPU/ L+TU23eFB9nqhx8Zpf3R/KILSGyeBP3eP+UBFbXAGVWXBbwGjotUjBcbg1CL1PIfmdRn AulX6zn16SlPl+5BY6TyzYmV7wZgH/BiSECn0fNXv14VsRFGwVDfjSVq4TZP7sUYuA8+ nPqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Q+ykiBMRTkCeImqS+tC78J5Rh8XlO4UH5sOpHLm2riY=; b=SPEa8qlgTgOnqrN1VKh9WzKhRaHGv0znbu0m4uihQCpM/wRiccITNTR4pMhPGWo2wj eIXt+INA5DiaHN/kYgAl7JiT9afv0gPXblUqGZskymdkCyuzU5+tXI7ORiPB9CcxBsg8 YAjrEZwEXB11kqot9GKSz5GfWg2ucldNNBMyKmYV/pVLdpfiy7bdlUsWNhKMVxt2c6yY T7OdVJ6NlpNJ6GgEFWzu6nj9Xe2N1ZZO32bVACqaxC7wUrKidUJ76NRA6MjDkNnUjoqU HUvGF2iCbMC8iuXvsSp44VIx3AHtWo96rMzXfQJH5teixlkLhg4HcWellkj7nZgjWpLd KnBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=h9F7wLZF; spf=pass (google.com: domain of richard.weiyang@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id az5sor29170747plb.11.2018.12.05.16.26.32 for (Google Transport Security); Wed, 05 Dec 2018 16:26:32 -0800 (PST) Received-SPF: pass (google.com: domain of richard.weiyang@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=h9F7wLZF; spf=pass (google.com: domain of richard.weiyang@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=Q+ykiBMRTkCeImqS+tC78J5Rh8XlO4UH5sOpHLm2riY=; b=h9F7wLZFqRiMYuebpBQeZkD1Uzf7nnDxqkjrZvFlpI+6b+WMMRfMoZKck5fbU9xglk gEHxKZzutP/r7zojICtrQy5KBT5NHUD+3C9NWjZ/x3eWLRk923PR6xPwOGcI5uzFSU/E JRRAehsxzEmoLf8aZRVCCjep2/Rz2Ud6Jx341O8p8+vK05evlGWbArF6zNSWVjkL8hkP aeBBImDZn4NodwZVrdAeP16sh41GfR0T8v74GQX5FKEEtFqBoVFNeKkbda4kpnwt50JS 0Fqw6dKvyHL043v+7xJFlDHAiMR63vhfV/HYkB1S3IobjQJ2xBItjSbUpqkEX5nHqUC2 6KwA== X-Google-Smtp-Source: AFSGD/XYP1iDJaINowV0OHqBgU+KrIneycWfBQNEdVmXtrovPSboSSw+z6xVLwlxBMDCnyiekjM/3w== X-Received: by 2002:a17:902:8c91:: with SMTP id t17mr25395582plo.119.1544055991816; Wed, 05 Dec 2018 16:26:31 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id z8sm49214584pgz.53.2018.12.05.16.26.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 16:26:31 -0800 (PST) From: Wei Yang To: rppt@linux.ibm.com, david@redhat.com, mhocko@suse.com, osalvador@suse.de Cc: akpm@linux-foundation.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, Wei Yang Subject: [PATCH v2 1/2] admin-guide/memory-hotplug.rst: remove locking internal part from admin-guide Date: Thu, 6 Dec 2018 08:26:21 +0800 Message-Id: <20181206002622.30675-1-richard.weiyang@gmail.com> X-Mailer: git-send-email 2.15.1 In-Reply-To: <20181205023426.24029-1-richard.weiyang@gmail.com> References: <20181205023426.24029-1-richard.weiyang@gmail.com> 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: X-Virus-Scanned: ClamAV using ClamSMTP Locking Internal section exists in core-api documentation, which is more suitable for this. This patch removes the duplication part here. Signed-off-by: Wei Yang Reviewed-by: David Hildenbrand Acked-by: Mike Rapoport --- Documentation/admin-guide/mm/memory-hotplug.rst | 40 ------------------------- 1 file changed, 40 deletions(-) diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index 5c4432c96c4b..241f4ce1e387 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -392,46 +392,6 @@ Need more implementation yet.... - Notification completion of remove works by OS to firmware. - Guard from remove if not yet. - -Locking Internals -================= - -When adding/removing memory that uses memory block devices (i.e. ordinary RAM), -the device_hotplug_lock should be held to: - -- synchronize against online/offline requests (e.g. via sysfs). This way, memory - block devices can only be accessed (.online/.state attributes) by user - space once memory has been fully added. And when removing memory, we - know nobody is in critical sections. -- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC) - -Especially, there is a possible lock inversion that is avoided using -device_hotplug_lock when adding memory and user space tries to online that -memory faster than expected: - -- device_online() will first take the device_lock(), followed by - mem_hotplug_lock -- add_memory_resource() will first take the mem_hotplug_lock, followed by - the device_lock() (while creating the devices, during bus_add_device()). - -As the device is visible to user space before taking the device_lock(), this -can result in a lock inversion. - -onlining/offlining of memory should be done via device_online()/ -device_offline() - to make sure it is properly synchronized to actions -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type) - -When adding/removing/onlining/offlining memory or adding/removing -heterogeneous/device memory, we should always hold the mem_hotplug_lock in -write mode to serialise memory hotplug (e.g. access to global/zone -variables). - -In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read -mode allows for a quite efficient get_online_mems/put_online_mems -implementation, so code accessing memory can protect from that memory -vanishing. - - Future Work ===========