Received: by 10.192.165.148 with SMTP id m20csp4162274imm; Mon, 30 Apr 2018 12:59:00 -0700 (PDT) X-Google-Smtp-Source: AB8JxZos0gZ9ber3nIBpRc3/vSjMfaXS1K5dV0fEBh23M2FGabJ6totFy7PnKpHKWo+vdeAJaFe/ X-Received: by 2002:a17:902:9344:: with SMTP id g4-v6mr13840271plp.10.1525118340799; Mon, 30 Apr 2018 12:59:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525118340; cv=none; d=google.com; s=arc-20160816; b=THeVWz5B33WWMbN5pyCSOOyrqUHD93Ycnm4UiI3OBj0kldrr+Ek3SkNLn7BrznSmu9 vWPSpKgDJ4WRPWtUDu2HhTYaoRaa7zf2gN13cT9pGmlpKcz0hi/uBYHcc+Z6vxMjUcQT l0YeZLByEH/cir/XNGvDAq54nmy7dQj4iGkFFb6KsGngbJ1rTYCS7CZJFfIe4ezuod+P rA4keYX+ApWN561ygYjwLPkdqyUAuUpkqjL5mB4nofeEjjWVS8cxQnQ0bN/x+xHElphb 6JWwEDYxRYiC5g5OjeH2RNsMUKMx6iLYG7XTxM6y24vGSs44l3S28j2Njs6xUhjaE18t 5h4g== 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=K+TS+6UoePTM0JcZOKpNlp8TLlAxb9MHS7gw2KYbUBY=; b=SFKrn2T8i1sHWKCSxTmN8vU8cnufjpiq5swo6nQ4McPDpBI734VRJlynA41yPXksNk UWH4FR/hZYiFfCD02A0LNwGqqJuwkxazMjNBL+fm57JnYpxS+Rqt077p1L0oAxLemCT3 rr2zr1sM/hoRSrSaRRQlbSX7J+/yNmgjROxGMZ4RH7CKoYIS+vmjChHiZE0KlyBvxA5G srGK8EWel3fu30F8X+sRjeC5dr0ZjA3wRSyhQ0X+npa5bn7yQVlcaQipOX+KbRMWCHE1 ccp+qRqwVTP0KfvzV9d5luOCcP6JcAD+wqbt0frlpTyT1LbYR8C44ACU2EerTLHAqryz hvkA== 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 b12-v6si6570331pge.252.2018.04.30.12.58.46; Mon, 30 Apr 2018 12:59:00 -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 S1756137AbeD3T5b (ORCPT + 99 others); Mon, 30 Apr 2018 15:57:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:34810 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756061AbeD3T1t (ORCPT ); Mon, 30 Apr 2018 15:27:49 -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 9233322DBF; Mon, 30 Apr 2018 19:27:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9233322DBF 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.14 69/91] powerpc/mm: Flush cache on memory hot(un)plug Date: Mon, 30 Apr 2018 12:24:51 -0700 Message-Id: <20180430184007.842987749@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180430184004.216234025@linuxfoundation.org> References: <20180430184004.216234025@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.14-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, want_memblock); } @@ -171,6 +172,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