* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Barry Song @ 2026-05-20 9:07 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Suren Baghdasaryan, Matthew Wilcox, akpm, linux-mm, david, liam,
vbabka, rppt, mhocko, jack, pfalcato, wanglian, chentao,
lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng,
nphamcs, bhe, youngjun.park, linux-arm-kernel, linux-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <ag1mk2DSJsiORaxK@lucifer>
On Wed, May 20, 2026 at 3:50 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
>
> On Wed, May 20, 2026 at 05:18:52AM +0800, Barry Song wrote:
> > On Tue, May 19, 2026 at 8:53 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> > >
> > > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
> > >
> > > > >
> > > > > I think we either need to fix `fork()`, or keep the current
> > > > > behavior of dropping the VMA lock before performing I/O.
> > > >
> > > > I see. So, this problem arises from the fact that we are changing the
> > > > pagefaults requiring I/O operation to hold VMA lock...
> > > > And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> > > > is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> > > > anonymous and COW VMAs only while holding mmap_write_lock, preventing
> > > > any VMA modification. On the surface, that looks ok to me but I might
> > > > be missing some corner cases. If nobody sees any obvious issues, I
> > > > think it's worth a try.
> > >
> > > Not sure if you noticed but I did raise concerns ;)
> > >
> > > I wonder if you've confused the fault path and fork here, as I think Barry has
> > > been a little unclear on that.
> >
> > I think I’ve been absolutely clear :-)
>
> On this point sure, I would argue less so around the fork stuff but I responded
> on that specifically elsewhere so let's keep things moving :>)
>
> > We should either stick to the current behavior - drop
> > the VMA lock before doing I/O, or change fork() so that it
> > does not wait on vma_start_write().
>
> Again, as I said elsewhere, I think there might be a 3rd way possibly. It's a
> big mistake to assume that there are only specific solutions to problems in the
> kernel then to present a false dichotomy.
I recalled that when we discussed this part in my slides:
‘For simplicity, rather than using a whitelist mechanism for
per-VMA retry, we could use a blacklist instead: default to
always retry via the VMA lock, and only allow mmap_lock-based
page-fault retry for specific cases such as
__vmf_anon_prepare().’
Suren mentioned introducing a FALLBACK flag. With the
FALLBACK flag, we would retry via mmap_lock; with the RETRY
flag, we would retry via the VMA lock.
Not sure whether this could really be called a ‘third way,’
but it seems more like a shift from a whitelist model to a
blacklist model, without changing the fundamental design, but
it does change where we would need to touch the source code.
>
> We absolutely hear you on this being a problem and it WILL be addressed one way
> or another.
Thanks. This is a bit of light in what has felt like a fairly
dark situation. I really appreciate your thoughtful and
responsible approach.
>
> Of the two approaches, as I said elsewhere, I prefer what you've done in this
> series to anything touching fork.
>
> But give me time to look through the series please (I'd also suggest RFC'ing
> when it's something kinda fundamental that might generate converastion, makes
> life a bit easier on the review side :)
Thanks! Sure, I’m happy to wait and there’s no urgency.
Last year you made quite a significant contribution to the work
when I tried to remove mmap_lock in madvise. I really
appreciated it. Now we’re back to the same lock again, just in
different places.
Best Regards
Barry
^ permalink raw reply
* Re: [PATCH] PCI/AER: Clear non-fatal errors on AER recovery failure
From: Lukas Wunner @ 2026-05-20 9:02 UTC (permalink / raw)
To: Yury M.; +Cc: bhelgaas, mahesh, oohall, linux-pci, linux-kernel, linuxppc-dev
In-Reply-To: <3633b587-5782-4cfa-b967-997de86866bb@arista.com>
On Tue, May 19, 2026 at 05:05:20PM +0100, Yury M. wrote:
> [ 476.224325] pci 0000:46:00.1: AER: can't recover (no error_detected callback)
> [ 476.224333] pci 0000:46:00.2: AER: can't recover (no error_detected callback)
> [ 476.224335] pci 0000:46:00.3: AER: can't recover (no error_detected callback)
> [ 476.224338] pci 0000:46:00.4: AER: can't recover (no error_detected callback)
> [ 476.224371] pcieport 0000:06:07.0: AER: device recovery failed
One more thing, recovery is failing here because those four devices
on bus 46 are unbound. I've got two patches under development to
allow error recovery for unbound devices. You may want to try those
and see if error recovery succeeds:
https://github.com/l1k/linux/commits/aer_unbound
Thanks,
Lukas
^ permalink raw reply
* Re: [PATCH resend] powerpc/code-patching: Avoid r/w mapping of the zero page
From: Christophe Leroy (CS GROUP) @ 2026-05-20 9:36 UTC (permalink / raw)
To: Ard Biesheuvel, linux-kernel
Cc: linuxppc-dev, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin
In-Reply-To: <20260520085423.485402-1-ardb@kernel.org>
Le 20/05/2026 à 10:54, Ard Biesheuvel a écrit :
> The only remaining use of map_patch_area() is mapping the zero page, and
> immediately unmapping it again so that the intermediate page table
> levels are all guaranteed to be populated.
>
> The use of the zero page here is completely arbitrary, and not harmful
> per se, but currently, it creates a writable mapping, and does so in a
> manner that requires that the empty_zero_page[] symbol is not
> const-qualified.
>
> Given that this is about to change, and that map_patch_area() now never
> maps anything other than the zero page, let's simplify the code and
> - take the PA of empty_zero_page directly
> - create a read-only temporary mapping.
>
> This allows empty_zero_page[] to be repainted as const u8[] in a
> subsequent patch, without making substantial changes to this code
> patching logic.
>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> Build tested only (Clang)
>
> Resending from my non-Google email. Apologies if you are receiving this
> twice.
>
> arch/powerpc/lib/code-patching.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
> index f84e0337cc02..13a8acf851f1 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -60,7 +60,7 @@ struct patch_context {
>
> static DEFINE_PER_CPU(struct patch_context, cpu_patching_context);
>
> -static int map_patch_area(void *addr, unsigned long text_poke_addr);
> +static int map_patch_area(unsigned long text_poke_addr);
> static void unmap_patch_area(unsigned long addr);
>
> static bool mm_patch_enabled(void)
> @@ -117,7 +117,7 @@ static int text_area_cpu_up(unsigned int cpu)
>
> // Map/unmap the area to ensure all page tables are pre-allocated
> addr = (unsigned long)area->addr;
> - err = map_patch_area(empty_zero_page, addr);
> + err = map_patch_area(addr);
I would get rid of map_patch_area() completely and just do:
err = map_kernel_page(addr, __pa_symbol(empty_zero_page), PAGE_KERNEL_RO);
By the way I don't know how vital it is to map in read-only but in case
it is see commit da3a3b0a0e38 ("powerpc/32s: map kasan zero shadow with
PAGE_READONLY instead of PAGE_KERNEL_RO")
> if (err)
> return err;
>
> @@ -236,11 +236,10 @@ static unsigned long get_patch_pfn(void *addr)
> /*
> * This can be called for kernel text or a module.
> */
> -static int map_patch_area(void *addr, unsigned long text_poke_addr)
> +static int map_patch_area(unsigned long text_poke_addr)
> {
> - unsigned long pfn = get_patch_pfn(addr);
> -
> - return map_kernel_page(text_poke_addr, (pfn << PAGE_SHIFT), PAGE_KERNEL);
> + return map_kernel_page(text_poke_addr, __pa_symbol(empty_zero_page),
> + PAGE_KERNEL_RO);
> }
>
> static void unmap_patch_area(unsigned long addr)
^ permalink raw reply
* Re: [PATCH resend] powerpc/code-patching: Avoid r/w mapping of the zero page
From: Ard Biesheuvel @ 2026-05-20 9:40 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), linux-kernel
Cc: linuxppc-dev, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin
In-Reply-To: <d4690d12-77d5-4575-9a79-484a919d3203@kernel.org>
On Wed, 20 May 2026, at 11:36, Christophe Leroy (CS GROUP) wrote:
> Le 20/05/2026 à 10:54, Ard Biesheuvel a écrit :
>> The only remaining use of map_patch_area() is mapping the zero page, and
>> immediately unmapping it again so that the intermediate page table
>> levels are all guaranteed to be populated.
>>
>> The use of the zero page here is completely arbitrary, and not harmful
>> per se, but currently, it creates a writable mapping, and does so in a
>> manner that requires that the empty_zero_page[] symbol is not
>> const-qualified.
>>
>> Given that this is about to change, and that map_patch_area() now never
>> maps anything other than the zero page, let's simplify the code and
>> - take the PA of empty_zero_page directly
>> - create a read-only temporary mapping.
>>
>> This allows empty_zero_page[] to be repainted as const u8[] in a
>> subsequent patch, without making substantial changes to this code
>> patching logic.
>>
>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Nicholas Piggin <npiggin@gmail.com>
>> Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> ---
>> Build tested only (Clang)
>>
>> Resending from my non-Google email. Apologies if you are receiving this
>> twice.
>>
>> arch/powerpc/lib/code-patching.c | 11 +++++------
>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
>> index f84e0337cc02..13a8acf851f1 100644
>> --- a/arch/powerpc/lib/code-patching.c
>> +++ b/arch/powerpc/lib/code-patching.c
>> @@ -60,7 +60,7 @@ struct patch_context {
>>
>> static DEFINE_PER_CPU(struct patch_context, cpu_patching_context);
>>
>> -static int map_patch_area(void *addr, unsigned long text_poke_addr);
>> +static int map_patch_area(unsigned long text_poke_addr);
>> static void unmap_patch_area(unsigned long addr);
>>
>> static bool mm_patch_enabled(void)
>> @@ -117,7 +117,7 @@ static int text_area_cpu_up(unsigned int cpu)
>>
>> // Map/unmap the area to ensure all page tables are pre-allocated
>> addr = (unsigned long)area->addr;
>> - err = map_patch_area(empty_zero_page, addr);
>> + err = map_patch_area(addr);
>
> I would get rid of map_patch_area() completely and just do:
>
> err = map_kernel_page(addr, __pa_symbol(empty_zero_page), PAGE_KERNEL_RO);
>
I think retaining the symmetry of map_patch_area() and unmap_patch_area()
makes sense too.
>
> By the way I don't know how vital it is to map in read-only but in case
> it is see commit da3a3b0a0e38 ("powerpc/32s: map kasan zero shadow with
> PAGE_READONLY instead of PAGE_KERNEL_RO")
>
In the end, it doesn't make any difference, given that the mapping is removed
again immediately. It is just neater to use _RO to map a const object, rather
than explicitly creating a read-write mapping of something that should really
never be written to.
^ permalink raw reply
* Re: [PATCH resend] powerpc/code-patching: Avoid r/w mapping of the zero page
From: Christophe Leroy (CS GROUP) @ 2026-05-20 9:59 UTC (permalink / raw)
To: Ard Biesheuvel, linux-kernel
Cc: linuxppc-dev, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin
In-Reply-To: <3e63e2eb-30b3-4377-9331-41445d9c8720@app.fastmail.com>
Le 20/05/2026 à 11:40, Ard Biesheuvel a écrit :
>
> On Wed, 20 May 2026, at 11:36, Christophe Leroy (CS GROUP) wrote:
>> Le 20/05/2026 à 10:54, Ard Biesheuvel a écrit :
>>> The only remaining use of map_patch_area() is mapping the zero page, and
>>> immediately unmapping it again so that the intermediate page table
>>> levels are all guaranteed to be populated.
>>>
>>> The use of the zero page here is completely arbitrary, and not harmful
>>> per se, but currently, it creates a writable mapping, and does so in a
>>> manner that requires that the empty_zero_page[] symbol is not
>>> const-qualified.
>>>
>>> Given that this is about to change, and that map_patch_area() now never
>>> maps anything other than the zero page, let's simplify the code and
>>> - take the PA of empty_zero_page directly
>>> - create a read-only temporary mapping.
>>>
>>> This allows empty_zero_page[] to be repainted as const u8[] in a
>>> subsequent patch, without making substantial changes to this code
>>> patching logic.
>>>
>>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>>> Cc: Nicholas Piggin <npiggin@gmail.com>
>>> Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>>> ---
>>> Build tested only (Clang)
>>>
>>> Resending from my non-Google email. Apologies if you are receiving this
>>> twice.
>>>
>>> arch/powerpc/lib/code-patching.c | 11 +++++------
>>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
>>> index f84e0337cc02..13a8acf851f1 100644
>>> --- a/arch/powerpc/lib/code-patching.c
>>> +++ b/arch/powerpc/lib/code-patching.c
>>> @@ -60,7 +60,7 @@ struct patch_context {
>>>
>>> static DEFINE_PER_CPU(struct patch_context, cpu_patching_context);
>>>
>>> -static int map_patch_area(void *addr, unsigned long text_poke_addr);
>>> +static int map_patch_area(unsigned long text_poke_addr);
>>> static void unmap_patch_area(unsigned long addr);
>>>
>>> static bool mm_patch_enabled(void)
>>> @@ -117,7 +117,7 @@ static int text_area_cpu_up(unsigned int cpu)
>>>
>>> // Map/unmap the area to ensure all page tables are pre-allocated
>>> addr = (unsigned long)area->addr;
>>> - err = map_patch_area(empty_zero_page, addr);
>>> + err = map_patch_area(addr);
>>
>> I would get rid of map_patch_area() completely and just do:
>>
>> err = map_kernel_page(addr, __pa_symbol(empty_zero_page), PAGE_KERNEL_RO);
>>
>
> I think retaining the symmetry of map_patch_area() and unmap_patch_area()
> makes sense too.
Could also drop unmap_patch_area() and use unmap_kernel_page() instead.
>
>>
>> By the way I don't know how vital it is to map in read-only but in case
>> it is see commit da3a3b0a0e38 ("powerpc/32s: map kasan zero shadow with
>> PAGE_READONLY instead of PAGE_KERNEL_RO")
>>
>
> In the end, it doesn't make any difference, given that the mapping is removed
> again immediately. It is just neater to use _RO to map a const object, rather
> than explicitly creating a read-write mapping of something that should really
> never be written to.
>
Ok
^ permalink raw reply
* Re: [PATCH] PCI/AER: Clear non-fatal errors on AER recovery failure
From: Yury M. @ 2026-05-20 10:00 UTC (permalink / raw)
To: Lukas Wunner
Cc: bhelgaas, mahesh, oohall, linux-pci, linux-kernel, linuxppc-dev
In-Reply-To: <ag10ON5pZ4ymPT9U@wunner.de>
On 5/20/26 09:43, Lukas Wunner wrote:
> No, is_error_source() considers bus number 0 as a bogus number
> and will iterate over all devices on the bus.
Right, if address is 0, is_error_source accepts any device with AER
error and returns 'true' for any device on a bus. But
when is_error_source reports 'true' for the first device on a bus, we
stop iterating in find_device_iter. We stop iterating if
"e_info->multi_error_valid == 0", that is our case. So, the error is
reported only for the first device on a bus.
On 5/20/26 10:02, Lukas Wunner wrote:
> One more thing, recovery is failing here because those four devices
> on bus 46 are unbound. I've got two patches under development to
> allow error recovery for unbound devices. You may want to try those
> and see if error recovery succeeds:
>
> https://github.com/l1k/linux/commits/aer_unbound
I believe that aer_unbound will fix our issue. I need some time to
confirm that the commit fixes our particular issue.
But I think that we still have an issue in the pcie_do_recovery
function. It is still possible that AER recovery will fail. The reason
could be different, and most of these cases should be investigated and
fixed. But until these issues are fixed and there is possibility that
AER recovery could fail, users should not experience the kind of issues
I described in this patch. For me, it looks better to do an AER error
cleanup even if AER recovery failed. We can add an error log with a
warning that we did the AER errors cleanup although AER recovery failed.
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-20 10:07 UTC (permalink / raw)
To: Barry Song
Cc: Suren Baghdasaryan, Matthew Wilcox, akpm, linux-mm, david, liam,
vbabka, rppt, mhocko, jack, pfalcato, wanglian, chentao,
lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng,
nphamcs, bhe, youngjun.park, linux-arm-kernel, linux-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAGsJ_4zN5ezh9vvvQDQdMF2KuuDGvkhNjTZWc0y0Lsa-P4Aahw@mail.gmail.com>
On Wed, May 20, 2026 at 05:07:16PM +0800, Barry Song wrote:
> On Wed, May 20, 2026 at 3:50 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > On Wed, May 20, 2026 at 05:18:52AM +0800, Barry Song wrote:
> > > On Tue, May 19, 2026 at 8:53 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> > > >
> > > > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
> > > >
> > > > > >
> > > > > > I think we either need to fix `fork()`, or keep the current
> > > > > > behavior of dropping the VMA lock before performing I/O.
> > > > >
> > > > > I see. So, this problem arises from the fact that we are changing the
> > > > > pagefaults requiring I/O operation to hold VMA lock...
> > > > > And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> > > > > is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> > > > > anonymous and COW VMAs only while holding mmap_write_lock, preventing
> > > > > any VMA modification. On the surface, that looks ok to me but I might
> > > > > be missing some corner cases. If nobody sees any obvious issues, I
> > > > > think it's worth a try.
> > > >
> > > > Not sure if you noticed but I did raise concerns ;)
> > > >
> > > > I wonder if you've confused the fault path and fork here, as I think Barry has
> > > > been a little unclear on that.
> > >
> > > I think I’ve been absolutely clear :-)
> >
> > On this point sure, I would argue less so around the fork stuff but I responded
> > on that specifically elsewhere so let's keep things moving :>)
> >
> > > We should either stick to the current behavior - drop
> > > the VMA lock before doing I/O, or change fork() so that it
> > > does not wait on vma_start_write().
> >
> > Again, as I said elsewhere, I think there might be a 3rd way possibly. It's a
> > big mistake to assume that there are only specific solutions to problems in the
> > kernel then to present a false dichotomy.
>
> I recalled that when we discussed this part in my slides:
>
> ‘For simplicity, rather than using a whitelist mechanism for
> per-VMA retry, we could use a blacklist instead: default to
> always retry via the VMA lock, and only allow mmap_lock-based
> page-fault retry for specific cases such as
> __vmf_anon_prepare().’
Yeah that's an itneresting approach actually, sorry if I missed that.
>
> Suren mentioned introducing a FALLBACK flag. With the
> FALLBACK flag, we would retry via mmap_lock; with the RETRY
> flag, we would retry via the VMA lock.
Yeah, and honestly I'm beginning to wonder if we don't just have to pay the
complexity tax anyway and eat the fact we have to deal with that.
But as per Josef's comment re: this whole mechanism, simply not waiting for
file-backed I think is another option (but I don't recall where we left that
conversation actually?)
Anyway I want to make sure any complexity we add is necessary so will take a
look through patches and have a think (and obviously others will have their own
opinions!)
>
> Not sure whether this could really be called a ‘third way,’
> but it seems more like a shift from a whitelist model to a
> blacklist model, without changing the fundamental design, but
> it does change where we would need to touch the source code.
Right yeah, good to have more options.
>
> >
> > We absolutely hear you on this being a problem and it WILL be addressed one way
> > or another.
>
> Thanks. This is a bit of light in what has felt like a fairly
> dark situation. I really appreciate your thoughtful and
> responsible approach.
Yes, sorry, I maybe was a bit too harsh in my tone here, I didn't really intend
to be negative as to addresisng the problem as a whole.
Moreso I've been concerned about the fork approach, and that is what's led to me
being shall we say 'emphatic' about it :)
But of course I sometimes make mistakes in quite how my tone comes across, so
apologies if it came across overly negatively - I am negative (on a technical
level) about the fork approach, but not the fact we should address this.
To be clear - I'm very glad you've brought this up, it's important, as much as
it's painful that we have this issue in the first place! :)
>
> >
> > Of the two approaches, as I said elsewhere, I prefer what you've done in this
> > series to anything touching fork.
> >
> > But give me time to look through the series please (I'd also suggest RFC'ing
> > when it's something kinda fundamental that might generate converastion, makes
> > life a bit easier on the review side :)
>
> Thanks! Sure, I’m happy to wait and there’s no urgency.
>
> Last year you made quite a significant contribution to the work
> when I tried to remove mmap_lock in madvise. I really
> appreciated it. Now we’re back to the same lock again, just in
> different places.
Yeah :) one day maybe we can get rid of it altogether (maybe I'm dreaming :)
>
> Best Regards
> Barry
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH resend] powerpc/code-patching: Avoid r/w mapping of the zero page
From: Ard Biesheuvel @ 2026-05-20 10:16 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), linux-kernel
Cc: linuxppc-dev, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin
In-Reply-To: <757318e3-91df-4e39-ba44-5130626d38b8@kernel.org>
On Wed, 20 May 2026, at 11:59, Christophe Leroy (CS GROUP) wrote:
> Le 20/05/2026 à 11:40, Ard Biesheuvel a écrit :
>>
>> On Wed, 20 May 2026, at 11:36, Christophe Leroy (CS GROUP) wrote:
>>> Le 20/05/2026 à 10:54, Ard Biesheuvel a écrit :
>>>> The only remaining use of map_patch_area() is mapping the zero page, and
>>>> immediately unmapping it again so that the intermediate page table
>>>> levels are all guaranteed to be populated.
>>>>
>>>> The use of the zero page here is completely arbitrary, and not harmful
>>>> per se, but currently, it creates a writable mapping, and does so in a
>>>> manner that requires that the empty_zero_page[] symbol is not
>>>> const-qualified.
>>>>
>>>> Given that this is about to change, and that map_patch_area() now never
>>>> maps anything other than the zero page, let's simplify the code and
>>>> - take the PA of empty_zero_page directly
>>>> - create a read-only temporary mapping.
>>>>
>>>> This allows empty_zero_page[] to be repainted as const u8[] in a
>>>> subsequent patch, without making substantial changes to this code
>>>> patching logic.
>>>>
>>>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>>>> Cc: Nicholas Piggin <npiggin@gmail.com>
>>>> Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
>>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>>>> ---
>>>> Build tested only (Clang)
>>>>
>>>> Resending from my non-Google email. Apologies if you are receiving this
>>>> twice.
>>>>
>>>> arch/powerpc/lib/code-patching.c | 11 +++++------
>>>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
>>>> index f84e0337cc02..13a8acf851f1 100644
>>>> --- a/arch/powerpc/lib/code-patching.c
>>>> +++ b/arch/powerpc/lib/code-patching.c
>>>> @@ -60,7 +60,7 @@ struct patch_context {
>>>>
>>>> static DEFINE_PER_CPU(struct patch_context, cpu_patching_context);
>>>>
>>>> -static int map_patch_area(void *addr, unsigned long text_poke_addr);
>>>> +static int map_patch_area(unsigned long text_poke_addr);
>>>> static void unmap_patch_area(unsigned long addr);
>>>>
>>>> static bool mm_patch_enabled(void)
>>>> @@ -117,7 +117,7 @@ static int text_area_cpu_up(unsigned int cpu)
>>>>
>>>> // Map/unmap the area to ensure all page tables are pre-allocated
>>>> addr = (unsigned long)area->addr;
>>>> - err = map_patch_area(empty_zero_page, addr);
>>>> + err = map_patch_area(addr);
>>>
>>> I would get rid of map_patch_area() completely and just do:
>>>
>>> err = map_kernel_page(addr, __pa_symbol(empty_zero_page), PAGE_KERNEL_RO);
>>>
>>
>> I think retaining the symmetry of map_patch_area() and unmap_patch_area()
>> makes sense too.
>
> Could also drop unmap_patch_area() and use unmap_kernel_page() instead.
>
Good point. That way, we'll end up with
arch/powerpc/lib/code-patching.c | 52 ++--------------------------------------
1 file changed, 2 insertions(+), 50 deletions(-
I'll spin a v2 with those changes once everyone on cc has had the opportunity
to chime in.
^ permalink raw reply
* Re: [PATCH v8 3/3] powerpc/pseries: PLPKS SED Opal keystore support
From: Dan Carpenter @ 2026-05-20 10:24 UTC (permalink / raw)
To: gjoyce
Cc: linux-block, axboe, linuxppc-dev, jonathan.derrick, brking,
msuchanek, mpe, nayna, akpm, ndesaulniers, nathan, jarkko,
okozina
In-Reply-To: <20231004201957.1451669-4-gjoyce@linux.vnet.ibm.com>
On Wed, Oct 04, 2023 at 03:19:57PM -0500, gjoyce@linux.vnet.ibm.com wrote:
> +int sed_read_key(char *keyname, char *key, u_int *keylen)
> +{
> + struct plpks_var var;
> + struct plpks_sed_object_data data;
> + int ret;
> + u_int len;
> +
> + plpks_init_var(&var, keyname);
> +
> + if (!plpks_sed_available)
> + return -EOPNOTSUPP;
> +
> + var.data = (u8 *)&data;
> + var.datalen = sizeof(data);
> +
> + ret = plpks_read_os_var(&var);
> + if (ret != 0)
> + return ret;
> +
> + len = min_t(u16, be32_to_cpu(data.key_len), var.datalen);
^^^^^^^^^^^
This isn't the correct limit. This is the number of bytes that we
copied into data. Probably it's sizeof(data) and, hopefully, it's
at least the offsetof(struct plpks_sed_object_data, key).
To me the temptation is the initialize data to zero and
s/var.datalen/sizeof(data.key)/.
> + memcpy(key, data.key, len);
^^^^^^^^
> + key[len] = '\0';
> + *keylen = len;
> +
> + return 0;
> +}
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: David Hildenbrand (Arm) @ 2026-05-20 10:33 UTC (permalink / raw)
To: Lorenzo Stoakes, Suren Baghdasaryan
Cc: Barry Song, Matthew Wilcox, akpm, linux-mm, liam, vbabka, rppt,
mhocko, jack, pfalcato, wanglian, chentao, lianux.mm, kunwu.chan,
liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <agxbq1TxJdniMQT3@lucifer>
On 5/19/26 14:53, Lorenzo Stoakes wrote:
> On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
>
>>>
>>> I think we either need to fix `fork()`, or keep the current
>>> behavior of dropping the VMA lock before performing I/O.
>>
>> I see. So, this problem arises from the fact that we are changing the
>> pagefaults requiring I/O operation to hold VMA lock...
>> And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
>> is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
>> anonymous and COW VMAs only while holding mmap_write_lock, preventing
>> any VMA modification. On the surface, that looks ok to me but I might
>> be missing some corner cases. If nobody sees any obvious issues, I
>> think it's worth a try.
>
> Not sure if you noticed but I did raise concerns ;)
>
> I wonder if you've confused the fault path and fork here, as I think Barry has
> been a little unclear on that.
>
> What's being suggested in this thread is to fundamentally change fork behaviour
> so it's different from the entire history of the kernel (or - presumably - at
> least recent history :)
I don't want fork() to become different in that regard.
There is already a slight difference with vs. without per-VMA locks, because
there is a window in-between us taking the write mmap_lock and all the per-VMA
locks. I raised that previously [1] and assumed that it is probably fine.
I also raised in the past why I think we must not allow concurrent page faults,
at least as soon as anonymous memory is involved [2].
... and I raised that this is pretty much slower by design right now: "Well, the
design decision that CONFIG_PER_VMA_LOCK made for now to make page faults fast
and to make blocking any page faults from happening to be slower ..." [3]
[1] https://lore.kernel.org/all/970295ab-e85d-7af3-76e6-df53a5c52f8b@redhat.com/
[2] https://lore.kernel.org/all/7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com/
[3] https://lore.kernel.org/all/2efa2c89-3765-721d-2c3c-00590054aa5b@redhat.com/
--
Cheers,
David
^ permalink raw reply
* [PATCH AUTOSEL 7.0-5.10] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec
From: Sasha Levin @ 2026-05-20 11:18 UTC (permalink / raw)
To: patches, stable
Cc: Sourabh Jain, Aboorva Devarajan, Ritesh Harjani (IBM),
Madhavan Srinivasan, Sasha Levin, mpe, linuxppc-dev, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Sourabh Jain <sourabhjain@linux.ibm.com>
[ Upstream commit 38e989d504fc52900a3786b7144fb53cd67e0389 ]
The kexec sequence invokes enter_vmx_ops() via copy_page() with the MMU
disabled. In this context, code must not rely on normal virtual address
translations or trigger page faults.
With KASAN enabled, functions get instrumented and may access shadow
memory using regular address translation. When executed with the MMU
off, this can lead to page faults (bad_page_fault) from which the
kernel cannot recover in the kexec path, resulting in a hang.
The kexec path sets preempt_count to HARDIRQ_OFFSET before entering
the MMU-off copy sequence.
current_thread_info()->preempt_count = HARDIRQ_OFFSET
kexec_sequence(..., copy_with_mmu_off = 1)
-> kexec_copy_flush(image)
copy_segments()
-> copy_page(dest, addr)
bl enter_vmx_ops()
if (in_interrupt())
return 0
beq .Lnonvmx_copy
Since kexec sets preempt_count to HARDIRQ_OFFSET, in_interrupt()
evaluates to true and enter_vmx_ops() returns early.
As in_interrupt() (and preempt_count()) are always inlined, mark
enter_vmx_ops() with __no_sanitize_address to avoid KASAN
instrumentation and shadow memory access with MMU disabled, helping
kexec boot fine with KASAN enabled.
Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260407124349.1698552-2-sourabhjain@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Record: subsystem `powerpc/vmx`; action verb `avoid`; intent is to
prevent KASAN instrumentation of `enter_vmx_ops()` when it is reached
from the kexec MMU-off copy path.
Record: tags parsed from the candidate message:
- `Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>`
- `Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>`
- `Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>`
- `Link: https://patch.msgid.link/20260407124349.1698552-2-
sourabhjain@linux.ibm.com`
- No `Fixes:` tag in this commit. Absence is not a negative signal.
Record: bug description from the message: `kexec_sequence()` may call
`copy_page()` with the MMU disabled; on PowerPC Book3S this can enter
`copypage_power7.S`, which calls `enter_vmx_ops()`. If KASAN instruments
`enter_vmx_ops()`, the instrumentation may access shadow memory using
normal virtual translation, which is invalid with MMU off and can cause
an unrecoverable `bad_page_fault`/hang in kexec.
Record: hidden bug fix: yes. Although phrased as “avoid
instrumentation,” this fixes a real boot/hang failure in the kexec/kdump
path under KASAN.
## Phase 2: Diff Analysis
Record: one file changed: `arch/powerpc/lib/vmx-helper.c`, with 8
insertions and 1 deletion in the fetched v3 patch. The only functional
change is changing `int enter_vmx_ops(void)` to `int
__no_sanitize_address enter_vmx_ops(void)`; the remaining additions are
explanatory comments.
Record: modified function: `enter_vmx_ops()`.
Record: before behavior: `enter_vmx_ops()` could be KASAN-instrumented.
During kexec with MMU off, the function first checks `in_interrupt()`
and should return `0`, but KASAN prologue/body instrumentation can run
before or around normal code and touch shadow memory.
Record: after behavior: `__no_sanitize_address` suppresses KASAN
instrumentation for this function, preserving the intended early return
path when `preempt_count` contains `HARDIRQ_OFFSET`.
Record: bug category: sanitizer/real-mode correctness bug causing kexec
hang. This is a crash/hang class fix, not a cleanup.
Record: fix quality: small, surgical, and low risk. It does not alter
normal logic, public API, data structures, or userspace-visible
behavior. The only behavioral effect is disabling KASAN instrumentation
for one helper that can run in an MMU-off path.
## Phase 3: Git History Investigation
Record: local `HEAD` is a stable release commit, not the candidate. `git
log --grep` on current history, `master`, and `power-next` did not find
the candidate commit locally, so there was no commit hash available for
`b4 dig -c`.
Record: `git blame` on current `arch/powerpc/lib/vmx-helper.c` shows the
unannotated `enter_vmx_ops()` present in the local tree; due this
repository’s history shape, blame attributes the original lines to a
merge/root history point, so the exact original introduction commit was
not verifiable locally.
Record: no candidate `Fixes:` tag to follow. The companion patch in the
same series has `Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address
sanitization in kexec paths")`; `git show` confirms that commit disabled
sanitization for PowerPC kexec real-mode paths in 2022.
Record: related recent local history: `6bc9c0a905228` changed VMX
usercopy flow and added export context around the same file. That
affects hunk context for older stable trees, but not the actual one-line
fix.
Record: author context: `git log --author="Sourabh Jain" --
arch/powerpc/...` shows multiple PowerPC kexec/crash/fadump commits.
`MAINTAINERS` lists Madhavan Srinivasan and Michael Ellerman as PowerPC
maintainers; Madhavan signed off the candidate.
Record: dependencies: no source-level prerequisite for the annotation
itself. Function `enter_vmx_ops()` and `__no_sanitize_address` exist in
checked stable tags. Functional completeness is best with the companion
patch fixing `KASAN_SANITIZE_core_$(BITS).o`, because review/test
discussion says both patches together make KASAN kexec succeed.
## Phase 4: Mailing List And External Research
Record: `b4 am` for message id
`20260407124349.1698552-2-sourabhjain@linux.ibm.com` fetched a v3 two-
patch series. It reported total patches: 2, current tree apply clean,
and DKIM signature valid for patch 2.
Record: `b4 am -c` checked for newer revisions and did not report a
newer v4. v3 appears to be the latest fetched revision.
Record: `b4 mbox` fetched the v3 thread. Patch 2 was addressed to
`linuxppc-dev` and CC’d PowerPC/kexec stakeholders including Michael
Ellerman, Madhavan Srinivasan, Mahesh Salgaonkar, Hari Bathini, Daniel
Axtens, Venkat Rao Bagalkote, Aboorva Devarajan, and Ritesh Harjani.
Record: `WebFetch` of lore URLs was blocked by Anubis, but `b4` and the
`yhbt.net` lore mirror provided the thread content.
Record: v2 review discussion verified:
- Ritesh Harjani reviewed patch 2 and said “LGTM,” granting `Reviewed-
by`.
- Aboorva Devarajan reported an actual KASAN-enabled kexec hang on
pseries PowerVM: system reached “kexec: Starting switchover sequence”
and then hung.
- Aboorva tested that “with both the patches applied, kexec completes
successfully with KASAN enabled.”
- v1 annotated both `enter_vmx_ops()` and `exit_vmx_ops()`; v2 removed
`exit_vmx_ops()` annotation and added the explanatory comment. This
shows review-driven narrowing of the fix.
Record: stable-specific discussion: Ritesh explicitly suggested `Cc:
stable@vger.kernel.org` for patch 1. I did not find a direct stable
nomination for patch 2, but patch 2 was reviewed and tested as part of
the same two-patch functional fix.
## Phase 5: Code Semantic Analysis
Record: modified function: `enter_vmx_ops()`.
Record: callers found by exact search:
- `arch/powerpc/lib/copypage_power7.S`
- `arch/powerpc/lib/memcpy_power7.S`
- `arch/powerpc/lib/memcmp_64.S`
Record: relevant kexec call chain verified in code:
`reboot(LINUX_REBOOT_CMD_KEXEC)` -> `kernel_kexec()` ->
`machine_kexec()` -> `default_machine_kexec()` -> `kexec_sequence()` ->
`kexec_copy_flush()` -> `copy_segments()` -> `copy_page()` ->
`copypage_power7.S` -> `enter_vmx_ops()`.
Record: key callees/logic in `enter_vmx_ops()`: `in_interrupt()`,
`preempt_disable()`, and `enable_kernel_altivec()`. In the kexec MMU-off
path, `default_machine_kexec()` sets
`current_thread_info()->preempt_count = HARDIRQ_OFFSET`, and
`include/linux/preempt.h` defines `in_interrupt()` via `irq_count()`,
which observes the hardirq bits.
Record: reachability: reachable from privileged kexec/kdump paths. It is
not unprivileged-user reachable, but kdump reliability is operationally
important.
Record: similar patterns: PowerPC already disables KASAN for sensitive
real-mode/interrupt code in multiple Makefiles and uses
`__no_sanitize_address` in PowerPC interrupt/stack code, so the
attribute is consistent with local practice.
## Phase 6: Cross-Referencing And Stable Tree Analysis
Record: buggy code exists in stable tags checked: `v5.4`, `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.18`, `v6.19`, and `v7.0` all have
`enter_vmx_ops()` without `__no_sanitize_address`.
Record: the kexec `copy_segments()` -> `copy_page()` path and
`preempt_count = HARDIRQ_OFFSET` were verified in `v5.4`, `v5.10`,
`v5.15`, `v6.1`, and current/v7.0-era code.
Record: `copypage_power7.S` calls `enter_vmx_ops()` in `v5.4`, `v5.10`,
`v5.15`, and current code.
Record: `__no_sanitize_address` exists in compiler headers in checked
stable tags, including `v5.4`, `v5.10`, `v6.1`, `v6.6`, and current.
Record: backport difficulty: clean on current `7.0.y` per `git apply
--check` and `b4`. Older stable trees may need a tiny context adjustment
because `EXPORT_SYMBOL(exit_vmx_usercopy)` is not present in older
versions, but the actual function signature is present and the backport
is straightforward.
Record: related fixes already in stable: not verified as already
present; local stable tags checked do not contain the candidate
annotation.
## Phase 7: Subsystem And Maintainer Context
Record: subsystem is PowerPC architecture library/kexec path:
`arch/powerpc/lib` and `arch/powerpc/kexec`.
Record: criticality: important/platform-specific. It affects PowerPC
systems using kexec/kdump with KASAN enabled, especially pseries/PowerVM
cases verified in review. It is not universal across all architectures.
Record: subsystem activity: local history shows recent PowerPC VMX
usercopy and kexec/crash/fadump activity, and the patch was handled
through the PowerPC maintainer path.
## Phase 8: Impact And Risk Assessment
Record: affected users: PowerPC Book3S/PowerVM-style systems using
kexec/kdump with KASAN-enabled kernels and VMX copy paths.
Record: trigger conditions: kexec/kdump switchover, MMU-off copy path,
KASAN enabled, and `copy_page()` selecting the Power7 VMX copy path. The
triggering operation is privileged, but the failure impacts crash dump
capture and reboot into the new kernel.
Record: failure mode: system hang during kexec/kdump. Review discussion
includes an observed hang after “kexec: Starting switchover sequence,”
and the commit message explains unrecoverable `bad_page_fault` risk with
MMU off. Severity: HIGH to CRITICAL for affected debug/crash-dump
deployments.
Record: benefit: high for affected PowerPC KASAN/kdump users because it
prevents a hard hang and restores kexec completion.
Record: risk: very low. One function annotation plus comment; no logic
change. The main concern is that stable maintainers should also take the
companion Makefile fix for full KASAN/kexec coverage.
## Phase 9: Final Synthesis
Record: evidence for backporting:
- Fixes a real, reviewed, and tested kexec hang with KASAN enabled.
- Aboorva Devarajan reported and tested the failure/fix.
- Ritesh Harjani reviewed the final approach.
- The fix is one function attribute and explanatory comment.
- It affects a serious operational path: kexec/kdump boot into a
new/capture kernel.
- The buggy code and call path exist across active stable versions
checked.
- Backport is clean for current `7.0.y` and trivial for older stable
trees.
Record: evidence against backporting:
- The issue is config/platform specific: PowerPC plus KASAN plus
kexec/kdump plus VMX copy path.
- Older stable trees may require minor context adjustment.
- The commit is part of a two-patch series; the companion Makefile KASAN
fix should be included for the tested complete fix.
Record: unresolved questions:
- Exact original introduction commit for `enter_vmx_ops()` could not be
verified from local history.
- Direct lore `WebFetch` was blocked by Anubis; I used `b4` and a lore
mirror instead.
- I did not build-test the backport.
Stable rules checklist:
1. Obviously correct and tested: yes. The annotation directly suppresses
KASAN instrumentation on the one helper that can execute with MMU
off; tested-by is present.
2. Fixes a real bug: yes. Review discussion reports an actual kexec hang
with KASAN.
3. Important issue: yes. Failure mode is kexec/kdump hang.
4. Small and contained: yes. One file, one function annotation.
5. No new features/APIs: yes.
6. Can apply to stable: yes for current `7.0.y`; older trees may need
trivial context adjustment.
Exception category: not a device ID/quirk/build/doc exception. It is a
normal stability fix.
## Verification
- [Phase 1] Parsed the supplied commit message and fetched patch mbox;
confirmed tags, no `Fixes:` tag in patch 2, and the linked message id.
- [Phase 2] Inspected fetched v3 diff; confirmed `arch/powerpc/lib/vmx-
helper.c` has 8 insertions and 1 deletion, changing only
`enter_vmx_ops()`.
- [Phase 3] Ran `git log --grep` on current history, `master`, and
`power-next`; candidate not present locally.
- [Phase 3] Ran `git blame` around `enter_vmx_ops()`; local history
could not identify true original introduction beyond repository
history shape.
- [Phase 3] Ran `git show 2ab2d5794f14`; confirmed related PowerPC kexec
KASAN sanitization commit from 2022.
- [Phase 4] Ran `b4 am` and `b4 am -c`; fetched v3 two-patch series, no
newer revision reported, patch 2 DKIM valid.
- [Phase 4] Ran `b4 mbox`; confirmed original recipients and patch
content.
- [Phase 4] Used lore mirror for v2 thread; confirmed Ritesh review,
Aboorva tested-by/reported hang, and v1-to-v2 narrowing.
- [Phase 5] Searched call sites; confirmed `copypage_power7.S`,
`memcpy_power7.S`, and `memcmp_64.S` call `enter_vmx_ops()`.
- [Phase 5] Read kexec and assembly code; confirmed kexec path reaches
`copy_page()` with MMU-off logic and `preempt_count = HARDIRQ_OFFSET`.
- [Phase 6] Checked stable tags `v5.4` through `v7.0`; confirmed
`enter_vmx_ops()` exists without the annotation and the relevant
kexec/copy path exists in checked trees.
- [Phase 6] Ran `git apply --check` on current tree for patch 2 and the
series; clean on current `7.0.y`.
- [Phase 7] Checked `MAINTAINERS`; confirmed PowerPC maintainers and
that Madhavan Srinivasan is listed for PowerPC.
- [Phase 8] Verified failure mode from review discussion: KASAN-enabled
kexec hangs after switchover; with both patches applied, kexec
completes.
This should be backported, ideally together with the companion
`powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o` patch
for the tested complete KASAN/kexec fix.
**YES**
arch/powerpc/lib/vmx-helper.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/vmx-helper.c b/arch/powerpc/lib/vmx-helper.c
index 554b248002b4f..57e897b60db86 100644
--- a/arch/powerpc/lib/vmx-helper.c
+++ b/arch/powerpc/lib/vmx-helper.c
@@ -52,7 +52,14 @@ int exit_vmx_usercopy(void)
}
EXPORT_SYMBOL(exit_vmx_usercopy);
-int enter_vmx_ops(void)
+/*
+ * Can be called from kexec copy_page() path with MMU off. The kexec
+ * code sets preempt_count to HARDIRQ_OFFSET so we return early here.
+ * Since in_interrupt() is always inline, __no_sanitize_address on this
+ * function is sufficient to avoid KASAN shadow memory accesses in real
+ * mode.
+ */
+int __no_sanitize_address enter_vmx_ops(void)
{
if (in_interrupt())
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] powerpc/g5: Enable all windfarms by default
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Linus Walleij, Madhavan Srinivasan, Sasha Levin, mpe,
linuxppc-dev, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Linus Walleij <linusw@kernel.org>
[ Upstream commit 8d57bb61734b23f6342e9de781173f1d83f90d3a ]
The G5 defconfig is clearly intended for the G5 Powermac
series, and that should enable all the available
windfarm drivers, or the machine will overheat a short
while after booting and shut itself down, which is
annoying.
Signed-off-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260505-powermac-g5-config-v3-1-7747bf72f874@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `powerpc/g5`; action verb `Enable`; intent: enable
all existing windfarm thermal drivers in `g5_defconfig`.
Record 1.2: Tags found: `Signed-off-by: Linus Walleij
<linusw@kernel.org>`, `Signed-off-by: Madhavan Srinivasan
<maddy@linux.ibm.com>`, `Link: https://patch.msgid.link/20260505-
powermac-g5-config-v3-1-7747bf72f874@kernel.org`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.
Record 1.3: The body says G5 machines using this defconfig may overheat
shortly after boot and shut down if not all windfarm drivers are
enabled. Root cause: the G5 defconfig enables some, but not all, G5
windfarm thermal control drivers.
Record 1.4: This is a hidden bug fix despite “Enable” wording: it
changes default configuration to include missing existing thermal-
management drivers, preventing hardware overheat shutdown.
## Phase 2: Diff Analysis
Record 2.1: One file changed: `arch/powerpc/configs/g5_defconfig`,
`+2/-0`. No functions modified. Scope: single-file surgical defconfig
fix.
Record 2.2: Before: `g5_defconfig` enabled `WINDFARM_PM81`, `PM91`,
`PM112`, and `PM121`, but omitted `PM72` and `RM31`. After: it also
enables `CONFIG_WINDFARM_PM72=y` and `CONFIG_WINDFARM_RM31=y`.
Record 2.3: Bug category: hardware/default-config correctness fix.
Mechanism: builds in already-existing thermal control drivers for
PowerMac7,2/7,3 and RackMac3,1 systems.
Record 2.4: Fix quality is high: two config lines, no API change, no
code refactor. Regression risk is low because the enabled drivers check
machine compatibility and return `-ENODEV` on nonmatching hardware.
## Phase 3: Git History Investigation
Record 3.1: Blame shows surrounding windfarm entries came from
`2c39bf49fd0530` in 2012, while PM72/RM31 drivers were introduced by
`6cd320996746` and are present from v3.5. Checked v3.5, v3.6, v4.0,
v5.4, v5.10: the defconfig omitted PM72/RM31.
Record 3.2: No `Fixes:` tag, so no Fixes target to follow.
Record 3.3: Recent `g5_defconfig` history is mostly defconfig
maintenance and symbol removals; no prerequisite patch was identified.
The mailed patch is a one-patch series.
Record 3.4: Linus Walleij is an established kernel
maintainer/contributor, though not listed as PowerPC maintainer. The
patch was acked by Michael Ellerman in-thread and applied by Madhavan
Srinivasan, both PowerPC maintainers per `MAINTAINERS`.
Record 3.5: Dependencies are existing Kconfig symbols and are satisfied.
`make ARCH=powerpc g5_defconfig` on the candidate produced
`CONFIG_WINDFARM_PM72=y`, `CONFIG_WINDFARM_RM31=y`, and `CONFIG_I2C=y`.
## Phase 4: Mailing List And External Research
Record 4.1: `b4 am` found the v3 submission and three revisions: v1, v2,
v3. `b4 dig` matched the patch-id and found lore/patch.msgid links.
Direct `WebFetch` to lore was blocked by Anubis, but `b4 mbox`
downloaded the full v3 thread.
Record 4.2: `b4 dig -w` showed the patch was sent to Madhavan
Srinivasan, Michael Ellerman, Nicholas Piggin, Christophe Leroy,
`linuxppc-dev`, and `linux-kernel`.
Record 4.3: No separate bug report link was present. Thread evidence
confirms impact: Segher Boessenkool wrote that affected machines boot
but “won’t run for even a minute”; Linus said Debian likely works by
having the driver in initramfs/rootfs and that built-in is safer.
Record 4.4: Series context: same two-line patch rebased from v1 to v3,
no multi-patch dependency.
Record 4.5: Web search found no stable-list discussion for this exact
patch. No known stable objection found.
## Phase 5: Code Semantic Analysis
Record 5.1: No functions changed. Relevant enabled init functions are
`wf_pm72_init()` and `wf_rm31_init()`.
Record 5.2: These init functions are run at boot/module init when built.
`windfarm_core_init()` registers the `windfarm` platform device.
Record 5.3: `wf_pm72_init()` checks `PowerMac7,2`/`PowerMac7,3`;
`wf_rm31_init()` checks `RackMac3,1`; both register a platform driver
only after compatibility checks.
Record 5.4: Reachability is boot-time on affected hardware using
`g5_defconfig`, not syscall-triggered. The failure mode is hardware
thermal shutdown, not userspace API behavior.
Record 5.5: Similar pattern already exists in the same defconfig for
other G5 windfarm drivers (`PM81`, `PM91`, `PM112`, `PM121`).
## Phase 6: Stable Tree Analysis
Record 6.1: Checked v5.10, v5.15, v6.1, v6.6, v6.12, v6.18, v6.19, and
v7.0 tags: the buggy omission exists and the PM72/RM31 Kconfig symbols
exist.
Record 6.2: Generated patch applied cleanly to all checked tags: v5.10
through v7.0.
Record 6.3: Checked those tags for the exact subject; no related fix
already present.
## Phase 7: Subsystem Context
Record 7.1: Subsystem: PowerPC defconfig / Power Macintosh thermal
management. Criticality: platform-specific but important for affected
hardware because thermal control is required for safe operation.
Record 7.2: `drivers/macintosh` has low-to-moderate activity, mostly
treewide cleanups and small fixes; PowerMac is marked orphan, while
broader PowerPC is supported.
## Phase 8: Impact And Risk
Record 8.1: Affected users: PowerMac G5 AGP systems (`PowerMac7,2`,
`PowerMac7,3`) and Xserve G5 (`RackMac3,1`) using kernels built from
`g5_defconfig`.
Record 8.2: Trigger: booting affected hardware with the default G5
config lacking the built-in thermal driver. Not unprivileged-user-
triggered.
Record 8.3: Failure mode: overheating followed by shutdown shortly after
boot. Severity: CRITICAL for affected hardware availability and hardware
safety.
Record 8.4: Benefit is high for affected stable users; risk is very low:
two defconfig lines, existing drivers, clean applies, machine-specific
init guards.
## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: fixes real hardware thermal
shutdown; two-line contained patch; existing drivers; dependencies
verified; applies cleanly to checked stable tags; maintainer
ack/application in PowerPC fixes. Evidence against: affects only niche
old hardware; no explicit `Cc: stable` or `Tested-by`. No unresolved
technical blockers.
Record 9.2: Stable rules: obviously correct: yes; tested: config
generation verified, no runtime `Tested-by`; real bug: yes; important
issue: yes, overheating/shutdown; small/contained: yes; no new
API/features: yes, only enables existing drivers in defconfig; applies
to stable: yes for checked tags.
Record 9.3: Exception category: closest match is hardware-support/config
fix for existing drivers, not new driver code.
Record 9.4: Decision: backport. This is a small, low-risk default-config
fix for a severe hardware failure mode.
## Verification
- Phase 1: Parsed tags from supplied commit and b4-fetched mbox.
- Phase 2: Verified diff is `+2/-0` in
`arch/powerpc/configs/g5_defconfig`.
- Phase 3: Used `git blame`, `git log`, and `git show`; found PM72/RM31
drivers introduced by `6cd320996746`, present since v3.5.
- Phase 4: Used `b4 am`, `b4 dig`, `b4 dig -w`, `b4 mbox`; full thread
shows Michael Ellerman ack and Madhavan Srinivasan applied it to
`powerpc/fixes`.
- Phase 5: Read `drivers/macintosh/Kconfig`, `Makefile`,
`windfarm_pm72.c`, `windfarm_rm31.c`, and `windfarm_core.c`; verified
machine-specific guards and boot/init path.
- Phase 6: Checked v5.10, v5.15, v6.1, v6.6, v6.12, v6.18, v6.19, v7.0
for symbol presence and clean patch application.
- Phase 8: Failure mode verified from commit text and mailing-list
thread; no independent runtime test performed here.
**YES**
arch/powerpc/configs/g5_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 428f17b455132..2fe8ca266b5f6 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -85,6 +85,8 @@ CONFIG_PMAC_SMU=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_WINDFARM=y
CONFIG_WINDFARM_PM81=y
+CONFIG_WINDFARM_PM72=y
+CONFIG_WINDFARM_RM31=y
CONFIG_WINDFARM_PM91=y
CONFIG_WINDFARM_PM112=y
CONFIG_WINDFARM_PM121=y
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.1] powerpc/pasemi: Drop redundant res assignment
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Krzysztof Kozlowski, Madhavan Srinivasan, Sasha Levin, mpe,
linuxppc-dev, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
[ Upstream commit f583bd5f64d40e083dde5bb22846c4d93e59d471 ]
Return value of pas_add_bridge() is not used, so code can be simplified
to fix W=1 clang warnings:
arch/powerpc/platforms/pasemi/pci.c:275:6: error: variable 'res' set but not used [-Werror,-Wunused-but-set-variable]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260317130823.240279-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record 1.1: Subsystem `powerpc/pasemi`; action verb `Drop`; intent is to
remove an unused local variable assignment in PA Semi PCI init.
Record 1.2: Tags found: `Signed-off-by: Krzysztof Kozlowski`, `Signed-
off-by: Madhavan Srinivasan`, `Link: https://patch.msgid.link/2026031713
0823.240279-4-krzysztof.kozlowski@oss.qualcomm.com`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.
Record 1.3: The commit explicitly describes a Clang `W=1` build warning
promoted to an error: `variable 'res' set but not used
[-Werror,-Wunused-but-set-variable]`. No runtime symptom, crash, data
corruption, or user-visible functional failure is described.
Record 1.4: This is not a hidden runtime bug fix. It is a build-warning
cleanup that can matter when building powerpc with warning-as-error
settings.
### Phase 2: Diff Analysis
Record 2.1: One file changed: `arch/powerpc/platforms/pasemi/pci.c`, `1
insertion(+), 2 deletions(-)`. Only `pas_pci_init()` is modified. Scope
is single-file surgical.
Record 2.2: Before: `pas_pci_init()` declared `int res;` and assigned
`res = pas_add_bridge(np);`, then never read `res`. After: it still
calls `pas_add_bridge(np);` but does not assign the return value. The
execution path and side effects are unchanged.
Record 2.3: Bug category: build warning/build error under specific
compiler options. Mechanism: remove unused-but-set variable. No resource
lifetime, locking, memory safety, reference counting, or logic behavior
changes.
Record 2.4: Fix quality is obviously correct by inspection: the function
call remains, only the unused local storage is removed. Regression risk
is very low because runtime behavior is unchanged.
### Phase 3: Git History Investigation
Record 3.1: `git blame` on current stable code shows the exact changed
lines are present in the checked-out stable tree. Deeper history shows
the unused `res` assignment was introduced by `250a93501d626`
(`powerpc/pasemi: Search for PCI root bus by compatible property`),
first described by `git describe` as `v4.19-rc1~110^2~83`.
Record 3.2: No `Fixes:` tag is present. Manual history identified
`250a93501d626` as the introducing commit for the exact unused
assignment pattern.
Record 3.3: Recent file history shows only the candidate commit and
unrelated treewide allocation changes in `next-20260508`; no
prerequisite pasemi PCI refactor was found.
Record 3.4: The author has other powerpc cleanup commits nearby,
including the sibling PS3 warning fix. `MAINTAINERS` identifies Madhavan
Srinivasan and Michael Ellerman as powerpc maintainers; Madhavan
committed this patch.
Record 3.5: The sibling commit `8333e4916040e` is part of the same
cleanup series but is independent. This pasemi patch applies standalone
to the current 7.0.5 checkout.
### Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c f583bd5f64d40` found the original submission by
patch-id. It found the January submission and the March resend
corresponding to the commit `Link:`. Direct WebFetch to
lore/patch.msgid.link was blocked by Anubis.
Record 4.2: `b4 dig -w` showed appropriate powerpc maintainers and
LLVM/compiler-warning stakeholders were copied: Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy, Nathan Chancellor,
LLVM list, linuxppc-dev, and others.
Record 4.3: No bug report link or reporter tag exists. The thread
describes a compiler warning/build-cleanliness issue, not a runtime bug
report.
Record 4.4: The patch is part of a two-patch series with `powerpc/ps3:
Drop redundant result assignment`; the other patch is the same class of
cleanup and is not a dependency.
Record 4.5: The downloaded thread contains no `stable` mention. A direct
lore stable search was attempted but blocked by Anubis, so no stable-
list archive result could be independently verified.
### Phase 5: Code Semantic Analysis
Record 5.1: Modified function: `pas_pci_init()`.
Record 5.2: Callers: `pas_pci_init()` is assigned to `.discover_phbs` in
the PA Semi machine descriptor in
`arch/powerpc/platforms/pasemi/setup.c`. `pas_add_bridge()` is static
and, in `next-20260508`, is called only from `pas_pci_init()`.
Record 5.3: Relevant callees in the affected path include
`pci_set_flags()`, `of_find_compatible_node()`, `pas_add_bridge()`, and
`of_node_put()`. `pas_add_bridge()` allocates/configures the PCI
controller and scans OF ranges/ISA bridge state.
Record 5.4: Reachability is boot-time/platform-init only for PA Semi
systems. It is not syscall-reachable and has no unprivileged runtime
trigger.
Record 5.5: Similar pattern found: sibling commit `8333e4916040e`
removes an unused assignment in PS3 platform code for the same warning
class.
### Phase 6: Stable Tree Analysis
Record 6.1: The exact unused `res = pas_add_bridge(np);` pattern exists
in verified tags `v4.19`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.17`, `v6.18`, `v6.19`, and `v7.0`. It was not present in the same
form in `v4.14` or `v4.9`.
Record 6.2: Backport difficulty is clean for the current 7.0.5 tree,
verified by `git format-patch -1 --stdout f583bd5f64d40 | git apply
--check`. Older stable trees may need minor context adjustment because
surrounding code differs in older releases.
Record 6.3: No earlier same-subject fix exists in `v7.0`; related same-
series warning fixes were found only in `next-20260508`.
### Phase 7: Subsystem Context
Record 7.1: Subsystem is `arch/powerpc/platforms/pasemi`, a platform-
specific powerpc PCI init path. Criticality is peripheral/platform-
specific, not core kernel.
Record 7.2: Recent pasemi file history is low churn. This is mature
platform code with little recent activity.
### Phase 8: Impact And Risk
Record 8.1: Affected population: PA Semi powerpc platform builders,
especially Clang `W=1` builds with powerpc `-Werror` behavior.
Record 8.2: Trigger condition is build-time only. No runtime trigger and
no unprivileged-user trigger were verified.
Record 8.3: Failure mode is build failure under specific warning/error
settings, not crash/corruption/deadlock. Severity is medium for affected
builders, low for runtime users.
Record 8.4: Benefit is narrow but real under the stable build-fix
exception. Risk is extremely low because the generated runtime behavior
should be unchanged: the same function call remains and only an unused
local assignment is removed.
### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: fixes a verified compiler
warning/error class; code exists across many stable-era releases; patch
is tiny, standalone, and behavior-preserving; applies cleanly to current
stable checkout. Evidence against: no runtime bug, no default-build
failure was verified, no stable nomination, platform-specific impact.
Unresolved: direct stable lore search was blocked, and I did not run a
full Clang `W=1` build.
Record 9.2: Stable rules checklist: obviously correct: yes by
inspection; tested: no explicit `Tested-by` and no local full build;
fixes a real issue: yes as a build-warning/error issue under specific
settings; important: only under build-fix exception, not runtime-
critical; small/contained: yes, 3-line single-function change; no new
feature/API: yes; applies to stable: current 7.0.5 yes, older trees
likely simple but not all tested.
Record 9.3: Exception category: build fix. This is the only reason to
take it; it is not a runtime bug fix.
Record 9.4: Decision: backport as a low-risk build fix for Clang
`W=1`/powerpc warning-as-error builds. The benefit is narrow, but the
patch is minimal, standalone, and behavior-preserving.
## Verification
- [Phase 1] `git show --format=fuller --stat --patch f583bd5f64d40`
verified commit message, tags, and exact diff.
- [Phase 2] Diff verified one file, one function, `1 insertion`, `2
deletions`.
- [Phase 3] `git blame` and `git show 250a93501d626` verified the unused
assignment pattern was introduced by `250a93501d626`, described as
before `v4.19-rc1`.
- [Phase 4] `b4 dig -c`, `-a`, `-w`, and `b4 mbox` verified the patch
submission, resend, recipients, and lack of candidate-specific stable
tags in the downloaded thread.
- [Phase 5] `rg` and `git grep` verified `pas_pci_init()` call placement
and `pas_add_bridge()` call sites.
- [Phase 6] `git grep` verified the pattern in `v4.19`, `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.17`, `v6.18`, `v6.19`, and
`v7.0`; `git apply --check` verified clean apply to current 7.0.5.
- [Phase 7] `MAINTAINERS` verified powerpc maintainers and subsystem
ownership.
- [Phase 8] `arch/powerpc/Kconfig.debug` and `arch/powerpc/Kbuild`
verified powerpc warning-as-error configuration exists.
- UNVERIFIED: I did not run a full Clang `W=1` build, and direct lore
stable search was blocked by Anubis.
**YES**
arch/powerpc/platforms/pasemi/pci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index 60f990a336c47..2df9552746529 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -272,13 +272,12 @@ void __init pas_pci_init(void)
{
struct device_node *root = of_find_node_by_path("/");
struct device_node *np;
- int res;
pci_set_flags(PCI_SCAN_ALL_PCIE_DEVS);
np = of_find_compatible_node(root, NULL, "pasemi,rootbus");
if (np) {
- res = pas_add_bridge(np);
+ pas_add_bridge(np);
of_node_put(np);
}
of_node_put(root);
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] powerpc/pseries/htmdump: Free the global buffers in htmdump module exit
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Athira Rajeev, Madhavan Srinivasan, Sasha Levin, mpe,
linuxppc-dev, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Athira Rajeev <atrajeev@linux.ibm.com>
[ Upstream commit 54d54f33813d7911555226b4220737177a2ba8d6 ]
htmdump modules uses global memory buffers to capture
details like capabilities, status of specified HTM, read the
trace buffer. These are initialized during module init and
hence needs to be freed in module exit.
Patch adds freeing of the memory in module exit. The change
also includes minor clean up for the variable name. The
read call back for the debugfs interface file saves filp->private_data
to local variable name which is same as global variable
name for the memory buffers. Rename these local variable
names.
Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260314132432.25581-1-atrajeev@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Summary
This commit fixes a real resource leak in
`arch/powerpc/platforms/pseries/htmdump.c`: `htm_status_buf`,
`htm_info_buf`, and `htm_caps_buf` are each allocated with
`kmalloc(PAGE_SIZE, GFP_KERNEL)` during module/debugfs initialization,
but only `htm_buf` is freed in `htmdump_exit()`. The patch adds the
three missing `kfree()` calls. The local-variable renames are cleanup
and are also used by the following two patches in the same posted
series.
The benefit is modest because the leak is on module unload, not a hot
path, and the feature is PowerPC pseries/debugfs-specific. But it is a
real leak in a `default m` module, the fix is trivial, isolated, and low
risk. For stable trees that contain the v6.16-era `htmstatus`,
`htminfo`, and `htmcaps` additions, this is suitable.
## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record 1.1: Subsystem is `powerpc/pseries/htmdump`; action verb is
`Free`; claimed intent is freeing global HTM debugfs buffers during
module exit.
Record 1.2: Tags in the supplied commit message: `Signed-off-by: Athira
Rajeev <atrajeev@linux.ibm.com>`, `Signed-off-by: Madhavan Srinivasan
<maddy@linux.ibm.com>`, `Link:
https://patch.msgid.link/20260314132432.25581-1-atrajeev@linux.ibm.com`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
or `Cc: stable@vger.kernel.org` tag was present in this commit.
Record 1.3: The body describes global memory buffers initialized in
module init and not freed in module exit. The user-visible symptom is
unreclaimed kernel memory after unloading the module. No crash, stack
trace, reporter, affected-version statement, or reproducer is given.
Record 1.4: This is a hidden cleanup-style bug fix: the functional
change is missing resource release on module exit.
### Phase 2: Diff Analysis
Record 2.1: One file changed:
`arch/powerpc/platforms/pseries/htmdump.c`, 17 insertions and 14
deletions in the posted patch. Modified functions are `htmdump_read()`,
`htmstatus_read()`, `htminfo_read()`, `htmcaps_read()`, and
`htmdump_exit()`. Scope is single-file surgical.
Record 2.2: The read-callback hunks rename local variables from names
shadowing globals to `*_data`; behavior is unchanged. The exit hunk
changes `htmdump_exit()` from freeing only `htm_buf` to freeing
`htm_buf`, `htm_status_buf`, `htm_info_buf`, and `htm_caps_buf`.
Record 2.3: Bug category is resource leak. Verified allocations are
three `PAGE_SIZE` buffers for status/info/caps in
`htmdump_init_debugfs()` without corresponding frees before this patch.
Record 2.4: Fix quality is high: `kfree(NULL)` is safe, the buffers are
global module-owned allocations, and debugfs removal already happens
before freeing. Regression risk is very low. The only non-functional
churn is local-variable rename.
### Phase 3: Git History Investigation
Record 3.1: `git blame` on the current stable checkout points the
relevant lines at the repository boundary merge `f3f5edc5e41e0`, so I
followed explicit commit objects. `htm_status_buf` was added by
`627cf584f4c3`, `htm_info_buf` by `dea7384e14e7`, and `htm_caps_buf` by
`143a2584627c`, all described by `git describe --contains`/history as
v6.16-rc1-era commits.
Record 3.2: Candidate has no `Fixes:` tag, so no direct Fixes target
applies. Related series patches 2/3 and 3/3 have `Fixes:` tags for
`dea7384e14e7` and `627cf584f4c3`, but this patch does not depend on
those fixes.
Record 3.3: Recent `htmdump` history shows the v6.16 additions for
status/info/setup/flags/caps and a header include fix. The candidate is
patch 1/3 in a series; patch 1 is standalone, while patches 2/3 and 3/3
textually build on its variable renames.
Record 3.4: Author Athira Rajeev authored the original htmdump expansion
commits; Madhavan Srinivasan committed them. This was verified from `git
show` for the status/info/caps commits.
Record 3.5: No prerequisite is needed for patch 1 beyond the buffers
existing. An isolated `git apply --check` of patch 1 succeeds on the
current 7.0 stable checkout.
### Phase 4: Mailing List And External Research
Record 4.1: `b4 dig` could not be meaningfully run because the candidate
commit object/hash is not present in the checked-out refs; `b4 dig -h`
confirmed it requires `-c <commitish>`. I used `b4 mbox -c` with
message-id `20260314132432.25581-1-atrajeev@linux.ibm.com`; it fetched a
3-message thread and reported no newer revision.
Record 4.2: Original recipients from the mbox were
`maddy@linux.ibm.com`, `linuxppc-dev@lists.ozlabs.org`, and CCs
including `hbathini`, `sshegde`, and IBM HTM-related recipients. No
review replies, NAKs, or stable nominations were present in the fetched
mbox.
Record 4.3: No `Reported-by` or bug-report link exists for this
candidate. `WebFetch` to lore/patch.msgid was blocked by Anubis, but `b4
mbox` successfully fetched the thread.
Record 4.4: The patch is part of a 3-patch series. Patch 1 fixes exit
cleanup; patch 2 fixes `htminfo_read()` offset handling; patch 3 fixes
`htmstatus_read()` offset handling. Patch 1 can apply standalone, and
later patches depend textually on its renames.
Record 4.5: Stable-specific lore WebFetch was blocked by Anubis.
WebSearch for the exact subject and stable context found no specific
stable discussion. Local `git log --grep` checks of `v6.18`, `v6.19`,
`v7.0`, and `linux-rolling-stable` found no exact-subject match.
### Phase 5: Code Semantic Analysis
Record 5.1: Modified functions are `htmdump_read()`, `htmstatus_read()`,
`htminfo_read()`, `htmcaps_read()`, and `htmdump_exit()`.
Record 5.2: Callers/entry points are verified through file operations
and module macros: `htmdump_exit()` is registered with `module_exit()`,
reads are reached through debugfs files created by
`debugfs_create_file()` with the corresponding fops.
Record 5.3: Key callees are `debugfs_remove_recursive()`, `kfree()`,
`htm_hcall_wrapper()`, `virt_to_phys()`, and
`simple_read_from_buffer()`. The functional fix only adds `kfree()`
calls in exit.
Record 5.4: Reachability is module lifecycle and debugfs based. The leak
triggers on module unload after successful allocation of the
status/info/caps buffers. Unprivileged triggering was not verified and
is not relied on; Kconfig shows `HTMDUMP` is `tristate`, `default m`,
and depends on `PPC_PSERIES && DEBUG_FS`.
Record 5.5: Similar pattern found: `htm_buf` was already freed in
`htmdump_exit()`, while the three later-added global buffers were not.
### Phase 6: Stable Tree Analysis
Record 6.1: `v6.15` has `htmdump.c` with only `htm_buf`; `v6.16`,
`v6.17`, `v6.18`, `v6.19`, and `v7.0` have the three additional buffers
and only free `htm_buf`. So the bug affects stable trees containing the
v6.16 htmdump expansions, not older trees lacking those buffers.
Record 6.2: Backport difficulty is low for affected trees. The patch’s
base blob matches `v6.16`/`v6.17`/current 7.0 content for the relevant
file, and isolated patch 1 applies cleanly to the current checkout.
Record 6.3: No exact-subject related fix was found in checked `v6.18`,
`v6.19`, `v7.0`, or `linux-rolling-stable`.
### Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is PowerPC pseries platform driver/debugfs
support. Criticality is peripheral/platform-specific, not core kernel-
wide.
Record 7.2: `git log -20 v7.0 -- arch/powerpc/platforms/pseries` shows
active pseries development, but this particular fix is contained to
`htmdump.c`.
### Phase 8: Impact And Risk
Record 8.1: Affected users are PowerPC pseries users with
`CONFIG_HTMDUMP` enabled, primarily using the debugfs HTM dump module.
Record 8.2: Trigger is successful module initialization followed by
module exit/unload. Repeated load/unload can accumulate unreclaimed
pages until reboot. This is not verified as unprivileged-triggerable.
Record 8.3: Failure mode is kernel memory/resource leak, three
`PAGE_SIZE` allocations per unload for the later buffers. Severity is
medium: real and persistent until reboot, but not a crash/security/data-
corruption fix and not a hot path.
Record 8.4: Benefit is moderate for affected stable users; risk is very
low because the functional change is only three `kfree()` calls after
debugfs removal.
### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: real resource leak, affects stable
trees v6.16 and newer that contain the expanded htmdump module, fix is
tiny and obviously correct, isolated patch applies cleanly. Evidence
against: peripheral platform-specific module, leak occurs on module
unload rather than common runtime path, no reporter/testing/stable tags
in this patch. Unresolved: no full lore review discussion was available
beyond the 3-patch mbox; direct WebFetch lore pages were blocked.
Record 9.2: Stable rules checklist: obviously correct yes; fixes a real
bug yes; important enough is borderline but acceptable as a real
resource leak with very low regression risk; small and contained yes; no
new feature/API yes; applies to affected stable trees yes for current
7.0 and likely cleanly where file matches v6.16+.
Record 9.3: No automatic exception category applies: this is not a
device ID, quirk, DT update, build fix, or documentation-only fix.
Record 9.4: Decision is YES for stable trees that contain
`htm_status_buf`, `htm_info_buf`, and `htm_caps_buf`.
## Verification
- Phase 1: Parsed supplied commit message and b4-fetched patch 1;
confirmed no `Fixes:`, `Reported-by`, `Tested-by`, review, or stable
tag in patch 1.
- Phase 2: Read `arch/powerpc/platforms/pseries/htmdump.c`; confirmed
allocations and missing frees; inspected patch hunks from
`/tmp/htmdump-20260314.mbx`.
- Phase 3: Ran `git blame -L 410,485`; followed explicit commits
`627cf584f4c3`, `dea7384e14e7`, and `143a2584627c` with `git show`;
checked author/subsystem history.
- Phase 4: `b4 mbox -c` fetched the 3-message thread; direct `WebFetch`
lore URLs were blocked; WebSearch found no exact stable discussion.
- Phase 5: Used `rg`, `ReadFile`, and Kconfig/Makefile/docs to verify
module/debugfs reachability and `CONFIG_HTMDUMP` as `tristate`,
`default m`.
- Phase 6: Checked `v6.15`, `v6.16`, `v6.17`, `v6.18`, `v6.19`, and
`v7.0` file contents; isolated patch 1 passed `git apply --check`.
- Phase 8: Verified failure mode from concrete `kmalloc(PAGE_SIZE)`
allocations and missing matching `kfree()` calls.
- Unverified: whether every downstream stable branch has identical
context; direct stable-list lore search was blocked by Anubis.
**YES**
arch/powerpc/platforms/pseries/htmdump.c | 31 +++++++++++++-----------
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/htmdump.c b/arch/powerpc/platforms/pseries/htmdump.c
index 742ec52c9d4df..93f0cc2dc7fb6 100644
--- a/arch/powerpc/platforms/pseries/htmdump.c
+++ b/arch/powerpc/platforms/pseries/htmdump.c
@@ -86,7 +86,7 @@ static ssize_t htm_return_check(long rc)
static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
size_t count, loff_t *ppos)
{
- void *htm_buf = filp->private_data;
+ void *htm_buf_data = filp->private_data;
unsigned long page, read_size, available;
loff_t offset;
long rc, ret;
@@ -100,7 +100,7 @@ static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
* - last three values are address, size and offset
*/
rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
- htmtype, H_HTM_OP_DUMP_DATA, virt_to_phys(htm_buf),
+ htmtype, H_HTM_OP_DUMP_DATA, virt_to_phys(htm_buf_data),
PAGE_SIZE, page);
ret = htm_return_check(rc);
@@ -112,7 +112,7 @@ static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
available = PAGE_SIZE;
read_size = min(count, available);
*ppos += read_size;
- return simple_read_from_buffer(ubuf, count, &offset, htm_buf, available);
+ return simple_read_from_buffer(ubuf, count, &offset, htm_buf_data, available);
}
static const struct file_operations htmdump_fops = {
@@ -226,7 +226,7 @@ static int htmstart_get(void *data, u64 *val)
static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
size_t count, loff_t *ppos)
{
- void *htm_status_buf = filp->private_data;
+ void *htm_status_data = filp->private_data;
long rc, ret;
u64 *num_entries;
u64 to_copy;
@@ -238,7 +238,7 @@ static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
* - last three values as addr, size and offset
*/
rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
- htmtype, H_HTM_OP_STATUS, virt_to_phys(htm_status_buf),
+ htmtype, H_HTM_OP_STATUS, virt_to_phys(htm_status_data),
PAGE_SIZE, 0);
ret = htm_return_check(rc);
@@ -255,13 +255,13 @@ static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
* So total count to copy is:
* 32 bytes (for first 7 fields) + (number of HTM entries * entry size)
*/
- num_entries = htm_status_buf + 0x10;
+ num_entries = htm_status_data + 0x10;
if (htmtype == 0x2)
htmstatus_flag = 0x8;
else
htmstatus_flag = 0x6;
to_copy = 32 + (be64_to_cpu(*num_entries) * htmstatus_flag);
- return simple_read_from_buffer(ubuf, count, ppos, htm_status_buf, to_copy);
+ return simple_read_from_buffer(ubuf, count, ppos, htm_status_data, to_copy);
}
static const struct file_operations htmstatus_fops = {
@@ -273,7 +273,7 @@ static const struct file_operations htmstatus_fops = {
static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
size_t count, loff_t *ppos)
{
- void *htm_info_buf = filp->private_data;
+ void *htm_info_data = filp->private_data;
long rc, ret;
u64 *num_entries;
u64 to_copy;
@@ -284,7 +284,7 @@ static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
* - last three values as addr, size and offset
*/
rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
- htmtype, H_HTM_OP_DUMP_SYSPROC_CONF, virt_to_phys(htm_info_buf),
+ htmtype, H_HTM_OP_DUMP_SYSPROC_CONF, virt_to_phys(htm_info_data),
PAGE_SIZE, 0);
ret = htm_return_check(rc);
@@ -301,15 +301,15 @@ static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
* So total count to copy is:
* 32 bytes (for first 5 fields) + (number of HTM entries * entry size)
*/
- num_entries = htm_info_buf + 0x10;
+ num_entries = htm_info_data + 0x10;
to_copy = 32 + (be64_to_cpu(*num_entries) * 16);
- return simple_read_from_buffer(ubuf, count, ppos, htm_info_buf, to_copy);
+ return simple_read_from_buffer(ubuf, count, ppos, htm_info_data, to_copy);
}
static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
size_t count, loff_t *ppos)
{
- void *htm_caps_buf = filp->private_data;
+ void *htm_caps_data = filp->private_data;
long rc, ret;
/*
@@ -319,7 +319,7 @@ static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
* and zero
*/
rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
- htmtype, H_HTM_OP_CAPABILITIES, virt_to_phys(htm_caps_buf),
+ htmtype, H_HTM_OP_CAPABILITIES, virt_to_phys(htm_caps_data),
0x80, 0);
ret = htm_return_check(rc);
@@ -328,7 +328,7 @@ static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
return ret;
}
- return simple_read_from_buffer(ubuf, count, ppos, htm_caps_buf, 0x80);
+ return simple_read_from_buffer(ubuf, count, ppos, htm_caps_data, 0x80);
}
static const struct file_operations htminfo_fops = {
@@ -482,6 +482,9 @@ static void __exit htmdump_exit(void)
{
debugfs_remove_recursive(htmdump_debugfs_dir);
kfree(htm_buf);
+ kfree(htm_status_buf);
+ kfree(htm_info_buf);
+ kfree(htm_caps_buf);
}
module_init(htmdump_init);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] video: console: mdacon: remove this obsolete driver
From: Helge Deller @ 2026-05-20 11:45 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-doc, linux-alpha, linux-serial,
linux-fbdev, Linux DRI Development, linuxppc-dev
Cc: Jonathan Corbet, Shuah Khan, Richard Henderson, Matt Turner,
Magnus Lindholm, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Greg Kroah-Hartman,
Jiri Slaby, Nicolas Pitre
In-Reply-To: <20260520033155.17378-1-enelsonmoore@gmail.com>
On 5/20/26 05:31, Ethan Nelson-Moore wrote:
> The mdacon driver supports using ISA MDA or Hercules-compatible display
> adapters as a secondary text console. This was commonly used in the
> 1990s and earlier for debugging software which took over the primary
> display. It is highly unlikely anyone is doing so nowadays because
> serial consoles and much better methods of debugging exist.
>
> The driver is not enabled by any defconfig, nor any of the
> dozens of distro configs collected at [1]. It has been relegated to VTs
> 13-16 since commit 0b9cf3aa6b1e ("mdacon messing up default vc's - set
> default to vc13-16 again") in Linux 2.6.27 (and before Linux 2.5.53 -
> see the link in the message of the above commit). The change in 2.6.27
> was done because it was incorrectly detecting non-MDA adapters as MDA
> and taking over all VTs, rendering them unusable.
>
> Furthermore, vgacon supports using MDA/Hercules-compatible adapters as
> the primary text console, so any systems with only one of these
> adapters were already using vgacon and will not experience any loss in
> functionality from the removal of this driver.
>
> Given all of these factors, the mdacon driver is likely entirely
> unused. Remove it.
I've applied this patch to the fbdev git tree, since I also believe that
there is no use case or user left (with Linux kernels >= 7.0), which uses the mdacon.
If someone thinks we need to keep it, please speak up.
Helge
>
> [1] https://github.com/nyrahul/linux-kernel-configs/tree/f0bee86a135a0406ea427855f52702dd00d770f9
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
> .../admin-guide/kernel-parameters.txt | 5 -
> arch/alpha/kernel/io.c | 2 +-
> arch/powerpc/include/asm/vga.h | 4 +-
> drivers/tty/vt/vt.c | 3 -
> drivers/video/console/Kconfig | 15 -
> drivers/video/console/Makefile | 1 -
> drivers/video/console/mdacon.c | 566 ------------------
> include/linux/console.h | 2 -
> include/linux/vt_buffer.h | 2 +-
> 9 files changed, 4 insertions(+), 596 deletions(-)
> delete mode 100644 drivers/video/console/mdacon.c
^ permalink raw reply
* [PATCH] powerpc/code-patching: Avoid r/w mapping of the zero page
From: Ard Biesheuvel @ 2026-05-20 7:34 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, Ard Biesheuvel, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP)
From: Ard Biesheuvel <ardb@kernel.org>
The only remaining use of map_patch_area() is mapping the zero page, and
immediately unmapping it again so that the intermediate page table
levels are all guaranteed to be populated.
The use of the zero page here is completely arbitrary, and not harmful
per se, but currently, it creates a writable mapping, and does so in a
manner that requires that the empty_zero_page[] symbol is not
const-qualified.
Given that this is about to change, and that map_patch_area() now never
maps anything other than the zero page, let's simplify the code and
- take the PA of empty_zero_page directly
- create a read-only temporary mapping.
This allows empty_zero_page[] to be repainted as const u8[] in a
subsequent patch, without making substantial changes to this code
patching logic.
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
Build tested only (Clang)
arch/powerpc/lib/code-patching.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index f84e0337cc02..13a8acf851f1 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -60,7 +60,7 @@ struct patch_context {
static DEFINE_PER_CPU(struct patch_context, cpu_patching_context);
-static int map_patch_area(void *addr, unsigned long text_poke_addr);
+static int map_patch_area(unsigned long text_poke_addr);
static void unmap_patch_area(unsigned long addr);
static bool mm_patch_enabled(void)
@@ -117,7 +117,7 @@ static int text_area_cpu_up(unsigned int cpu)
// Map/unmap the area to ensure all page tables are pre-allocated
addr = (unsigned long)area->addr;
- err = map_patch_area(empty_zero_page, addr);
+ err = map_patch_area(addr);
if (err)
return err;
@@ -236,11 +236,10 @@ static unsigned long get_patch_pfn(void *addr)
/*
* This can be called for kernel text or a module.
*/
-static int map_patch_area(void *addr, unsigned long text_poke_addr)
+static int map_patch_area(unsigned long text_poke_addr)
{
- unsigned long pfn = get_patch_pfn(addr);
-
- return map_kernel_page(text_poke_addr, (pfn << PAGE_SHIFT), PAGE_KERNEL);
+ return map_kernel_page(text_poke_addr, __pa_symbol(empty_zero_page),
+ PAGE_KERNEL_RO);
}
static void unmap_patch_area(unsigned long addr)
--
2.54.0.631.ge1b05301d1-goog
^ permalink raw reply related
* Re: [PATCH 4/8] mm/bootmem_info: remove call to kmemleak_free_part_phys()
From: Lance Yang @ 2026-05-20 12:15 UTC (permalink / raw)
To: david
Cc: osalvador, davem, andreas, rppt, akpm, agordeev, gerald.schaefer,
hca, gor, borntraeger, svens, maddy, mpe, npiggin, chleroy, ljs,
liam, vbabka, surenb, mhocko, sparclinux, linux-kernel, linux-mm,
linux-s390, linuxppc-dev, Lance Yang
In-Reply-To: <b2a8e918-7ed2-46b4-bf59-e65dc9359310@kernel.org>
On Tue, May 12, 2026 at 10:45:03AM +0200, David Hildenbrand (Arm) wrote:
>On 5/12/26 10:34, Oscar Salvador wrote:
[...]
>>> diff --git a/mm/bootmem_info.c b/mm/bootmem_info.c
>>> index 6e2aaab3dca9..74c1116626c8 100644
>>> --- a/mm/bootmem_info.c
>>> +++ b/mm/bootmem_info.c
>>> @@ -32,7 +32,6 @@ void put_page_bootmem(struct page *page)
>>>
>>> if (page_ref_dec_return(page) == 1) {
>>> set_page_private(page, 0);
>>> - kmemleak_free_part_phys(PFN_PHYS(page_to_pfn(page)), PAGE_SIZE);
>>
>> A bit odd that kmemleak_free_part_phys() did not complain if we never
>> did kmemleak_alloc_phys() for these pages?
>
>delete_object_part() calls __find_and_remove_object() and essentially just skips
>if it didn't find anything.
>
>Maybe the kmemleak_warn() would trigger, but it's guarded by "#ifdef DEBUG" ...
Right! With kmemleak DEBUG enabled, kmemleak_free_part_phys() does warns
whenever delete_object_part() cannot find the corresponding physical
object ...
Before this patch, booting with:
"kmemleak=on hugetlb_free_vmemmap=on default_hugepagesz=2M hugepagesz=2M hugepages=512"
I got a lot of warnings, something like:
[ 44.481883] kmemleak: Partially freeing unknown object at 0x2acc59000 (size 4096)
[ 44.482754] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.1.0-rc3 #206 PREEMPT(full)
[ 44.482758] Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
[ 44.482760] Call Trace:
[ 44.482762] <TASK>
[ 44.482764] dump_stack_lvl+0x60/0x90
[ 44.482769] dump_stack+0x14/0x1a
[ 44.482774] delete_object_part.cold+0x28/0x2d
[ 44.482779] kmemleak_free_part_phys+0x67/0x80
[ 44.482783] put_page_bootmem+0xc0/0x100
[ 44.482787] free_vmemmap_page_list+0x13e/0x230
[ 44.482791] __hugetlb_vmemmap_optimize_folios+0x351/0x430
[...]
So, yeah, looks like these calls are trying to free physical kmemleak
objects that are no longer tracked after memmap_alloc() started using
MEMBLOCK_ALLOC_NOLEAKTRACE :)
With this patch applied, those stale calls are gone, and so are the
warnings :P
Tested-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* Re: [RFC PATCH net-next 2/2] powerpc: remove ehea driver references
From: Christophe Leroy (CS GROUP) @ 2026-05-20 12:27 UTC (permalink / raw)
To: David Christensen, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Michael Ellerman, Nicholas Piggin
Cc: netdev, linuxppc-dev, linux-kernel
In-Reply-To: <20260519224353.1282038-3-drc@linux.ibm.com>
Le 20/05/2026 à 00:43, David Christensen a écrit :
> [Vous ne recevez pas souvent de courriers de drc@linux.ibm.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>
> Follow-on cleanup after the removal of the IBM eHEA driver in commit
> XXXXXXXXXXXX ("net: ethernet: ibm: remove the ehea driver").
>
> Remove the CONFIG_IBM_EHEA entry from ppc64_defconfig and the obsolete
> comment in arch/powerpc/mm/mem.c that referenced the driver.
What do you mean by 'obsolete' ?
As far as I can see the commit is still valid, I can't see any other
module caller of function walk_system_ram_range().
The comment was introduced by commit 26b523356f49 ("powerpc: Drop
page_is_ram() and walk_system_ram_range()")
>
> Signed-off-by: David Christensen <drc@linux.ibm.com>
> ---
> arch/powerpc/configs/ppc64_defconfig | 1 -
> arch/powerpc/mm/mem.c | 4 ----
> 2 files changed, 5 deletions(-)
>
> diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
> index 6316ca4df25d..b022d00708f4 100644
> --- a/arch/powerpc/configs/ppc64_defconfig
> +++ b/arch/powerpc/configs/ppc64_defconfig
> @@ -210,7 +210,6 @@ CONFIG_BNX2X=m
> CONFIG_CHELSIO_T1=m
> CONFIG_BE2NET=m
> CONFIG_IBMVETH=m
> -CONFIG_EHEA=m
> CONFIG_IBMVNIC=m
> CONFIG_E100=y
> CONFIG_E1000=y
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 648d0c5602ec..1f5ad1a59d68 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -370,10 +370,6 @@ int devmem_is_allowed(unsigned long pfn)
> }
> #endif /* CONFIG_STRICT_DEVMEM */
>
> -/*
> - * This is defined in kernel/resource.c but only powerpc needs to export it, for
> - * the EHEA driver. Drop this when drivers/net/ethernet/ibm/ehea is removed.
> - */
> EXPORT_SYMBOL_GPL(walk_system_ram_range);
As mentioned in the comment, the EXPORT_SYMBOL_GPL() has to be dropped
when drivers/net/ethernet/ibm/ehea is removed, which is now.
>
> #ifdef CONFIG_EXECMEM
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-20 12:55 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Suren Baghdasaryan, Barry Song, Matthew Wilcox, akpm, linux-mm,
liam, vbabka, rppt, mhocko, jack, pfalcato, wanglian, chentao,
lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng,
nphamcs, bhe, youngjun.park, linux-arm-kernel, linux-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <e6d1017a-e4c5-493e-bfca-932c6d64eaac@kernel.org>
On Wed, May 20, 2026 at 12:33:56PM +0200, David Hildenbrand (Arm) wrote:
> On 5/19/26 14:53, Lorenzo Stoakes wrote:
> > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
> >
> >>>
> >>> I think we either need to fix `fork()`, or keep the current
> >>> behavior of dropping the VMA lock before performing I/O.
> >>
> >> I see. So, this problem arises from the fact that we are changing the
> >> pagefaults requiring I/O operation to hold VMA lock...
> >> And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> >> is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> >> anonymous and COW VMAs only while holding mmap_write_lock, preventing
> >> any VMA modification. On the surface, that looks ok to me but I might
> >> be missing some corner cases. If nobody sees any obvious issues, I
> >> think it's worth a try.
> >
> > Not sure if you noticed but I did raise concerns ;)
> >
> > I wonder if you've confused the fault path and fork here, as I think Barry has
> > been a little unclear on that.
> >
> > What's being suggested in this thread is to fundamentally change fork behaviour
> > so it's different from the entire history of the kernel (or - presumably - at
> > least recent history :)
> I don't want fork() to become different in that regard.
>
> There is already a slight difference with vs. without per-VMA locks, because
> there is a window in-between us taking the write mmap_lock and all the per-VMA
> locks. I raised that previously [1] and assumed that it is probably fine.
>
> I also raised in the past why I think we must not allow concurrent page faults,
> at least as soon as anonymous memory is involved [2].
>
> ... and I raised that this is pretty much slower by design right now: "Well, the
> design decision that CONFIG_PER_VMA_LOCK made for now to make page faults fast
> and to make blocking any page faults from happening to be slower ..." [3]
Thanks for the background will read through! :)
But yeah I think the transition from !vma->anon_vma -> vma->anon_vma being a bit
slow is kinda ok most page faults will of course have anon_vma populated.
Be interesting with CoW context, because we won't need to mmap read lock there
at all :)
>
> [1] https://lore.kernel.org/all/970295ab-e85d-7af3-76e6-df53a5c52f8b@redhat.com/
> [2] https://lore.kernel.org/all/7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com/
> [3] https://lore.kernel.org/all/2efa2c89-3765-721d-2c3c-00590054aa5b@redhat.com/
>
> --
> Cheers,
>
> David
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] powerpc: define __LITTLE_ENDIAN and __BIG_ENDIAN for math-emu
From: Christophe Leroy (CS GROUP) @ 2026-05-20 13:14 UTC (permalink / raw)
To: David Laight, Mingcong Bai
Cc: linux-kernel, Xi Ruoyao, Kexy Biscuit, stable, kernel test robot,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
linuxppc-dev
In-Reply-To: <20260517145421.2d1ac77c@pumpkin>
Le 17/05/2026 à 15:54, David Laight a écrit :
> On Sun, 17 May 2026 12:14:21 +0800
> Mingcong Bai <jeffbai@aosc.io> wrote:
>
>> Similar to commit b929926f01f2 ("sh: define __BIG_ENDIAN for math-emu"),
>> define __LITTLE_ENDIAN and __BIG_ENDIAN as 0 to mitigate build-time
>> warnings:
>>
>> ./include/math-emu/double.h:59:21: error: ‘__BIG_ENDIAN’ is not defined, evaluates to ‘0’ [-Werror=undef]
>> 59 | #if __BYTE_ORDER == __BIG_ENDIAN
>> |
>>
>> Cc: stable@vger.kernel.org
>> Fixes: 13da9e200fe4 ("Revert "endian: #define __BYTE_ORDER"")
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Foe-kbuild-all%2F202507301656.7FEX6J5W-lkp%40intel.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C08977974fb1c495e9bd508deb41bd275%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639146228768693730%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4qGulR%2BL7i7inksEbEH9jNGZS8HG80uvm3I9IyYzZww%3D&reserved=0
>> Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
>> ---
>> arch/powerpc/include/asm/sfp-machine.h | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/sfp-machine.h b/arch/powerpc/include/asm/sfp-machine.h
>> index 8b957aabb826d..db8525605c026 100644
>> --- a/arch/powerpc/include/asm/sfp-machine.h
>> +++ b/arch/powerpc/include/asm/sfp-machine.h
>> @@ -319,10 +319,12 @@
>> #define abort() \
>> return 0
>>
>> -#ifdef __BIG_ENDIAN
>> +#ifdef __BIG_ENDIAN__
>> #define __BYTE_ORDER __BIG_ENDIAN
>> +#define __LITTLE_ENDIAN 0
>> #else
>> #define __BYTE_ORDER __LITTLE_ENDIAN
>> +#define __BIG_ENDIAN 0
>> #endif
>
> I thought the expected/correct value for __BYTE_ORDER__ was either 1234 or 4321.
> (apart from pdp11's 2143).
That's the case, in include/linux/kconfig.h we have:
#ifdef CONFIG_CPU_BIG_ENDIAN
#define __BIG_ENDIAN 4321
#else
#define __LITTLE_ENDIAN 1234
#endif
But as far as I understand the problem is that math-emu expects
__BIG_ENDIAN to be defined at all time as it has tests like:
#if __BYTE_ORDER == __BIG_ENDIAN
Christophe
^ permalink raw reply
* Re: [PATCHv2] powerpc/44x: Set GPIO chip parent
From: Christophe Leroy (CS GROUP) @ 2026-05-20 13:15 UTC (permalink / raw)
To: Rosen Penev, linuxppc-dev
Cc: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Linus Walleij, open list
In-Reply-To: <20260517063754.21819-1-rosenp@gmail.com>
Le 17/05/2026 à 08:37, Rosen Penev a écrit :
> The PPC4xx GPIO driver stopped assigning an explicit parent
> to the gpio_chip when it moved away from of_mm_gpiochip_add_data().
>
> Restore that association from the platform device so OF GPIO lookup
> can match phandles to the registered gpiochip.
>
> Tested on: Cisco MX60W. No more probe deferral.
>
> Assisted-by: Codex:GPT-5.5
> Fixes: 1044dbaf2a77 ("powerpc/44x: Change GPIO driver to a proper platform driver")
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> ---
> arch/powerpc/platforms/44x/gpio.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/platforms/44x/gpio.c b/arch/powerpc/platforms/44x/gpio.c
> index aea0d913b59d..4413a94cf7a6 100644
> --- a/arch/powerpc/platforms/44x/gpio.c
> +++ b/arch/powerpc/platforms/44x/gpio.c
> @@ -169,6 +169,7 @@ static int ppc4xx_gpio_probe(struct platform_device *ofdev)
>
> gc = &chip->gc;
>
> + gc->parent = dev;
> gc->base = -1;
> gc->ngpio = 32;
> gc->direction_input = ppc4xx_gpio_dir_in;
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-05-20 13:40 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Mostafa Saleh, iommu, linux-arm-kernel, linux-kernel, linux-coco,
Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <yq5a5x4ispg8.fsf@kernel.org>
On Wed, May 20, 2026 at 09:27:27AM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@ziepe.ca> writes:
>
> > On Tue, May 19, 2026 at 09:35:30PM +0530, Aneesh Kumar K.V wrote:
> >> Yes, that also resulted in simpler and cleaner code.
> >>
> >> swiotlb_tbl_map_single
> >> /*
> >> * If the physical address is encrypted but the device requires
> >> * decrypted DMA, use a decrypted io_tlb_mem and update the
> >> * attributes so the caller knows that a decrypted io_tlb_mem
> >> * was used.
> >> */
> >> if (!(*attrs & DMA_ATTR_CC_SHARED) && force_dma_unencrypted(dev))
> >> *attrs |= DMA_ATTR_CC_SHARED;
> >>
> >> if (mem->unencrypted != !!(*attrs & DMA_ATTR_CC_SHARED))
> >> return (phys_addr_t)DMA_MAPPING_ERROR;
> >
> > Yeah, exactly that is so much clearer now that the mem->unecrypted is
> > tied directly.
> >
> > That logic is reversed though, the incoming ATTR_CC doesn't matter for
> > swiotlb, that is just the source of the memcpy.
> >
> > /* swiotlb pool is incorrect for this device */
> > if (mem->unencrypted != force_dma_unencrypted(dev))
> > return (phys_addr_t)DMA_MAPPING_ERROR;
> >
> > /* Force attrs to match the kind of memory in the pool */
> > if (mem->unencrypted)
> > *attrs |= DMA_ATTR_CC_SHARED;
> > else
> > *attrs &= ~DMA_ATTR_CC_SHARED;
> >
> >
> > Attrs should be forced to whatever memory swiotlb selected.
> >
>
> But that will not handle a T=1 device that wants to use swiotlb to
> bounce unencrypted memory. That is:
>
> force_dma_unencrypted(dev) == 0 /* T=1 device */
> attrs = DMA_ATTR_CC_SHARED;
>
> In that case, it should use an unencrypted io_tlb_mem:
> mem->unencrypted == 1
No! The DMA_ATTR_CC_SHARED only states the nature of the source
memory, the DMA transfer will always happen under T=1
It is perfectly fine to memcpy from shared to private and do a T=1 DMA
from the private memory if we have to bounce.
Jason
^ permalink raw reply
* Re: [PATCH 5/8] mm/bootmem_info: stop marking the pgdat as NODE_INFO
From: Lance Yang @ 2026-05-20 15:30 UTC (permalink / raw)
To: david
Cc: davem, andreas, rppt, akpm, agordeev, gerald.schaefer, hca, gor,
borntraeger, svens, maddy, mpe, npiggin, chleroy, ljs, liam,
vbabka, surenb, mhocko, sparclinux, linux-kernel, linux-mm,
linux-s390, linuxppc-dev, Lance Yang
In-Reply-To: <20260511-bootmem_info_prep-v1-5-3fb0be6fc688@kernel.org>
On Mon, May 11, 2026 at 04:05:33PM +0200, David Hildenbrand (Arm) wrote:
>We removed the last user of NODE_INFO in commit 119c31caa59e ("mm/sparse:
>remove !CONFIG_SPARSEMEM_VMEMMAP leftovers for CONFIG_MEMORY_HOTPLUG").
>
>But it really was never used it besides for safety-checks ever since it was
>introduced in commit 04753278769f ("memory hotplug: register section/node
>id to free"), where we had the comment:
>
> 5) The node information like pgdat has similar issues. But, this
> will be able to be solved too by this.
> (Not implemented yet, but, remembering node id in the pages.)
>
>Of course, that never happened, and we are not planning on freeing the
>node data (pgdat/pglist_data), during memory hotunplug.
>
>So let's just stop marking the pgdat as NODE_INFO.
>
>Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>---
> mm/bootmem_info.c | 9 +--------
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
>diff --git a/mm/bootmem_info.c b/mm/bootmem_info.c
>index 74c1116626c8..cce1d560f094 100644
>--- a/mm/bootmem_info.c
>+++ b/mm/bootmem_info.c
>@@ -62,15 +62,8 @@ static void __init register_page_bootmem_info_section(unsigned long start_pfn)
>
> void __init register_page_bootmem_info_node(struct pglist_data *pgdat)
> {
>- unsigned long i, pfn, end_pfn, nr_pages;
>+ unsigned long pfn, end_pfn;
> int node = pgdat->node_id;
>- struct page *page;
>-
>- nr_pages = PAGE_ALIGN(sizeof(struct pglist_data)) >> PAGE_SHIFT;
>- page = virt_to_page(pgdat);
>-
>- for (i = 0; i < nr_pages; i++, page++)
>- get_page_bootmem(node, page, NODE_INFO);
Cool. IIUC, pgdat isn't freed during memory hotremove. Offline nodes
stick around and can get reinitialized on hotadd, so NODE_INFO doesn't
buy us anything here :D
LGTM, feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* [PATCH 0/4] fbdev: Internalize fbcon
From: Thomas Zimmermann @ 2026-05-20 16:00 UTC (permalink / raw)
To: deller, simona, airlied, lukas, maddy, mpe, npiggin, chleroy
Cc: dri-devel, linux-fbdev, linuxppc-dev, Thomas Zimmermann
Turn fbcon into an internal client of fbdev. Manage all interactions
with graphics drivers within fbdev. Add helpers for these tasks and
convert drivers.
Fbdev's PS3 and SH-Mobile drivers update fbcon as part of user-invoked
mode changes. Call the new helpers, which also fix inconsistencies
among the various code paths.
Vga-switcheroo remaps the fbcon terminals when switching physical
outputs. For now, hide this in another helper. The call will later
move into DRM's fbdev emulation.
When all refactoring in place, fbdev manages fbcon interactions by
itself. Remove the public interfaces.
Thomas Zimmermann (4):
fbdev: Wrap user-invoked calls to fb_set_var() in helper
fbdev: Wrap user-invoked calls to fb_blank() in helper
fbdev: Wrap fbcon updates from vga-switcheroo in helper
fbdev: Do not export fbcon from fbdev
MAINTAINERS | 1 -
drivers/gpu/vga/vga_switcheroo.c | 6 +--
drivers/video/fbdev/core/fb_chrdev.c | 12 ++----
drivers/video/fbdev/core/fb_internal.h | 1 +
drivers/video/fbdev/core/fbcon.c | 3 --
drivers/video/fbdev/core/fbcon.h | 50 +++++++++++++++++++++++
drivers/video/fbdev/core/fbmem.c | 35 +++++++++++++++-
drivers/video/fbdev/core/fbsysfs.c | 9 +----
drivers/video/fbdev/ps3fb.c | 5 +--
drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 +--
include/linux/fb.h | 3 ++
include/linux/fbcon.h | 55 --------------------------
12 files changed, 98 insertions(+), 87 deletions(-)
delete mode 100644 include/linux/fbcon.h
base-commit: 121c16f9d8c56ea07263df84ab971cc10870fe88
--
2.54.0
^ permalink raw reply
* [PATCH 1/4] fbdev: Wrap user-invoked calls to fb_set_var() in helper
From: Thomas Zimmermann @ 2026-05-20 16:00 UTC (permalink / raw)
To: deller, simona, airlied, lukas, maddy, mpe, npiggin, chleroy
Cc: dri-devel, linux-fbdev, linuxppc-dev, Thomas Zimmermann
In-Reply-To: <20260520160744.130841-1-tzimmermann@suse.de>
Handle fbcon during display updates in fb_set_var_from_user(). Check
with fbcon if the mode change is possible, update hardware state and
finally update fbcon. Update all callers.
Only the FBIOPUT_VSCREENINFO ioctl currently does all steps. Other
mode-changes callers in sysfs and driver code are missing fbcon-related
steps.
With the new helper, ps3fb and sh_mobile_lcdcfb no longer maintain
fbcon state themselves.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fb_chrdev.c | 6 +-----
drivers/video/fbdev/core/fbcon.c | 2 --
drivers/video/fbdev/core/fbmem.c | 13 +++++++++++++
drivers/video/fbdev/core/fbsysfs.c | 4 +---
drivers/video/fbdev/ps3fb.c | 5 +----
drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 +----
include/linux/fb.h | 2 ++
7 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_chrdev.c b/drivers/video/fbdev/core/fb_chrdev.c
index 4ebd16b7e3b8..54f926fb411b 100644
--- a/drivers/video/fbdev/core/fb_chrdev.c
+++ b/drivers/video/fbdev/core/fb_chrdev.c
@@ -85,11 +85,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
var.activate &= ~FB_ACTIVATE_KD_TEXT;
console_lock();
lock_fb_info(info);
- ret = fbcon_modechange_possible(info, &var);
- if (!ret)
- ret = fb_set_var(info, &var);
- if (!ret)
- fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
+ ret = fb_set_var_from_user(info, &var);
unlock_fb_info(info);
console_unlock();
if (!ret && copy_to_user(argp, &var, sizeof(var)))
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index b0e3e765360d..50b84cd32938 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2699,7 +2699,6 @@ void fbcon_update_vcs(struct fb_info *info, bool all)
else
fbcon_modechanged(info);
}
-EXPORT_SYMBOL(fbcon_update_vcs);
/* let fbcon check if it supports a new screen resolution */
int fbcon_modechange_possible(struct fb_info *info, struct fb_var_screeninfo *var)
@@ -2727,7 +2726,6 @@ int fbcon_modechange_possible(struct fb_info *info, struct fb_var_screeninfo *va
return 0;
}
-EXPORT_SYMBOL_GPL(fbcon_modechange_possible);
int fbcon_mode_deleted(struct fb_info *info,
struct fb_videomode *mode)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 30f2b59c47bf..d37a1039e221 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -346,6 +346,19 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
}
EXPORT_SYMBOL(fb_set_var);
+int fb_set_var_from_user(struct fb_info *info, struct fb_var_screeninfo *var)
+{
+ int ret = fbcon_modechange_possible(info, var);
+
+ if (!ret)
+ ret = fb_set_var(info, var);
+ if (!ret)
+ fbcon_update_vcs(info, var->activate & FB_ACTIVATE_ALL);
+
+ return ret;
+}
+EXPORT_SYMBOL(fb_set_var_from_user);
+
static void fb_lcd_notify_blank(struct fb_info *info)
{
int power;
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index baa2bae0fb5b..5ece236e6252 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -19,9 +19,7 @@ static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var)
var->activate |= FB_ACTIVATE_FORCE;
console_lock();
lock_fb_info(fb_info);
- err = fb_set_var(fb_info, var);
- if (!err)
- fbcon_update_vcs(fb_info, var->activate & FB_ACTIVATE_ALL);
+ err = fb_set_var_from_user(fb_info, var);
unlock_fb_info(fb_info);
console_unlock();
if (err)
diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
index dbcda307f6a6..1376d19b19ae 100644
--- a/drivers/video/fbdev/ps3fb.c
+++ b/drivers/video/fbdev/ps3fb.c
@@ -29,7 +29,6 @@
#include <linux/freezer.h>
#include <linux/uaccess.h>
#include <linux/fb.h>
-#include <linux/fbcon.h>
#include <linux/init.h>
#include <asm/cell-regs.h>
@@ -830,9 +829,7 @@ static int ps3fb_ioctl(struct fb_info *info, unsigned int cmd,
/* Force, in case only special bits changed */
var.activate |= FB_ACTIVATE_FORCE;
par->new_mode_id = val;
- retval = fb_set_var(info, &var);
- if (!retval)
- fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
+ retval = fb_set_var_from_user(info, &var);
console_unlock();
}
break;
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index 72969fe8e513..e8324b01700f 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -15,7 +15,6 @@
#include <linux/ctype.h>
#include <linux/dma-mapping.h>
#include <linux/delay.h>
-#include <linux/fbcon.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/ioctl.h>
@@ -1768,11 +1767,9 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
var.height = ch->display.height;
var.activate = FB_ACTIVATE_NOW;
- if (fb_set_var(info, &var) < 0)
+ if (fb_set_var_from_user(info, &var) < 0)
/* Couldn't reconfigure, hopefully, can continue as before */
return;
-
- fbcon_update_vcs(info, true);
}
/*
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 5178a33c752c..88680a7cabd5 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -533,6 +533,8 @@ extern int fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var);
extern int fb_pan_display(struct fb_info *info, struct fb_var_screeninfo *var);
extern int fb_blank(struct fb_info *info, int blank);
+int fb_set_var_from_user(struct fb_info *info, struct fb_var_screeninfo *var);
+
/*
* Helpers for framebuffers in I/O memory
*/
--
2.54.0
^ permalink raw reply related
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