On Sat, Sep 10, 2022 at 12:53 AM Fangrui Song wrote:
>
> On 2022-08-30, Fangrui Song wrote:
> >The actual intention is that no dynamic relocation exists. However, some
> >GNU ld ports produce unneeded R_*_NONE. (If a port is not care enough to
> >determine the exact .rel[a].dyn size, the trailing
Hi All,
Looking for what direction we can take here.
Do we want to change all tests in tools/perf/tests/shell except
test_intel_pt.sh to use "bash" or go with
the approach in the patch ? Please share your comments
Thanks
Athira
> On 23-Sep-2022, at 11:54 AM, Adrian Hunter wrote:
>
> On
The testcase “vmlinux-kallsyms.c” fails in powerpc.
vmlinux symtab matches kallsyms: FAILED!
This test look at the symbols in the vmlinux DSO
and check if we find all of them in the kallsyms dso.
But from the powerpc logs , observed that the failure
happens for:
ERR :
On 9/27/22 9:20 PM, Zhuo Chen wrote:
>
>
> On 9/28/22 3:39 AM, Sathyanarayanan Kuppuswamy wrote:
>>
>>
>> On 9/27/22 8:35 AM, Zhuo Chen wrote:
>>> Status bits for ERR_NONFATAL errors only are cleared in
>>> pci_aer_clear_nonfatal_status(), but we want clear uncorrectable
>>> error status in
On 9/28/22 3:39 AM, Sathyanarayanan Kuppuswamy wrote:
On 9/27/22 8:35 AM, Zhuo Chen wrote:
Status bits for ERR_NONFATAL errors only are cleared in
pci_aer_clear_nonfatal_status(), but we want clear uncorrectable
error status in idt_init_pci(), so we change to use
On Wed Sep 28, 2022 at 1:04 AM AEST, Michael Ellerman wrote:
> On little endian the stack frame marker appears reserved when dumping
> memory sequentially, as is typical in xmon or gdb, eg:
>
> c4733e40 ||
> c4733e50
On Wed Sep 28, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote:
> Thank Nick for reviewing my patch
>
> On Tue, Sep 27, 2022 at 12:25 PM Nicholas Piggin wrote:
> >
> > On Tue Sep 27, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote:
> > > This is second version of my fix to PPC's "WARNING: suspicious RCU
> >
On Sun, Sep 11, 2022 at 2:35 AM Vlastimil Babka wrote:
>
> On 9/2/22 01:26, Suren Baghdasaryan wrote:
> > On Thu, Sep 1, 2022 at 1:58 PM Kent Overstreet
> > wrote:
> >>
> >> On Thu, Sep 01, 2022 at 10:34:48AM -0700, Suren Baghdasaryan wrote:
> >> > Resending to fix the issue with the In-Reply-To
On Tue, 2022-09-27 at 06:40 +, Christophe Leroy wrote:
> > + /* Flush on the EA that may be executed in case of a non-
> > coherent icache */
> > + icbi(prog_addr);
>
> prog_addr is a misleading name ? Is that the address at which you
> program it ? Is that the address the
Thank Nick for reviewing my patch
On Tue, Sep 27, 2022 at 12:25 PM Nicholas Piggin wrote:
>
> On Tue Sep 27, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote:
> > This is second version of my fix to PPC's "WARNING: suspicious RCU usage",
> > I improved my fix under Paul E. McKenney's guidance:
> >
The data storage interrupt (DSI) error will be generated when the
paste operation is issued on the suspended Nest Accelerator (NX)
window due to NX state changes. The hypervisor expects the
partition to ignore this error during page fault handling.
To differentiate DSI caused by an actual HW
After commit 96f413f47677("soc/fsl/qbman: fix issue in qman_delete_cgr_safe()"),
no one use struct cgr_comp, so remove it.
Signed-off-by: Yuan Can
---
drivers/soc/fsl/qbman/qman.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
On Tue, Sep 27, 2022 at 03:17:59PM +0300, Andy Shevchenko wrote:
> On Mon, Sep 26, 2022 at 01:25:05PM -0500, Rob Herring wrote:
> > On Mon, Sep 19, 2022 at 5:56 PM Olof Johansson wrote:
> > >
> > > On Mon, Sep 19, 2022 at 1:44 AM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Sun, Sep 18,
On Mon, Sep 26, 2022 at 01:25:05PM -0500, Rob Herring wrote:
> On Mon, Sep 19, 2022 at 5:56 PM Olof Johansson wrote:
> >
> > On Mon, Sep 19, 2022 at 1:44 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Sun, Sep 18, 2022 at 08:44:27PM -0700, Olof Johansson wrote:
> > > > On Tue, Aug 23, 2022 at
Hi,
* Peter Zijlstra [220919 10:08]:
> Hi All!
>
> At long last, a respin of the cpuidle vs rcu cleanup patches.
>
> v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org
>
> These here patches clean up the mess that is cpuidle vs rcuidle.
I just gave these a quick test and
* Peter Zijlstra [220919 10:09]:
> arch_cpu_idle() is a very simple idle interface and exposes only a
> single idle state and is expected to not require RCU and not do any
> tracing/instrumentation.
>
> As such, omap2_pm_idle() is not a valid implementation. Replace it
> with a simple (shallow)
Hi mm and ppc list,
Recently I started to hit a kernel panic [2] rarely on *ppc64le* with *1k
blocksize* ext4. It's not easy to reproduce, but still has chance to trigger
by loop running generic/048 on ppc64le (not sure all kind of ppc64le can
reproduce it).
Although I've reported a bug to ext4
On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
> When the module is unloaded or a GPU is unbound from the module it is
> possible for device private pages to be left mapped in currently running
> processes. This leads to a kernel crash when the pages are either freed
> or accessed from
On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
> nouveau_dmem_fault_copy_one() is used during handling of CPU faults via
> the migrate_to_ram() callback and is used to copy data from GPU to CPU
> memory. It is currently specific to fault handling, however a future
> patch implementing
Nit, the subject should have "tracing:" an not "ftrace:" as the former
encompasses the tracing infrastructure and the latter is for the function
hook part of that.
On Mon, 19 Sep 2022 12:00:12 +0200
Peter Zijlstra wrote:
> CONFIG_GENERIC_ENTRY disallows any and all tracing when RCU isn't
>
On Mon, Sep 19, 2022 at 5:56 PM Olof Johansson wrote:
>
> On Mon, Sep 19, 2022 at 1:44 AM Greg Kroah-Hartman
> wrote:
> >
> > On Sun, Sep 18, 2022 at 08:44:27PM -0700, Olof Johansson wrote:
> > > On Tue, Aug 23, 2022 at 8:37 AM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Thu, Jun 30,
On Tue, Sep 27, 2022 at 10:15 PM Yicong Yang wrote:
>
> On 2022/9/27 14:16, Anshuman Khandual wrote:
> > [...]
> >
> > On 9/21/22 14:13, Yicong Yang wrote:
> >> +static inline bool arch_tlbbatch_should_defer(struct mm_struct *mm)
> >> +{
> >> +/* for small systems with small number of CPUs,
On 9/27/22 8:35 AM, Zhuo Chen wrote:
> Since pci_aer_clear_nonfatal_status() is used only internally, move
> its declaration to the PCI internal header file. Also, no one cares
> about return value of pci_aer_clear_nonfatal_status(), so make it void.
>
> Signed-off-by: Zhuo Chen
> ---
Looks
On 9/27/22 8:35 AM, Zhuo Chen wrote:
> Status bits for ERR_NONFATAL errors only are cleared in
> pci_aer_clear_nonfatal_status(), but we want clear uncorrectable
> error status in lpfc_aer_cleanup_state(), so we change to use
> pci_aer_clear_uncorrect_error_status().
I think you don't need to
On 9/27/22 8:35 AM, Zhuo Chen wrote:
> Status bits for ERR_NONFATAL errors only are cleared in
> pci_aer_clear_nonfatal_status(), but we want clear uncorrectable
> error status in idt_init_pci(), so we change to use
> pci_aer_clear_uncorrect_error_status().
You mean currently driver does not
Hi,
On 9/27/22 8:35 AM, Zhuo Chen wrote:
> Sometimes we need to clear aer uncorrectable error status, so we add
Adding n actual use case will help.
> pci_aer_clear_uncorrect_error_status() to PCI core.
If possible, try to avoid "we" usage in commit log. Just say "so add
Hi,
On 9/27/22 8:35 AM, Zhuo Chen wrote:
> Use pci_aer_clear_nonfatal_status() in dpc_process_error(), which has
> no functional changes.
Just say pci_aer_clear_uncorrect_error_status() clears both fatal and
non-fatal errors. So use it in place of pci_aer_clear_nonfatal_status()
and
This patch converts the driver to newer gpiod API, and away from
OF-specific legacy gpio API that we want to stop using.
While at it, let's address a few more issues:
- switch to using dev_info()/pr_info() and friends
- cancel work when unbinding the driver
Note that the original code handled
On 9/27/22 11:33 AM, Rob Herring wrote:
> On Mon, Sep 26, 2022 at 03:03:13PM -0400, Sean Anderson wrote:
>> This allows multiple phandles to be specified for pcs-handle, such as
>> when multiple PCSs are present for a single MAC. To differentiate
>> between them, also add a pcs-handle-names
On 9/27/22 9:36 AM, Yuan Can wrote:
> [You don't often get email from yuan...@huawei.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> After commit 96f413f47677("soc/fsl/qbman: fix issue in
> qman_delete_cgr_safe()"),
> no one use struct cgr_comp, so
Statements clearing status in aer_enable_rootport() is functionally
equivalent with pcie_clear_device_status() and pci_aer_clear_status().
So we replace them, which has no functional changes.
After commit 20e15e673b05 ("PCI/AER: Add pci_aer_raw_clear_status()
to unconditionally clear Error
When state is pci_channel_io_frozen in pcie_do_recovery(),
the severity is fatal and fatal status should be cleared.
So we add pci_aer_clear_fatal_status().
Signed-off-by: Zhuo Chen
---
drivers/pci/pcie/err.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Use pcie_aer_is_native() in place of "host->native_aer ||
pcie_ports_native" to judge whether OS owns AER in aer_root_reset().
Replace "dev->aer_cap && (pcie_ports_native || host->native_aer)" in
get_port_device_capability() with pcie_aer_is_native(), which has no
functional changes.
pcie_clear_device_status() doesn't check for pcie_aer_is_native()
internally, but after commit 068c29a248b6 ("PCI/ERR: Clear PCIe Device
Status errors only if OS owns AER") and commit aa344bc8b727 ("PCI/ERR:
Clear AER status only when we control AER"), both callers check before
calling it. So we
Since pci_aer_clear_nonfatal_status() is used only internally, move
its declaration to the PCI internal header file. Also, no one cares
about return value of pci_aer_clear_nonfatal_status(), so make it void.
Signed-off-by: Zhuo Chen
---
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/aer.c | 7
Status bits for ERR_NONFATAL errors only are cleared in
pci_aer_clear_nonfatal_status(), but we want clear uncorrectable
error status in lpfc_aer_cleanup_state(), so we change to use
pci_aer_clear_uncorrect_error_status().
Signed-off-by: Zhuo Chen
---
drivers/scsi/lpfc/lpfc_attr.c | 4 ++--
1
Status bits for ERR_NONFATAL errors only are cleared in
pci_aer_clear_nonfatal_status(), but we want clear uncorrectable
error status in idt_init_pci(), so we change to use
pci_aer_clear_uncorrect_error_status().
Signed-off-by: Zhuo Chen
---
drivers/ntb/hw/idt/ntb_hw_idt.c | 4 ++--
1 file
Use pci_aer_clear_nonfatal_status() in dpc_process_error(), which has
no functional changes.
Signed-off-by: Zhuo Chen
---
drivers/pci/pcie/dpc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index 3e9afee02e8d..7942073fbb34
Sometimes we need to clear aer uncorrectable error status, so we add
pci_aer_clear_uncorrect_error_status() to PCI core.
Signed-off-by: Zhuo Chen
---
drivers/pci/pcie/aer.c | 16
include/linux/aer.h| 5 +
2 files changed, 21 insertions(+)
diff --git
Hello.
Here comes patch v2, which contains some fixes and optimizations of
aer api usage. The original version can be found on the mailing list.
Changes since v1:
- Modifications to comments proposed by Bjorn. Split patch into more
obvious parts.
Zhuo Chen (9):
PCI/AER: Add
On Mon, Sep 26, 2022 at 03:03:13PM -0400, Sean Anderson wrote:
> This allows multiple phandles to be specified for pcs-handle, such as
> when multiple PCSs are present for a single MAC. To differentiate
> between them, also add a pcs-handle-names property.
>
> Signed-off-by: Sean Anderson
> ---
Hi
Am 23.09.22 um 09:14 schrieb Geert Uytterhoeven:
Hi Thomas,
On Thu, Sep 22, 2022 at 1:33 PM Thomas Zimmermann wrote:
Open Firmware provides basic display output via the 'display' node.
DT platform code already provides a device that represents the node's
framebuffer. Add a DRM driver for
Now that the stack frame regs marker is only 32-bits it is not as
obvious in memory dumps and easier to miss, eg:
c4733e40 ||
c4733e50 ||
c4733e60
On little endian the stack frame marker appears reserved when dumping
memory sequentially, as is typical in xmon or gdb, eg:
c4733e40 ||
c4733e50 ||
c4733e60
On Mon, 26 Sep 2022 15:03:13 -0400, Sean Anderson wrote:
> This allows multiple phandles to be specified for pcs-handle, such as
> when multiple PCSs are present for a single MAC. To differentiate
> between them, also add a pcs-handle-names property.
>
> Signed-off-by: Sean Anderson
> ---
> This
Argh !! Looks like I sent an old already applied series nested in the
new one.
Ignore those x/4 patches, only look at the x/6 ones.
Le 27/09/2022 à 16:33, Christophe Leroy a écrit :
> This series reduces by 70% the time required to activate
> ftrace on an 8xx with CONFIG_STRICT_KERNEL_RWX.
>
cgel@gmail.com writes:
> From: Lv Ruyi
>
> This function fsl_msi_setup_hwirq() seems to return zero on success and
> non-zero on failure, but it returns zero in error handing path.
I agree it seems wrong, but I can't be sure the current code is wrong,
so unless you're able to test this on
Once init section is freed, attempting to patch init code
ends up in the weed.
Commit 51c3c62b58b3 ("powerpc: Avoid code patching freed init sections")
protected patch_instruction() against that, but it is the responsibility
of the caller to ensure that the patched memory is valid.
All callers
Several fonctions have the same loop for patching instructions.
Introduce function do_patch_entry_fixups() to refactor those loops.
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/feature-fixups.c | 84 ---
1 file changed, 32 insertions(+), 52 deletions(-)
Several fonctions have the same loop for patching instructions.
Introduce function do_patch_fixups() to refactor those loops.
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/feature-fixups.c | 77 +++
1 file changed, 28 insertions(+), 49 deletions(-)
diff
Once init section is freed, attempting to patch init code
ends up in the weed.
Commit 51c3c62b58b3 ("powerpc: Avoid code patching freed init sections")
protected patch_instruction() against that, but it is the responsibility
of the caller to ensure that the patched memory is valid.
In the same
It's only during early startup that poking_init() is not done yet,
for instance when calling ftrace_init().
Once poking_init() has been called there must be a poking area, no
need to check it everytime patch_instruction() is called.
ftrace activation time is reduced by 7% with the change on an
Since commit 591b4b268435 ("powerpc/code-patching: Pre-map patch area")
the patch area is premapped so intermediate page tables are already
allocated.
Use __set_pte_at() directly instead of the heavy map_kernel_page(),
at for unmapping just do a pte_clear() followed by a flush.
__set_pte_at()
Once init is done, initmem is freed forever so no need to
test system_state at every call to patch_instruction().
Use jump_label.
This reduces by 2% the time needed to activate ftrace on an 8xx.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/code-patching.h | 2 ++
No need to have one implementation of patch_instruction() for
CONFIG_STRICT_KERNEL_RWX and one for !CONFIG_STRICT_KERNEL_RWX.
In patch_instruction(), call raw_patch_instruction() when
!CONFIG_STRICT_KERNEL_RWX.
In poking_init(), bail out immediately, it will be equivalent
to the weak default
virt_to_kpte() checks pmd_none() and returns NULL in that case.
__do_patch_instruction() doesn't expect the pmd to be none and
doesn't handle the case anyway.
So avoid the pmd_none() check by using pte_offset_kernel()
directly.
It improves ftrace activation by approx 1% on an 8xx.
If CONFIG_MODULES is not set, there is no point in checking
whether text is in module area.
This reduced the time needed to activate/deactivate ftrace
by more than 10% on an 8xx.
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/code-patching.c | 2 +-
1 file changed, 1 insertion(+), 1
This series reduces by 70% the time required to activate
ftrace on an 8xx with CONFIG_STRICT_KERNEL_RWX.
Measure is performed in function ftrace_replace_code() using mftb()
around the loop.
With the series,
- Without CONFIG_STRICT_KERNEL_RWX, 416000 TB ticks are measured.
- With
Christophe Leroy writes:
> Le 26/09/2022 à 05:40, Nicholas Piggin a écrit :
>> Using a 32-bit constant for this marker allows it to be loaded with
>> two ALU instructions, like 32-bit. This avoids a TOC entry and a
>> TOC load that depends on the r2 value that has just been loaded from
>> the
On 9/27/22 2:09 AM, Bjorn Helgaas wrote:
On Mon, Sep 26, 2022 at 10:01:55PM +0800, Zhuo Chen wrote:
On 9/23/22 5:08 AM, Bjorn Helgaas wrote:
On Fri, Sep 02, 2022 at 02:16:33AM +0800, Zhuo Chen wrote:
When state is pci_channel_io_frozen in pcie_do_recovery(),
the severity is fatal and fatal
On Tue, Sep 27, 2022 at 01:22:11PM +0530, Srikar Dronamraju wrote:
> Commit 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section
> failures")
> can cause scripts/faddr2line to fail on ppc64le machines on few
> distributions, while working on other distributions. The failure can be
>
On Fri, 23 Sep 2022 18:15:47 +0800, Shengjiu Wang wrote:
> From: Sascha Hauer
>
> The driver uses two statically ininitialized struct dma_slave_config,
> but only one of them is initialized to zero. Initialize config_be to
> zero as well to make sure that no fields are filled with random values.
On 2022/9/27 14:16, Anshuman Khandual wrote:
> [...]
>
> On 9/21/22 14:13, Yicong Yang wrote:
>> +static inline bool arch_tlbbatch_should_defer(struct mm_struct *mm)
>> +{
>> +/* for small systems with small number of CPUs, TLB shootdown is cheap
>> */
>> +if (num_online_cpus() <= 4)
>
Commit 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section
failures")
can cause scripts/faddr2line to fail on ppc64le machines on few
distributions, while working on other distributions. The failure can be
attributed to difference in readelf output on various distributions.
$
On Tue, Sep 27, 2022 at 11:39:52AM +0900, AKASHI Takahiro wrote:
> On Mon, Sep 26, 2022 at 09:40:25AM +0200, Michal Such??nek wrote:
> > On Mon, Sep 26, 2022 at 08:47:32AM +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Sep 24, 2022 at 01:55:23PM +0200, Michal Suchánek wrote:
> > > > On Sat, Sep
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
branch HEAD: 725963f3e89679894d3f33ce73f2d5b8eca3ec7c powerpc/64e: provide an
addressing macro for use with TOC in alternate register
elapsed time: 944m
configs tested: 63
configs skipped: 2
The
Le 26/09/2022 à 08:43, Benjamin Gray a écrit :
> Adds a generic text patching mechanism for patches of 1, 2, 4, or (64-bit) 8
> bytes. The patcher conditionally syncs the icache depending on if
> the content will be executed (as opposed to, e.g., read-only data).
>
> The `patch_instruction`
Le 26/09/2022 à 08:43, Benjamin Gray a écrit :
> Adds a generic text patching mechanism for patches of 1, 2, 4, or (64-bit) 8
> bytes. The patcher conditionally syncs the icache depending on if
> the content will be executed (as opposed to, e.g., read-only data).
>
> The `patch_instruction`
[...]
On 9/21/22 14:13, Yicong Yang wrote:
> +static inline bool arch_tlbbatch_should_defer(struct mm_struct *mm)
> +{
> + /* for small systems with small number of CPUs, TLB shootdown is cheap
> */
> + if (num_online_cpus() <= 4)
It would be great to have some more inputs from others,
Le 27/09/2022 à 07:18, Benjamin Gray a écrit :
> On Mon, 2022-09-26 at 13:16 +, Christophe Leroy wrote:
>> Build failure with GCC 5.5 (ppc64le_defconfig):
>>
>> CC arch/powerpc/kernel/ptrace/ptrace.o
>> {standard input}: Assembler messages:
>> {standard input}:10: Error: .localentry
Le 27/09/2022 à 05:31, Benjamin Gray a écrit :
> On Mon, 2022-09-26 at 14:55 +, Christophe Leroy wrote:
>>> +config PPC_STATIC_CALL_KUNIT_TEST
>>> + tristate "KUnit tests for PPC64 ELF ABI V2 static calls"
>>> + default KUNIT_ALL_TESTS
>>> + depends on HAVE_STATIC_CALL &&
This switches PIKA Warp away from legacy gpio API and to newer gpiod
API, so that we can eventually deprecate the former.
Because LEDs are normally driven by leds-gpio driver, but the
platform code also wants to access the LEDs during thermal shutdown,
and gpiod API does not allow locating GPIO
Le 27/09/2022 à 05:21, Benjamin Gray a écrit :
> On Mon, 2022-09-26 at 14:54 +, Christophe Leroy wrote:
>>> diff --git a/arch/powerpc/kernel/static_call.c
>>> b/arch/powerpc/kernel/static_call.c
>>> index 863a7aa24650..ecbb74e1b4d3 100644
>>> --- a/arch/powerpc/kernel/static_call.c
>>> +++
On Mon, Sep 26, 2022 at 08:41:53PM +1000, Michael Ellerman wrote:
> Christophe Leroy writes:
> > Hi Dmitry
> >
> > Le 25/09/2022 à 07:06, Dmitry Torokhov a écrit :
> >> Hi Michael, Nick,
> >>
> >> I was wondering if PIKA Warp board still relevant. The reason for my
> >> question is that I am
74 matches
Mail list logo
