From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55879C55ABD for ; Wed, 11 Nov 2020 14:54:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E4989206D9 for ; Wed, 11 Nov 2020 14:54:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="VQjhgdHs" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727334AbgKKOxv (ORCPT ); Wed, 11 Nov 2020 09:53:51 -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