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 8DD5CC44501 for ; Tue, 14 Jul 2026 04:02:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=I+ZBXykHnbEwGIuh63wccmA7DmHMIqMB7lgyh5rZR2Q=; b=b4VfNRY3LB1XB4FWsFU8XOvot6 1Uh7AW1IUHmjR0I68WA7f2EF3qqJt9+Kz5LsZd6Phoj0TsSWOMqXYw4Wmn+W0V6Z5hWjHA577BOsA g6ZGBkE7g3BOI7q5e6VzUL7fBisTZgOwWENCoxfxZkt09aMH4MltAgFcA3A11sb8/Qg1LW5166RpI jVIKdAd28Lq2ZgegilD6QMLDom49zEsoGshON3a1l6lCLd9TbxVgxOFzd7qRjnm+4TOlV7Rejd3xB Q1sQ+Q5UP7q3qkfQHCNbcqUtQkFVsPAuUsONGWkBJlDZkMvZ/QIgXPlQdJjNU+Zyrz3SH/GiKKfuR FS5/+sow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjULy-0000000Aqe8-481E; Tue, 14 Jul 2026 04:02:42 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjULx-0000000Aqdv-2zWT for linux-arm-kernel@lists.infradead.org; Tue, 14 Jul 2026 04:02:41 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id DF9A5408CC; Tue, 14 Jul 2026 04:02:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BA5F1F000E9; Tue, 14 Jul 2026 04:02:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784001760; bh=I+ZBXykHnbEwGIuh63wccmA7DmHMIqMB7lgyh5rZR2Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Sz+jLGb5lqaIZdWXV5CgOFgtGhqpCdS9TzBy3Zi/FZdiL/JcpHnSOLFWaVYHy2tEu 0z60X/PsuJFrCARLJjubigCSTZRICnH353bC8OXad9IyIY1+enenSt0y3KaF+xL+sW 8lQgb6amuJFbAq4Z7TcDyrBgJFMIjy39lUR5T7hoQVIygJmSNBiAoM5TuHUBIWcLut 2EEU0Hw+Op7oSrVx/EtawGwStFg7Ok6X4NqNJM4I2Db/C/xB0XLNZOyBmyxFoT/3er DeOXIY8HufW/cYyNZJxzZZ+EDvupXNVMaU/JsNpu6rlNiKMwKGhQi4/GS9d4rdv9qi YoUbvZuFqm5LQ== X-Mailer: emacs 30.2 (via feedmail 11-beta-1 I) From: Aneesh Kumar K.V To: Jason Gunthorpe Cc: iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, Robin Murphy , Marek Szyprowski , Will Deacon , Marc Zyngier , Steven Price , Suzuki K Poulose , Catalin Marinas , Jiri Pirko , Mostafa Saleh , Petr Tesarik , Alexey Kardashevskiy , Dan Williams , Xu Yilun , linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , x86@kernel.org, Jiri Pirko , Michael Kelley Subject: Re: [PATCH v7 11/22] dma-pool: track decrypted atomic pools and select them via attrs In-Reply-To: <20260713175616.GJ3133966@ziepe.ca> References: <20260701054926.825925-1-aneesh.kumar@kernel.org> <20260701054926.825925-12-aneesh.kumar@kernel.org> <20260713175616.GJ3133966@ziepe.ca> Date: Tue, 14 Jul 2026 09:32:27 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Jason Gunthorpe writes: > On Wed, Jul 01, 2026 at 11:19:15AM +0530, Aneesh Kumar K.V (Arm) wrote: >> -static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size, >> +static int atomic_pool_expand(struct dma_gen_pool *dma_pool, size_t pool_size, >> gfp_t gfp) >> { >> unsigned int order; >> @@ -114,14 +120,17 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size, >> * Memory in the atomic DMA pools must be unencrypted, the pools do not >> * shrink so no re-encryption occurs in dma_direct_free(). >> */ >> - ret = set_memory_decrypted((unsigned long)page_to_virt(page), >> - 1 << order); >> - if (ret) { >> - leak_pages = true; >> - goto remove_mapping; >> + if (dma_pool->cc_shared) { >> + ret = set_memory_decrypted((unsigned long)page_to_virt(page), >> + 1 << order); >> + if (ret) { >> + leak_pages = true; >> + goto remove_mapping; >> + } >> } >> - ret = gen_pool_add_virt(pool, (unsigned long)addr, page_to_phys(page), >> - pool_size, NUMA_NO_NODE); >> + >> + ret = gen_pool_add_virt(dma_pool->pool, (unsigned long)addr, >> + page_to_phys(page), pool_size, NUMA_NO_NODE); >> if (ret) >> goto encrypt_mapping; >> >> @@ -129,12 +138,10 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size, >> return 0; >> >> encrypt_mapping: >> - ret = set_memory_encrypted((unsigned long)page_to_virt(page), >> - 1 << order); >> - if (WARN_ON_ONCE(ret)) { >> - /* Decrypt succeeded but encrypt failed, purposely leak */ >> + if (dma_pool->cc_shared && >> + set_memory_encrypted((unsigned long)page_to_virt(page), 1 << order)) >> leak_pages = true; >> - } >> + > > Was it intentional to remove the WARN_ON and comment ? That WARN_ON() was a bit inconsistent. Not all page leaks due to encrypt/decrypt failures triggered a warning, so I removed it. If we want to warn about such failures, we should add the warning consistently across the code. We may also want to handle decrypt failures by encrypting the page again to avoid leaking it. I will work on that as a tree-wide change in a separate patch. -aneesh