Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp612578ybj; Thu, 7 May 2020 03:35:50 -0700 (PDT) X-Google-Smtp-Source: APiQypIm1ngeW8pRjwyCxtf/hxPTXLD/IRSQ0QTA7r4ZskaawySKzyIgSoantWiP42tU2HuRtCA4 X-Received: by 2002:a17:906:5e50:: with SMTP id b16mr11819420eju.331.1588847749989; Thu, 07 May 2020 03:35:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588847749; cv=none; d=google.com; s=arc-20160816; b=Uq61IL9ElOOQae3qnNABnRVYEQmmJZZxlSf2d97JrAh6LGvc+9tv+FztrrpMYk7inK atNfXeukMj9FSaTnLnRK31OJ9u/YaxxmaYHN+cY563EO/HOJJ3SZMie3P7Myx0CfgHoa IhGp8sw0Hv5Nn+5fmSrcwD3lCNtnHyo52QgBwsgYnx87IUzmuMucQgBrDwsnSWnjFb7u OFl1aL/co5WeprDtHob5cu0RAK0n2K+ByVkOV1WzEVoYxPuAva6CY1e2E5jDb4IhOVL2 AI0ayUKcOSv7NQrPWqgVwrAWV5OhS0bec4jNHSGdr1nRtuU7grDkVP31nJtoHsb+yH1I Qz/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=LfKs05RuoTQVAkleaDqaXa4vjxynrDAbg0h7VJOtKyY=; b=u//sNH2WejoFvIRMHdtR0vIT4hI5dXZCJ2HeqMTGv7Kf2fi8cKtAafC8Z9io5idhkI ZSB56Ys4T7fBRZ0nb84EPE70B4K+CmMPC2OUuDKqwFlDjxa6N2r30NwPppzMamaHkVvF 86aczuHbIswpmEJ2SGzFmv0hhasNfJvRSF89OPTjKYPAI9dHrNZYKGIBiUTV/TUGfMir gB5C0myhbqHCv7aF8fGHctVrVQmea1g056l2NyQKpHYVCp1UQMSZJfSs3R8Jo5qCmbYz 3st/95K/fF6t5Sc8CxNCNMQAmssYEPcrkMpsu4JChl7Smp6z062tOCjstAWARGaaJ5La 0kZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UOu2Ds7o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o14si3151773ejm.511.2020.05.07.03.35.26; Thu, 07 May 2020 03:35:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UOu2Ds7o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727769AbgEGKdU (ORCPT + 99 others); Thu, 7 May 2020 06:33:20 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:54982 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727113AbgEGKdM (ORCPT ); Thu, 7 May 2020 06:33:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588847586; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LfKs05RuoTQVAkleaDqaXa4vjxynrDAbg0h7VJOtKyY=; b=UOu2Ds7owDyR0kyOjYjVZ7iJ3ztzUx4OM9cUFK1bD8z4AngfTFqiDzsBv8BIzEiskYoZyI qsMivQVK3Pvw21oMJN+HI6kdua1gNH6yTHSVwapVbw5gry9Cg0SGUwxAK0U1ZncNLVQ+NT 65b+3Rpp4qTBUaUKRKnIa5/wnpAxPBg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-357-CMkwtfsPM12pJ7l3auCYKg-1; Thu, 07 May 2020 06:33:02 -0400 X-MC-Unique: CMkwtfsPM12pJ7l3auCYKg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 18828107ACF3; Thu, 7 May 2020 10:33:00 +0000 (UTC) Received: from t480s.redhat.com (ovpn-113-245.ams2.redhat.com [10.36.113.245]) by smtp.corp.redhat.com (Postfix) with ESMTP id 820BC5D9C5; Thu, 7 May 2020 10:32:51 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, virtio-dev@lists.oasis-open.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, Michal Hocko , Andrew Morton , "Michael S . Tsirkin" , David Hildenbrand , Michal Hocko , Pankaj Gupta , Oscar Salvador , Pavel Tatashin , Wei Yang , Dan Williams , Qian Cai Subject: [PATCH v3 07/15] mm/memory_hotplug: Introduce offline_and_remove_memory() Date: Thu, 7 May 2020 12:31:11 +0200 Message-Id: <20200507103119.11219-8-david@redhat.com> In-Reply-To: <20200507103119.11219-1-david@redhat.com> References: <20200507103119.11219-1-david@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org virtio-mem wants to offline and remove a memory block once it unplugged all subblocks (e.g., using alloc_contig_range()). Let's provide an interface to do that from a driver. virtio-mem already supports to offline partially unplugged memory blocks. Offlining a fully unplugged memory block will not require to migrate any pages. All unplugged subblocks are PageOffline() and have a reference count of 0 - so offlining code will simply skip them. All we need is an interface to offline and remove the memory from kernel module context, where we don't have access to the memory block devices (esp. find_memory_block() and device_offline()) and the device hotplug lock. To keep things simple, allow to only work on a single memory block. Acked-by: Michal Hocko Tested-by: Pankaj Gupta Cc: Andrew Morton Cc: David Hildenbrand Cc: Oscar Salvador Cc: Michal Hocko Cc: Pavel Tatashin Cc: Wei Yang Cc: Dan Williams Cc: Qian Cai Signed-off-by: David Hildenbrand --- include/linux/memory_hotplug.h | 1 + mm/memory_hotplug.c | 37 ++++++++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+) diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplu= g.h index 7dca9cd6076b..d641828e5596 100644 --- a/include/linux/memory_hotplug.h +++ b/include/linux/memory_hotplug.h @@ -318,6 +318,7 @@ extern void try_offline_node(int nid); extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages= ); extern int remove_memory(int nid, u64 start, u64 size); extern void __remove_memory(int nid, u64 start, u64 size); +extern int offline_and_remove_memory(int nid, u64 start, u64 size); =20 #else static inline void try_offline_node(int nid) {} diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 936bfe208a6e..bf1941f02a60 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1748,4 +1748,41 @@ int remove_memory(int nid, u64 start, u64 size) return rc; } EXPORT_SYMBOL_GPL(remove_memory); + +/* + * Try to offline and remove a memory block. Might take a long time to + * finish in case memory is still in use. Primarily useful for memory de= vices + * that logically unplugged all memory (so it's no longer in use) and wa= nt to + * offline + remove the memory block. + */ +int offline_and_remove_memory(int nid, u64 start, u64 size) +{ + struct memory_block *mem; + int rc =3D -EINVAL; + + if (!IS_ALIGNED(start, memory_block_size_bytes()) || + size !=3D memory_block_size_bytes()) + return rc; + + lock_device_hotplug(); + mem =3D find_memory_block(__pfn_to_section(PFN_DOWN(start))); + if (mem) + rc =3D device_offline(&mem->dev); + /* Ignore if the device is already offline. */ + if (rc > 0) + rc =3D 0; + + /* + * In case we succeeded to offline the memory block, remove it. + * This cannot fail as it cannot get onlined in the meantime. + */ + if (!rc) { + rc =3D try_remove_memory(nid, start, size); + WARN_ON_ONCE(rc); + } + unlock_device_hotplug(); + + return rc; +} +EXPORT_SYMBOL_GPL(offline_and_remove_memory); #endif /* CONFIG_MEMORY_HOTREMOVE */ --=20 2.25.3