On Tue, Jun 11, 2024 at 07:00:14PM +, LEROY Christophe wrote:
> We have space available in PMD if we need more flags, but in PTE I can't
> see anything possible without additional churn that would require
> additional instructions in TLB miss handlers, which is what I want to
> avoid most.
>
On Mon, Jun 10, 2024 at 07:55:01AM +0200, Christophe Leroy wrote:
> On book3s/64, the only user of hugepd is hash in 4k mode.
>
> All other setups (hash-64, radix-4, radix-64) use leaf PMD/PUD.
>
> Rework hash-4k to use contiguous PMD and PUD instead.
>
> In that setup there are only two huge pa
On Tue, Jun 11, 2024 at 02:51:24PM +0900, Damien Le Moal wrote:
> > + if (sdkp->device->type == TYPE_ZBC)
>
> Nit: use sd_is_zoned() here ?
Actually - is there much in even keeping sd_is_zoned now that the
host aware support is removed? Just open coding the type check isn't
any more code, and
Linus Torvalds writes:
> On Sun, 9 Jun 2024 at 19:45, Al Viro wrote:
>>
>> Unless I'm misreading that code (entirely possible), this fdput() shouldn't
>> be done until we are done with stt.
>
> Ack. That looks right to me.
>
> If I follow it right, the lifetime of stt is tied to the lifetime of
>
https://bugzilla.kernel.org/show_bug.cgi?id=218858
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Co
https://bugzilla.kernel.org/show_bug.cgi?id=218905
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=216156
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=216156
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Yo
"Nysal Jan K.A." writes:
> From: "Nysal Jan K.A"
>
> After the addition of HOTPLUG_SMT support for PowerPC [1] there was a
> regression reported [2] when enabling SMT.
This implies it was a kernel regression. But it can't be a kernel
regression because previously there was no support at all for
On Wed, Jun 12, 2024 at 03:37:55PM -0700, Paul E. McKenney wrote:
> On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
> > On Sun, 9 Jun 2024 10:27:12 +0200 Julia Lawall wrote:
> > > Since SLOB was removed, it is not necessary to use call_rcu
> > > when the callback only performs kmem
On Thu, Jun 13, 2024 at 09:34:10PM +1000, Michael Ellerman wrote:
> "Nysal Jan K.A." writes:
> > From: "Nysal Jan K.A"
> >
> > After the addition of HOTPLUG_SMT support for PowerPC [1] there was a
> > regression reported [2] when enabling SMT.
>
> This implies it was a kernel regression. But it
Hi Michael,
Can you please share your review comments on this patch when you get a chance?
On 28/05/24 09:33, Anjali K wrote:
> Currently in some cases, when the sampled instruction address register
> latches to a specific address during sampling, the privilege bits captured
> in the sampled event
On Wed, Jun 12, 2024 at 08:38:02PM -0700, Paul E. McKenney wrote:
> o Make the current kmem_cache_destroy() asynchronously wait for
> all memory to be returned, then complete the destruction.
> (This gets rid of a valuable debugging technique because
> in normal use, it is a b
On Thu, Jun 13, 2024 at 01:58:59PM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 12, 2024 at 03:37:55PM -0700, Paul E. McKenney wrote:
> > On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
> > > On Sun, 9 Jun 2024 10:27:12 +0200 Julia Lawall wrote:
> > > > Since SLOB was removed, it
On Thu, Jun 13, 2024 at 05:47:08AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 13, 2024 at 01:58:59PM +0200, Jason A. Donenfeld wrote:
> > On Wed, Jun 12, 2024 at 03:37:55PM -0700, Paul E. McKenney wrote:
> > > On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
> > > > On Sun, 9 Jun
On 6/11/24 8:18 AM, Michael Ellerman wrote:
Hi Ganesh,
Ganesh Goudar writes:
If a PCI device is removed during eeh_pe_report_edev(), edev->pdev
will change and can cause a crash, hold the PCI rescan/remove lock
while taking a copy of edev->pdev.
Signed-off-by: Ganesh Goudar
---
arch/power
On Thu, Jun 13, 2024 at 05:46:11AM -0700, Paul E. McKenney wrote:
> How about a kmem_cache_destroy_rcu() that marks that specified cache
> for destruction, and then a kmem_cache_destroy_barrier() that waits?
>
> I took the liberty of adding your name to the Google document [1] and
> adding this se
On Wed, 12 Jun 2024 20:38:02 -0700 Paul E. McKenney wrote:
> o Make rcu_barrier() wait for kfree_rcu() objects. (This is
> surprisingly complex and will wait unnecessarily in some cases.
> However, it does preserve current code.)
Not sure how much mental capacity for API variation
If a PCI device is removed during eeh_pe_report_edev(), edev->pdev
will change and can cause a crash, hold the PCI rescan/remove lock
while taking a copy of edev->pdev.
Signed-off-by: Ganesh Goudar
---
v2: Hold rescan lock till we get the bus address.
---
arch/powerpc/kernel/eeh_pe.c | 7 +--
On Wed, Jun 12, 2024 at 05:56:15PM +0200, Roger Pau Monné wrote:
> Right. AFAICT advertising "feature-barrier" and/or
> "feature-flush-cache" could be done based on whether blkback
> understand those commands, not on whether the underlying storage
> supports the equivalent of them.
>
> Worst case
On Thu, Jun 13, 2024 at 07:17:38AM -0700, Jakub Kicinski wrote:
> On Wed, 12 Jun 2024 20:38:02 -0700 Paul E. McKenney wrote:
> > o Make rcu_barrier() wait for kfree_rcu() objects. (This is
> > surprisingly complex and will wait unnecessarily in some cases.
> > However, it does preserve c
…
> +++ b/drivers/pci/endpoint/pci-epc-core.c
…
> +void pci_epc_deinit_notify(struct pci_epc *epc)
> +{
…
> + mutex_lock(&epc->list_lock);
> + list_for_each_entry(epf, &epc->pci_epf, list) {
> + mutex_lock(&epf->lock);
> + if (epf->event_ops && epf->event_ops->epc_de
Le 13/06/2024 à 09:19, Oscar Salvador a écrit :
> On Tue, Jun 11, 2024 at 07:00:14PM +, LEROY Christophe wrote:
>> We have space available in PMD if we need more flags, but in PTE I can't
>> see anything possible without additional churn that would require
>> additional instructions in TLB mi
On Thu, Jun 13, 2024 at 04:11:52PM +0200, Jason A. Donenfeld wrote:
> On Thu, Jun 13, 2024 at 05:46:11AM -0700, Paul E. McKenney wrote:
> > How about a kmem_cache_destroy_rcu() that marks that specified cache
> > for destruction, and then a kmem_cache_destroy_barrier() that waits?
> >
> > I took t
On Sat, 01 Jun 2024 00:17:13 -0300, MarileneGarcia wrote:
> Use __free for device_node values, and thus drop calls to
> of_node_put.
>
> The variable attribute __free adds a scope based cleanup to
> the device node. The goal is to reduce memory management issues
> in the kernel code.
>
> [...]
A
On Thu, Jun 13, 2024 at 08:06:30AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 13, 2024 at 03:06:54PM +0200, Uladzislau Rezki wrote:
> > On Thu, Jun 13, 2024 at 05:47:08AM -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 13, 2024 at 01:58:59PM +0200, Jason A. Donenfeld wrote:
> > > > On Wed, Jun 1
On Thu, Jun 13, 2024 at 10:45:59AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 13, 2024 at 07:38:59PM +0200, Uladzislau Rezki wrote:
> > On Thu, Jun 13, 2024 at 08:06:30AM -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 13, 2024 at 03:06:54PM +0200, Uladzislau Rezki wrote:
> > > > On Thu, Jun 13,
On Thu, Jun 13, 2024 at 07:58:17PM +0200, Uladzislau Rezki wrote:
> On Thu, Jun 13, 2024 at 10:45:59AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 13, 2024 at 07:38:59PM +0200, Uladzislau Rezki wrote:
> > > On Thu, Jun 13, 2024 at 08:06:30AM -0700, Paul E. McKenney wrote:
> > > > On Thu, Jun 13,
Add support for TIF_NOTIFY_IPI on PowerPC. With TIF_NOTIFY_IPI, a sender
sending an IPI to an idle CPU in TIF_POLLING mode will set the
TIF_NOTIFY_IPI flag in the target's idle tasks's thread_info to pull the
CPU out of idle, as opposed to setting TIF_NEED_RESCHED previously. This
avoids spurious c
On Thu, Jun 13, 2024 at 07:38:59PM +0200, Uladzislau Rezki wrote:
> On Thu, Jun 13, 2024 at 08:06:30AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 13, 2024 at 03:06:54PM +0200, Uladzislau Rezki wrote:
> > > On Thu, Jun 13, 2024 at 05:47:08AM -0700, Paul E. McKenney wrote:
> > > > On Thu, Jun 13,
On Fri, 07 Jun 2024, Marilene Andrade Garcia wrote:
> On 01/06/2024 00:17, MarileneGarcia wrote:
> > Use __free for device_node values, and thus drop calls to
> > of_node_put.
> >
> > The variable attribute __free adds a scope based cleanup to
> > the device node. The goal is to reduce memory man
Hi,
On 5/9/24 1:48 AM, Zhenzhong Duan wrote:
> In some cases the detector of a Non-Fatal Error(NFE) is not the most
> appropriate agent to determine the type of the error. For example,
> when software performs a configuration read from a non-existent
> device or Function, completer will send an ER
On 5/9/24 1:48 AM, Zhenzhong Duan wrote:
> When an Advisory Non-Fatal error(ANFE) triggers, both correctable error(CE)
> status and ANFE related uncorrectable error(UE) status will be printed:
>
> AER: Correctable error message received from :b7:02.0
> PCIe Bus Error: severity=Correctable
ftrace_location() was changed to not only return the __fentry__ location
when called for the __fentry__ location, but also when called for the
sym+0 location after commit aebfd12521d9 ("x86/ibt,ftrace: Search for
__fentry__ location"). That is, if sym+0 location is not __fentry__,
ftrace_location()
When a weak type function is overridden, its symbol will be removed
from the symbol table, but its code will not been removed. It will
cause find_kallsyms_symbol() to compute a larger function size than
it actually is, just because symbol of its following weak function is
removed.
To fix this issu
ftrace_location() was changed to not only return the __fentry__ location
when called for the __fentry__ location, but also when called for the
sym+0 location after commit aebfd12521d9 ("x86/ibt,ftrace: Search for
__fentry__ location"). That is, if sym+0 location is not __fentry__,
ftrace_location()
Array 'table' is used to store pointers of symbols that read from in.map
file, and its size depends on the number of symbols. Currently 'table'
is expanded by calling realloc() every 1 symbols read.
However, there generally are around 10+ symbols, which means that
the expansion is generall
In ftrace_process_locs(), a series pages are prepared and linked in
start_pg, then fentry records are skipped or added, then unused pages
are freed.
However, assume that all records are skipped, currently the start_pg
will still be in list of ftrace_pages_start but without any record.
Then in ftra
When a weak type function is overridden, its symbol will be removed
from the symbol table, but its code will not be removed. Besides,
due to lacking of size for kallsyms, kernel compute function size by
substracting its symbol address from its next symbol address (see
kallsyms_lookup_size_offset())
After patch titled "ftrace: Skip invalid __fentry__ in
ftrace_process_locs()", __fentry__ locations in overridden weak function
have been checked and skipped, then all records in ftrace_pages are
valid, the FTRACE_MCOUNT_MAX_OFFSET workaround can be reverted, include:
1. commit b39181f7c690 ("ftra
Hello everyone,
Before jumping into the issue, let me clarify the Cc list. Everyone have
been cc'ed on Patch 0 through Patch 3. Respective arch maintainers,
reviewers, and committers returned by scripts/get_maintainer.pl have
been cc'ed on the respective arch side changes. Scheduler and CPU Idle
m
From: "Gautham R. Shenoy"
Introduce the notion of TIF_NOTIFY_IPI flag. When a processor in
TIF_POLLING mode needs to process an IPI, the sender sets NEED_RESCHED
bit in idle task's thread_info to pull the target out of idle and avoids
sending an interrupt to the idle CPU. When NEED_RESCHED is set
From: "Gautham R. Shenoy"
Currently TIF_NEED_RESCHED is being overloaded, to wakeup an idle CPU in
TIF_POLLING mode to service an IPI even if there are no new tasks being
woken up on the said CPU.
In preparation of a proper fix, introduce a new helper
"need_resched_or_ipi()" which is intended to
From: "Gautham R. Shenoy"
Problem statement
=
When measuring IPI throughput using a modified version of Anton
Blanchard's ipistorm benchmark [1], configured to measure time taken to
perform a fixed number of smp_call_function_single() (with wait set to
1), an increase in benchmar
On Wed Jun 12, 2024 at 6:28 PM AEST, Segher Boessenkool wrote:
> On Wed, Jun 12, 2024 at 02:42:32PM +1000, Nicholas Piggin wrote:
> > arm, powerpc, riscv, build .aux.o targets with implicit pattern rules
> > in dependency chains that cause them to be made as intermediate files,
> > which get remove
On Wed Jun 12, 2024 at 5:26 PM AEST, Andrew Jones wrote:
> On Wed, Jun 12, 2024 at 03:23:17PM GMT, Nicholas Piggin wrote:
> > run_qemu_status() looks for "EXIT: STATUS=%d" if the harness command
> > returned 1, to determine the final status of the test. In the case of
> > panic tests, QEMU should t
On Fri, Jun 14, 2024 at 10:43:39AM +1000, Nicholas Piggin wrote:
> On Wed Jun 12, 2024 at 6:28 PM AEST, Segher Boessenkool wrote:
> > On Wed, Jun 12, 2024 at 02:42:32PM +1000, Nicholas Piggin wrote:
> > > arm, powerpc, riscv, build .aux.o targets with implicit pattern rules
> > > in dependency chai
On 5/9/24 1:48 AM, Zhenzhong Duan wrote:
> When processing an ANFE, ideally both correctable error(CE) status and
> uncorrectable error(UE) status should be cleared. However, there is no
> way to fully identify the UE associated with ANFE. Even worse, Non-Fatal
> Error(NFE) may set the same UE st
Hi
>-Original Message-
>From: Kuppuswamy Sathyanarayanan
>
>Subject: Re: [PATCH v4 1/3] PCI/AER: Store UNCOR_STATUS bits that might
>be ANFE in aer_err_info
>
>Hi,
>
>On 5/9/24 1:48 AM, Zhenzhong Duan wrote:
>> In some cases the detector of a Non-Fatal Error(NFE) is not the most
>> appropr
>-Original Message-
>From: Kuppuswamy, Sathyanarayanan
>Subject: Re: [PATCH v4 3/3] PCI/AER: Clear UNCOR_STATUS bits that might
>be ANFE
>
>
>On 5/9/24 1:48 AM, Zhenzhong Duan wrote:
>> When processing an ANFE, ideally both correctable error(CE) status and
>> uncorrectable error(UE) statu
On 6/13/24 7:39 PM, Duan, Zhenzhong wrote:
> Hi
>
>> -Original Message-
>> From: Kuppuswamy Sathyanarayanan
>>
>> Subject: Re: [PATCH v4 1/3] PCI/AER: Store UNCOR_STATUS bits that might
>> be ANFE in aer_err_info
>>
>> Hi,
>>
>> On 5/9/24 1:48 AM, Zhenzhong Duan wrote:
>>> In some cases
>-Original Message-
>From: Kuppuswamy Sathyanarayanan
>
>Subject: Re: [PATCH v4 1/3] PCI/AER: Store UNCOR_STATUS bits that might
>be ANFE in aer_err_info
>
>
>On 6/13/24 7:39 PM, Duan, Zhenzhong wrote:
>> Hi
>>
>>> -Original Message-
>>> From: Kuppuswamy Sathyanarayanan
>>>
>>> S
On 6/13/24 7:40 PM, Duan, Zhenzhong wrote:
>
>> -Original Message-
>> From: Kuppuswamy, Sathyanarayanan
>> Subject: Re: [PATCH v4 3/3] PCI/AER: Clear UNCOR_STATUS bits that might
>> be ANFE
>>
>>
>> On 5/9/24 1:48 AM, Zhenzhong Duan wrote:
>>> When processing an ANFE, ideally both correct
>-Original Message-
>From: Kuppuswamy Sathyanarayanan
>
>Subject: Re: [PATCH v4 3/3] PCI/AER: Clear UNCOR_STATUS bits that might
>be ANFE
>
>
>On 6/13/24 7:40 PM, Duan, Zhenzhong wrote:
>>
>>> -Original Message-
>>> From: Kuppuswamy, Sathyanarayanan
>>> Subject: Re: [PATCH v4 3/3]
On Thu, Jun 13, 2024 at 09:34:10PM GMT, Michael Ellerman wrote:
> "Nysal Jan K.A." writes:
> > From: "Nysal Jan K.A"
> >
> > After the addition of HOTPLUG_SMT support for PowerPC [1] there was a
> > regression reported [2] when enabling SMT.
>
> This implies it was a kernel regression. But it ca
55 matches
Mail list logo
