* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Yosry Ahmed @ 2026-04-24 19:15 UTC (permalink / raw)
To: Zi Yan
Cc: Peter Zijlstra, David Hildenbrand (Arm), Andrew Morton,
Pasha Tatashin, Lance Yang, dave.hansen, dave.hansen, ypodemsk,
hughd, will, aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa,
arnd, ljs, baolin.wang, Liam.Howlett, npache, ryan.roberts,
dev.jain, baohua, shy828301, riel, jannh, jgross, seanjc,
pbonzini, boris.ostrovsky, virtualization, kvm, linux-arch,
linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <E375C69C-557E-44EB-9B3C-618C9F7BA9D8@nvidia.com>
On Fri, Apr 24, 2026 at 12:12 PM Zi Yan <ziy@nvidia.com> wrote:
>
> On 24 Apr 2026, at 15:01, Peter Zijlstra wrote:
>
> > On Fri, Apr 24, 2026 at 11:50:03AM -0700, Yosry Ahmed wrote:
> >
> >> But I imagine it's useful for reviewers to see Sashiko's feedback as
> >> well (without having to go look on the website).
> >
> > That's why I have a script; if I press 'S' in mutt on an 0/n email, said
> > script goes and does webrequest to sashiko and inserts the review
> > comments into my local maildir as properly threaded replies to the
> > series at hand.
> >
> > No looking at website needed.
>
> Do you mind sharing that script? It looks like a great work flow. Thanks.
Yeah that sounds great :)
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Zi Yan @ 2026-04-24 19:12 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Yosry Ahmed, David Hildenbrand (Arm), Andrew Morton,
Pasha Tatashin, Lance Yang, dave.hansen, dave.hansen, ypodemsk,
hughd, will, aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa,
arnd, ljs, baolin.wang, Liam.Howlett, npache, ryan.roberts,
dev.jain, baohua, shy828301, riel, jannh, jgross, seanjc,
pbonzini, boris.ostrovsky, virtualization, kvm, linux-arch,
linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <20260424190141.GA3783056@noisy.programming.kicks-ass.net>
On 24 Apr 2026, at 15:01, Peter Zijlstra wrote:
> On Fri, Apr 24, 2026 at 11:50:03AM -0700, Yosry Ahmed wrote:
>
>> But I imagine it's useful for reviewers to see Sashiko's feedback as
>> well (without having to go look on the website).
>
> That's why I have a script; if I press 'S' in mutt on an 0/n email, said
> script goes and does webrequest to sashiko and inserts the review
> comments into my local maildir as properly threaded replies to the
> series at hand.
>
> No looking at website needed.
Do you mind sharing that script? It looks like a great work flow. Thanks.
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: David Hildenbrand (Arm) @ 2026-04-24 19:09 UTC (permalink / raw)
To: Yosry Ahmed
Cc: Andrew Morton, Pasha Tatashin, Lance Yang, peterz, dave.hansen,
dave.hansen, ypodemsk, hughd, will, aneesh.kumar, npiggin, tglx,
mingo, bp, x86, hpa, arnd, ljs, ziy, baolin.wang, Liam.Howlett,
npache, ryan.roberts, dev.jain, baohua, shy828301, riel, jannh,
jgross, seanjc, pbonzini, boris.ostrovsky, virtualization, kvm,
linux-arch, linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <CAO9r8zN1pRfyC0Rh+UdW-Lsret=z3oveT3=gnZftX-Sr_ubyyQ@mail.gmail.com>
On 4/24/26 20:50, Yosry Ahmed wrote:
> On Fri, Apr 24, 2026 at 11:36 AM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>>
>> On 4/24/26 16:31, Andrew Morton wrote:
>>>
>>>
>>> Why do you think so?
>>
>> The most important part for me is that authors are aware of the reports.
>>
>> Sending them as a mail forces people to publicly reply to the feedback, and at
>> this point in time, I am not convinced that that is the right approach.
>
> But I imagine it's useful for reviewers to see Sashiko's feedback as
> well (without having to go look on the website).
I read a lot of them, yes. Maintainers know how to find it.
I even think maintainers should briefly go over it before applying to spot if
anything in there is still left unanswered. But that doesn't need a mailing list
posting.
I enjoy if contributors are aware of the reports and use that input in a
reasonable, like Zi just did [1]. And if they are unsure, they usually ask to
double-check.
[1] https://lore.kernel.org/r/15191F7F-0D10-4907-B963-DA4EA0E36EB6@nvidia.com
> It's possible that
> Sashiko is right but the author isn't convinced, so getting more eyes
> on the feedback would help.
Forcing contributors to reply to everything. I don't like that, in particular
not as long as there is no way for contributors to run it early in private.
In most cases, contributors just do the reasonable thing: incorporate the
feedback in a new version.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Andrew Morton @ 2026-04-24 19:08 UTC (permalink / raw)
To: Yosry Ahmed
Cc: David Hildenbrand (Arm), Pasha Tatashin, Lance Yang, peterz,
dave.hansen, dave.hansen, ypodemsk, hughd, will, aneesh.kumar,
npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs, ziy, baolin.wang,
Liam.Howlett, npache, ryan.roberts, dev.jain, baohua, shy828301,
riel, jannh, jgross, seanjc, pbonzini, boris.ostrovsky,
virtualization, kvm, linux-arch, linux-mm, linux-kernel,
ioworker0, roman.gushchin
In-Reply-To: <CAO9r8zN1pRfyC0Rh+UdW-Lsret=z3oveT3=gnZftX-Sr_ubyyQ@mail.gmail.com>
On Fri, 24 Apr 2026 11:50:03 -0700 Yosry Ahmed <yosry@kernel.org> wrote:
> > >>> Preferences?
> > >>
> > >> Reply-to-author would likely be better as a first step.
> > >
> > > Why do you think so?
> >
> > The most important part for me is that authors are aware of the reports.
> >
> > Sending them as a mail forces people to publicly reply to the feedback, and at
> > this point in time, I am not convinced that that is the right approach.
>
> But I imagine it's useful for reviewers to see Sashiko's feedback as
> well (without having to go look on the website). It's possible that
> Sashiko is right but the author isn't convinced, so getting more eyes
> on the feedback would help. If Sashiko is wrong, it's still useful for
> more people to see it and point it out, instead of Sashiko privately
> misguiding the author, especially that reviewers are probably more
> likely to tell if Sashiko is right or wrong.
Also, Sashiko does like to find unrelated bugs in surrounding code. I
saw two of these today.
But whatever, one step at a time. My main interest at present is to
stop having to send lame emails linking to the Sashiko reports!
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Peter Zijlstra @ 2026-04-24 19:01 UTC (permalink / raw)
To: Yosry Ahmed
Cc: David Hildenbrand (Arm), Andrew Morton, Pasha Tatashin,
Lance Yang, dave.hansen, dave.hansen, ypodemsk, hughd, will,
aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs, ziy,
baolin.wang, Liam.Howlett, npache, ryan.roberts, dev.jain, baohua,
shy828301, riel, jannh, jgross, seanjc, pbonzini, boris.ostrovsky,
virtualization, kvm, linux-arch, linux-mm, linux-kernel,
ioworker0, roman.gushchin
In-Reply-To: <CAO9r8zN1pRfyC0Rh+UdW-Lsret=z3oveT3=gnZftX-Sr_ubyyQ@mail.gmail.com>
On Fri, Apr 24, 2026 at 11:50:03AM -0700, Yosry Ahmed wrote:
> But I imagine it's useful for reviewers to see Sashiko's feedback as
> well (without having to go look on the website).
That's why I have a script; if I press 'S' in mutt on an 0/n email, said
script goes and does webrequest to sashiko and inserts the review
comments into my local maildir as properly threaded replies to the
series at hand.
No looking at website needed.
^ permalink raw reply
* Re: [PATCH RFC v3 01/19] mm: thread user_addr through page allocator for cache-friendly zeroing
From: David Hildenbrand (Arm) @ 2026-04-24 18:51 UTC (permalink / raw)
To: Matthew Wilcox, Michael S. Tsirkin
Cc: linux-kernel, Andrew Morton, Vlastimil Babka, Brendan Jackman,
Michal Hocko, Suren Baghdasaryan, Jason Wang, Andrea Arcangeli,
Gregory Price, linux-mm, virtualization, Johannes Weiner, Zi Yan,
Lorenzo Stoakes, Liam R. Howlett, Mike Rapoport, Muchun Song,
Oscar Salvador, Baolin Wang, Nico Pache, Ryan Roberts, Dev Jain,
Barry Song, Lance Yang, Matthew Brost, Joshua Hahn, Rakie Kim,
Byungchul Park, Ying Huang, Alistair Popple, Hugh Dickins,
Christoph Lameter, David Rientjes, Roman Gushchin, Harry Yoo,
Chris Li, Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He,
linux-fsdevel
In-Reply-To: <aeu5P1bZW3yEH54t@casper.infradead.org>
On 4/24/26 20:41, Matthew Wilcox wrote:
> On Tue, Apr 21, 2026 at 06:01:10PM -0400, Michael S. Tsirkin wrote:
>> Thread a user virtual address from vma_alloc_folio() down through
>> the page allocator to post_alloc_hook(). This is plumbing preparation
>> for a subsequent patch that will use user_addr to call folio_zero_user()
>> for cache-friendly zeroing of user pages.
>>
>> The user_addr is stored in struct alloc_context and flows through:
>> vma_alloc_folio -> folio_alloc_mpol -> __alloc_pages_mpol ->
>> __alloc_frozen_pages -> get_page_from_freelist -> prep_new_page ->
>> post_alloc_hook
>
> I don't like this. I think we should instead lift the zeroing from
> post_alloc_hook() to the callers of __alloc_frozen_pages().
I don't think so. In particular how zeroing optimizations are related to buddy
details (tag zeroing, kasan unpoisoning, init_on_alloc/init_on_free, now
pre-zeroing).
>
> I don't understand why you want to remove the double-zeroing of memory
> when the user has asked for zero_on_alloc. They asked for stupid things,
> let them bear the cost.
That's not how the world works :)
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Yosry Ahmed @ 2026-04-24 18:50 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Andrew Morton, Pasha Tatashin, Lance Yang, peterz, dave.hansen,
dave.hansen, ypodemsk, hughd, will, aneesh.kumar, npiggin, tglx,
mingo, bp, x86, hpa, arnd, ljs, ziy, baolin.wang, Liam.Howlett,
npache, ryan.roberts, dev.jain, baohua, shy828301, riel, jannh,
jgross, seanjc, pbonzini, boris.ostrovsky, virtualization, kvm,
linux-arch, linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <644e65dc-3d39-4137-b51f-51d953b67d50@kernel.org>
On Fri, Apr 24, 2026 at 11:36 AM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 4/24/26 16:31, Andrew Morton wrote:
> > On Fri, 24 Apr 2026 16:20:55 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> >
> >> On 4/24/26 16:15, Andrew Morton wrote:
> >>>
> >>>
> >>> Yep. I'd be OK with an automatic reply-to-all. Maybe some won't like
> >>> that.
> >>>
> >>> An alternative I've discussed with Roman is an automated
> >>> reply-to-author with a cc to a dedicated list (we could use mm-commits
> >>> for now).
> >>>
> >>> Preferences?
> >>
> >> Reply-to-author would likely be better as a first step.
> >
> > Why do you think so?
>
> The most important part for me is that authors are aware of the reports.
>
> Sending them as a mail forces people to publicly reply to the feedback, and at
> this point in time, I am not convinced that that is the right approach.
But I imagine it's useful for reviewers to see Sashiko's feedback as
well (without having to go look on the website). It's possible that
Sashiko is right but the author isn't convinced, so getting more eyes
on the feedback would help. If Sashiko is wrong, it's still useful for
more people to see it and point it out, instead of Sashiko privately
misguiding the author, especially that reviewers are probably more
likely to tell if Sashiko is right or wrong.
I understand the fear of too much noise, but I think it's easy to
ignore Sashiko if we want to. It's also a good exercise to spell out
why Sashiko is wrong (e.g. improve changelogs/comments to document
assumptions more obviously). We can always tune it down later if we
think it's too much, right?
^ permalink raw reply
* Re: [PATCH RFC v3 01/19] mm: thread user_addr through page allocator for cache-friendly zeroing
From: David Hildenbrand (Arm) @ 2026-04-24 18:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Gregory Price, linux-kernel, Andrew Morton, Vlastimil Babka,
Brendan Jackman, Michal Hocko, Suren Baghdasaryan, Jason Wang,
Andrea Arcangeli, linux-mm, virtualization, Johannes Weiner,
Zi Yan, Lorenzo Stoakes, Liam R. Howlett, Mike Rapoport,
Matthew Wilcox (Oracle), Muchun Song, Oscar Salvador, Baolin Wang,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, Lance Yang,
Matthew Brost, Joshua Hahn, Rakie Kim, Byungchul Park, Ying Huang,
Alistair Popple, Hugh Dickins, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, linux-fsdevel
In-Reply-To: <20260424143541-mutt-send-email-mst@kernel.org>
On 4/24/26 20:36, Michael S. Tsirkin wrote:
> On Fri, Apr 24, 2026 at 08:33:45PM +0200, David Hildenbrand (Arm) wrote:
>> On 4/23/26 18:13, Michael S. Tsirkin wrote:
>>>
>>>
>>> You mean, that it stays because of the reserved pool?
>>
>> I meant, that if we are running with init_on_free or init_on_alloc, that we end
>> up double-zeroing right now upstream. So nobody cared to optimize that part so far.
>
> on the aliasing arches you mean? that double zeroing?
Essentially where user_alloc_needs_zeroing() would have told you that there is
no need to call folio_zero_user().
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH RFC v3 01/19] mm: thread user_addr through page allocator for cache-friendly zeroing
From: Matthew Wilcox @ 2026-04-24 18:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Andrew Morton, David Hildenbrand, Vlastimil Babka,
Brendan Jackman, Michal Hocko, Suren Baghdasaryan, Jason Wang,
Andrea Arcangeli, Gregory Price, linux-mm, virtualization,
Johannes Weiner, Zi Yan, Lorenzo Stoakes, Liam R. Howlett,
Mike Rapoport, Muchun Song, Oscar Salvador, Baolin Wang,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, Lance Yang,
Matthew Brost, Joshua Hahn, Rakie Kim, Byungchul Park, Ying Huang,
Alistair Popple, Hugh Dickins, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, linux-fsdevel
In-Reply-To: <9dd9deabd42801f3c344326991d1431c3d8db39d.1776808210.git.mst@redhat.com>
On Tue, Apr 21, 2026 at 06:01:10PM -0400, Michael S. Tsirkin wrote:
> Thread a user virtual address from vma_alloc_folio() down through
> the page allocator to post_alloc_hook(). This is plumbing preparation
> for a subsequent patch that will use user_addr to call folio_zero_user()
> for cache-friendly zeroing of user pages.
>
> The user_addr is stored in struct alloc_context and flows through:
> vma_alloc_folio -> folio_alloc_mpol -> __alloc_pages_mpol ->
> __alloc_frozen_pages -> get_page_from_freelist -> prep_new_page ->
> post_alloc_hook
I don't like this. I think we should instead lift the zeroing from
post_alloc_hook() to the callers of __alloc_frozen_pages().
I don't understand why you want to remove the double-zeroing of memory
when the user has asked for zero_on_alloc. They asked for stupid things,
let them bear the cost.
^ permalink raw reply
* Re: [PATCH RFC v3 01/19] mm: thread user_addr through page allocator for cache-friendly zeroing
From: Michael S. Tsirkin @ 2026-04-24 18:36 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Gregory Price, linux-kernel, Andrew Morton, Vlastimil Babka,
Brendan Jackman, Michal Hocko, Suren Baghdasaryan, Jason Wang,
Andrea Arcangeli, linux-mm, virtualization, Johannes Weiner,
Zi Yan, Lorenzo Stoakes, Liam R. Howlett, Mike Rapoport,
Matthew Wilcox (Oracle), Muchun Song, Oscar Salvador, Baolin Wang,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, Lance Yang,
Matthew Brost, Joshua Hahn, Rakie Kim, Byungchul Park, Ying Huang,
Alistair Popple, Hugh Dickins, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, linux-fsdevel
In-Reply-To: <4e12d67b-60e3-4bf5-a229-43c0d2c62cfb@kernel.org>
On Fri, Apr 24, 2026 at 08:33:45PM +0200, David Hildenbrand (Arm) wrote:
> On 4/23/26 18:13, Michael S. Tsirkin wrote:
> > On Thu, Apr 23, 2026 at 05:54:26PM +0200, David Hildenbrand (Arm) wrote:
> >> On 4/23/26 16:46, Michael S. Tsirkin wrote:
> >>>
> >>> I just dislike it when things are non orthogonal.
> >>> People are used to: hugetlb = same perf as THP but more predictable at the cost
> >>> of being harder to use and using more resources.
> >>> Here, suddenly, we have an optimization but only for THP.
> >>
> >> Note that we also didn't care about user_alloc_needs_zeroing() with hugetlb so far.
> >
> >
> > You mean, that it stays because of the reserved pool?
>
> I meant, that if we are running with init_on_free or init_on_alloc, that we end
> up double-zeroing right now upstream. So nobody cared to optimize that part so far.
on the aliasing arches you mean? that double zeroing?
> --
> Cheers,
>
> David
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: David Hildenbrand (Arm) @ 2026-04-24 18:36 UTC (permalink / raw)
To: Andrew Morton
Cc: Pasha Tatashin, Lance Yang, peterz, dave.hansen, dave.hansen,
ypodemsk, hughd, will, aneesh.kumar, npiggin, tglx, mingo, bp,
x86, hpa, arnd, ljs, ziy, baolin.wang, Liam.Howlett, npache,
ryan.roberts, dev.jain, baohua, shy828301, riel, jannh, jgross,
seanjc, pbonzini, boris.ostrovsky, virtualization, kvm,
linux-arch, linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <20260424073145.b990fe9b925da304508aad71@linux-foundation.org>
On 4/24/26 16:31, Andrew Morton wrote:
> On Fri, 24 Apr 2026 16:20:55 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
>
>> On 4/24/26 16:15, Andrew Morton wrote:
>>>
>>>
>>> Yep. I'd be OK with an automatic reply-to-all. Maybe some won't like
>>> that.
>>>
>>> An alternative I've discussed with Roman is an automated
>>> reply-to-author with a cc to a dedicated list (we could use mm-commits
>>> for now).
>>>
>>> Preferences?
>>
>> Reply-to-author would likely be better as a first step.
>
> Why do you think so?
The most important part for me is that authors are aware of the reports.
Sending them as a mail forces people to publicly reply to the feedback, and at
this point in time, I am not convinced that that is the right approach.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH RFC v3 01/19] mm: thread user_addr through page allocator for cache-friendly zeroing
From: David Hildenbrand (Arm) @ 2026-04-24 18:33 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Gregory Price, linux-kernel, Andrew Morton, Vlastimil Babka,
Brendan Jackman, Michal Hocko, Suren Baghdasaryan, Jason Wang,
Andrea Arcangeli, linux-mm, virtualization, Johannes Weiner,
Zi Yan, Lorenzo Stoakes, Liam R. Howlett, Mike Rapoport,
Matthew Wilcox (Oracle), Muchun Song, Oscar Salvador, Baolin Wang,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, Lance Yang,
Matthew Brost, Joshua Hahn, Rakie Kim, Byungchul Park, Ying Huang,
Alistair Popple, Hugh Dickins, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, linux-fsdevel
In-Reply-To: <20260423121222-mutt-send-email-mst@kernel.org>
On 4/23/26 18:13, Michael S. Tsirkin wrote:
> On Thu, Apr 23, 2026 at 05:54:26PM +0200, David Hildenbrand (Arm) wrote:
>> On 4/23/26 16:46, Michael S. Tsirkin wrote:
>>>
>>> I just dislike it when things are non orthogonal.
>>> People are used to: hugetlb = same perf as THP but more predictable at the cost
>>> of being harder to use and using more resources.
>>> Here, suddenly, we have an optimization but only for THP.
>>
>> Note that we also didn't care about user_alloc_needs_zeroing() with hugetlb so far.
>
>
> You mean, that it stays because of the reserved pool?
I meant, that if we are running with init_on_free or init_on_alloc, that we end
up double-zeroing right now upstream. So nobody cared to optimize that part so far.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 1/3] vfio/pci: Set up bar resources and maps in vfio_pci_core_enable()
From: Alex Williamson @ 2026-04-24 17:20 UTC (permalink / raw)
To: Matt Evans
Cc: Kevin Tian, Jason Gunthorpe, Ankit Agrawal, Alistair Popple,
Leon Romanovsky, Kees Cook, Shameer Kolothum, Yishai Hadas,
Alexey Kardashevskiy, Eric Auger, Peter Xu, Vivek Kasireddy,
Zhi Wang, kvm, linux-kernel, virtualization, alex
In-Reply-To: <729d6593-f88b-42bf-b3a0-8c364d9ca5b4@meta.com>
On Fri, 24 Apr 2026 16:15:06 +0100
Matt Evans <mattev@meta.com> wrote:
> On 23/04/2026 22:30, Alex Williamson wrote:
> > On Thu, 23 Apr 2026 11:25:07 -0700
> > Matt Evans <mattev@meta.com> wrote:
> >> +
> >> + if (pci_resource_len(pdev, i) == 0)
> >> + continue;
> >> +
> >> + ret = pci_request_selected_regions(pdev, 1 << bar, "vfio");
> >> + if (ret) {
> >> + pci_warn(vdev->pdev, "Failed to reserve region %d\n", bar);
> >> + continue;
> >> + }
> >> + vdev->have_bar_resource[bar] = true;
> >> +
> >> + io = pci_iomap(pdev, bar, 0);
> >> + if (io)
> >> + vdev->barmap[bar] = io;
> >> + else
> >> + pci_warn(vdev->pdev, "Failed to iomap region %d\n", bar);
> >> + }
> >> +}
> >
> > I see you making the point in the cover letter about the resource
> > request vs the iomap resource, but we currently handle these together.
> > If either fails, setup barmap fails and the path returns error. I
> > don't see any justification for now allowing the request resource to
> > succeed but the iomap fails.
>
> The primary effect was to let consumers see -EBUSY for a resource
> reservation failure or -ENOMEM for an iomap failure (whether through
> this patch's vfio_pci_core_setup_barmap() or the next patch's helpers),
> and that keeps the error signatures identical.
>
> A weak secondary effect was that a BAR that gets resource but fails for
> whatever reason to iomap it can still be used by most clients (assuming
> the general usage is to mmap). The system's pretty sick if this is the
> case, so as I say it's weak.
Right, I don't see that's really a necessary add at this point. In
fact while we expect users to access through the mmap when available,
we don't actually have a way to specify that mmap works w/o read/write,
which is effectively what this proposes is a valid state.
>
> OK, if you prefer the combined approach and don't feel the subsequent
> single-semantic check helpers (need mapping, need resource) are clearer
> to read then I'll recombine them, though:
>
> - If vfio_pci_core_map_bars() just sets barmap[n] iff both resource
> acquisition and iomap succeed, then a later check can only return one
> error from either cause. I'll go with -ENOMEM unless you prefer -EBUSY.
> Using something else can again make userspace see previously-unseen
> error values.
>
> - IMHO vfio_pci_core_setup_barmap() should still be renamed (in a 2nd
> patch) since it doesn't do any setting up anymore. Cosmetic, but
> cleaner to parse when the callers use vfio_pci_core_check_barmap_valid() no?
I'm not sure how important it is to preserve the identical errno, but
we can actually do that too. Make the enable time "setup" function
store the ERR_PTR in the barmap and change the current callers from
"setup" to "get-iomap", where get-iomap is a __must_check return that
callers test against IS_ERR_OR_NULL().
Or maybe better, collapse NULL into -ENODEV so callers only test
IS_ERR().
There's even one user in vfio_pci_bar_rw() where this provides a minor
simplification. Likely the others are just wrapping the get-iomap call
in the ERR/NULL test to get the equivalent behavior. Thoughts? Thanks,
Alex
^ permalink raw reply
* Re: [PATCH] virtio: Add ID for virtio media
From: Michael S. Tsirkin @ 2026-04-24 16:31 UTC (permalink / raw)
To: Albert Esteve
Cc: Jason Wang, Xuan Zhuo, Eugenio Pérez, virtualization,
linux-kernel, gnurou
In-Reply-To: <CADSE00JEjrecyM==PyjX9LT5X62awYQOn3as-KFGYQrSD0+K_w@mail.gmail.com>
On Fri, Apr 24, 2026 at 03:37:14PM +0200, Albert Esteve wrote:
> On Fri, Apr 24, 2026 at 3:07 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Apr 09, 2026 at 06:53:41PM +0200, Albert Esteve wrote:
> > > Hi,
> > >
> > >
> > > On Tue, Mar 10, 2026 at 9:41 AM Albert Esteve <aesteve@redhat.com> wrote:
> > > >
> > > > Add VIRTIO_ID_MEDIA definition for virtio-media.
> > > >
> > > > Signed-off-by: Albert Esteve <aesteve@redhat.com>
> > >
> > > Are there any thoughts on this patch, or any actions I need to take?
> > >
> > > Thanks,
> > > Albert
> >
> > Create a github issue and request a vote as documented in README.md
>
> The inclusion of this ID was already voted and approved. The device
> already appears in the VirtIO v1.4 specification, with the same ID (as
> linked below). This patch is only meant to translate the decision to
> the kernel header.
>
> >
> > > > ---
> > > > While the Linux driver for virtio media is currently under active
> > > > development and review [1], the VirtIO v1.4 specification has
> > > > already been published and oficially defines the media device type [2].
> > > >
> > > > Adding the device ID now allows other components and tools to reference it
> > > > before the driver lands, and ensures the kernel headers stay aligned
> > > > with the specification.
> > > >
> > > > [1] https://lore.kernel.org/linux-media/20250412-virtio-media-v3-1-97dc94c18398@gmail.com/
> > > > [2] https://docs.oasis-open.org/virtio/virtio/v1.4/virtio-v1.4.html#x1-82200022
> > > > ---
> > > > include/uapi/linux/virtio_ids.h | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/include/uapi/linux/virtio_ids.h b/include/uapi/linux/virtio_ids.h
> > > > index 6c12db16faa3a..f9056af0c6223 100644
> > > > --- a/include/uapi/linux/virtio_ids.h
> > > > +++ b/include/uapi/linux/virtio_ids.h
> > > > @@ -69,6 +69,7 @@
> > > > #define VIRTIO_ID_BT 40 /* virtio bluetooth */
> > > > #define VIRTIO_ID_GPIO 41 /* virtio gpio */
> > > > #define VIRTIO_ID_SPI 45 /* virtio spi */
> > > > +#define VIRTIO_ID_MEDIA 48 /* virtio media */
> > > >
> > > > /*
> > > > * Virtio Transitional IDs
> > > >
> > > > ---
> > > > base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> > > > change-id: 20260310-virtio-media-id-b31179fcdc44
> > > >
> > > > Best regards,
> > > > --
> > > > Albert Esteve <aesteve@redhat.com>
> > > >
> >
Oh my bad. I misfiled it into the spec folder. I will take care of this.
Thanks!
^ permalink raw reply
* Re: [PATCH 7.2 v10 1/2] mm/mmu_gather: prepare to skip redundant sync IPIs
From: Dave Hansen @ 2026-04-24 15:52 UTC (permalink / raw)
To: Peter Zijlstra, Lance Yang
Cc: akpm, david, dave.hansen, ypodemsk, hughd, will, aneesh.kumar,
npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs, ziy, baolin.wang,
Liam.Howlett, npache, ryan.roberts, dev.jain, baohua, shy828301,
riel, jannh, jgross, seanjc, pbonzini, boris.ostrovsky,
virtualization, kvm, linux-arch, linux-mm, linux-kernel,
ioworker0
In-Reply-To: <20260424150454.GF3126523@noisy.programming.kicks-ass.net>
On 4/24/26 08:04, Peter Zijlstra wrote:
> So I don't like this at all.... The comment says there is a preceding
> TLB flush, but there is nothing that guarantees there is. One would have
> to go audit all users and ensure this is always true.
>
> This thing is incredibly fragile.
Yeah, this seems like an attempt to apply a code solution to a data
structure problem.
I think I talked about this in earlier iterations. But, ideally, what
happens here is that the things doing the table freeing or collapsing or
whatever would note in a data structure what they did.
Then the actual flushing code can look at the data structure and figure
out what kind of flush it needs. Things like "do I need to flush on lazy
CPUs?" Or, "have I done an IPI since the last page table free?"
But, if I remember from earlier in this thread, some of the callers of
this stuff didn't have a nice data structure (like an mmu_gather) passed
in to the places where it would be needed to exfiltrate the information.
I think Lance gave up on that because it looked too invasive to him.
But, I think this boils down to the code being too fragile as-is to
support what Lance is trying to do. It actually needs some refactoring
love before it can support the desired optimization. I'm not sure
there's an easy way out here.
^ permalink raw reply
* Re: [PATCH 7.2 v10 2/2] x86/tlb: skip redundant sync IPIs for native TLB flush
From: Lance Yang @ 2026-04-24 15:49 UTC (permalink / raw)
To: peterz, dave.hansen
Cc: lance.yang, akpm, david, dave.hansen, ypodemsk, hughd, will,
aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs, ziy,
baolin.wang, Liam.Howlett, npache, ryan.roberts, dev.jain, baohua,
shy828301, riel, jannh, jgross, seanjc, pbonzini, boris.ostrovsky,
virtualization, kvm, linux-arch, linux-mm, linux-kernel,
ioworker0
In-Reply-To: <20260424151247.GG3126523@noisy.programming.kicks-ass.net>
On Fri, Apr 24, 2026 at 05:12:47PM +0200, Peter Zijlstra wrote:
>On Fri, Apr 24, 2026 at 02:25:28PM +0800, Lance Yang wrote:
>> diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
>> index cfcb60468b01..2cf1eeaffd6f 100644
>> --- a/arch/x86/hyperv/mmu.c
>> +++ b/arch/x86/hyperv/mmu.c
>> @@ -63,7 +63,7 @@ static void hyperv_flush_tlb_multi(const struct cpumask *cpus,
>> struct hv_tlb_flush *flush;
>> u64 status;
>> unsigned long flags;
>> - bool do_lazy = !info->freed_tables;
>> + bool do_lazy = !info->wake_lazy_cpus;
>>
>> trace_hyperv_mmu_flush_tlb_multi(cpus, info);
>>
>> @@ -198,7 +198,7 @@ static u64 hyperv_flush_tlb_others_ex(const struct cpumask *cpus,
>>
>> flush->hv_vp_set.format = HV_GENERIC_SET_SPARSE_4K;
>> nr_bank = cpumask_to_vpset_skip(&flush->hv_vp_set, cpus,
>> - info->freed_tables ? NULL : cpu_is_lazy);
>> + info->wake_lazy_cpus ? NULL : cpu_is_lazy);
>> if (nr_bank < 0)
>> return HV_STATUS_INVALID_PARAMETER;
>>
>> diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
>> index 866ea78ba156..fb256fd95f95 100644
>> --- a/arch/x86/include/asm/tlb.h
>> +++ b/arch/x86/include/asm/tlb.h
>
>> static inline void tlb_flush(struct mmu_gather *tlb)
>> {
>> unsigned long start = 0UL, end = TLB_FLUSH_ALL;
>> unsigned int stride_shift = tlb_get_unmap_shift(tlb);
>>
>> + /*
>> + * Both freed_tables and unshared_tables must wake lazy-TLB CPUs, so
>> + * they receive IPIs before reusing or freeing page tables, allowing
>> + * us to safely implement tlb_table_flush_implies_ipi_broadcast().
>> + */
>> + bool wake_lazy_cpus = tlb->freed_tables || tlb->unshared_tables;
>> +
>> if (!tlb->fullmm && !tlb->need_flush_all) {
>> start = tlb->start;
>> end = tlb->end;
>> }
>>
>> - flush_tlb_mm_range(tlb->mm, start, end, stride_shift, tlb->freed_tables);
>> + flush_tlb_mm_range(tlb->mm, start, end, stride_shift, wake_lazy_cpus);
>> }
>>
>> static inline void invlpg(unsigned long addr)
>> diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
>> index 5a3cdc439e38..39b9454781c3 100644
>> --- a/arch/x86/include/asm/tlbflush.h
>> +++ b/arch/x86/include/asm/tlbflush.h
>> @@ -225,7 +227,7 @@ struct flush_tlb_info {
>> u64 new_tlb_gen;
>> unsigned int initiating_cpu;
>> u8 stride_shift;
>> - u8 freed_tables;
>> + u8 wake_lazy_cpus;
>> u8 trim_cpumask;
>> };
>>
>> @@ -315,7 +317,7 @@ static inline bool mm_in_asid_transition(struct mm_struct *mm) { return false; }
>> extern void flush_tlb_all(void);
>> extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
>> unsigned long end, unsigned int stride_shift,
>> - bool freed_tables);
>> + bool wake_lazy_cpus);
>> extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
>>
>> static inline void flush_tlb_page(struct vm_area_struct *vma, unsigned long a)
>
>> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
>> index 621e09d049cb..3ce254a3982c 100644
>> --- a/arch/x86/mm/tlb.c
>> +++ b/arch/x86/mm/tlb.c
>> @@ -1360,16 +1362,16 @@ STATIC_NOPV void native_flush_tlb_multi(const struct cpumask *cpumask,
>> (info->end - info->start) >> PAGE_SHIFT);
>>
>> /*
>> - * If no page tables were freed, we can skip sending IPIs to
>> - * CPUs in lazy TLB mode. They will flush the CPU themselves
>> - * at the next context switch.
>> + * If lazy-TLB CPUs do not need to be woken, we can skip sending
>> + * IPIs to them. They will flush themselves at the next context
>> + * switch.
>> *
>> - * However, if page tables are getting freed, we need to send the
>> - * IPI everywhere, to prevent CPUs in lazy TLB mode from tripping
>> - * up on the new contents of what used to be page tables, while
>> - * doing a speculative memory access.
>> + * However, if page tables are getting freed or unshared, we need
>> + * to send the IPI everywhere, to prevent CPUs in lazy TLB mode
>> + * from tripping up on the new contents of what used to be page
>> + * tables, while doing a speculative memory access.
>> */
>> - if (info->freed_tables || mm_in_asid_transition(info->mm))
>> + if (info->wake_lazy_cpus || mm_in_asid_transition(info->mm))
>> on_each_cpu_mask(cpumask, flush_tlb_func, (void *)info, true);
>> else
>> on_each_cpu_cond_mask(should_flush_tlb, flush_tlb_func,
>> @@ -1402,7 +1404,7 @@ static DEFINE_PER_CPU(unsigned int, flush_tlb_info_idx);
>>
>> static struct flush_tlb_info *get_flush_tlb_info(struct mm_struct *mm,
>> unsigned long start, unsigned long end,
>> - unsigned int stride_shift, bool freed_tables,
>> + unsigned int stride_shift, bool wake_lazy_cpus,
>> u64 new_tlb_gen)
>> {
>> struct flush_tlb_info *info = this_cpu_ptr(&flush_tlb_info);
>> @@ -1429,7 +1431,7 @@ static struct flush_tlb_info *get_flush_tlb_info(struct mm_struct *mm,
>> info->end = end;
>> info->mm = mm;
>> info->stride_shift = stride_shift;
>> - info->freed_tables = freed_tables;
>> + info->wake_lazy_cpus = wake_lazy_cpus;
>> info->new_tlb_gen = new_tlb_gen;
>> info->initiating_cpu = smp_processor_id();
>> info->trim_cpumask = 0;
>> @@ -1448,7 +1450,7 @@ static void put_flush_tlb_info(void)
>>
>> void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
>> unsigned long end, unsigned int stride_shift,
>> - bool freed_tables)
>> + bool wake_lazy_cpus)
>> {
>> struct flush_tlb_info *info;
>> int cpu = get_cpu();
>> @@ -1457,7 +1459,7 @@ void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
>> /* This is also a barrier that synchronizes with switch_mm(). */
>> new_tlb_gen = inc_mm_tlb_gen(mm);
>>
>> - info = get_flush_tlb_info(mm, start, end, stride_shift, freed_tables,
>> + info = get_flush_tlb_info(mm, start, end, stride_shift, wake_lazy_cpus,
>> new_tlb_gen);
>>
>> /*
>
>This whole s/freed_tables/wake_lazy_cpus/ rename should probably be its
>own patch, as should that include unshare_tables thing be.
>
>That seems like unrelated changes.
Thanks, makes sense! Will split the pure s/freed_tables/wake_lazy_cpus/
rename out.
For the tlb->unshared_tables part, I would keep it with this patch,
since lazy-TLB CPUs still have to be woken before reusing unshared page
tables.
@Dave what do you think?
Thanks,
Lance
^ permalink raw reply
* Re: [PATCH 7.2 v10 1/2] mm/mmu_gather: prepare to skip redundant sync IPIs
From: Lance Yang @ 2026-04-24 15:40 UTC (permalink / raw)
To: lance.yang
Cc: akpm, peterz, david, dave.hansen, dave.hansen, ypodemsk, hughd,
will, aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs,
ziy, baolin.wang, Liam.Howlett, npache, ryan.roberts, dev.jain,
baohua, shy828301, riel, jannh, jgross, seanjc, pbonzini,
boris.ostrovsky, virtualization, kvm, linux-arch, linux-mm,
linux-kernel, ioworker0
In-Reply-To: <20260424062528.71951-2-lance.yang@linux.dev>
On Fri, Apr 24, 2026 at 02:25:27PM +0800, Lance Yang wrote:
>From: Lance Yang <lance.yang@linux.dev>
>
>When page table operations require synchronization with software/lockless
>walkers, they call tlb_remove_table_sync_{one,rcu}() after flushing the
>TLB (tlb->freed_tables or tlb->unshared_tables).
>
>On architectures where the TLB flush already sends IPIs to all target CPUs,
>the subsequent sync IPI broadcast is redundant. This is not only costly on
>large systems where it disrupts all CPUs even for single-process page table
>operations, but has also been reported to hurt RT workloads[1].
>
>Introduce tlb_table_flush_implies_ipi_broadcast() to check if the prior TLB
>flush already provided the necessary synchronization. When true, the sync
>calls can early-return.
>
>A few cases rely on this synchronization:
>
>1) hugetlb PMD unshare[2]: The problem is not the freeing but the reuse
> of the PMD table for other purposes in the last remaining user after
> unsharing.
>
>2) khugepaged collapse[3]: Ensure no concurrent GUP-fast before collapsing
> and (possibly) freeing the page table / re-depositing it.
>
>Currently always returns false (no behavior change). The follow-up patch
>will enable the optimization for x86.
>
>[1] https://lore.kernel.org/linux-mm/1b27a3fa-359a-43d0-bdeb-c31341749367@kernel.org/
>[2] https://lore.kernel.org/linux-mm/6a364356-5fea-4a6c-b959-ba3b22ce9c88@kernel.org/
>[3] https://lore.kernel.org/linux-mm/2cb4503d-3a3f-4f6c-8038-7b3d1c74b3c2@kernel.org/
>
>Suggested-by: David Hildenbrand (Arm) <david@kernel.org>
>Acked-by: David Hildenbrand (Arm) <david@kernel.org>
>Signed-off-by: Lance Yang <lance.yang@linux.dev>
>---
> include/asm-generic/tlb.h | 17 +++++++++++++++++
> mm/mmu_gather.c | 15 +++++++++++++++
> 2 files changed, 32 insertions(+)
>
>diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
>index bdcc2778ac64..cb41cc6a0024 100644
>--- a/include/asm-generic/tlb.h
>+++ b/include/asm-generic/tlb.h
>@@ -240,6 +240,23 @@ static inline void tlb_remove_table(struct mmu_gather *tlb, void *table)
> }
> #endif /* CONFIG_MMU_GATHER_TABLE_FREE */
>
>+/**
>+ * tlb_table_flush_implies_ipi_broadcast - does TLB flush imply IPI sync
>+ *
>+ * When page table operations require synchronization with software/lockless
>+ * walkers, they flush the TLB (tlb->freed_tables or tlb->unshared_tables)
>+ * then call tlb_remove_table_sync_{one,rcu}(). If the flush already sent
>+ * IPIs to all CPUs, the sync call is redundant.
>+ *
>+ * Returns false by default. Architectures can override by defining this.
>+ */
>+#ifndef tlb_table_flush_implies_ipi_broadcast
>+static inline bool tlb_table_flush_implies_ipi_broadcast(void)
>+{
>+ return false;
>+}
>+#endif
>+
> #ifdef CONFIG_MMU_GATHER_RCU_TABLE_FREE
> /*
> * This allows an architecture that does not use the linux page-tables for
>diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
>index 3985d856de7f..37a6a711c37e 100644
>--- a/mm/mmu_gather.c
>+++ b/mm/mmu_gather.c
>@@ -283,6 +283,14 @@ void tlb_remove_table_sync_one(void)
> * It is however sufficient for software page-table walkers that rely on
> * IRQ disabling.
> */
>+
>+ /*
>+ * Skip IPI if the preceding TLB flush already synchronized with
>+ * all CPUs that could be doing software/lockless page table walks.
>+ */
>+ if (tlb_table_flush_implies_ipi_broadcast())
>+ return;
Sashiko told me[1]:
"
Could skipping the global IPI fail to synchronize with lockless walkers
running outside the mm_cpumask?
tlb_remove_table_sync_one() is used (e.g., by khugepaged during THP collapse)
to wait for lockless page table walkers to finish. On 32-bit architectures
like x86 PAE, pmdp_get_lockless() disables interrupts to prevent torn reads
of 64-bit PMDs.
While the preceding TLB flush sends IPIs to CPUs in the target mm's
mm_cpumask, lockless walkers such as pte_offset_map() are frequently executed
by background threads unrelated to the target mm (e.g., kswapd via
page_vma_mapped_walk()). These threads run on CPUs outside of mm_cpumask
and would not receive the TLB flush IPI.
If the global smp_call_function(..., 1) IPI is skipped, the modifying thread
might not wait for kswapd. Could this allow it to overwrite the PMD while the
out-of-context reader is reading it, resulting in a torn PMD?
"
Afraid not.
When CONFIG_MMU_GATHER_RCU_TABLE_FREE=n, tlb_remove_table_sync_one() is
just a NOP.
So if lockless walkers outside mm_cpumask really required a separate
global IPI here, systems running with CONFIG_MMU_GATHER_RCU_TABLE_FREE=n
would already be broken today, because there is no such IPI there to
begin with :)
[1] https://sashiko.dev/#/patchset/20260424062528.71951-1-lance.yang@linux.dev
>
> smp_call_function(tlb_remove_table_smp_sync, NULL, 1);
> }
>
>@@ -312,6 +320,13 @@ static void tlb_remove_table_free(struct mmu_table_batch *batch)
> */
> void tlb_remove_table_sync_rcu(void)
> {
>+ /*
>+ * Skip RCU wait if the preceding TLB flush already synchronized
>+ * with all CPUs that could be doing software/lockless page table walks.
>+ */
>+ if (tlb_table_flush_implies_ipi_broadcast())
>+ return;
>+
And Sashiko also pointed out[2]:
"
Does skipping synchronize_rcu() here violate the RCU lifetime guarantee of
page tables?
Generic software page table walkers, such as pte_offset_map(), rely strictly
on rcu_read_lock() to protect page table pages from being freed concurrently.
Crucially, they execute with hardware interrupts enabled.
Under CONFIG_PREEMPT_RCU, an IPI broadcast does not wait for rcu_read_lock()
critical sections to complete. The IPI simply interrupts the reader, executes
the flush, and returns immediately.
Could this allow the page table to be freed while the reader is still actively
accessing it, leading to a use-after-free for concurrent pte_offset_map()
readers?
"
Nop.
tlb_remove_table_sync_rcu() still has a single caller: the
!CONFIG_PT_RECLAIM __tlb_remove_table_one() fallback. It was introduced
for that slow batch-allocation-failure path in 1fb3d8c20bfa
("mm/mmu_gather: replace IPI with synchronize_rcu() when batch
allocation fails"), replacing the previous tlb_remove_table_sync_one()
there.
So if pte_offset_map() readers really required a full RCU grace period
in that fallback path, that concern would already have existed before
1fb3d8c20bfa.
So we're safe here :)
[2] https://sashiko.dev/#/patchset/20260424062528.71951-1-lance.yang@linux.dev
> synchronize_rcu();
> }
>
>--
>2.49.0
>
>
^ permalink raw reply
* Re: [PATCH v2 1/3] vfio/pci: Set up bar resources and maps in vfio_pci_core_enable()
From: Matt Evans @ 2026-04-24 15:15 UTC (permalink / raw)
To: Alex Williamson
Cc: Kevin Tian, Jason Gunthorpe, Ankit Agrawal, Alistair Popple,
Leon Romanovsky, Kees Cook, Shameer Kolothum, Yishai Hadas,
Alexey Kardashevskiy, Eric Auger, Peter Xu, Vivek Kasireddy,
Zhi Wang, kvm, linux-kernel, virtualization
In-Reply-To: <20260423153053.6833135e@shazbot.org>
Hi Alex,
On 23/04/2026 22:30, Alex Williamson wrote:
>
> On Thu, 23 Apr 2026 11:25:07 -0700
> Matt Evans <mattev@meta.com> wrote:
>
>> Previously BAR resource requests and the corresponding pci_iomap()
>> were performed on-demand and without synchronisation, which was racy.
>> Rather than add synchronisation, it's simplest to address this by
>> doing both activities from vfio_pci_core_enable().
>>
>> The resource allocation and/or pci_iomap() can still fail; their
>> status is tracked and existing calls to vfio_pci_core_setup_barmap()
>> will fail in the same way as before. This keeps the point of failure
>> as observed by userspace the same, i.e. failures to request/map unused
>> BARs are benign.
>>
>> Fixes: 7f5764e179c6 ("vfio: use vfio_pci_core_setup_barmap to map bar in mmap")
>> Fixes: 0d77ed3589ac0 ("vfio/pci: Pull BAR mapping setup from read-write path")
>> Signed-off-by: Matt Evans <mattev@meta.com>
>> ---
>> drivers/vfio/pci/vfio_pci_core.c | 61 +++++++++++++++++++++++++++-----
>> drivers/vfio/pci/vfio_pci_rdwr.c | 29 ++++++---------
>> include/linux/vfio_pci_core.h | 1 +
>> 3 files changed, 64 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
>> index 3f8d093aacf8..c59c61861d81 100644
>> --- a/drivers/vfio/pci/vfio_pci_core.c
>> +++ b/drivers/vfio/pci/vfio_pci_core.c
>> @@ -482,6 +482,55 @@ static int vfio_pci_core_runtime_resume(struct device *dev)
>> }
>> #endif /* CONFIG_PM */
>>
>> +static void __vfio_pci_core_unmap_bars(struct vfio_pci_core_device *vdev)
>> +{
>> + struct pci_dev *pdev = vdev->pdev;
>> + int i;
>> +
>> + for (i = 0; i < PCI_STD_NUM_BARS; i++) {
>> + int bar = i + PCI_STD_RESOURCES;
>> +
>> + if (vdev->barmap[bar])
>> + pci_iounmap(pdev, vdev->barmap[bar]);
>> + if (vdev->have_bar_resource[bar])
>> + pci_release_selected_regions(pdev, 1 << bar);
>> + vdev->barmap[bar] = NULL;
>> + vdev->have_bar_resource[bar] = false;
>> + }
>> +}
>> +
>> +static void __vfio_pci_core_map_bars(struct vfio_pci_core_device *vdev)
>> +{
>> + struct pci_dev *pdev = vdev->pdev;
>> + int i;
>> +
>> + /*
>> + * Eager-request BAR resources, and iomap; soft failures are
>> + * allowed, and consumers must check before use.
>> + */
>
> I'd use this to describe that soft failures maintain compatible error
> signatures to previously used on-demand mapping.
Done.
>> + for (i = 0; i < PCI_STD_NUM_BARS; i++) {
>> + int ret;
>> + int bar = i + PCI_STD_RESOURCES;
>> + void __iomem *io;
>
> Reverse Christmas tree ordering.
Done.
>> +
>> + if (pci_resource_len(pdev, i) == 0)
>> + continue;
>> +
>> + ret = pci_request_selected_regions(pdev, 1 << bar, "vfio");
>> + if (ret) {
>> + pci_warn(vdev->pdev, "Failed to reserve region %d\n", bar);
>> + continue;
>> + }
>> + vdev->have_bar_resource[bar] = true;
>> +
>> + io = pci_iomap(pdev, bar, 0);
>> + if (io)
>> + vdev->barmap[bar] = io;
>> + else
>> + pci_warn(vdev->pdev, "Failed to iomap region %d\n", bar);
>> + }
>> +}
>
> I see you making the point in the cover letter about the resource
> request vs the iomap resource, but we currently handle these together.
> If either fails, setup barmap fails and the path returns error. I
> don't see any justification for now allowing the request resource to
> succeed but the iomap fails.
The primary effect was to let consumers see -EBUSY for a resource
reservation failure or -ENOMEM for an iomap failure (whether through
this patch's vfio_pci_core_setup_barmap() or the next patch's helpers),
and that keeps the error signatures identical.
A weak secondary effect was that a BAR that gets resource but fails for
whatever reason to iomap it can still be used by most clients (assuming
the general usage is to mmap). The system's pretty sick if this is the
case, so as I say it's weak.
OK, if you prefer the combined approach and don't feel the subsequent
single-semantic check helpers (need mapping, need resource) are clearer
to read then I'll recombine them, though:
- If vfio_pci_core_map_bars() just sets barmap[n] iff both resource
acquisition and iomap succeed, then a later check can only return one
error from either cause. I'll go with -ENOMEM unless you prefer -EBUSY.
Using something else can again make userspace see previously-unseen
error values.
- IMHO vfio_pci_core_setup_barmap() should still be renamed (in a 2nd
patch) since it doesn't do any setting up anymore. Cosmetic, but
cleaner to parse when the callers use vfio_pci_core_check_barmap_valid() no?
> These functions also don't need the double-underscore prefix.
Done.
>> +
>> /*
>> * The pci-driver core runtime PM routines always save the device state
>> * before going into suspended state. If the device is going into low power
>> @@ -568,6 +617,7 @@ int vfio_pci_core_enable(struct vfio_pci_core_device *vdev)
>> if (!vfio_vga_disabled() && vfio_pci_is_vga(pdev))
>> vdev->has_vga = true;
>>
>> + __vfio_pci_core_map_bars(vdev);
>>
>> return 0;
>>
>> @@ -591,7 +641,7 @@ void vfio_pci_core_disable(struct vfio_pci_core_device *vdev)
>> struct pci_dev *pdev = vdev->pdev;
>> struct vfio_pci_dummy_resource *dummy_res, *tmp;
>> struct vfio_pci_ioeventfd *ioeventfd, *ioeventfd_tmp;
>> - int i, bar;
>> + int i;
>>
>> /* For needs_reset */
>> lockdep_assert_held(&vdev->vdev.dev_set->lock);
>> @@ -646,14 +696,7 @@ void vfio_pci_core_disable(struct vfio_pci_core_device *vdev)
>>
>> vfio_config_free(vdev);
>>
>> - for (i = 0; i < PCI_STD_NUM_BARS; i++) {
>> - bar = i + PCI_STD_RESOURCES;
>> - if (!vdev->barmap[bar])
>> - continue;
>> - pci_iounmap(pdev, vdev->barmap[bar]);
>> - pci_release_selected_regions(pdev, 1 << bar);
>> - vdev->barmap[bar] = NULL;
>> - }
>> + __vfio_pci_core_unmap_bars(vdev);
>
> I expect this doesn't need to change if we drop the separation between
> resources and iomap.
OK, restored.
>> list_for_each_entry_safe(dummy_res, tmp,
>> &vdev->dummy_resources_list, res_next) {
>> diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
>> index 4251ee03e146..bf7152316db4 100644
>> --- a/drivers/vfio/pci/vfio_pci_rdwr.c
>> +++ b/drivers/vfio/pci/vfio_pci_rdwr.c
>> @@ -200,25 +200,18 @@ EXPORT_SYMBOL_GPL(vfio_pci_core_do_io_rw);
>>
>> int vfio_pci_core_setup_barmap(struct vfio_pci_core_device *vdev, int bar)
>> {
>> - struct pci_dev *pdev = vdev->pdev;
>> - int ret;
>> - void __iomem *io;
>> -
>> - if (vdev->barmap[bar])
>> - return 0;
>> -
>> - ret = pci_request_selected_regions(pdev, 1 << bar, "vfio");
>> - if (ret)
>> - return ret;
>> -
>> - io = pci_iomap(pdev, bar, 0);
>> - if (!io) {
>> - pci_release_selected_regions(pdev, 1 << bar);
>> + /*
>> + * The barmap is now always set up in vfio_pci_core_enable().
>
> "now" is going to read strangely very quickly.
Hm, yeah, fixed.
>> + * Some legacy callers use this function to ensure the BAR
>> + * resources are requested, and others to ensure the
>> + * pci_iomap() was done, so check here:
>> + */
>> + if (bar < 0 || bar >= PCI_STD_NUM_BARS)
>> + return -EINVAL;
>> + if (vdev->barmap[bar] == 0)
>> return -ENOMEM;
>> - }
>> -
>> - vdev->barmap[bar] = io;
>> -
>> + if (!vdev->bar_has_rsrc[bar])
>
> Typo, this won't incrementally compile. Thanks,
Fixed.
Alex, thanks for all your comments so far, I realise this is a pretty
noddy fix but it's good to get it clean.
Matt
>
> Alex
>
>> + return -EBUSY;
>> return 0;
>> }
>> EXPORT_SYMBOL_GPL(vfio_pci_core_setup_barmap);
>> diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h
>> index 2ebba746c18f..1f508b067d82 100644
>> --- a/include/linux/vfio_pci_core.h
>> +++ b/include/linux/vfio_pci_core.h
>> @@ -101,6 +101,7 @@ struct vfio_pci_core_device {
>> const struct vfio_pci_device_ops *pci_ops;
>> void __iomem *barmap[PCI_STD_NUM_BARS];
>> bool bar_mmap_supported[PCI_STD_NUM_BARS];
>> + bool have_bar_resource[PCI_STD_NUM_BARS];
>> u8 *pci_config_map;
>> u8 *vconfig;
>> struct perm_bits *msi_perm;
>
^ permalink raw reply
* Re: [PATCH 7.2 v10 2/2] x86/tlb: skip redundant sync IPIs for native TLB flush
From: Peter Zijlstra @ 2026-04-24 15:12 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, david, dave.hansen, dave.hansen, ypodemsk, hughd, will,
aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs, ziy,
baolin.wang, Liam.Howlett, npache, ryan.roberts, dev.jain, baohua,
shy828301, riel, jannh, jgross, seanjc, pbonzini, boris.ostrovsky,
virtualization, kvm, linux-arch, linux-mm, linux-kernel,
ioworker0
In-Reply-To: <20260424062528.71951-3-lance.yang@linux.dev>
On Fri, Apr 24, 2026 at 02:25:28PM +0800, Lance Yang wrote:
> diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
> index cfcb60468b01..2cf1eeaffd6f 100644
> --- a/arch/x86/hyperv/mmu.c
> +++ b/arch/x86/hyperv/mmu.c
> @@ -63,7 +63,7 @@ static void hyperv_flush_tlb_multi(const struct cpumask *cpus,
> struct hv_tlb_flush *flush;
> u64 status;
> unsigned long flags;
> - bool do_lazy = !info->freed_tables;
> + bool do_lazy = !info->wake_lazy_cpus;
>
> trace_hyperv_mmu_flush_tlb_multi(cpus, info);
>
> @@ -198,7 +198,7 @@ static u64 hyperv_flush_tlb_others_ex(const struct cpumask *cpus,
>
> flush->hv_vp_set.format = HV_GENERIC_SET_SPARSE_4K;
> nr_bank = cpumask_to_vpset_skip(&flush->hv_vp_set, cpus,
> - info->freed_tables ? NULL : cpu_is_lazy);
> + info->wake_lazy_cpus ? NULL : cpu_is_lazy);
> if (nr_bank < 0)
> return HV_STATUS_INVALID_PARAMETER;
>
> diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
> index 866ea78ba156..fb256fd95f95 100644
> --- a/arch/x86/include/asm/tlb.h
> +++ b/arch/x86/include/asm/tlb.h
> static inline void tlb_flush(struct mmu_gather *tlb)
> {
> unsigned long start = 0UL, end = TLB_FLUSH_ALL;
> unsigned int stride_shift = tlb_get_unmap_shift(tlb);
>
> + /*
> + * Both freed_tables and unshared_tables must wake lazy-TLB CPUs, so
> + * they receive IPIs before reusing or freeing page tables, allowing
> + * us to safely implement tlb_table_flush_implies_ipi_broadcast().
> + */
> + bool wake_lazy_cpus = tlb->freed_tables || tlb->unshared_tables;
> +
> if (!tlb->fullmm && !tlb->need_flush_all) {
> start = tlb->start;
> end = tlb->end;
> }
>
> - flush_tlb_mm_range(tlb->mm, start, end, stride_shift, tlb->freed_tables);
> + flush_tlb_mm_range(tlb->mm, start, end, stride_shift, wake_lazy_cpus);
> }
>
> static inline void invlpg(unsigned long addr)
> diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
> index 5a3cdc439e38..39b9454781c3 100644
> --- a/arch/x86/include/asm/tlbflush.h
> +++ b/arch/x86/include/asm/tlbflush.h
> @@ -225,7 +227,7 @@ struct flush_tlb_info {
> u64 new_tlb_gen;
> unsigned int initiating_cpu;
> u8 stride_shift;
> - u8 freed_tables;
> + u8 wake_lazy_cpus;
> u8 trim_cpumask;
> };
>
> @@ -315,7 +317,7 @@ static inline bool mm_in_asid_transition(struct mm_struct *mm) { return false; }
> extern void flush_tlb_all(void);
> extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
> unsigned long end, unsigned int stride_shift,
> - bool freed_tables);
> + bool wake_lazy_cpus);
> extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
>
> static inline void flush_tlb_page(struct vm_area_struct *vma, unsigned long a)
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 621e09d049cb..3ce254a3982c 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -1360,16 +1362,16 @@ STATIC_NOPV void native_flush_tlb_multi(const struct cpumask *cpumask,
> (info->end - info->start) >> PAGE_SHIFT);
>
> /*
> - * If no page tables were freed, we can skip sending IPIs to
> - * CPUs in lazy TLB mode. They will flush the CPU themselves
> - * at the next context switch.
> + * If lazy-TLB CPUs do not need to be woken, we can skip sending
> + * IPIs to them. They will flush themselves at the next context
> + * switch.
> *
> - * However, if page tables are getting freed, we need to send the
> - * IPI everywhere, to prevent CPUs in lazy TLB mode from tripping
> - * up on the new contents of what used to be page tables, while
> - * doing a speculative memory access.
> + * However, if page tables are getting freed or unshared, we need
> + * to send the IPI everywhere, to prevent CPUs in lazy TLB mode
> + * from tripping up on the new contents of what used to be page
> + * tables, while doing a speculative memory access.
> */
> - if (info->freed_tables || mm_in_asid_transition(info->mm))
> + if (info->wake_lazy_cpus || mm_in_asid_transition(info->mm))
> on_each_cpu_mask(cpumask, flush_tlb_func, (void *)info, true);
> else
> on_each_cpu_cond_mask(should_flush_tlb, flush_tlb_func,
> @@ -1402,7 +1404,7 @@ static DEFINE_PER_CPU(unsigned int, flush_tlb_info_idx);
>
> static struct flush_tlb_info *get_flush_tlb_info(struct mm_struct *mm,
> unsigned long start, unsigned long end,
> - unsigned int stride_shift, bool freed_tables,
> + unsigned int stride_shift, bool wake_lazy_cpus,
> u64 new_tlb_gen)
> {
> struct flush_tlb_info *info = this_cpu_ptr(&flush_tlb_info);
> @@ -1429,7 +1431,7 @@ static struct flush_tlb_info *get_flush_tlb_info(struct mm_struct *mm,
> info->end = end;
> info->mm = mm;
> info->stride_shift = stride_shift;
> - info->freed_tables = freed_tables;
> + info->wake_lazy_cpus = wake_lazy_cpus;
> info->new_tlb_gen = new_tlb_gen;
> info->initiating_cpu = smp_processor_id();
> info->trim_cpumask = 0;
> @@ -1448,7 +1450,7 @@ static void put_flush_tlb_info(void)
>
> void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
> unsigned long end, unsigned int stride_shift,
> - bool freed_tables)
> + bool wake_lazy_cpus)
> {
> struct flush_tlb_info *info;
> int cpu = get_cpu();
> @@ -1457,7 +1459,7 @@ void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
> /* This is also a barrier that synchronizes with switch_mm(). */
> new_tlb_gen = inc_mm_tlb_gen(mm);
>
> - info = get_flush_tlb_info(mm, start, end, stride_shift, freed_tables,
> + info = get_flush_tlb_info(mm, start, end, stride_shift, wake_lazy_cpus,
> new_tlb_gen);
>
> /*
This whole s/freed_tables/wake_lazy_cpus/ rename should probably be its
own patch, as should that include unshare_tables thing be.
That seems like unrelated changes.
^ permalink raw reply
* Re: [PATCH 7.2 v10 1/2] mm/mmu_gather: prepare to skip redundant sync IPIs
From: Peter Zijlstra @ 2026-04-24 15:04 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, david, dave.hansen, dave.hansen, ypodemsk, hughd, will,
aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs, ziy,
baolin.wang, Liam.Howlett, npache, ryan.roberts, dev.jain, baohua,
shy828301, riel, jannh, jgross, seanjc, pbonzini, boris.ostrovsky,
virtualization, kvm, linux-arch, linux-mm, linux-kernel,
ioworker0
In-Reply-To: <20260424062528.71951-2-lance.yang@linux.dev>
On Fri, Apr 24, 2026 at 02:25:27PM +0800, Lance Yang wrote:
> diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
> index 3985d856de7f..37a6a711c37e 100644
> --- a/mm/mmu_gather.c
> +++ b/mm/mmu_gather.c
> @@ -283,6 +283,14 @@ void tlb_remove_table_sync_one(void)
> * It is however sufficient for software page-table walkers that rely on
> * IRQ disabling.
> */
> +
> + /*
> + * Skip IPI if the preceding TLB flush already synchronized with
> + * all CPUs that could be doing software/lockless page table walks.
> + */
> + if (tlb_table_flush_implies_ipi_broadcast())
> + return;
> +
> smp_call_function(tlb_remove_table_smp_sync, NULL, 1);
> }
>
> @@ -312,6 +320,13 @@ static void tlb_remove_table_free(struct mmu_table_batch *batch)
> */
> void tlb_remove_table_sync_rcu(void)
> {
> + /*
> + * Skip RCU wait if the preceding TLB flush already synchronized
> + * with all CPUs that could be doing software/lockless page table walks.
> + */
> + if (tlb_table_flush_implies_ipi_broadcast())
> + return;
> +
> synchronize_rcu();
> }
So I don't like this at all.... The comment says there is a preceding
TLB flush, but there is nothing that guarantees there is. One would have
to go audit all users and ensure this is always true.
This thing is incredibly fragile.
Also, the comment in gup_fast() is nonsense, the local_irq_disable()
isn't about tlb_remove_table_sync_one(), it is primarily about TLBI
IPIs.
^ permalink raw reply
* [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen()
From: Deepanshu Kartikey @ 2026-04-24 15:03 UTC (permalink / raw)
To: mst, jasowang, xuanzhuo, eperezma, stefanha, sgarzare, davem,
edumazet, kuba, pabeni, horms
Cc: virtualization, kvm, netdev, linux-kernel, Deepanshu Kartikey,
syzbot+1b2c9c4a0f8708082678
Two bugs exist in virtio_transport_recv_listen():
1. On the transport assignment error path, sk_acceptq_added() is called
but sk_acceptq_removed() is never called when vsock_assign_transport()
fails or assigns a different transport than expected. This causes the
parent listener's accept backlog counter to be permanently inflated,
eventually causing sk_acceptq_is_full() to reject legitimate incoming
connections.
2. There is a race between __vsock_release() and vsock_enqueue_accept().
__vsock_release() sets sk->sk_shutdown to SHUTDOWN_MASK and flushes
the accept queue under the parent socket lock. However,
virtio_transport_recv_listen() checks sk_shutdown and subsequently
calls vsock_enqueue_accept() without holding the parent socket lock.
This means a child socket can be enqueued after __vsock_release() has
already flushed the queue, causing the child socket and its associated
resources to leak
permanently. The existing comment in the code hints at this race but
the fix was never implemented.
Fix both issues: add sk_acceptq_removed() on the transport error path,
and re-check sk->sk_shutdown under the parent socket lock before calling
vsock_enqueue_accept() to close the race window. The child socket lock
is released before acquiring the parent socket lock to maintain correct
lock ordering (parent before child).
Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
Tested-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
net/vmw_vsock/virtio_transport_common.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 416d533f493d..fad5fa4a4296 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -1578,6 +1578,7 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
*/
if (ret || vchild->transport != &t->transport) {
release_sock(child);
+ sk_acceptq_removed(sk);
virtio_transport_reset_no_sock(t, skb, sock_net(sk));
sock_put(child);
return ret;
@@ -1588,11 +1589,19 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
child->sk_write_space(child);
vsock_insert_connected(vchild);
+ release_sock(child);
+ lock_sock(sk);
+ if (sk->sk_shutdown == SHUTDOWN_MASK) {
+ release_sock(sk);
+ sk_acceptq_removed(sk);
+ virtio_transport_reset_no_sock(t, skb, sock_net(sk));
+ sock_put(child);
+ return -ESHUTDOWN;
+ }
vsock_enqueue_accept(sk, child);
+ release_sock(sk);
virtio_transport_send_response(vchild, skb);
- release_sock(child);
-
sk->sk_data_ready(sk);
return 0;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] drm/bochs: Drop manual put on probe error path
From: Thomas Zimmermann @ 2026-04-24 14:59 UTC (permalink / raw)
To: Myeonghun Pak
Cc: Gerd Hoffmann, Maarten Lankhorst, Maxime Ripard, David Airlie,
Simona Vetter, virtualization, dri-devel, linux-kernel
In-Reply-To: <CAGEsz8FrkbQEWZbxV3Q0NkSxhQka575uemKMQtTJQaCm44ByxQ@mail.gmail.com>
Hi
Am 24.04.26 um 15:40 schrieb Myeonghun Pak:
> Hi Thomas,
>
> Thank you for your reply. I will ensure that the requested |Fixes| tag
> and |stable| CC are included in the next patch I send.
>
> Regarding your request for information about AI usage and how the
> issue was identified:
>
> * This issue was identified during our ongoing static-analysis
> research while reviewing kernel code.
> 1
> <https://mail.google.com/mail/u/0/#all/%23thread-f:1863355320119932959>
> * Specifically, it was found by an experimental static analysis tool
> that we are currently developing. The tool is not public yet, so I
> prefer not to disclose further project details at this stage.
>
> * AI was used only for cross-review, not as the primary means of
> finding or fixing the bug.
> * I manually reviewed the code and verified the issue before sending
> the patch.
>
> I will incorporate your requests and this additional context, and then
> resend the modified patch.
Thanks a lot.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Best regards
Thomas
>
> Thank you.
>
> Myeonghun Pak
>
>
> 2026년 4월 24일 (금) 오후 10:25, Thomas Zimmermann
> <tzimmermann@suse.de>님이 작성:
>
> Hi,
>
> please add fixes tags to all these patches you're sending. You
> also need
> to CC stable so that they can be backported easily. Also list the AI
> you're using to find and create these patches.
>
> Best regards
> Thomas
>
> Am 24.04.26 um 14:34 schrieb Myeonghun Pak:
> > bochs_pci_probe() allocates the DRM device with
> devm_drm_dev_alloc(),
> > which registers a devres action to drop the initial DRM device
> reference
> > on driver detach or probe failure.
> >
> > The error path currently calls drm_dev_put() manually. If probe then
> > returns an error, devres will run the registered release action
> and put
> > the same device again, after the first put may already have
> released it.
> >
> > Return the probe error directly and let devres own the final put.
> >
> > Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> > ---
> > drivers/gpu/drm/tiny/bochs.c | 10 +++-------
> > 1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tiny/bochs.c
> b/drivers/gpu/drm/tiny/bochs.c
> > index 222e4ae1ab..5d8dc5efec 100644
> > --- a/drivers/gpu/drm/tiny/bochs.c
> > +++ b/drivers/gpu/drm/tiny/bochs.c
> > @@ -761,25 +761,21 @@ static int bochs_pci_probe(struct pci_dev
> *pdev, const struct pci_device_id *ent
> >
> > ret = pcim_enable_device(pdev);
> > if (ret)
> > - goto err_free_dev;
> > + return ret;
> >
> > pci_set_drvdata(pdev, dev);
> >
> > ret = bochs_load(bochs);
> > if (ret)
> > - goto err_free_dev;
> > + return ret;
> >
> > ret = drm_dev_register(dev, 0);
> > if (ret)
> > - goto err_free_dev;
> > + return ret;
> >
> > drm_client_setup(dev, NULL);
> >
> > return ret;
> > -
> > -err_free_dev:
> > - drm_dev_put(dev);
> > - return ret;
> > }
> >
> > static void bochs_pci_remove(struct pci_dev *pdev)
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
> <http://www.suse.com>
> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG
> Nürnberg)
>
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Pasha Tatashin @ 2026-04-24 14:40 UTC (permalink / raw)
To: Andrew Morton
Cc: David Hildenbrand (Arm), Pasha Tatashin, Lance Yang, peterz,
dave.hansen, dave.hansen, ypodemsk, hughd, will, aneesh.kumar,
npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs, ziy, baolin.wang,
Liam.Howlett, npache, ryan.roberts, dev.jain, baohua, shy828301,
riel, jannh, jgross, seanjc, pbonzini, boris.ostrovsky,
virtualization, kvm, linux-arch, linux-mm, linux-kernel,
ioworker0, roman.gushchin
In-Reply-To: <20260424073145.b990fe9b925da304508aad71@linux-foundation.org>
On 04-24 07:31, Andrew Morton wrote:
> On Fri, 24 Apr 2026 16:20:55 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
>
> > On 4/24/26 16:15, Andrew Morton wrote:
> > > On Fri, 24 Apr 2026 13:37:04 +0000 Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> > >
> > >> On 04-24 06:30, Andrew Morton wrote:
> > >>>
> > >>>
> > >>> Sashiko questions:
> > >>> https://sashiko.dev/#/patchset/20260424062528.71951-1-lance.yang@linux.dev
> > >>>
> > >>> (I never know if my Sashiko emails are welcome/useful. Maybe Sashiko
> > >>> said the same stuff about v9 and it's all wrong. But better safe than
> > >>> sorry!)
> > >>
> > >> These emails are helpful; but, I do not believe you should have to
> > >> manually follow up with a link to every new patch series.
> > >>
> > >> Perhaps Sashiko could automatically send a summary email in response to
> > >> the cover letter, or provide a link once the reviews are complete. For
> > >> the kexec ML, we opted-in with Roman to receive automated emails from
> > >> sashiko.
> > >
> > > Yep. I'd be OK with an automatic reply-to-all. Maybe some won't like
> > > that.
> > >
> > > An alternative I've discussed with Roman is an automated
> > > reply-to-author with a cc to a dedicated list (we could use mm-commits
> > > for now).
> > >
> > > Preferences?
> >
> > Reply-to-author would likely be better as a first step.
>
> Why do you think so?
>
> Pasha, is it too early to determine how reply-to-all is working out for
> kexec?
It is too early, we have opted-in only at the end of last week.
Pasha
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Andrew Morton @ 2026-04-24 14:31 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Pasha Tatashin, Lance Yang, peterz, dave.hansen, dave.hansen,
ypodemsk, hughd, will, aneesh.kumar, npiggin, tglx, mingo, bp,
x86, hpa, arnd, ljs, ziy, baolin.wang, Liam.Howlett, npache,
ryan.roberts, dev.jain, baohua, shy828301, riel, jannh, jgross,
seanjc, pbonzini, boris.ostrovsky, virtualization, kvm,
linux-arch, linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <80ab39c2-efb9-4a23-bd56-46d9bb4e41bb@kernel.org>
On Fri, 24 Apr 2026 16:20:55 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> On 4/24/26 16:15, Andrew Morton wrote:
> > On Fri, 24 Apr 2026 13:37:04 +0000 Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> >
> >> On 04-24 06:30, Andrew Morton wrote:
> >>>
> >>>
> >>> Sashiko questions:
> >>> https://sashiko.dev/#/patchset/20260424062528.71951-1-lance.yang@linux.dev
> >>>
> >>> (I never know if my Sashiko emails are welcome/useful. Maybe Sashiko
> >>> said the same stuff about v9 and it's all wrong. But better safe than
> >>> sorry!)
> >>
> >> These emails are helpful; but, I do not believe you should have to
> >> manually follow up with a link to every new patch series.
> >>
> >> Perhaps Sashiko could automatically send a summary email in response to
> >> the cover letter, or provide a link once the reviews are complete. For
> >> the kexec ML, we opted-in with Roman to receive automated emails from
> >> sashiko.
> >
> > Yep. I'd be OK with an automatic reply-to-all. Maybe some won't like
> > that.
> >
> > An alternative I've discussed with Roman is an automated
> > reply-to-author with a cc to a dedicated list (we could use mm-commits
> > for now).
> >
> > Preferences?
>
> Reply-to-author would likely be better as a first step.
Why do you think so?
Pasha, is it too early to determine how reply-to-all is working out for
kexec?
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: David Hildenbrand (Arm) @ 2026-04-24 14:20 UTC (permalink / raw)
To: Andrew Morton, Pasha Tatashin
Cc: Lance Yang, peterz, dave.hansen, dave.hansen, ypodemsk, hughd,
will, aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs,
ziy, baolin.wang, Liam.Howlett, npache, ryan.roberts, dev.jain,
baohua, shy828301, riel, jannh, jgross, seanjc, pbonzini,
boris.ostrovsky, virtualization, kvm, linux-arch, linux-mm,
linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <20260424071533.d28ce90126f05e1c6fc1b740@linux-foundation.org>
On 4/24/26 16:15, Andrew Morton wrote:
> On Fri, 24 Apr 2026 13:37:04 +0000 Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
>
>> On 04-24 06:30, Andrew Morton wrote:
>>>
>>>
>>> Sashiko questions:
>>> https://sashiko.dev/#/patchset/20260424062528.71951-1-lance.yang@linux.dev
>>>
>>> (I never know if my Sashiko emails are welcome/useful. Maybe Sashiko
>>> said the same stuff about v9 and it's all wrong. But better safe than
>>> sorry!)
>>
>> These emails are helpful; but, I do not believe you should have to
>> manually follow up with a link to every new patch series.
>>
>> Perhaps Sashiko could automatically send a summary email in response to
>> the cover letter, or provide a link once the reviews are complete. For
>> the kexec ML, we opted-in with Roman to receive automated emails from
>> sashiko.
>
> Yep. I'd be OK with an automatic reply-to-all. Maybe some won't like
> that.
>
> An alternative I've discussed with Roman is an automated
> reply-to-author with a cc to a dedicated list (we could use mm-commits
> for now).
>
> Preferences?
Reply-to-author would likely be better as a first step.
--
Cheers,
David
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox