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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 396AEC48BC4 for ; Tue, 20 Feb 2024 19:51:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hpuWU/N+jKCYq6YbraSAhEtV6WLI4iEOMRwNZRth2lM=; b=ysa1nQm7/0cIFY 6VUU3mfYEV3pn+qr+A02CJy7aJi6+/E6NGAhZ1eqznGzumdxba/6GbKrbSTl/XG+t08/uOBGpgNgL 1OQCuGU8U1ogMr2ATAt2jtnB+i0Rdvb1wGhJ0sxS82Mb/tUcratKy8Agv6Xrfir98conEtbjOsukG yF2TByAt6fmtNVtUuj3xZ30GSaUJD8vZ0LzkOV47igPbh2/sKKasCKdoANimC/1hFVVmWodA/E8IQ 8Gzfjj3NbNR+EdGaXASVH+3fCL6txWXbv4eQtILHVbmJvGdtNIsGezdoXIa7/LKtfODkgzQxX2ZBp XFfoTouqiSn0MxhJ7Ewg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rcW8l-0000000G0fZ-26Lj; Tue, 20 Feb 2024 19:50:55 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rcW8i-0000000G0eX-20JJ for linux-arm-kernel@lists.infradead.org; Tue, 20 Feb 2024 19:50:54 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 171D1FEC; Tue, 20 Feb 2024 11:51:24 -0800 (PST) Received: from [172.20.10.9] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 47F7F3F73F; Tue, 20 Feb 2024 11:50:39 -0800 (PST) Message-ID: <061b8c8a-51cc-46b0-8a2d-90bf6c6ce5d8@arm.com> Date: Tue, 20 Feb 2024 20:50:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 12/18] arm64/mm: Wire up PTE_CONT for user mappings Content-Language: en-GB To: John Hubbard , Catalin Marinas Cc: Will Deacon , Ard Biesheuvel , Marc Zyngier , James Morse , Andrey Ryabinin , Andrew Morton , Matthew Wilcox , Mark Rutland , David Hildenbrand , Kefeng Wang , Zi Yan , Barry Song <21cnbao@gmail.com>, Alistair Popple , Yang Shi , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240215103205.2607016-1-ryan.roberts@arm.com> <20240215103205.2607016-13-ryan.roberts@arm.com> <892caa6a-e4fe-4009-aa33-0570526961c5@arm.com> From: Ryan Roberts In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240220_115052_606559_6AAF8F6F X-CRM114-Status: GOOD ( 18.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 16/02/2024 19:54, John Hubbard wrote: > On 2/16/24 08:56, Catalin Marinas wrote: > ... >>> The problem is that the contpte_* symbols are called from the ptep_* inline >>> functions. So where those inlines are called from modules, we need to make sure >>> the contpte_* symbols are available. >>> >>> John Hubbard originally reported this problem against v1 and I enumerated all >>> the drivers that call into the ptep_* inlines here: >>> https://lore.kernel.org/linux-arm-kernel/b994ff89-1a1f-26ca-9479-b08c77f94be8@arm.com/#t >>> >>> So they definitely need to be exported. Perhaps we can tighten it to > > Yes. Let's keep the in-tree modules working. > >>> EXPORT_SYMBOL_GPL(), but I was being cautious as I didn't want to break anything >>> out-of-tree. I'm not sure what the normal policy is? arm64 seems to use ~equal >>> amounts of both. > > EXPORT_SYMBOL_GPL() seems appropriate and low risk. As Catalin says below, > these really are deeply core mm routines, and any module operating at this > level is not going to be able to survive on EXPORT_SYMBOL alone, IMHO. > > Now, if only I could find an out of tree module to test that claim on... :) > > >> I don't think we are consistent here. For example set_pte_at() can't be >> called from non-GPL modules because of __sync_icache_dcache. OTOH, such >> driver is probably doing something dodgy. Same with >> apply_to_page_range(), it's GPL-only (called from i915). >> >> Let's see if others have any view over the next week or so, otherwise >> I'd go for _GPL and relax it later if someone has a good use-case (can >> be a patch on top adding _GPL). > > I think going directly to _GPL for these is fine, actually. OK I'll send out a patch to convert these to _GPL on my return on Monday. Hopefully Andrew will be able to squash the patch into the existing series. > > > thanks, _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel