Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp414836pxb; Wed, 11 Nov 2020 06:56:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJwEbFbmnRIz8gODN+T61xsO+WWFYpYxV2gh3u2mPQjr+RQASRm2K0ChOKSU2oaCO6FfhlrK X-Received: by 2002:a17:906:7247:: with SMTP id n7mr25235346ejk.174.1605106564758; Wed, 11 Nov 2020 06:56:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605106564; cv=none; d=google.com; s=arc-20160816; b=do+j2eDEUW9ImZK8hse6Q6T5XrNu378BUPowfGGoYEkdbMnFKVcQVHTe3aC8/LwL0j bLqzSofwXJ/k+NTb5I62bPZJw+n7/oZqxIxNauIUas4wzPEdLgj/3GjbhL8Zrm7Nkl2C RsRnBK5YM+WTvXBwUg8cPMMFrP67LJVmjD54nk1+e/Wdl9DZhyEYt45S5jT3kTzGTsbW Anx9k6/zKTdjYYI7vW1b27YlpbCE5ZfbBWk6/fsgZ/cl2QRyP6o3ttZVg3Lmfzm224D6 lQoC2iIFRiuqcaJjMaWd2oidVEaTFZdhrSzRSGJX2OyOj8S0RJHPBevf30f92xpkPpzV q92w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=GSQatxuwdd1ehWeHPVVOm8FQ78oIMefwI0KM3vx9OUY=; b=Q+6cEaLlm9mm1bh96IHVp86j/u8UyNTCXTxKiL76806XviO0DVpcSk4Ycp/FzloVod bpTV2ay8g6yux2gfDY8ywu/Mtfcf1jeUMjj7t4iZ5HXhwt8HOc+qhUWANG3MQ4/C6O5Z jxG8ycTKXXHeL/m9M9vIgXHH5l1LsgkvfLnGYzWQFUuy+w4fJaHl7cyZ+/PMF7cdbaLY Hd3ZhNLNygqqwnwJzZecjEvR9xgjZYZB/E1GeH8LJoK93FWQSZSXRT0K8EMlhWyLvF8C mewjgC2n7j/ZZYFqb9VOL3P1atlNVfXAwe6mWS7N181Vt7br/diOiCCTcb8laMJsliA9 bq/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VQjhgdHs; 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 ga12si1714973ejc.14.2020.11.11.06.55.40; Wed, 11 Nov 2020 06:56:04 -0800 (PST) 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=VQjhgdHs; 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 S1727236AbgKKOxt (ORCPT + 99 others); Wed, 11 Nov 2020 09:53:49 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:26913 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727311AbgKKOxs (ORCPT ); Wed, 11 Nov 2020 09:53:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605106427; 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=GSQatxuwdd1ehWeHPVVOm8FQ78oIMefwI0KM3vx9OUY=; b=VQjhgdHs8AYav6x0BunlQpdNjniSlMa84QKCQbmmskCcw+NzrbDcmdiyRUixiwyhi75nMR vl3sr72jrGtSgs+dgodTXcM0GmPpNOfI3TEqU6DhEehdpeaY2QhOKkLMUvcQFBemYY+aMW hLfj3Yozo29eK//kkJ1E/xMbRMx+510= 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-310-eMn4ZS-3NWCR9QdUC20pPQ-1; Wed, 11 Nov 2020 09:53:43 -0500 X-MC-Unique: eMn4ZS-3NWCR9QdUC20pPQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D269A8049CC; Wed, 11 Nov 2020 14:53:41 +0000 (UTC) Received: from t480s.redhat.com (ovpn-114-151.ams2.redhat.com [10.36.114.151]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3A9F9380; Wed, 11 Nov 2020 14:53:39 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, David Hildenbrand , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Rashmica Gupta , Andrew Morton , Mike Rapoport , Michal Hocko , Oscar Salvador , Wei Yang Subject: [PATCH v2 4/8] powerpc/mm: protect linear mapping modifications by a mutex Date: Wed, 11 Nov 2020 15:53:18 +0100 Message-Id: <20201111145322.15793-5-david@redhat.com> In-Reply-To: <20201111145322.15793-1-david@redhat.com> References: <20201111145322.15793-1-david@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This code currently relies on mem_hotplug_begin()/mem_hotplug_done() - create_section_mapping()/remove_section_mapping() implementations cannot tollerate getting called concurrently. Let's prepare for callers (memtrace) not holding any such locks (and don't force them to mess with memory hotplug locks). Other parts in these functions don't seem to rely on external locking. Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Rashmica Gupta Cc: Andrew Morton Cc: Mike Rapoport Cc: Michal Hocko Cc: Oscar Salvador Cc: Wei Yang Signed-off-by: David Hildenbrand --- arch/powerpc/mm/mem.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 8a86d81f8df0..ca5c4b54c366 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -58,6 +58,7 @@ #define CPU_FTR_NOEXECUTE 0 #endif +static DEFINE_MUTEX(linear_mapping_mutex); unsigned long long memory_limit; bool init_mem_is_free; @@ -126,8 +127,10 @@ int __ref arch_create_linear_mapping(int nid, u64 start, u64 size, int rc; start = (unsigned long)__va(start); + mutex_lock(&linear_mapping_mutex); rc = create_section_mapping(start, start + size, nid, params->pgprot); + mutex_unlock(&linear_mapping_mutex); if (rc) { pr_warn("Unable to create linear mapping for 0x%llx..0x%llx: %d\n", start, start + size, rc); @@ -144,7 +147,9 @@ void __ref arch_remove_linear_mapping(u64 start, u64 size) start = (unsigned long)__va(start); flush_dcache_range_chunked(start, start + size, FLUSH_CHUNK_SIZE); + mutex_lock(&linear_mapping_mutex); ret = remove_section_mapping(start, start + size); + mutex_unlock(&linear_mapping_mutex); WARN_ON_ONCE(ret); /* Ensure all vmalloc mappings are flushed in case they also -- 2.26.2