From patchwork Wed Dec 5 02:34:25 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wei Yang X-Patchwork-Id: 10712909 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 9DDD213BF for ; Wed, 5 Dec 2018 02:35:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8BAA02C95D for ; Wed, 5 Dec 2018 02:35:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7D4E52CB42; Wed, 5 Dec 2018 02:35:28 +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 1183B2C95D for ; Wed, 5 Dec 2018 02:35:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 453B96B71FD; Tue, 4 Dec 2018 21:35:27 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 402B36B71FE; Tue, 4 Dec 2018 21:35:27 -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 2F48E6B71FF; Tue, 4 Dec 2018 21:35:27 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) by kanga.kvack.org (Postfix) with ESMTP id E37D56B71FD for ; Tue, 4 Dec 2018 21:35:26 -0500 (EST) Received: by mail-pf1-f200.google.com with SMTP id q64so15589282pfa.18 for ; Tue, 04 Dec 2018 18:35:26 -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; bh=byW6p4S4eM51fSS1xfZ9xzVN+oqvY4pZ3OBeX/tNsqM=; b=cYGf2+q78Gce6N++QGSL0N8bO1Fndg/qkdS3vECbLx7Os0UBYkdKMubFWFMiCJ0Vzl 7PVipL1uk3H9jLhbSPRXupxN/UnJTcDbtq7Y1EkulIcT1DHFaFYmg3j7Y8jNtZ1Knqbi XdP+QIns6cV/GBWewcXTDw+aPubcGZ8MdPXUuQBtDtuXuaqNh6UzkTmDbvR9ie6urzO5 fBX1oyZGP5tnn4/U2v0lmN/rVIh3MhhWjjhZmRXXL0loI2Lkpr3YiEEECRdK5m9BEOuT 0KPIesSDTHzFfPOMkN/RwN5AP1Qo0kk5bGlGm7C8nKiZtAO0gCzFNsYBUik7oSt6xIVH sAmw== X-Gm-Message-State: AA+aEWZQ+wZTHPO9zQX8+GrlOnBWuls/yq0xVnxR2qAAJX9uq91w7mTQ JMP73wMXh8oFDB8d+n7+lHoyzdk70Y4yRDTGiUbm25XjJNbVEUK+F0pDwvKoBxhOkEBfA7if3FD d9krFTPPhgyuqS82r4JVGtamHy6x2Sc41FYAelNBIN9xrJGnX8nAZznAXWhtkPWITvkJEUA90lZ kfxsWxJBHyRr8bt/QrpbTUz7zhEN+QkJ3uXNJQfMavrjycGJh6pKTvBE2Osl8VSNUdw/V2tuA2o cz2H5vU5A2vcZ8XXWfwJVea2HEwCC/P7pV2Z4JuQ3AsyJyWsPjWu1whds3pk5BIfSaQmwMGE/u7 thloKdQSiGkYxEJf8JuxiiYhxpHnTrJD0BHmRM7sE5J4QM5mBxw0icJ5Y8H++oEbQsKx9Motna3 G X-Received: by 2002:a17:902:24e7:: with SMTP id l36mr10819659plg.61.1543977326521; Tue, 04 Dec 2018 18:35:26 -0800 (PST) X-Received: by 2002:a17:902:24e7:: with SMTP id l36mr10819605plg.61.1543977325642; Tue, 04 Dec 2018 18:35:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543977325; cv=none; d=google.com; s=arc-20160816; b=zTegkzU3/7UWPIslMzCUhij7isYWw+929JHQNlpcHzWaaXiFg6uCyCj1ccmLtjq8Wy +f9fhj0Z7OBwHEqT4gZYWM7PLmjFtsi+4gbrHcB0/QkFIL29qbAFGXHSlfPkNdn9Mn1a siE7XyEmaLWY20WgJd7D5uVELLklWugZT5NWsfdPoj904aDV2DORuMKTvqwzr2b9xUBA 2EwoRvIh0Fgz1Puf4au7QmdsoV9V2tBxkuqmx3FToB2GeZi6EV8fsX8/ugkOnZiXl0rr rogM5EfUeyE+L5O3zyhpCzKMjvuV+1RW1z+dfwmVpew1QcKIMkrTOOtkskne0eQzWZNi BkMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from:dkim-signature; bh=byW6p4S4eM51fSS1xfZ9xzVN+oqvY4pZ3OBeX/tNsqM=; b=zGngfDhcejD2GnsO6MGrE/Yhn0+svvamQWTkiaW1LQUBUFxNsQrpbrkjLbwxU3cCp/ 82R+tcKXUrPPkj7i+wH7zve0GgRcy4yKajfVzRw/vm+QPz2fhbtC+blmcpRsfLsGgc28 lPex6zAvBDGdElNwdXsIKulypzWILGTpVlbJ29PygocJhzGBjeedYuyPlh3tEIl2q5pE F/c7ZCDGZWZByFOF0vyfD+Jc9M90n91DA9xJVKgf8H77qQSGIVyeZzSY4ujXytyymJE0 +TqCxyjkt0dR9LyEGMmuRAE4OSBX6QgFvRB7x2GRQ/lhcwxiss600h6rJL7cFtqP0QO3 8ahA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ATrCFX0A; 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 24sor23920910pgq.13.2018.12.04.18.35.25 for (Google Transport Security); Tue, 04 Dec 2018 18:35:25 -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=ATrCFX0A; 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; bh=byW6p4S4eM51fSS1xfZ9xzVN+oqvY4pZ3OBeX/tNsqM=; b=ATrCFX0AUw3N/t6K+D+lC4nB4fmUsKeq1RFks/SpheQPpkjHC6Z6CVITWp++RH2gdi bhuO2LU5WwxohVR983/iYAhPARSEcMbe/1NywaUFmz2I+Q5+LCrS1u6Zcx319/nyUbKD Rvq9/glWewozLqQvUXAoMF9eMq1ov4Kwgc5VxCb7PnO6zL5rMySEb/MB9Oftw0sD9Cfj +nue9qyZbyEfBFatQTtGrSq40KdkZ73XecHRBRgpMpWMyvcL7d8UbdkAU1bxI+7vshuQ D5ZWYyUPzZd3i1lNMke7wIKSONnf5juC8wicTHD8DQdA05lFx2MWVeoy/mEVqerZnYaO PIPg== X-Google-Smtp-Source: AFSGD/VZ460ddkmSWsEb1ZtVrfS9y8Y9IMIzLwBgweXpFQGuJwDn1pNI83oEFnMYDXs/iW68Hcno5Q== X-Received: by 2002:a63:c10f:: with SMTP id w15mr18644758pgf.199.1543977325174; Tue, 04 Dec 2018 18:35:25 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id v9sm27454463pfg.144.2018.12.04.18.35.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 18:35:24 -0800 (PST) From: Wei Yang To: 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 1/2] admin-guide/memory-hotplug.rst: remove locking internal part from admin-guide Date: Wed, 5 Dec 2018 10:34:25 +0800 Message-Id: <20181205023426.24029-1-richard.weiyang@gmail.com> X-Mailer: git-send-email 2.15.1 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 ===========