From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f48.google.com (mail-dl1-f48.google.com [74.125.82.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9ED3C15C for ; Mon, 8 Jun 2026 19:55:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780948532; cv=none; b=IogK9XdnfZpQ7l7uCzA9VCRtDw/0ZL6FoozMaRgzD0sF61lzXJavWIX/hZMBQGFbsDSrAsjyayLphfIZrjEpiwnCNEqdb0+5F9e3QbD1JUOOK55+G4vhfFAb74zqUHqOf2xqjqoW+mQ8tWWuKll0EZe5iJ/Ye06t/quXNmrAY7g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780948532; c=relaxed/simple; bh=6+HXf+FDYiwTqChwNe1Waa3meZ8yJYGg35Bx3IDfIRk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=osW+8N6r5Rb++c6WAj/uxE1BhMpD+0FSPcKlchwtqraLLkomK9iJlNvLfCKyqxAaj2dBfmhiAJ7JCURZqdzSnIX6GVGDnbset3VG6NRLGGkTLKnfPR9rZJNN8ynJxoR382ZL2bVG6PyRVxFHg5+YEr/3AKlWHSiOEEls/r+kPVk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=YwryDb1R; arc=none smtp.client-ip=74.125.82.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="YwryDb1R" Received: by mail-dl1-f48.google.com with SMTP id a92af1059eb24-137ff9a7d5eso30097c88.1 for ; Mon, 08 Jun 2026 12:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780948530; x=1781553330; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ns7tVcW9XWyLcZvttsJ0K9GITGIgrVGAf3TGrFOv8Tc=; b=YwryDb1RSWoM5S/oD6A8n/peQ/YJPPeJ1587sVrbjU30b+AZiL27Bcro3WB5h02iW0 xC22nVBPFGuTxQUJRLeyNI2Pei5pjVHBpzNhDvJej3JolTvnXqe2XzYU6mfSA7aHEl4y sooihuHOLp3zBeRyQS4XuU+qHfMDruRonjAO3eAcCq5OUALe+t8GiWJHmuzdxSCX3+OQ BWqIyiXUYl6Ay7NHvWY4ofaG6YGkCO+i9T5E6ff7jT7ypCcEHGLsEVOa0IFP+BvcCIKB lxyeZs3hps1D7yrLnVwCM/F/fih5y5FGcYk1ivqvK93/E3hfpyaNbj8SAFTLmeq1MQ8d uytg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780948530; x=1781553330; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ns7tVcW9XWyLcZvttsJ0K9GITGIgrVGAf3TGrFOv8Tc=; b=ZYLOqwzW9pcKUmVa+THccUiVEW0x1Jo2OvJ4E3y03Zt+r2XZNsvLZBqwdS0HyoE3p+ dNTmZcBszFgLRRzevEWVlU9D+Lf/2iVE+uPD8Fb16cpnqMtMwxfBR+7JzanfV8MW5ZH+ 9q5cY1qAWTJ+VPc0JVrduOUcxHFObs06lh5OzQF7o13mOGNyQ54zZcnHx3EwnNMgVngU IYlYaui5m9xdBdJ/UtmkNRhF4ZAZ/2w6NCEHhKu3sbUo/YlB/KOr92LkEmXixlL/Patv xy9BXXn44tZ8fMsoIL5EGqjKZVxO89IJMIeDeDAHKeL2WsX20A6sh+ZCDTf3i9kdwWnl EXsg== X-Forwarded-Encrypted: i=1; AFNElJ8HZ0q7zfjSkedvbT6AZEFeu8mQfuSDPFuSCoutcbSbTQi/mF+IiKYKg/JTXkpL2eXW6G+CzJjrF7XTkBQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxgP4bclWqWdDyi1Rm/RWTOQ76rOL2yqZoMSwjEncQV/CptMavH 6YwYezthfS02XKDDym4sIZp40vYGjRDBQ/oFEabUCGGNyrXtiPDvH2pC+lyAIzg7+A== X-Gm-Gg: Acq92OFL/qnjwnUwDKath3KEAMO/Rtl0vp9/1AqfXfLh3IMYrJxQUscStu3GXyOfQ+S W2pfn7TymFskZDUGuYFV/jtmqbgZ6SUwYoxKFKEepiwKOcfNuz/77RshiTKblJTJGWmaEyMHmbh Ur5O2MOCAlKOtXpaP+JcwXlIj97ns9paRrO+pQjvNf7dhCHMcgSHa9sPvs95kcHF0mDin8/U27C 4qkzmd0/PYY8kO7jEu3ZFI/R3q3WheAIA1J4waM+JAYKSPHHZkIKEc1wyeC5VT0qIZ4XoZoNq4y wkvALtqdbElT/IbVGhjVtkeMfwrrdou5VErRErQ3L2Z+L4k/NbStyLSsvtYALZ8ThlOkmE2SHzN N0NPto5r2uR9lWeuKw53a/SzlRZ+EaONXJ5FckbfxxffSnXh6c12u9KwFpPcfWazpvlMrhIVsYA u4DxaH3UXa66UDMKSCrmHb6s2i0FAbQB0Ql9LZx6MpOxEFAmyBZ1hszoXElZ9U8Rx4WbjknHw= X-Received: by 2002:a05:7022:170e:b0:138:888:e99d with SMTP id a92af1059eb24-1380888eb22mr103345c88.32.1780948529234; Mon, 08 Jun 2026 12:55:29 -0700 (PDT) Received: from google.com (199.255.142.34.bc.googleusercontent.com. [34.142.255.199]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-30791f6381fsm9666160eec.0.2026.06.08.12.55.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 12:55:28 -0700 (PDT) Date: Mon, 8 Jun 2026 19:55:21 +0000 From: Pranjal Shrivastava To: Samiullah Khawaja Cc: Marek Szyprowski , Will Deacon , Jason Gunthorpe , Pasha Tatashin , Mike Rapoport , Pratyush Yadav , Alexander Graf , Robin Murphy , Kevin Tian , iommu@lists.linux.dev, kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Matlack , Andrew Morton , Vipin Sharma Subject: Re: [RFC PATCH 3/4] dma-direct: Add API to preserve/restore allocations Message-ID: References: <20260505002737.2213734-1-skhawaja@google.com> <20260505002737.2213734-4-skhawaja@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260505002737.2213734-4-skhawaja@google.com> On Tue, May 05, 2026 at 12:27:36AM +0000, Samiullah Khawaja wrote: > Add an API to preserve/restore the DMA direct allocation for liveupdate. > The underlying memory is preserved/restored using KHO. During restore > the memory is setup based on the device configuration, gfp flags and > allocation attributes. Once restored, the driver can use the usual > dma_free* API to deallocate the restored DMA allocation. > > This API will be used to add support in dma_alloc* APIs to > preseve/restore the DMA allocations. > > Signed-off-by: Samiullah Khawaja > --- > include/linux/dma-direct.h | 29 +++++++ > kernel/dma/Kconfig | 3 + > kernel/dma/direct.c | 163 +++++++++++++++++++++++++++++++++++++ > 3 files changed, 195 insertions(+) > [...] > diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig > index bfef21b4a9ae..d92852942c6c 100644 > --- a/kernel/dma/Kconfig > +++ b/kernel/dma/Kconfig > @@ -265,3 +265,6 @@ config DMA_MAP_BENCHMARK > performance of dma_(un)map_page. > > See tools/testing/selftests/dma/dma_map_benchmark.c > + > +config DMA_LIVEUPDATE > + bool "Enable preservation of DMA direct allocations" Nit: depends on LIVEUPDATE? > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c > index ec887f443741..c2b98f91900a 100644 > --- a/kernel/dma/direct.c > +++ b/kernel/dma/direct.c > @@ -6,6 +6,8 @@ > */ > #include /* for max_pfn */ > #include > +#include > +#include > #include > #include > #include > @@ -307,6 +309,167 @@ void *dma_direct_alloc(struct device *dev, size_t size, > return NULL; > } > > +#ifdef CONFIG_DMA_LIVEUPDATE > +int dma_direct_preserve_allocation(struct device *dev, void *cpu_addr, > + size_t size, dma_addr_t dma_handle, > + unsigned long attrs, u64 *state) > +{ > + struct dma_alloc_ser *ser; > + int ret; > + > + if (!kho_is_enabled()) > + return -EOPNOTSUPP; > + > + if (IS_ENABLED(CONFIG_DMA_CMA)) > + return -EOPNOTSUPP; > + > + if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) && > + !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev)) > + return -EOPNOTSUPP; > + > + if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_ALLOC) && > + !dev_is_dma_coherent(dev) && > + !is_swiotlb_for_alloc(dev)) > + return -EOPNOTSUPP; > + > + if (IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) && > + !dev_is_dma_coherent(dev)) > + return -EOPNOTSUPP; > + > + if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) && > + dma_is_from_pool(dev, cpu_addr, PAGE_ALIGN(size))) > + return -EOPNOTSUPP; > + > + ser = kho_alloc_preserve(sizeof(*ser)); > + if (IS_ERR(ser)) > + return PTR_ERR(ser); > + > + ser->page_phys = dma_to_phys(dev, dma_handle); > + ser->force_decrypted = force_dma_unencrypted(dev); > + ser->size = size; > + > + ret = kho_preserve_pages(phys_to_page(ser->page_phys), > + size >> PAGE_SHIFT); Should this be `PAGE_ALIGN(size) >> PAGE_SHIFT` OR `DIV_ROUND_UP(size, PAGE_SIZE)`? Otherwise, if size is small, say, size == 64-bytes, we preserve 0 pages? Also, IIRC, even with PAGE_ALIGN, preserving just the requested pgcount is not enough because buddy allocator allocates in order-N. For e.g. if a driver requests 20KB (5 pages), the buddy allocator fulfills it with an order-3 block (8 pages). Now, if we only tell KHO to preserve 5 pages, the remaining 3 pages are free in the new kernel. When the driver eventually tears down and calls dma_free_coherent(), dma_direct_free() will call __free_pages(page, get_order(size)), which will attempt to free all 8 pages, causing a double-free panic on the 3 unpreserved pages? Should we be preserving exactly 1 << get_order(size) pages as per buddy? Same applies to unpreserve, and restore. > + if (ret) { > + kho_unpreserve_free(ser); > + return ret; > + } > + > + *state = virt_to_phys(ser); > + return 0; > +} > + > +void dma_direct_unpreserve_allocation(struct device *dev, u64 state) > +{ > + struct dma_alloc_ser *ser; > + > + if (!kho_is_enabled()) > + return; > + > + ser = phys_to_virt(state); > + kho_unpreserve_pages(phys_to_page(ser->page_phys), > + ser->size >> PAGE_SHIFT); > + kho_unpreserve_free(ser); > +} > + > +void *dma_direct_restore_allocation(struct device *dev, size_t size, > + dma_addr_t *dma_handle, gfp_t gfp, > + unsigned long attrs, u64 state) Are we relying on the caller to pass same attrs? So, a buffer with non-coherent attrs can be mapped with coherent attrs in the new kernel. Could this cause side-effects? Should we check for such driver bugs with a WARN here while comparing older attrs with the newer ones too? Coherency breaking due to subtle driver bugs is very painful to debug :/ > +{ > + bool remap = false, set_uncached = false; > + struct dma_alloc_ser *ser = NULL; > + struct page *page; > + void *cpu_addr; > + > + if (!kho_is_enabled()) > + return NULL; > + > + ser = phys_to_virt(state); > + page = phys_to_page(ser->page_phys); [...] > + > + /* > + * Remapping will be blocking so return error. The preserved memory > + * might be already decrypted in the previous kernel, but the decryption > + * call is not guaranteed to be non-blocking so return error always if > + * decryption is required. > + */ > + if ((remap || force_dma_unencrypted(dev)) && > + dma_direct_use_pool(dev, gfp)) > + return NULL; > + > + /* > + * Encryption scheme changed between two kernels and this might cause > + * issues if device/driver is not handling it properly. > + */ > + WARN_ON_ONCE(ser->force_decrypted != force_dma_unencrypted(dev)); > + > + /* > + * arch_dma_prep_coherent() should make sure that any cache lines from > + * the previous kernel, if the device was coherent previously or cached > + * mapping in this kernel during init are not problamatic for > + * non-coherent allocations. > + */ > + if (remap) { > + pgprot_t prot = dma_pgprot(dev, PAGE_KERNEL, attrs); > + > + if (force_dma_unencrypted(dev)) > + prot = pgprot_decrypted(prot); > + > + arch_dma_prep_coherent(page, size); > + > + cpu_addr = dma_common_contiguous_remap(page, size, prot, > + __builtin_return_address(0)); > + if (!cpu_addr) > + return NULL; Should we be kho_restore_free-ing on all these error paths? We only seem to be kho_restore_free-ing on the success path. Same for kho_restore_pages.. if we return an error here, we don't restore the preserved pages? Are we leaking those too? > + } else { > + cpu_addr = page_address(page); > + if (dma_set_decrypted(dev, cpu_addr, size)) > + return NULL; > + } > + > + if (set_uncached) { > + arch_dma_prep_coherent(page, size); > + cpu_addr = arch_dma_set_uncached(cpu_addr, size); > + if (IS_ERR(cpu_addr)) > + return NULL; > + } > + > + *dma_handle = phys_to_dma_direct(dev, ser->page_phys); > + > + /* > + * Cannot free the restored pages on error here as these might be in use > + * by a device with direct allocation in the previous kernel. > + */ > + WARN_ON(!kho_restore_pages(ser->page_phys, > + ser->size >> PAGE_SHIFT)); > + kho_restore_free(ser); > + return cpu_addr; > +} > +#endif > + > void dma_direct_free(struct device *dev, size_t size, > void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs) > { Thanks, Praan