From: Baolu Lu <baolu.lu@linux.intel.com>
To: Dave Hansen <dave.hansen@intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
Jason Gunthorpe <jgg@nvidia.com>
Cc: baolu.lu@linux.intel.com, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>, Jann Horn <jannh@google.com>,
Vasant Hegde <vasant.hegde@amd.com>,
Alistair Popple <apopple@nvidia.com>,
Peter Zijlstra <peterz@infradead.org>,
Uladzislau Rezki <urezki@gmail.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Andy Lutomirski <luto@kernel.org>, "Lai, Yi1" <yi1.lai@intel.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"security@kernel.org" <security@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
vishal.moola@gmail.com, Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v3 1/1] iommu/sva: Invalidate KVA range on kernel TLB flush
Date: Wed, 27 Aug 2025 18:58:02 +0800 [thread overview]
Message-ID: <c69950ee-660b-4f51-9277-522470d0ce5d@linux.intel.com> (raw)
In-Reply-To: <b57d7b97-8110-47c5-9c7a-516b7b535ce9@intel.com>
On 8/26/2025 10:22 PM, Dave Hansen wrote:
> On 8/25/25 19:49, Baolu Lu wrote:
>>> The three separate lists are needed because we're handling three
>>> distinct types of page deallocation. Grouping the pages this way allows
>>> the workqueue handler to free each type using the correct function.
>>
>> Please allow me to add more details.
>
> Right, I know why it got added this way: it was the quickest way to hack
> together a patch that fixes the IOMMU issue without refactoring anything.
>
> I agree that you have three cases:
> 1. A full on 'struct ptdesc' that needs its destructor run
> 2. An order-0 'struct page'
> 3. A higher-order 'struct page'
>
> Long-term, #2 and #3 probably need to get converted over to 'struct
> ptdesc'. They don't look _that_ hard to convert to me. Willy, Vishal,
> any other mm folks: do you agree?
>
> Short-term, I'd just consolidate your issue down to a single list.
>
> #1: For 'struct ptdesc', modify pte_free_kernel() to pass information in
> to pagetable_dtor_free() to tell it to use the deferred page table
> free list. Do this with a bit in the ptdesc or a new argument to
> pagetable_dtor_free().
> #2. Just append these to the deferred page table free list. Easy.
> #3. The biggest hacky way to do this is to just treat the higher-order
> non-compound page and put the pages on the deferred page table
> free list one at a time. The other way to do it is to track down how
> this thing got allocated in the first place and make sure it's got
> __GFP_COMP metadata. If so, you can just use __free_pages() for
> everything.
>
> Yeah, it'll take a couple patches up front to refactor some things. But
> that refactoring will make things more consistent instead of adding
> adding complexity to deal with the inconsistency.
Following the insights above, I wrote the code as follows. Does it look
good?
mm/pgtable-generic.c:
#ifdef CONFIG_ASYNC_PGTABLE_FREE
/* a 'struct ptdesc' that needs its destructor run */
#define ASYNC_PGTABLE_FREE_DTOR BIT(NR_PAGEFLAGS)
static void kernel_pgtable_work_func(struct work_struct *work);
static struct {
struct list_head list;
/* protect above ptdesc lists */
spinlock_t lock;
struct work_struct work;
} kernel_pgtable_work = {
.list = LIST_HEAD_INIT(kernel_pgtable_work.list),
.lock = __SPIN_LOCK_UNLOCKED(kernel_pgtable_work.lock),
.work = __WORK_INITIALIZER(kernel_pgtable_work.work,
kernel_pgtable_work_func),
};
static void kernel_pgtable_work_func(struct work_struct *work)
{
struct ptdesc *ptdesc, *next;
LIST_HEAD(page_list);
spin_lock(&kernel_pgtable_work.lock);
list_splice_tail_init(&kernel_pgtable_work.list, &page_list);
spin_unlock(&kernel_pgtable_work.lock);
iommu_sva_invalidate_kva_range(0, TLB_FLUSH_ALL);
list_for_each_entry_safe(ptdesc, next, &page_list, pt_list) {
list_del(&ptdesc->pt_list);
if (ptdesc->__page_flags & ASYNC_PGTABLE_FREE_DTOR)
pagetable_dtor_free(ptdesc);
else
__free_page(ptdesc_page(ptdesc));
}
}
void kernel_pgtable_async_free_dtor(struct ptdesc *ptdesc)
{
spin_lock(&kernel_pgtable_work.lock);
ptdesc->__page_flags |= ASYNC_PGTABLE_FREE_DTOR;
list_add(&ptdesc->pt_list, &kernel_pgtable_work.list);
spin_unlock(&kernel_pgtable_work.lock);
schedule_work(&kernel_pgtable_work.work);
}
void kernel_pgtable_async_free_page_list(struct list_head *list)
{
spin_lock(&kernel_pgtable_work.lock);
list_splice_tail(list, &kernel_pgtable_work.list);
spin_unlock(&kernel_pgtable_work.lock);
schedule_work(&kernel_pgtable_work.work);
}
void kernel_pgtable_async_free_page(struct page *page)
{
spin_lock(&kernel_pgtable_work.lock);
list_add(&page_ptdesc(page)->pt_list, &kernel_pgtable_work.list);
spin_unlock(&kernel_pgtable_work.lock);
schedule_work(&kernel_pgtable_work.work);
}
#endif
Thanks,
baolu
next prev parent reply other threads:[~2025-08-27 10:58 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-06 5:25 [PATCH v3 1/1] iommu/sva: Invalidate KVA range on kernel TLB flush Lu Baolu
2025-08-06 15:03 ` Dave Hansen
2025-08-06 15:52 ` Jason Gunthorpe
2025-08-06 16:04 ` Dave Hansen
2025-08-06 16:09 ` Jason Gunthorpe
2025-08-06 16:34 ` Dave Hansen
2025-08-06 16:42 ` Jason Gunthorpe
2025-08-07 14:40 ` Baolu Lu
2025-08-07 15:31 ` Dave Hansen
2025-08-08 5:15 ` Baolu Lu
2025-08-10 7:19 ` Ethan Zhao
2025-08-11 9:15 ` Uladzislau Rezki
2025-08-11 12:55 ` Jason Gunthorpe
2025-08-15 9:23 ` Baolu Lu
2025-08-11 13:55 ` Dave Hansen
2025-08-11 14:56 ` Uladzislau Rezki
2025-08-12 1:17 ` Ethan Zhao
2025-08-15 14:35 ` Dave Hansen
2025-08-11 12:57 ` Jason Gunthorpe
2025-08-13 3:17 ` Ethan Zhao
2025-08-18 1:34 ` Baolu Lu
2025-08-07 19:51 ` Jason Gunthorpe
2025-08-08 2:57 ` Tian, Kevin
2025-08-15 9:16 ` Baolu Lu
2025-08-15 9:46 ` Tian, Kevin
2025-08-18 5:58 ` Baolu Lu
2025-08-15 14:31 ` Dave Hansen
2025-08-18 6:08 ` Baolu Lu
2025-08-18 6:21 ` Baolu Lu
2025-08-21 7:05 ` Tian, Kevin
2025-08-23 3:26 ` Baolu Lu
2025-08-25 22:36 ` Dave Hansen
2025-08-26 1:25 ` Baolu Lu
2025-08-26 2:49 ` Baolu Lu
2025-08-26 14:22 ` Dave Hansen
2025-08-26 14:33 ` Matthew Wilcox
2025-08-26 14:57 ` Dave Hansen
2025-08-27 10:58 ` Baolu Lu [this message]
2025-08-27 23:31 ` Dave Hansen
2025-08-28 5:31 ` Baolu Lu
2025-08-28 7:08 ` Tian, Kevin
2025-08-28 18:56 ` Dave Hansen
2025-08-28 19:10 ` Jason Gunthorpe
2025-08-28 19:31 ` Dave Hansen
2025-08-28 19:39 ` Matthew Wilcox
2025-08-26 16:21 ` Dave Hansen
2025-08-27 6:34 ` Baolu Lu
2025-08-08 5:08 ` Baolu Lu
2025-08-07 6:53 ` Baolu Lu
2025-08-14 4:48 ` Ethan Zhao
2025-08-15 7:48 ` Baolu Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c69950ee-660b-4f51-9277-522470d0ce5d@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=apopple@nvidia.com \
--cc=dave.hansen@intel.com \
--cc=iommu@lists.linux.dev \
--cc=jannh@google.com \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=robin.murphy@arm.com \
--cc=security@kernel.org \
--cc=stable@vger.kernel.org \
--cc=urezki@gmail.com \
--cc=vasant.hegde@amd.com \
--cc=vishal.moola@gmail.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=yi1.lai@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox