Received: by 10.192.165.148 with SMTP id m20csp4143260imm; Mon, 30 Apr 2018 12:33:40 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq9j3TrWdgUtgnFqI/Qw3RICc5pi5IB35J3Jh3DjwyQZW/QqeyT7ns+3OZfvrb3mnLMZ89q X-Received: by 2002:a63:7a05:: with SMTP id v5-v6mr10978767pgc.184.1525116820114; Mon, 30 Apr 2018 12:33:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525116820; cv=none; d=google.com; s=arc-20160816; b=Vox4v7517mUj5jLGyz5u6zFaYn/ngDzChZkSk7XFY4mXYwi6dYJyoIkX1EZTtccTl2 xAoFAuFCvMpm4XNeQg4aZ9xzTYt/Te+3FbhPmKqNQLMS8XDAq02YO0yjld8r1MLUDgNS o9roFT+DHuqrpjIXRkw0nMl+te0olVgJYo06JYw6ZihSfOZOIMQvjPMN79XcW4KC3kJz +66xJo45/T4JTIqMmPZerp+eEcXIJXvQsBZutd8cDrnEFR8P8XJALjeE35/1tnPSW+W/ xiM+pNEE1UtfZ2+aNa/ZKsAtENLz0hjvr/bcHlVX+XKE9BxLK1ngUvYUwM7J7EjKHNis 6MJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dmarc-filter :arc-authentication-results; bh=ThtO/3JhJsrDdm9vIlTMGCVBtzOPeaspu2+pjV7s2tQ=; b=AS5E1At3WcCkbf3Kx8VNt/htqjx8X1EE+5KM22xf65H6TbXXGM6N/H7yHF/HHstYMv Snh6OrwxZ59cwKSTH0JDo22tB598KxLmfeGgjPpQq/Sem8G9oYiyVZsdFHeM3NNp0rrw 2oAQX7TLggLjNxuHw5phKBvt9W/6htJqcMY6HajGQ82KzTc0V6N0jnK0zySnthJQ0UJs j5SN+nfiqbAlU8wIl33cnx///emP9TefEN5bFavOocYRStQWIxDbi0RGjGAKE29zBxKH /9+YpsFtEg+ssrBuWZL2F6xs5VUSEZbSmH4jvHi5R99FJwHxQby2rSFMwG2DJn5vo0ZE 2Hhw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v6-v6si6499842pgs.399.2018.04.30.12.33.25; Mon, 30 Apr 2018 12:33:40 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932324AbeD3Tcg (ORCPT + 99 others); Mon, 30 Apr 2018 15:32:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:37368 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932403AbeD3T27 (ORCPT ); Mon, 30 Apr 2018 15:28:59 -0400 Received: from localhost (unknown [104.132.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 81AF122E72; Mon, 30 Apr 2018 19:28:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 81AF122E72 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=gregkh@linuxfoundation.org From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Balbir Singh , Reza Arbab , Rashmica Gupta , Michael Ellerman Subject: [PATCH 4.16 080/113] powerpc/mm: Flush cache on memory hot(un)plug Date: Mon, 30 Apr 2018 12:24:51 -0700 Message-Id: <20180430184018.566463069@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180430184015.043892819@linuxfoundation.org> References: <20180430184015.043892819@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 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 4.16-stable review patch. If anyone has any objections, please let me know. ------------------ From: Balbir Singh commit fb5924fddf9ee31db04da7ad4e8c3434a387101b upstream. This patch adds support for flushing potentially dirty cache lines when memory is hot-plugged/hot-un-plugged. The support is currently limited to 64 bit systems. The bug was exposed when mappings for a device were actually hot-unplugged and plugged in back later. A similar issue was observed during the development of memtrace, but memtrace does it's own flushing of region via a custom routine. These patches do a flush both on hotplug/unplug to clear any stale data in the cache w.r.t mappings, there is a small race window where a clean cache line may be created again just prior to tearing down the mapping. The patches were tested by disabling the flush routines in memtrace and doing I/O on the trace file. The system immediately checkstops (quite reliablly if prior to the hot-unplug of the memtrace region, we memset the regions we are about to hot unplug). After these patches no custom flushing is needed in the memtrace code. Fixes: 9d5171a8f248 ("powerpc/powernv: Enable removal of memory for in memory tracing") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Balbir Singh Acked-by: Reza Arbab Reviewed-by: Rashmica Gupta Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/mm/mem.c | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -143,6 +143,7 @@ int arch_add_memory(int nid, u64 start, start, start + size, rc); return -EFAULT; } + flush_inval_dcache_range(start, start + size); return __add_pages(nid, start_pfn, nr_pages, altmap, want_memblock); } @@ -169,6 +170,7 @@ int arch_remove_memory(u64 start, u64 si /* Remove htab bolted mappings for this section of memory */ start = (unsigned long)__va(start); + flush_inval_dcache_range(start, start + size); ret = remove_section_mapping(start, start + size); /* Ensure all vmalloc mappings are flushed in case they also