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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 DA74BC44507 for ; Tue, 14 Jul 2026 04:02:45 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4gzlyD22zrz2xJR; Tue, 14 Jul 2026 14:02:44 +1000 (AEST) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=172.234.252.31 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1784001764; cv=none; b=XE2+KMiI27UPhSdVIiuDLuSKsEYpX2SXiYHJt6tLc8EoNBycxJGu6WE8IHwlMgNQoiL+HmGCd5/Or4aQrl2Ix17ldXFYaCasKek7W5RtQrPxQVnHx6EaRcwOqmO2hJ2GqlJc7ZPl/MQuImCHleEYYPF282Lm86ky9CJcIneGtt0BjZTy39zFKf0W28xTEVUYgoJwSePCf+GiKvl/Ie5LoSBf+pbItMBQP7dkenQjYR6yFtsRk4gEDWM3hjdH+/sgg7mic8b/YJUO6Qzejx2iQP4WkGP2Hz5yNCYsM/UMoel4bDw7FHoOW3LNji/NTw3kGnWJ2LuXPslGCg09TnWW9Q== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1784001764; c=relaxed/relaxed; bh=I+ZBXykHnbEwGIuh63wccmA7DmHMIqMB7lgyh5rZR2Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ASoew42DoRMqvtjdoQp/Hfs8tvaLFUhZPEHUkiVYpdrBj7W5qmnufHYUmS/pBhy8NNt5ceJt/LG43A1pXkaH9bzsw9YlZwCvtb7m0y9KEgOi8tHsMwXJbE3wVyDY0GRLOjp4EaZzKy+aW/ow73in/TIox1LbLC2ofMuTGbrdT5RacC0Eer8T9OuLtNQ1kjLXco+W6uWj7d/GJLJ4o2OaoTkHIi3H7UNeDhe0UNy3ZJH26DWph1KajirbxFPYQmkpW13CZJ5y1FlujkG9daLIOFcI7OyiuBPIrR5hS7YXROdpnmvcmGkEpymm6ts2+abyOlsLBqmFsa4N+6O60/Qutg== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=Sz+jLGb5; dkim-atps=neutral; spf=pass (client-ip=172.234.252.31; helo=sea.source.kernel.org; envelope-from=aneesh.kumar@kernel.org; receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=Sz+jLGb5; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=172.234.252.31; helo=sea.source.kernel.org; envelope-from=aneesh.kumar@kernel.org; receiver=lists.ozlabs.org) Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4gzlyC2YZbz2xBb for ; Tue, 14 Jul 2026 14:02:43 +1000 (AEST) 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: X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 Content-Type: text/plain 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