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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A522C433F5 for ; Thu, 4 Nov 2021 12:47:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3697960EE9 for ; Thu, 4 Nov 2021 12:47:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231599AbhKDMuQ (ORCPT ); Thu, 4 Nov 2021 08:50:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:52642 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229809AbhKDMuO (ORCPT ); Thu, 4 Nov 2021 08:50:14 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D3FBD60EE9 for ; Thu, 4 Nov 2021 12:47:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636030056; bh=O89SG59ERFkapOwq86PzKcmSXMmROh38ILRsxSPw7zc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FUvx4DVOJMgsgc8Dclim6uiPNanlCw5L3gLp5PVRYWaoNB9rczDaMyOu74b5oF1d4 AHQF0P2QUe/aKt1at2I3AWfbFZ99fftU7/5wpYdVqsnnHuI/KpFI/ENXZez8TbJFb4 5TS6iTqKetd4Skk5at9pKxYakuM5yK4ng3Jdk71JGqsTnKlLuGhsWwFWtNfIFAKjFQ cyJuzZCeLF6on0nF5PCFzmBT7h8dRN7nAbyXaHB8drhluEVwshEhKQjWhhuHXt15VG d3Qzpw5oaHVDaArQs6B3Z7jd2EO/RgHBiPRqHM1jWw/Z0bJql4Pe26pacZ0L+oNTgI 3MfAezPvDs5Sg== Received: by mail-ot1-f42.google.com with SMTP id l7-20020a0568302b0700b0055ae988dcc8so4893139otv.12 for ; Thu, 04 Nov 2021 05:47:36 -0700 (PDT) X-Gm-Message-State: AOAM5315eAcQf593qWBAT3fl1daBLIeAt3yQTMuuroQEdcm2FDfenUNl teqZ7oCp72jRrcRUtmnzPOu5hn/UtUr4yaDR5E8= X-Google-Smtp-Source: ABdhPJxhWjJHaSYxFkhh2iWefDx6Z+2GQYHsj7ZwDXxYFvelaU3rJtXffw/e5rsmEHaDNyuzdbd+XCXcawBw+m5Y8K0= X-Received: by 2002:a9d:5911:: with SMTP id t17mr39447582oth.30.1636030056196; Thu, 04 Nov 2021 05:47:36 -0700 (PDT) MIME-Version: 1.0 References: <20211104023221.16391-1-walter-zh.wu@mediatek.com> <20211104085336.GA24260@lst.de> In-Reply-To: From: Ard Biesheuvel Date: Thu, 4 Nov 2021 13:47:24 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] dma-direct: improve DMA_ATTR_NO_KERNEL_MAPPING To: Walter Wu Cc: Christoph Hellwig , Marek Szyprowski , Robin Murphy , Matthias Brugger , Andrew Morton , Linux IOMMU , Linux Kernel Mailing List , Linux ARM , wsd_upstream , linux-mediatek@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 4 Nov 2021 at 13:31, Walter Wu wrote: > > On Thu, 2021-11-04 at 09:57 +0100, Ard Biesheuvel wrote: > > On Thu, 4 Nov 2021 at 09:53, Christoph Hellwig wrote: > > > > > > On Thu, Nov 04, 2021 at 10:32:21AM +0800, Walter Wu wrote: > > > > diff --git a/include/linux/set_memory.h > > > > b/include/linux/set_memory.h > > > > index f36be5166c19..6c7d1683339c 100644 > > > > --- a/include/linux/set_memory.h > > > > +++ b/include/linux/set_memory.h > > > > @@ -7,11 +7,16 @@ > > > > > > > > #ifdef CONFIG_ARCH_HAS_SET_MEMORY > > > > #include > > > > + > > > > +#ifndef CONFIG_RODATA_FULL_DEFAULT_ENABLED > > > > > > This is an arm64-specific symbol, and one that only controls a > > > default. I don't think it is suitable to key off stubs in common > > > code. > > > > > > > +static inline int set_memory_valid(unsigned long addr, int > > > > numpages, int enable) { return 0; } > > > > > > Pleae avoid overly long lines. > > > > > > > + if (IS_ENABLED(CONFIG_RODATA_FULL_DEFAULT_ENABLED)) > > > > { > > > > + kaddr = (unsigned > > > > long)phys_to_virt(dma_to_phys(dev, *dma_handle)); > > > > > > This can just use page_address. > > > > > > > + /* page remove kernel mapping for arm64 */ > > > > + set_memory_valid(kaddr, size >> PAGE_SHIFT, > > > > 0); > > > > + } > > > > > > But more importantly: set_memory_valid only exists on arm64, this > > > will break compile everywhere else. And this API is complete crap. > > > Passing kernel virtual addresses as unsigned long just sucks, and > > > passing an integer argument for valid/non-valid also is a horrible > > > API. > > > > > > > ... and as I pointed out before, you can still pass rodata=off on > > arm64, and get the old behavior, in which case bad things will happen > > if you try to use an API that expects to operate on page mappings > > with > > a 1 GB block mapping. > > > > Thanks for your suggestion. > > > > And you still haven't explained what the actual problem is: is this > > about CPU speculation corrupting non-cache coherent inbound DMA? > > No corrupiton, only cpu read it, we hope to fix the behavior. > Fix which behavior? Please explain 1) the current behavior 2) why the current behavior is problematic for you 3) how this patch changes the current behavior 4) why the new behavior fixes your problem. There is no penalty for using too many words. 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3A58C433FE for ; Thu, 4 Nov 2021 12:47:40 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AA51F611C3 for ; Thu, 4 Nov 2021 12:47:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AA51F611C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 675034059A; Thu, 4 Nov 2021 12:47:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvA4dMCueswb; Thu, 4 Nov 2021 12:47:39 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp4.osuosl.org (Postfix) with ESMTPS id 498EE4058C; Thu, 4 Nov 2021 12:47:39 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2C2D6C0019; Thu, 4 Nov 2021 12:47:39 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0165EC000E for ; Thu, 4 Nov 2021 12:47:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id D133360886 for ; Thu, 4 Nov 2021 12:47:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=kernel.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMVS4513lzzR for ; Thu, 4 Nov 2021 12:47:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp3.osuosl.org (Postfix) with ESMTPS id 40C196087C for ; Thu, 4 Nov 2021 12:47:37 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id DB5F5611CE for ; Thu, 4 Nov 2021 12:47:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636030056; bh=O89SG59ERFkapOwq86PzKcmSXMmROh38ILRsxSPw7zc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FUvx4DVOJMgsgc8Dclim6uiPNanlCw5L3gLp5PVRYWaoNB9rczDaMyOu74b5oF1d4 AHQF0P2QUe/aKt1at2I3AWfbFZ99fftU7/5wpYdVqsnnHuI/KpFI/ENXZez8TbJFb4 5TS6iTqKetd4Skk5at9pKxYakuM5yK4ng3Jdk71JGqsTnKlLuGhsWwFWtNfIFAKjFQ cyJuzZCeLF6on0nF5PCFzmBT7h8dRN7nAbyXaHB8drhluEVwshEhKQjWhhuHXt15VG d3Qzpw5oaHVDaArQs6B3Z7jd2EO/RgHBiPRqHM1jWw/Z0bJql4Pe26pacZ0L+oNTgI 3MfAezPvDs5Sg== Received: by mail-ot1-f48.google.com with SMTP id v2-20020a05683018c200b0054e3acddd91so8059672ote.8 for ; Thu, 04 Nov 2021 05:47:36 -0700 (PDT) X-Gm-Message-State: AOAM5325CXAJSrm+QEBCOt7VxUOUbE5BiiErr6nbXt5OC8Tv+kLZYZOx ILuqjDmqDLh+MMUzoaZbPa57aTvLCO3IwQTvOaQ= X-Google-Smtp-Source: ABdhPJxhWjJHaSYxFkhh2iWefDx6Z+2GQYHsj7ZwDXxYFvelaU3rJtXffw/e5rsmEHaDNyuzdbd+XCXcawBw+m5Y8K0= X-Received: by 2002:a9d:5911:: with SMTP id t17mr39447582oth.30.1636030056196; Thu, 04 Nov 2021 05:47:36 -0700 (PDT) MIME-Version: 1.0 References: <20211104023221.16391-1-walter-zh.wu@mediatek.com> <20211104085336.GA24260@lst.de> In-Reply-To: From: Ard Biesheuvel Date: Thu, 4 Nov 2021 13:47:24 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] dma-direct: improve DMA_ATTR_NO_KERNEL_MAPPING To: Walter Wu Cc: wsd_upstream , Linux Kernel Mailing List , Linux IOMMU , linux-mediatek@lists.infradead.org, Matthias Brugger , Andrew Morton , Robin Murphy , Christoph Hellwig , Linux ARM X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Thu, 4 Nov 2021 at 13:31, Walter Wu wrote: > > On Thu, 2021-11-04 at 09:57 +0100, Ard Biesheuvel wrote: > > On Thu, 4 Nov 2021 at 09:53, Christoph Hellwig wrote: > > > > > > On Thu, Nov 04, 2021 at 10:32:21AM +0800, Walter Wu wrote: > > > > diff --git a/include/linux/set_memory.h > > > > b/include/linux/set_memory.h > > > > index f36be5166c19..6c7d1683339c 100644 > > > > --- a/include/linux/set_memory.h > > > > +++ b/include/linux/set_memory.h > > > > @@ -7,11 +7,16 @@ > > > > > > > > #ifdef CONFIG_ARCH_HAS_SET_MEMORY > > > > #include > > > > + > > > > +#ifndef CONFIG_RODATA_FULL_DEFAULT_ENABLED > > > > > > This is an arm64-specific symbol, and one that only controls a > > > default. I don't think it is suitable to key off stubs in common > > > code. > > > > > > > +static inline int set_memory_valid(unsigned long addr, int > > > > numpages, int enable) { return 0; } > > > > > > Pleae avoid overly long lines. > > > > > > > + if (IS_ENABLED(CONFIG_RODATA_FULL_DEFAULT_ENABLED)) > > > > { > > > > + kaddr = (unsigned > > > > long)phys_to_virt(dma_to_phys(dev, *dma_handle)); > > > > > > This can just use page_address. > > > > > > > + /* page remove kernel mapping for arm64 */ > > > > + set_memory_valid(kaddr, size >> PAGE_SHIFT, > > > > 0); > > > > + } > > > > > > But more importantly: set_memory_valid only exists on arm64, this > > > will break compile everywhere else. And this API is complete crap. > > > Passing kernel virtual addresses as unsigned long just sucks, and > > > passing an integer argument for valid/non-valid also is a horrible > > > API. > > > > > > > ... and as I pointed out before, you can still pass rodata=off on > > arm64, and get the old behavior, in which case bad things will happen > > if you try to use an API that expects to operate on page mappings > > with > > a 1 GB block mapping. > > > > Thanks for your suggestion. > > > > And you still haven't explained what the actual problem is: is this > > about CPU speculation corrupting non-cache coherent inbound DMA? > > No corrupiton, only cpu read it, we hope to fix the behavior. > Fix which behavior? Please explain 1) the current behavior 2) why the current behavior is problematic for you 3) how this patch changes the current behavior 4) why the new behavior fixes your problem. There is no penalty for using too many words. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3EBAC433F5 for ; Thu, 4 Nov 2021 12:48:12 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 76B17611C3 for ; Thu, 4 Nov 2021 12:48:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 76B17611C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Il8Yg5oFPrdccR/fSiCHrZ38YEXPVBBH57GACQi3Pik=; b=ATQtovobsHKwlm PoPwRd5KhfO2bF352hhlnWcoSPCS2kmbTCEaHwR3IJdAthHm81j277ki7mzLiutQOeZ2zKtKAozGI kclmhFtwWbsElcZz9UImqdx98QCudMDGOqmT2pXah6VcRAbIzrD0z5JugL26xiKt8/FY/LSZzaXRz 1Vr9hKyiOE4LQR9lDbawnnQEmM7J8LI5/mUQdUm9oToJ4x/n/4ULo/Y9MDPDHjRqoSAuC4MRtg8fF Uxe+tOv7UztLRbPssjd+ngKo41g7gdEZmvWrN3/yemvxTT6Xn2SSpuxPMdJKRSTLohIOtK4YWFm0W U5PoHLZLhAIpuLcO5idA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mic9l-008vm2-Uk; Thu, 04 Nov 2021 12:47:49 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mic9Z-008viU-FG; Thu, 04 Nov 2021 12:47:38 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id F297961212; Thu, 4 Nov 2021 12:47:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636030057; bh=O89SG59ERFkapOwq86PzKcmSXMmROh38ILRsxSPw7zc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NkVY/z4nKKOIiV+FAlAYP4CIOPVfOdOIXOVrJ28PzkuGjbmTTp9QMS6iv95Pqanb5 SxsyDjL6k5M5pKl0geFwZUtsYdyn61mbu6j8lVjeGa1rJ3OCOjQknbrpbtD3OHKqFO 8JXN4VgtvAR6DfEWJYF0MVQDbb9IGM0u8Ogj+furg7fUXYf9M2Ouo3NwxxXw1xD9dd OWHkGbkDj+Ol3vS7ZSVWe1FE96jH3benjEO8jjoh0pbr509+J0dSEy65dyPd74zpse EO/c0Ov2JvPuVikEuXwF7ptU2M776WjRL41ZGMztkdyNL66tUcmn8VIT/Feaf63GMD gyWqavMuKETOQ== Received: by mail-ot1-f49.google.com with SMTP id q33-20020a056830442100b0055abeab1e9aso8068923otv.7; Thu, 04 Nov 2021 05:47:36 -0700 (PDT) X-Gm-Message-State: AOAM531pfwCKGinSo4JsYdAcOpWJJMPam4hhyTnMXpNuy7uSu6NI3bfR vNeUHXflwm8najAxZBeqjh/fO9QGGjT10oIwOY8= X-Google-Smtp-Source: ABdhPJxhWjJHaSYxFkhh2iWefDx6Z+2GQYHsj7ZwDXxYFvelaU3rJtXffw/e5rsmEHaDNyuzdbd+XCXcawBw+m5Y8K0= X-Received: by 2002:a9d:5911:: with SMTP id t17mr39447582oth.30.1636030056196; Thu, 04 Nov 2021 05:47:36 -0700 (PDT) MIME-Version: 1.0 References: <20211104023221.16391-1-walter-zh.wu@mediatek.com> <20211104085336.GA24260@lst.de> In-Reply-To: From: Ard Biesheuvel Date: Thu, 4 Nov 2021 13:47:24 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] dma-direct: improve DMA_ATTR_NO_KERNEL_MAPPING To: Walter Wu Cc: Christoph Hellwig , Marek Szyprowski , Robin Murphy , Matthias Brugger , Andrew Morton , Linux IOMMU , Linux Kernel Mailing List , Linux ARM , wsd_upstream , linux-mediatek@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211104_054737_596697_0FBA1FC4 X-CRM114-Status: GOOD ( 31.86 ) X-BeenThere: linux-mediatek@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-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Thu, 4 Nov 2021 at 13:31, Walter Wu wrote: > > On Thu, 2021-11-04 at 09:57 +0100, Ard Biesheuvel wrote: > > On Thu, 4 Nov 2021 at 09:53, Christoph Hellwig wrote: > > > > > > On Thu, Nov 04, 2021 at 10:32:21AM +0800, Walter Wu wrote: > > > > diff --git a/include/linux/set_memory.h > > > > b/include/linux/set_memory.h > > > > index f36be5166c19..6c7d1683339c 100644 > > > > --- a/include/linux/set_memory.h > > > > +++ b/include/linux/set_memory.h > > > > @@ -7,11 +7,16 @@ > > > > > > > > #ifdef CONFIG_ARCH_HAS_SET_MEMORY > > > > #include > > > > + > > > > +#ifndef CONFIG_RODATA_FULL_DEFAULT_ENABLED > > > > > > This is an arm64-specific symbol, and one that only controls a > > > default. I don't think it is suitable to key off stubs in common > > > code. > > > > > > > +static inline int set_memory_valid(unsigned long addr, int > > > > numpages, int enable) { return 0; } > > > > > > Pleae avoid overly long lines. > > > > > > > + if (IS_ENABLED(CONFIG_RODATA_FULL_DEFAULT_ENABLED)) > > > > { > > > > + kaddr = (unsigned > > > > long)phys_to_virt(dma_to_phys(dev, *dma_handle)); > > > > > > This can just use page_address. > > > > > > > + /* page remove kernel mapping for arm64 */ > > > > + set_memory_valid(kaddr, size >> PAGE_SHIFT, > > > > 0); > > > > + } > > > > > > But more importantly: set_memory_valid only exists on arm64, this > > > will break compile everywhere else. And this API is complete crap. > > > Passing kernel virtual addresses as unsigned long just sucks, and > > > passing an integer argument for valid/non-valid also is a horrible > > > API. > > > > > > > ... and as I pointed out before, you can still pass rodata=off on > > arm64, and get the old behavior, in which case bad things will happen > > if you try to use an API that expects to operate on page mappings > > with > > a 1 GB block mapping. > > > > Thanks for your suggestion. > > > > And you still haven't explained what the actual problem is: is this > > about CPU speculation corrupting non-cache coherent inbound DMA? > > No corrupiton, only cpu read it, we hope to fix the behavior. > Fix which behavior? Please explain 1) the current behavior 2) why the current behavior is problematic for you 3) how this patch changes the current behavior 4) why the new behavior fixes your problem. There is no penalty for using too many words. _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 452A7C433F5 for ; Thu, 4 Nov 2021 12:49:16 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 01C35611C3 for ; Thu, 4 Nov 2021 12:49:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 01C35611C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=KYrM7c/4FiJZRzKgWpEJnWuMQpXv23iBvpjIqYRRXvk=; b=yNZkiUHs7su0rP wVbM5ELSvJzN9U5n2FGFypNaNUpo8uiNZuPIvtl8fOwbsYW0XH+hXetEsc4pkmHn2fu79VbFfHZ7O DWQhysb+E6d5QJRAQA6TAc73sVg4a3RIeosIdfjwmSUNRl62qf94chRrPxQqSkHaadh8dYyYq+f0V zSEwjLRUKVqF50tD4r7gbycK6MTh1GLFW2jmr7UL5kzoMuzeTsN1x9ArQSfNCmsvCSuAa2hGwLCgg XVfN5s2KhkEy/FPvZMxDwI7ZGvWS0yJrxcUxDiX4lWZSdjWaOHo46PWWkqNj5lWk8t3wkqboH6zaB 91lPJ5A+1Be0ngJ/YEvw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mic9c-008vjA-HX; Thu, 04 Nov 2021 12:47:40 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mic9Z-008viU-FG; Thu, 04 Nov 2021 12:47:38 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id F297961212; Thu, 4 Nov 2021 12:47:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636030057; bh=O89SG59ERFkapOwq86PzKcmSXMmROh38ILRsxSPw7zc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NkVY/z4nKKOIiV+FAlAYP4CIOPVfOdOIXOVrJ28PzkuGjbmTTp9QMS6iv95Pqanb5 SxsyDjL6k5M5pKl0geFwZUtsYdyn61mbu6j8lVjeGa1rJ3OCOjQknbrpbtD3OHKqFO 8JXN4VgtvAR6DfEWJYF0MVQDbb9IGM0u8Ogj+furg7fUXYf9M2Ouo3NwxxXw1xD9dd OWHkGbkDj+Ol3vS7ZSVWe1FE96jH3benjEO8jjoh0pbr509+J0dSEy65dyPd74zpse EO/c0Ov2JvPuVikEuXwF7ptU2M776WjRL41ZGMztkdyNL66tUcmn8VIT/Feaf63GMD gyWqavMuKETOQ== Received: by mail-ot1-f49.google.com with SMTP id q33-20020a056830442100b0055abeab1e9aso8068923otv.7; Thu, 04 Nov 2021 05:47:36 -0700 (PDT) X-Gm-Message-State: AOAM531pfwCKGinSo4JsYdAcOpWJJMPam4hhyTnMXpNuy7uSu6NI3bfR vNeUHXflwm8najAxZBeqjh/fO9QGGjT10oIwOY8= X-Google-Smtp-Source: ABdhPJxhWjJHaSYxFkhh2iWefDx6Z+2GQYHsj7ZwDXxYFvelaU3rJtXffw/e5rsmEHaDNyuzdbd+XCXcawBw+m5Y8K0= X-Received: by 2002:a9d:5911:: with SMTP id t17mr39447582oth.30.1636030056196; Thu, 04 Nov 2021 05:47:36 -0700 (PDT) MIME-Version: 1.0 References: <20211104023221.16391-1-walter-zh.wu@mediatek.com> <20211104085336.GA24260@lst.de> In-Reply-To: From: Ard Biesheuvel Date: Thu, 4 Nov 2021 13:47:24 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] dma-direct: improve DMA_ATTR_NO_KERNEL_MAPPING To: Walter Wu Cc: Christoph Hellwig , Marek Szyprowski , Robin Murphy , Matthias Brugger , Andrew Morton , Linux IOMMU , Linux Kernel Mailing List , Linux ARM , wsd_upstream , linux-mediatek@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211104_054737_596697_0FBA1FC4 X-CRM114-Status: GOOD ( 31.86 ) 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 Thu, 4 Nov 2021 at 13:31, Walter Wu wrote: > > On Thu, 2021-11-04 at 09:57 +0100, Ard Biesheuvel wrote: > > On Thu, 4 Nov 2021 at 09:53, Christoph Hellwig wrote: > > > > > > On Thu, Nov 04, 2021 at 10:32:21AM +0800, Walter Wu wrote: > > > > diff --git a/include/linux/set_memory.h > > > > b/include/linux/set_memory.h > > > > index f36be5166c19..6c7d1683339c 100644 > > > > --- a/include/linux/set_memory.h > > > > +++ b/include/linux/set_memory.h > > > > @@ -7,11 +7,16 @@ > > > > > > > > #ifdef CONFIG_ARCH_HAS_SET_MEMORY > > > > #include > > > > + > > > > +#ifndef CONFIG_RODATA_FULL_DEFAULT_ENABLED > > > > > > This is an arm64-specific symbol, and one that only controls a > > > default. I don't think it is suitable to key off stubs in common > > > code. > > > > > > > +static inline int set_memory_valid(unsigned long addr, int > > > > numpages, int enable) { return 0; } > > > > > > Pleae avoid overly long lines. > > > > > > > + if (IS_ENABLED(CONFIG_RODATA_FULL_DEFAULT_ENABLED)) > > > > { > > > > + kaddr = (unsigned > > > > long)phys_to_virt(dma_to_phys(dev, *dma_handle)); > > > > > > This can just use page_address. > > > > > > > + /* page remove kernel mapping for arm64 */ > > > > + set_memory_valid(kaddr, size >> PAGE_SHIFT, > > > > 0); > > > > + } > > > > > > But more importantly: set_memory_valid only exists on arm64, this > > > will break compile everywhere else. And this API is complete crap. > > > Passing kernel virtual addresses as unsigned long just sucks, and > > > passing an integer argument for valid/non-valid also is a horrible > > > API. > > > > > > > ... and as I pointed out before, you can still pass rodata=off on > > arm64, and get the old behavior, in which case bad things will happen > > if you try to use an API that expects to operate on page mappings > > with > > a 1 GB block mapping. > > > > Thanks for your suggestion. > > > > And you still haven't explained what the actual problem is: is this > > about CPU speculation corrupting non-cache coherent inbound DMA? > > No corrupiton, only cpu read it, we hope to fix the behavior. > Fix which behavior? Please explain 1) the current behavior 2) why the current behavior is problematic for you 3) how this patch changes the current behavior 4) why the new behavior fixes your problem. There is no penalty for using too many words. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel