Re: [PATCH V3] perf test: Fix parse-events tests to skip parametrized events
On Wed, Sep 27, 2023 at 11:17 AM Athira Rajeev
wrote:
>
> Testcase "Parsing of all PMU events from sysfs" parse events for
> all PMUs, and not just cpu. In case of powerpc, the PowerVM
> environment supports events from hv_24x7 and hv_gpci PMU which
> is of example format like below:
>
> - hv_24x7/CPM_ADJUNCT_INST,domain=?,core=?/
> - hv_gpci/event,partition_id=?/
>
> The value for "?" needs to be filled in depending on system
> configuration. It is better to skip these parametrized events
> in this test as it is done in:
> 'commit b50d691e50e6 ("perf test: Fix "all PMU test" to skip
> parametrized events")' which handled a simialr instance with
> "all PMU test".
>
> Fix parse-events test to skip parametrized events since
> it needs proper setup of the parameters.
>
> Signed-off-by: Athira Rajeev
> Tested-by: Ian Rogers
> Tested-by: Sachin Sant
> Reviewed-by: Kajol Jain
Applied to perf-tools-next, thanks!
Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers
On Thu, 28 Sept 2023 at 20:50, Amir Goldstein wrote: > > OTOH, it is perfectly fine if the vfs wants to stop providing sub 100ns > services to filesystems. It's just going to be the fs problem and the > preserved pre-historic/fine-grained time on existing files would only > need to be provided in getattr(). It does not need to be in __i_mtime. Hmm. That sounds technically sane, but for one thing: if the aim is to try to do (a) atomic timestamp access (b) shrink the inode then having the filesystem maintain its own timestamp for fine-grained data will break both of those goals. Yes, we'd make 'struct inode' smaller if we pack the times into one 64-bit entity, but if btrfs responds by adding mtime fields to "struct btrfs_inode", we lost the size advantage and only made things worse. And if ->getattr() then reads those fields without locking (and we definitely don't want locking in that path), then we lost the atomicity thing too. So no. A "but the filesystem can maintain finer granularity" model is not acceptable, I think. If we do require nanoseconds for compatibility, what we could possibly do is say "we guarantee nanosecond values for *legacy* dates", and say that future dates use 100ns resolution. We'd define "legacy dates" to be the traditional 32-bit signed time_t. So with a 64-bit fstime_t, we'd have the "legacy format": - top 32 bits are seconds, bottom 32 bits are ns which gives us that ns format. Then, because only 30 bits are needed for nanosecond resolution, we use the top two bits of that ns field as flags. '00' means that legacy format, and '01' would mean "we're not doing nanosecond resolution, we're doing 64ns resolution, and the low 6 bits of the ns field are actually bits 32-37 of the seconds field". That still gives us some extensibility (unless the multi-grain code still wants to use the other top bit), and it gives us 40 bits of seconds, which is quite a lot. And all the conversion functions will be simple bit field manipulations, so there are no expensive ops here. Anyway, I agree with the "let's introduce the accessor functions first, we can do the 'pack into one word' decisions later". Linus
Re: [PATCH v6 4/9] mm: thp: Introduce anon_orders and anon_always_mask sysfs files
On Fri, 29 Sep 2023 12:44:15 +0100 Ryan Roberts wrote:
> In preparation for adding support for anonymous large folios that are
> smaller than the PMD-size, introduce 2 new sysfs files that will be used
> to control the new behaviours via the transparent_hugepage interface.
> For now, the kernel still only supports PMD-order anonymous THP, so when
> reading back anon_orders, it will reflect that. Therefore there are no
> behavioural changes intended here.
powerpc strikes again. ARCH=powerpc allmodconfig:
In file included from ./include/linux/bits.h:6,
from ./include/linux/ratelimit_types.h:5,
from ./include/linux/printk.h:9,
from ./include/asm-generic/bug.h:22,
from ./arch/powerpc/include/asm/bug.h:116,
from ./include/linux/bug.h:5,
from ./include/linux/mmdebug.h:5,
from ./include/linux/mm.h:6,
from mm/huge_memory.c:8:
./include/vdso/bits.h:7:33: error: initializer element is not constant
7 | #define BIT(nr) (UL(1) << (nr))
| ^
mm/huge_memory.c:77:47: note: in expansion of macro 'BIT'
77 | unsigned int huge_anon_orders __read_mostly = BIT(PMD_ORDER);
| ^~~
We keep tripping over this. I wish there was a way to fix it.
Style whine: an all-caps identifier is supposed to be a constant,
dammit.
#define PTE_INDEX_SIZE __pte_index_size
Nope.
I did this:
---
a/mm/huge_memory.c~mm-thp-introduce-anon_orders-and-anon_always_mask-sysfs-files-fix
+++ a/mm/huge_memory.c
@@ -74,7 +74,7 @@ static unsigned long deferred_split_scan
static atomic_t huge_zero_refcount;
struct page *huge_zero_page __read_mostly;
unsigned long huge_zero_pfn __read_mostly = ~0UL;
-unsigned int huge_anon_orders __read_mostly = BIT(PMD_ORDER);
+unsigned int huge_anon_orders __read_mostly;
static unsigned int huge_anon_always_mask __read_mostly;
/**
@@ -528,6 +528,9 @@ static int __init hugepage_init_sysfs(st
{
int err;
+ /* powerpc's PMD_ORDER isn't a compile-time constant */
+ huge_anon_orders = BIT(PMD_ORDER);
+
*hugepage_kobj = kobject_create_and_add("transparent_hugepage",
mm_kobj);
if (unlikely(!*hugepage_kobj)) {
pr_err("failed to create transparent hugepage kobject\n");
_
I assume this is set up early enough.
I don't know why powerpc's PTE_INDEX_SIZE is variable. Hopefully it
has been set up by this time and it won't get altered.
Re: [PATCH v2 1/2] mm: hugetlb: Add huge page size param to set_huge_pte_at()
On Fri, Sep 22, 2023 at 12:58:03PM +0100, Ryan Roberts wrote:
> In order to fix a bug, arm64 needs to be told the size of the huge page
> for which the pte is being set in set_huge_pte_at(). Provide for this by
> adding an `unsigned long sz` parameter to the function. This follows the
> same pattern as huge_pte_clear().
>
> This commit makes the required interface modifications to the core mm as
> well as all arches that implement this function (arm64, parisc, powerpc,
> riscv, s390, sparc). The actual arm64 bug will be fixed in a separate
> commit.
>
> No behavioral changes intended.
>
> Signed-off-by: Ryan Roberts
> Cc: # 6.5+
> ---
> arch/arm64/include/asm/hugetlb.h | 2 +-
> arch/arm64/mm/hugetlbpage.c | 6 ++-
> arch/parisc/include/asm/hugetlb.h | 2 +-
> arch/parisc/mm/hugetlbpage.c | 2 +-
> .../include/asm/nohash/32/hugetlb-8xx.h | 3 +-
> arch/powerpc/mm/book3s64/hugetlbpage.c| 5 ++-
> arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 3 +-
> arch/powerpc/mm/nohash/8xx.c | 3 +-
> arch/powerpc/mm/pgtable.c | 3 +-
> arch/riscv/include/asm/hugetlb.h | 3 +-
> arch/riscv/mm/hugetlbpage.c | 3 +-
> arch/s390/include/asm/hugetlb.h | 6 ++-
> arch/s390/mm/hugetlbpage.c| 8 +++-
> arch/sparc/include/asm/hugetlb.h | 6 ++-
> arch/sparc/mm/hugetlbpage.c | 8 +++-
> include/asm-generic/hugetlb.h | 2 +-
> include/linux/hugetlb.h | 6 ++-
> mm/damon/vaddr.c | 3 +-
> mm/hugetlb.c | 43 +++
> mm/migrate.c | 7 ++-
> mm/rmap.c | 23 +++---
> mm/vmalloc.c | 2 +-
> 22 files changed, 100 insertions(+), 49 deletions(-)
>
> diff --git a/arch/arm64/include/asm/hugetlb.h
> b/arch/arm64/include/asm/hugetlb.h
> index f43a38ac1779..2ddc33d93b13 100644
> --- a/arch/arm64/include/asm/hugetlb.h
> +++ b/arch/arm64/include/asm/hugetlb.h
> @@ -28,7 +28,7 @@ pte_t arch_make_huge_pte(pte_t entry, unsigned int shift,
> vm_flags_t flags);
> #define arch_make_huge_pte arch_make_huge_pte
> #define __HAVE_ARCH_HUGE_SET_HUGE_PTE_AT
> extern void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
> - pte_t *ptep, pte_t pte);
> + pte_t *ptep, pte_t pte, unsigned long sz);
> #define __HAVE_ARCH_HUGE_PTEP_SET_ACCESS_FLAGS
> extern int huge_ptep_set_access_flags(struct vm_area_struct *vma,
> unsigned long addr, pte_t *ptep,
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 9c52718ea750..a7f8c8db3425 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -249,7 +249,7 @@ static inline struct folio
> *hugetlb_swap_entry_to_folio(swp_entry_t entry)
> }
>
> void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
> - pte_t *ptep, pte_t pte)
> + pte_t *ptep, pte_t pte, unsigned long sz)
> {
> size_t pgsize;
> int i;
> @@ -571,5 +571,7 @@ pte_t huge_ptep_modify_prot_start(struct vm_area_struct
> *vma, unsigned long addr
> void huge_ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long
> addr, pte_t *ptep,
> pte_t old_pte, pte_t pte)
> {
> - set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
> + unsigned long psize = huge_page_size(hstate_vma(vma));
> +
> + set_huge_pte_at(vma->vm_mm, addr, ptep, pte, psize);
> }
> diff --git a/arch/parisc/include/asm/hugetlb.h
> b/arch/parisc/include/asm/hugetlb.h
> index f7f078c2872c..72daacc472a0 100644
> --- a/arch/parisc/include/asm/hugetlb.h
> +++ b/arch/parisc/include/asm/hugetlb.h
> @@ -6,7 +6,7 @@
>
> #define __HAVE_ARCH_HUGE_SET_HUGE_PTE_AT
> void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
> - pte_t *ptep, pte_t pte);
> + pte_t *ptep, pte_t pte, unsigned long sz);
>
> #define __HAVE_ARCH_HUGE_PTEP_GET_AND_CLEAR
> pte_t huge_ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
> diff --git a/arch/parisc/mm/hugetlbpage.c b/arch/parisc/mm/hugetlbpage.c
> index a8a1a7c1e16e..a9f7e21f6656 100644
> --- a/arch/parisc/mm/hugetlbpage.c
> +++ b/arch/parisc/mm/hugetlbpage.c
> @@ -140,7 +140,7 @@ static void __set_huge_pte_at(struct mm_struct *mm,
> unsigned long addr,
> }
>
> void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
> - pte_t *ptep, pte_t entry)
> + pte_t *ptep, pte_t entry, unsigned long sz)
> {
> __set_huge_pte_at(mm, addr, ptep, entry);
> }
> diff --git a/arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h
> b/arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h
>
Re: [PATCH v2] hwmon: (ibmpowernv) refactor deprecated strncpy
On Tue, 19 Sep 2023 05:22:51 +, Justin Stitt wrote:
> `strncpy` is deprecated for use on NUL-terminated destination strings [1].
>
> A suitable replacement is `memcpy` as we've already precisely calculated
> the number of bytes to copy while `buf` has been explicitly
> zero-initialized:
> | char buf[8] = { 0 };
>
> [...]
Applied to for-next/hardening, thanks! (I've updated the Subject here
and with the older "refactor" subjects...)
Take care,
--
Kees Cook
[PATCH 1/2] powerpc/platforms/pseries: Fix STK_PARAM access in the hcall tracing code
In powerpc pseries system, below behaviour is observed while
enabling tracing on hcall:
# cd /sys/kernel/debug/tracing/
# cat events/powerpc/hcall_exit/enable
0
# echo 1 > events/powerpc/hcall_exit/enable
# ls
-bash: fork: Bad address
Above is from power9 lpar with latest kernel. Past this, softlockup
is observed. Initially while attempting via perf_event_open to
use "PERF_TYPE_TRACEPOINT", kernel panic was observed.
perf config used:
memset([1],0,sizeof(struct perf_event_attr));
pe[1].type=PERF_TYPE_TRACEPOINT;
pe[1].size=96;
pe[1].config=0x26ULL; /* 38 raw_syscalls/sys_exit */
pe[1].sample_type=0; /* 0 */
pe[1].read_format=PERF_FORMAT_TOTAL_TIME_ENABLED|PERF_FORMAT_TOTAL_TIME_RUNNING|PERF_FORMAT_ID|PERF_FORMAT_GROUP|0x10ULL;
/* 1f */
pe[1].inherit=1;
pe[1].precise_ip=0; /* arbitrary skid */
pe[1].wakeup_events=0;
pe[1].bp_type=HW_BREAKPOINT_EMPTY;
pe[1].config1=0x1ULL;
Kernel panic logs:
==
Kernel attempted to read user page (8) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x0008
Faulting instruction address: 0xc04c2814
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: nfnetlink bonding tls rfkill sunrpc dm_service_time
dm_multipath pseries_rng xts vmx_crypto xfs libcrc32c sd_mod t10_pi
crc64_rocksoft crc64 sg ibmvfc scsi_transport_fc ibmveth dm_mirror
dm_region_hash dm_log dm_mod fuse
CPU: 0 PID: 1431 Comm: login Not tainted 6.4.0+ #1
Hardware name: IBM,8375-42A POWER9 (raw) 0x4e0202 0xf05
of:IBM,FW950.30 (VL950_892) hv:phyp pSeries
NIP [c04c2814] page_remove_rmap+0x44/0x320
LR [c049c2a4] wp_page_copy+0x384/0xec0
Call Trace:
[c98c7ad0] [c0001416e400] 0xc0001416e400 (unreliable)
[c98c7b20] [c049c2a4] wp_page_copy+0x384/0xec0
[c98c7bf0] [c04a4f64] __handle_mm_fault+0x9d4/0xfb0
[c98c7cf0] [c04a5630] handle_mm_fault+0xf0/0x350
[c98c7d40] [c0094e8c] ___do_page_fault+0x48c/0xc90
[c98c7df0] [c00958a0] hash__do_page_fault+0x30/0x70
[c98c7e20] [c009e244] do_hash_fault+0x1a4/0x330
[c98c7e50] [c0008918]
data_access_common_virt+0x198/0x1f0
--- interrupt: 300 at 0x7fffae971abc
git bisect tracked this down to below commit:
'commit baa49d81a94b ("powerpc/pseries: hvcall stack frame overhead")'
This commit changed STACK_FRAME_OVERHEAD (112 ) to
STACK_FRAME_MIN_SIZE (32 ) since 32 bytes is the minimum size
for ELFv2 stack. With the latest kernel, when running on ELFv2,
STACK_FRAME_MIN_SIZE is used to allocate stack size.
During plpar_hcall_trace, first call is made to HCALL_INST_PRECALL
which saves the registers and allocates new stack frame. In the
plpar_hcall_trace code, STK_PARAM is accessed at two places.
1. To save r4: std r4,STK_PARAM(R4)(r1)
2. To access r4 back: ld r12,STK_PARAM(R4)(r1)
HCALL_INST_PRECALL precall allocates a new stack frame. So all
the stack parameter access after the precall, needs to be accessed
with +STACK_FRAME_MIN_SIZE. So the store instruction should be:
std r4,STACK_FRAME_MIN_SIZE+STK_PARAM(R4)(r1)
If the "std" is not updated with STACK_FRAME_MIN_SIZE, we will
end up with overwriting stack contents and cause corruption.
But instead of updating 'std', we can instead remove it since
HCALL_INST_PRECALL already saves it to the correct location.
similarly load instruction should be:
ld r12,STACK_FRAME_MIN_SIZE+STK_PARAM(R4)(r1)
Fix the load instruction to correctly access the stack parameter
with +STACK_FRAME_MIN_SIZE and remove the store of r4 since the
precall saves it correctly.
Cc: sta...@vger.kernel.org
Fixes: baa49d81a94b ("powerpc/pseries: hvcall stack frame overhead")
Co-developed-by: Naveen N Rao
Signed-off-by: Naveen N Rao
Signed-off-by: Athira Rajeev
---
arch/powerpc/platforms/pseries/hvCall.S | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hvCall.S
b/arch/powerpc/platforms/pseries/hvCall.S
index bae45b358a09..2addf2ea03f0 100644
--- a/arch/powerpc/platforms/pseries/hvCall.S
+++ b/arch/powerpc/platforms/pseries/hvCall.S
@@ -184,7 +184,6 @@ _GLOBAL_TOC(plpar_hcall)
plpar_hcall_trace:
HCALL_INST_PRECALL(R5)
- std r4,STK_PARAM(R4)(r1)
mr r0,r4
mr r4,r5
@@ -196,7 +195,7 @@ plpar_hcall_trace:
HVSC
- ld r12,STK_PARAM(R4)(r1)
+ ld r12,STACK_FRAME_MIN_SIZE+STK_PARAM(R4)(r1)
std r4,0(r12)
std r5,8(r12)
std r6,16(r12)
@@ -296,7 +295,6 @@ _GLOBAL_TOC(plpar_hcall9)
[PATCH 2/2] powerpc/platforms/pseries: Remove unused r0 in the hcall tracing code
In the plpar_hcall trace code, currently we use r0 to store the ORed result of r4. But this value is not used subsequently in the code. Hence remove this unused save to r0 in plpar_hcall and plpar_hcall9 Suggested-by: Naveen N Rao Signed-off-by: Athira Rajeev --- arch/powerpc/platforms/pseries/hvCall.S | 4 1 file changed, 4 deletions(-) diff --git a/arch/powerpc/platforms/pseries/hvCall.S b/arch/powerpc/platforms/pseries/hvCall.S index 2addf2ea03f0..2b0cac6fb61f 100644 --- a/arch/powerpc/platforms/pseries/hvCall.S +++ b/arch/powerpc/platforms/pseries/hvCall.S @@ -184,8 +184,6 @@ _GLOBAL_TOC(plpar_hcall) plpar_hcall_trace: HCALL_INST_PRECALL(R5) - mr r0,r4 - mr r4,r5 mr r5,r6 mr r6,r7 @@ -295,8 +293,6 @@ _GLOBAL_TOC(plpar_hcall9) plpar_hcall9_trace: HCALL_INST_PRECALL(R5) - mr r0,r4 - mr r4,r5 mr r5,r6 mr r6,r7 -- 2.39.3
Re: [PATCH 14/15] hyper-v/azure: Remove now superfluous sentinel element from ctl_table array
On Thu, Sep 28, 2023 at 03:26:16PM +, Wei Liu wrote:
> Please change the prefix to "Drivers: hv:" in the subject line in the
> two patches.
I'll change the commit message for the 14/15 patch from "hyper-v/azure"
to "Drivers: hv:". But I only see one patch that needs this. Which is
the other one?
best
>
> On Thu, Sep 28, 2023 at 03:21:39PM +0200, Joel Granados via B4 Relay wrote:
> > From: Joel Granados
> >
> > This commit comes at the tail end of a greater effort to remove the
> > empty elements at the end of the ctl_table arrays (sentinels) which
> > will reduce the overall build time size of the kernel and run time
> > memory bloat by ~64 bytes per sentinel (further information Link :
> > https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/)
> >
> > Remove sentinel from hv_ctl_table
> >
> > Signed-off-by: Joel Granados
> > ---
> > drivers/hv/hv_common.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> > index ccad7bca3fd3..bc7d678030aa 100644
> > --- a/drivers/hv/hv_common.c
> > +++ b/drivers/hv/hv_common.c
> > @@ -147,8 +147,7 @@ static struct ctl_table hv_ctl_table[] = {
> > .proc_handler = proc_dointvec_minmax,
> > .extra1 = SYSCTL_ZERO,
> > .extra2 = SYSCTL_ONE
> > - },
> > - {}
> > + }
>
> Please keep the comma at the end.
>
> > };
> >
> > static int hv_die_panic_notify_crash(struct notifier_block *self,
> >
> > --
> > 2.30.2
> >
--
Joel Granados
signature.asc
Description: PGP signature
Re: Kernel Panic 6.5.0-1 PPC
Thanks Christophe, I'll give that a try over the weekend if I get a chance, and I'll also let the Debian devs know if they've not spotted this yet. -- Dan Whitehouse GPG: 3AA4 369C 86E1 4939 D420 AB25 D0DC 7BDD CA92 AD2E Telephone: +44(0)203 0955088
Re: [Bisected] PowerMac G5 fails booting kernel 6.6-rc3 (BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe)
[CCing the regression list, as it should be in the loop for regressions: https://docs.kernel.org/admin-guide/reporting-regressions.html] [TLDR: I'm adding this report to the list of tracked Linux kernel regressions; the text you find below is based on a few templates paragraphs you might have encountered already in similar form. See link in footer if these mails annoy you.] On 29.09.23 13:27, Erhard Furtner wrote: > Greetings! > > Kernel 6.5.5 boots fine on my PowerMac G5 11,2 but kernel 6.6-rc3 fails to > boot with following dmesg shown on the OpenFirmware console (transcribed > screenshot): > > [...] > SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 > rcu: Hierarchical RCU implementation. > Tracing variant of Tasks RCU enabled. > rcu: RCU calculated value of scheduler-enlistment delay is 30 jiffies. > NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 > mpic: Setting up MPIC " MPIC 1 " version 1.2 at f804, max 2 CPUs > mpic: ISU size: 124, shift: 7, mask: 7f > mpic: Initializing for 124 sources > mpic: Setting up HT PICs workarounds for U3/U4 > BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe > Faulting instruction address: 0xc005dc40 > Oops: Kernel access of bad area, sig: 11 [#1] > BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac > Modules linked in: > CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT 6.6.0-rc3-PMacGS #1 > Hardware name: PowerMac11,2 PPC970MP 0x440101 PowerMac > NIP: c005dc40 LR: c000 CTR: c0007730 > REGS: c22bf510 TRAP: 0380 Tainted: GT > (6.6.0-rc3-PMacGS) > MSR: 90001032 CR: 44004242 XER: > IRQMASK: 3 > GPR00: c22bf7b0 c10c0b00 01ac > GPR04: 03c8 0300 c000f20001ae 0300 > GPR08: 0006 feffbb62ffec65ff 0001 > GPR12: 90001032 c2362000 c0f76b80 0349ecd8 > GPR16: 02367ba8 02367f08 0006 > GPR20: 01ac c0f6f920 c22cd985 000c > GPR24: 0300 0003b0a3691d c0003e00803e > GPR28: c00c c000f20001ee feffbb62ffec65fe 01ac > NIP [c005dc40] hash_page_do_lazy_icache+0x50/0x100 > LR [c000] __hash_page_4K+0x420/0x590 > Call Trace: > [c22bf7e0] [] 0x > [c22bf8c0] [c005e164] hash_page_mm+0x364/0x6f0 > [c22bf990] [c005e684] do_hash_fault+0x114/0x2b0 > [c22bf9c0] [c00078e8] data_access_common_virt+0x198/0x1f0 > --- interrupt: 300 at mpic_init+0x4bc/0x10c4 > NIP: c2020a5c LR: c2020a04 CTR: > REGS: c22bf9f0 TRAP: 0300 Tainted: GT > (6.6.0-rc3-PMacGS) > MSR: 90001032 CR: 24004248 XER: > DAR: c0003e00803e DSISR: 4000 IRQMASK: 1 > GPR00: c22bfc90 c10c0b00 c0003e008030 > GPR04: > GPR08: 221b80894c06df2f > GPR12: c2362000 c0f76b80 0349ecd8 > GPR16: 02367ba8 02367f08 02367c70 > GPR20: 567ce25e8c9202b7 c0f6f920 0001 c0003e008030 > GPR24: c226f348 0004 c404c640 > GPR28: c0003e008030 c404c000 45886d8559cb69b4 c22bfc90 > NIP [c005dc40] mpic_init+0x4bc/0x10c4 > LR [c000] mpic_init+0x464/0x10c4 > ~~~ interrupt: 300 > [c22bfd90] [c2022ae4] pmac_setup_one_mpic+0x258/0x2dc > [c22bf2e0] [c2022df4] pmac_pic_init+0x28c/0x3d8 > [c22bfef0] [c200b750] init_IRQ+0x90/0x140 > [c22bff30] [c20053c0] start_kernel+0x57c/0x78c > [c22bffe0] [c000cb48] start_here_common+0x1c/0x20 > Code: 0929 7c292040 4081007c fbc10020 3d220127 78843664 3929d700 ebc9 > 7fde2214 e93e 712a0001 40820064 71232000 40820048 e93e > ---[ end trace ]--- > > Kernel panic - not syncing: Fatal exception > Rebooting in 40 seconds.. > > > I bisected the issue and got 9fee28baa601f4dbf869b1373183b312d2d5ef3d as 1st > bad commit: > > # git bisect good > 9fee28baa601f4dbf869b1373183b312d2d5ef3d is the first bad commit > commit 9fee28baa601f4dbf869b1373183b312d2d5ef3d > Author: Matthew Wilcox (Oracle) > Date: Wed Aug 2 16:13:49 2023 +0100 > > powerpc: implement the new page table range API > > Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio(). Change > the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to per-folio. > > [wi...@infradead.org: re-export flush_dcache_icache_folio()] > Link:
Re: [PATCH 01/15] cdrom: Remove now superfluous sentinel element from ctl_table array
On Thu, Sep 28, 2023 at 03:36:55PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 28, 2023 at 03:21:26PM +0200, Joel Granados via B4 Relay wrote:
> > From: Joel Granados
> >
> > This commit comes at the tail end of a greater effort to remove the
> > empty elements at the end of the ctl_table arrays (sentinels) which
> > will reduce the overall build time size of the kernel and run time
> > memory bloat by ~64 bytes per sentinel (further information Link :
> > https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/)
> >
> > Remove sentinel element from cdrom_table
> >
> > Signed-off-by: Joel Granados
> > ---
> > drivers/cdrom/cdrom.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
> > index cc2839805983..451907ade389 100644
> > --- a/drivers/cdrom/cdrom.c
> > +++ b/drivers/cdrom/cdrom.c
> > @@ -3654,8 +3654,7 @@ static struct ctl_table cdrom_table[] = {
> > .maxlen = sizeof(int),
> > .mode = 0644,
> > .proc_handler = cdrom_sysctl_handler
> > - },
> > - { }
> > + }
>
> You should have the final entry as "}," so as to make any future
> additions to the list to only contain that entry, that's long been the
> kernel style for lists like this.
Will send a V2 with this included. Thx.
>
> So your patches will just remove one line, not 2 and add 1, making it a
> smaller diff.
indeed.
>
> thanks,
>
> greg k-h
--
Joel Granados
signature.asc
Description: PGP signature
Re: [PATCH 14/15] hyper-v/azure: Remove now superfluous sentinel element from ctl_table array
On Thu, Sep 28, 2023 at 03:26:16PM +, Wei Liu wrote:
> Please change the prefix to "Drivers: hv:" in the subject line in the
> two patches.
>
> On Thu, Sep 28, 2023 at 03:21:39PM +0200, Joel Granados via B4 Relay wrote:
> > From: Joel Granados
> >
> > This commit comes at the tail end of a greater effort to remove the
> > empty elements at the end of the ctl_table arrays (sentinels) which
> > will reduce the overall build time size of the kernel and run time
> > memory bloat by ~64 bytes per sentinel (further information Link :
> > https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/)
> >
> > Remove sentinel from hv_ctl_table
> >
> > Signed-off-by: Joel Granados
> > ---
> > drivers/hv/hv_common.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> > index ccad7bca3fd3..bc7d678030aa 100644
> > --- a/drivers/hv/hv_common.c
> > +++ b/drivers/hv/hv_common.c
> > @@ -147,8 +147,7 @@ static struct ctl_table hv_ctl_table[] = {
> > .proc_handler = proc_dointvec_minmax,
> > .extra1 = SYSCTL_ZERO,
> > .extra2 = SYSCTL_ONE
> > - },
> > - {}
> > + }
>
> Please keep the comma at the end.
My V2 will have this.
>
> > };
> >
> > static int hv_die_panic_notify_crash(struct notifier_block *self,
> >
> > --
> > 2.30.2
> >
--
Joel Granados
signature.asc
Description: PGP signature
Re: [PATCH 11/15] sgi-xp: Remove the now superfluous sentinel element from ctl_table array
On Thu, Sep 28, 2023 at 12:51:15PM -0500, Steve Wahl wrote:
> On Thu, Sep 28, 2023 at 03:21:36PM +0200, Joel Granados via B4 Relay wrote:
> > From: Joel Granados
> >
> > This commit comes at the tail end of a greater effort to remove the
> > empty elements at the end of the ctl_table arrays (sentinels) which
> > will reduce the overall build time size of the kernel and run time
> > memory bloat by ~64 bytes per sentinel (further information Link :
> > https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/)
> >
> > Remove sentinel from xpc_sys_xpc_hb and xpc_sys_xpc
> >
> > Signed-off-by: Joel Granados
> > ---
> > drivers/misc/sgi-xp/xpc_main.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/misc/sgi-xp/xpc_main.c b/drivers/misc/sgi-xp/xpc_main.c
> > index 6da509d692bb..c898092ff3ac 100644
> > --- a/drivers/misc/sgi-xp/xpc_main.c
> > +++ b/drivers/misc/sgi-xp/xpc_main.c
> > @@ -109,8 +109,7 @@ static struct ctl_table xpc_sys_xpc_hb[] = {
> > .mode = 0644,
> > .proc_handler = proc_dointvec_minmax,
> > .extra1 = _hb_check_min_interval,
> > -.extra2 = _hb_check_max_interval},
> > - {}
> > +.extra2 = _hb_check_max_interval}
> > };
> > static struct ctl_table xpc_sys_xpc[] = {
> > {
> > @@ -120,8 +119,7 @@ static struct ctl_table xpc_sys_xpc[] = {
> > .mode = 0644,
> > .proc_handler = proc_dointvec_minmax,
> > .extra1 = _disengage_min_timelimit,
> > -.extra2 = _disengage_max_timelimit},
> > - {}
> > +.extra2 = _disengage_max_timelimit}
> > };
> >
> > static struct ctl_table_header *xpc_sysctl;
> >
> > --
> > 2.30.2
> >
>
> I assume you'll match the rest of the changes with regards to the
> trailing comma.
If you are refering to Greg's comments. yes. I'll send a V2 with the
trailing comma.
Best
>
> Reviewed-by: Steve Wahl
>
> --
> Steve Wahl, Hewlett Packard Enterprise
--
Joel Granados
signature.asc
Description: PGP signature
Re: [PATCH v7 25/30] dt-bindings: net: Add the Lantiq PEF2256 E1/T1/J1 framer
Hi Herve,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.6-rc3 next-20230929]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Herve-Codina/soc-fsl-cpm1-tsa-Fix-__iomem-addresses-declaration/20230928-151746
base: linus/master
patch link:
https://lore.kernel.org/r/20230928070652.330429-26-herve.codina%40bootlin.com
patch subject: [PATCH v7 25/30] dt-bindings: net: Add the Lantiq PEF2256
E1/T1/J1 framer
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce:
(https://download.01.org/0day-ci/archive/20230929/202309291924.obfdyhxb-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202309291924.obfdyhxb-...@intel.com/
dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/net/lantiq,pef2256.yaml:
>> properties:lantiq,data-rate-bps: 'oneOf' conditional failed, one must be
>> fixed:
'type' is a required property
hint: A vendor boolean property can use "type: boolean"
Additional properties are not allowed ('default', 'enum' were
unexpected)
hint: A vendor boolean property can use "type: boolean"
Additional properties are not allowed ('default' was unexpected)
hint: A vendor string property with exact values has an
implicit type
>> Documentation/devicetree/bindings/net/lantiq,pef2256.yaml:
>> properties:lantiq,data-rate-bps: 'oneOf' conditional failed, one must be
>> fixed:
'$ref' is a required property
'allOf' is a required property
hint: A vendor property needs a $ref to types.yaml
from schema $id:
http://devicetree.org/meta-schemas/vendor-props.yaml#
2048000 is not of type 'string'
hint: A vendor string property with exact values has an
implicit type
4096000 is not of type 'string'
hint: A vendor string property with exact values has an
implicit type
8192000 is not of type 'string'
hint: A vendor string property with exact values has an
implicit type
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: Kernel Panic 6.5.0-1 PPC
Le 28/09/2023 à 14:53, Dan Whitehouse a écrit : > [Vous ne recevez pas souvent de courriers de d...@dim-sum.org. D?couvrez > pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ] > > Hi, > I'm running Debian on an old Powermac (32-bit PPC G4). > I'm seeing kernel panics with 6.5.0-1. > Everything seems to be fine with: > > Linux powermac-g4 6.4.0-4-powerpc #1 Debian 6.4.13-1 (2023-08-31) ppc > GNU/Linux Can you try patch at https://patchwork.kernel.org/project/linux-mm/patch/2023091517.2835306-1-liam.howl...@oracle.com/ If it doesn't fix your problem, please provide the begining of the Oops. > > 0.00] MSR:9032 CR: 48024242 XER: > 0.00] > 0.00] GPR00: c0b29234 c13fde60 c12f3580 c12f3580 c12f3580 c13fde74 > > cc0 > 0.00] GPR08: 9032 28024242 > > 000 0004 > 0.00] GPR16: 02d159f4 02d1515c c00f6d38 0004 > > cc0 > 0.00] GPR24: c12f398c c0b29704 0001 0003 c12f3580 c1305080 > c12f > 5cc c12f3580 > 0.00] NIP [c0b28e4c] __schedule+0x364/0x920 > 0.00] LR [c0b29234] __schedule+0x74c/0x920 > 0.00] --- interrupt: 900 > 0.00] [c13fdeb0] [c0b29704] __cond_resched+0x40/060 > 0.00] [c13fdec0] [c0b2b5f0] mutex_lock_killable+0x24/0x74 > 0.00] [c13fdee0] [c02c3930] pcpu_alloc+0x54c/0x798 > 0.00] [c13fdf50] [c00f6d38] alloc_desc.irsa.0+0x60/0x174 > 0.00] [c13fdf80] [c1199c58] early_irq_init+0x70/0x9c > 0.00] [c13fdfa0] [c1183abc] start_kernel+0x4e4/0x640 > 0.00] [c13fdff0] [3540] 0x3540 > 0.00] Code: 7d2a01a4 4c00012c 4b28 7c0802a6 90010004 6000 > 9421f > e0 7c0802a6 3d20c141 93e1001c 90010024 83e9c294 <943f1ff0> 7fe1fb78 48b24909 > 80 > 1 > 0.00] ---[ end trace ]--- > 0.00] > 0.00] Kernel panic - not syncing: Attempted to kill the idle task! > 0.00] ---[ end Kernel panic - not syncing: Attempted to kill the > idle t > ask! ]--- > > -- > Dan Whitehouse > > GPG: 3AA4 369C 86E1 4939 D420 AB25 D0DC 7BDD CA92 AD2E > Telephone: +44(0)203 0955088
Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers
On Fri, 2023-09-29 at 11:44 +0200, Christian Brauner wrote:
> > It is a lot of churn though.
>
> I think that i_{a,c,m}time shouldn't be accessed directly by
> filesystems same as no filesystem should really access i_{g,u}id which
> we also provide i_{g,u}id_{read,write}() accessors for. The mode is
> another example where really most often should use helpers because of all
> the set*id stripping that we need to do (and the bugs that we had
> because of this...).
>
> The interdependency between ctime and mtime is enough to hide this in
> accessors. The other big advantage is simply grepability. So really I
> would like to see this change even without the type switch.
>
> In other words, there's no need to lump the two changes together. Do the
> conversion part and we can argue about the switch to discrete integers
> separately.
>
> The other adavantage is that we have a cycle to see any possible
> regression from the conversion.
>
> Thoughts anyone?
That works for me, and sort of what I was planning anyway. I mostly just
did the change to timestamp storage to see what it would look like
afterward.
FWIW, I'm planning to do a v2 patchbomb early next week, with the
changes that Chuck suggested (specific helpers for fetching the _sec and
_nsec fields). For now, I'll drop the change from timespec64 to discrete
fields. We can do that in a separate follow-on set.
--
Jeff Layton
Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers
> It is a lot of churn though.
I think that i_{a,c,m}time shouldn't be accessed directly by
filesystems same as no filesystem should really access i_{g,u}id which
we also provide i_{g,u}id_{read,write}() accessors for. The mode is
another example where really most often should use helpers because of all
the set*id stripping that we need to do (and the bugs that we had
because of this...).
The interdependency between ctime and mtime is enough to hide this in
accessors. The other big advantage is simply grepability. So really I
would like to see this change even without the type switch.
In other words, there's no need to lump the two changes together. Do the
conversion part and we can argue about the switch to discrete integers
separately.
The other adavantage is that we have a cycle to see any possible
regression from the conversion.
Thoughts anyone?
Re: [PATCH 87/87] fs: move i_blocks up a few places in struct inode
On Thu, Sep 28, 2023 at 10:41:34AM -0700, Linus Torvalds wrote: > On Thu, 28 Sept 2023 at 04:06, Jeff Layton wrote: > > > > Move i_blocks up above the i_lock, which moves the new 4 byte hole to > > just after the timestamps, without changing the size of the structure. > > I'm sure others have mentioned this, but 'struct inode' is marked with > __randomize_layout, so the actual layout may end up being very > different. > > I'm personally not convinced the whole structure randomization is > worth it - it's easy enough to figure out for any distro kernel since > the seed has to be the same across machines for modules to work, so > even if the seed isn't "public", any layout is bound to be fairly > easily discoverable. > > So the whole randomization only really works for private kernel > builds, and it adds this kind of pain where "optimizing" the structure > layout is kind of pointless depending on various options. > > I certainly *hope* no distro enables that pointless thing, but it's a worry. They don't last we checked. Just last cycle we moved stuff in struct file around to optimize things and we explicitly said we don't give a damn about struct randomization. Anyone who enables this will bleed performance pretty badly, I would reckon.
[6.6-rc3] WARNING at arch/powerpc/mm/book3s64/radix_tlb.c:1221
While running kernel selftests (powerpc/mce) following warning is triggered TAP version 13 1..1 # timeout set to 45 # selftests: powerpc/mce: inject-ra-err [ 37.851967] Disabling lock debugging due to kernel taint [ 37.851977] MCE: CPU19: machine check (Severe) Real address Load/Store (foreign/control memory) [Not recovered] [ 37.851982] MCE: CPU19: PID: 5254 Comm: inject-ra-err NIP: [1e48] [ 37.851986] MCE: CPU19: Initiator CPU [ 37.851988] MCE: CPU19: Unknown [ 37.852082] [ cut here ] [ 37.852086] WARNING: CPU: 19 PID: 5254 at arch/powerpc/mm/book3s64/radix_tlb.c:1221 radix__tlb_flush+0x160/0x180 [ 37.852096] Modules linked in: rpadlpar_io(E) rpaphp(E) xsk_diag(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) bonding(E) tls(E) rfkill(E) ip_set(E) nf_tables(E) nfnetlink(E) sunrpc(E) binfmt_misc(E) pseries_rng(E) aes_gcm_p10_crypto(E) drm(E) drm_panel_orientation_quirks(E) xfs(E) libcrc32c(E) sd_mod(E) sr_mod(E) t10_pi(E) crc64_rocksoft_generic(E) cdrom(E) crc64_rocksoft(E) crc64(E) sg(E) ibmvscsi(E) scsi_transport_srp(E) ibmveth(E) vmx_crypto(E) fuse(E) [ 37.852146] CPU: 19 PID: 5254 Comm: inject-ra-err Kdump: loaded Tainted: G ME 6.6.0-rc3-00055-g9ed22ae6be81 #4 [ 37.852153] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1030.20 (NH1030_058) hv:phyp pSeries [ 37.852157] NIP: c00a9c30 LR: c00a9bd4 CTR: c010a2d0 [ 37.852161] REGS: c00227b8b860 TRAP: 0700 Tainted: G ME (6.6.0-rc3-00055-g9ed22ae6be81) [ 37.852166] MSR: 80029033 CR: 4400 XER: 2004 [ 37.852177] CFAR: c00a9bdc IRQMASK: 0 [ 37.852177] GPR00: c00a9bc4 c00227b8bb00 c1902000 0041 [ 37.852177] GPR04: 0002 0080 0080 [ 37.852177] GPR08: 0002 0001 c00e81c73e90 44002228 [ 37.852177] GPR12: c010a2d0 c00e87bf6b00 [ 37.852177] GPR16: [ 37.852177] GPR20: [ 37.852177] GPR24: 0001 c5533b00 [ 37.852177] GPR28: c5533b60 c00227b8bbc0 c5533a80 [ 37.85] NIP [c00a9c30] radix__tlb_flush+0x160/0x180 [ 37.852227] LR [c00a9bd4] radix__tlb_flush+0x104/0x180 [ 37.852232] Call Trace: [ 37.852235] [c00227b8bb00] [c00a9bc4] radix__tlb_flush+0xf4/0x180 (unreliable) [ 37.852241] [c00227b8bb30] [c04e5dfc] tlb_finish_mmu+0x15c/0x1e0 [ 37.852250] [c00227b8bb60] [c04e1840] exit_mmap+0x1a0/0x510 [ 37.852256] [c00227b8bc90] [c0158760] __mmput+0x60/0x1e0 [ 37.852262] [c00227b8bcc0] [c0168b0c] exit_mm+0xdc/0x170 [ 37.852269] [c00227b8bd00] [c0168e5c] do_exit+0x2bc/0x5a0 [ 37.852280] [c00227b8bdb0] [c016938c] do_group_exit+0x4c/0xc0 [ 37.852286] [c00227b8bdf0] [c0169428] sys_exit_group+0x28/0x30 [ 37.852291] [c00227b8be10] [c0034258] system_call_exception+0x138/0x330 [ 37.852298] [c00227b8be50] [c000d05c] system_call_vectored_common+0x15c/0x2ec [ 37.852305] --- interrupt: 3000 at 0x7fff8010c2c4 [ 37.852312] NIP: 7fff8010c2c4 LR: CTR: [ 37.852316] REGS: c00227b8be80 TRAP: 3000 Tainted: G ME (6.6.0-rc3-00055-g9ed22ae6be81) [ 37.852321] MSR: 8280f033 CR: 44002822 XER: [ 37.852332] IRQMASK: 0 [ 37.852332] GPR00: 00ea 7243d010 7fff803f7e00 [ 37.852332] GPR04: 3a4602a0 [ 37.852332] GPR08: [ 37.852332] GPR12: 7fff803fab60 [ 37.852332] GPR16: [ 37.852332] GPR20: 0001 0001 [ 37.852332] GPR24: 7fff802423c0 7fff80240a38 [ 37.852332] GPR28: 0001 7fff803f3b70 f000 [ 37.852374] NIP [7fff8010c2c4] 0x7fff8010c2c4 [ 37.852378] LR [] 0x0 [ 37.852381] --- interrupt: 3000 [ 37.852383] Code: 38210030 38e1 ebe1fff8 4bfff46c 38210030 3880 ebe1fff8 4bffe9ec 38c7 4b38 6000 6000 <0fe0> 3881 7fe3fb78 4bffe9cd [ 37.852398] ---[ end trace ]--- # test:
Re: [PATCH v5 1/5] powerpc/code-patching: introduce patch_instructions()
Le 28/09/2023 à 21:48, Hari Bathini a écrit : > patch_instruction() entails setting up pte, patching the instruction, > clearing the pte and flushing the tlb. If multiple instructions need > to be patched, every instruction would have to go through the above > drill unnecessarily. Instead, introduce function patch_instructions() > that sets up the pte, clears the pte and flushes the tlb only once per > page range of instructions to be patched. This adds a slight overhead > to patch_instruction() call while improving the patching time for > scenarios where more than one instruction needs to be patched. On my powerpc8xx, this patch leads to an increase of about 8% of the time needed to activate ftrace function tracer. The problem is it complexifies patch_instruction(). Before your patch: 0234 : 234: 48 00 00 6c b 2a0 238: 7c e0 00 a6 mfmsr r7 23c: 7c 51 13 a6 mtspr 81,r2 240: 3d 40 00 00 lis r10,0 242: R_PPC_ADDR16_HA.data 244: 39 4a 00 00 addir10,r10,0 246: R_PPC_ADDR16_LO.data 248: 7c 69 1b 78 mr r9,r3 24c: 3d 29 40 00 addis r9,r9,16384 250: 81 0a 00 08 lwz r8,8(r10) 254: 55 29 00 26 clrrwi r9,r9,12 258: 81 4a 00 04 lwz r10,4(r10) 25c: 61 29 01 25 ori r9,r9,293 260: 91 28 00 00 stw r9,0(r8) 264: 55 49 00 26 clrrwi r9,r10,12 268: 50 6a 05 3e rlwimi r10,r3,0,20,31 26c: 90 8a 00 00 stw r4,0(r10) 270: 7c 00 50 6c dcbst 0,r10 274: 7c 00 04 ac hwsync 278: 7c 00 1f ac icbi0,r3 27c: 7c 00 04 ac hwsync 280: 4c 00 01 2c isync 284: 38 60 00 00 li r3,0 288: 39 40 00 00 li r10,0 28c: 91 48 00 00 stw r10,0(r8) 290: 7c 00 4a 64 tlbie r9,r0 294: 7c 00 04 ac hwsync 298: 7c e0 01 24 mtmsr r7 29c: 4e 80 00 20 blr 2a0: 90 83 00 00 stw r4,0(r3) 2a4: 7c 00 18 6c dcbst 0,r3 2a8: 7c 00 04 ac hwsync 2ac: 7c 00 1f ac icbi0,r3 2b0: 7c 00 04 ac hwsync 2b4: 4c 00 01 2c isync 2b8: 38 60 00 00 li r3,0 2bc: 4e 80 00 20 blr 2c0: 38 60 ff ff li r3,-1 2c4: 4b ff ff c4 b 288 2c8: 38 60 ff ff li r3,-1 2cc: 4e 80 00 20 blr After you patch: 020c <__do_patch_instructions>: 20c: 94 21 ff e0 stwur1,-32(r1) 210: 3d 40 00 00 lis r10,0 212: R_PPC_ADDR16_HA.data 214: 93 81 00 10 stw r28,16(r1) 218: 93 c1 00 18 stw r30,24(r1) 21c: 93 a1 00 14 stw r29,20(r1) 220: 93 e1 00 1c stw r31,28(r1) 224: 39 4a 00 00 addir10,r10,0 226: R_PPC_ADDR16_LO.data 228: 7c 69 1b 78 mr r9,r3 22c: 7c be 2b 79 mr. r30,r5 230: 3d 29 40 00 addis r9,r9,16384 234: 83 ea 00 04 lwz r31,4(r10) 238: 83 aa 00 08 lwz r29,8(r10) 23c: 55 29 00 26 clrrwi r9,r9,12 240: 61 29 01 25 ori r9,r9,293 244: 57 fc 00 26 clrrwi r28,r31,12 248: 91 3d 00 00 stw r9,0(r29) 24c: 50 7f 05 3e rlwimi r31,r3,0,20,31 250: 40 82 00 4c bne 29c <__do_patch_instructions+0x90> 254: 81 24 00 00 lwz r9,0(r4) 258: 91 3f 00 00 stw r9,0(r31) 25c: 7c 00 f8 6c dcbst 0,r31 260: 7c 00 04 ac hwsync 264: 7c 00 1f ac icbi0,r3 268: 7c 00 04 ac hwsync 26c: 4c 00 01 2c isync 270: 38 60 00 00 li r3,0 274: 39 20 00 00 li r9,0 278: 91 3d 00 00 stw r9,0(r29) 27c: 7c 00 e2 64 tlbie r28,r0 280: 7c 00 04 ac hwsync 284: 83 81 00 10 lwz r28,16(r1) 288: 83 a1 00 14 lwz r29,20(r1) 28c: 83 c1 00 18 lwz r30,24(r1) 290: 83 e1 00 1c lwz r31,28(r1) 294: 38 21 00 20 addir1,r1,32 298: 4e 80 00 20 blr 29c: 2c 06 00 00 cmpwi r6,0 2a0: 7c 08 02 a6 mflrr0 2a4: 90 01 00 24 stw r0,36(r1) 2a8: 40 82 00 24 bne 2cc <__do_patch_instructions+0xc0> 2ac: 7f e3 fb 78 mr r3,r31 2b0: 48 00 00 01 bl 2b0 <__do_patch_instructions+0xa4> 2b0: R_PPC_REL24memcpy 2b4: 7c 9f f2 14 add r4,r31,r30 2b8: 7f e3 fb 78 mr r3,r31 2bc: 48 00 00 01 bl 2bc <__do_patch_instructions+0xb0> 2bc: R_PPC_REL24flush_icache_range 2c0: 80 01 00 24 lwz r0,36(r1) 2c4: 7c 08 03 a6 mtlrr0 2c8: 4b ff ff a8 b 270 <__do_patch_instructions+0x64> 2cc: 80 84 00 00 lwz r4,0(r4) 2d0: 57 c5 f0 be srwir5,r30,2 2d4: 7f e3 fb 78 mr r3,r31 2d8: 48 00 00 01 bl 2d8 <__do_patch_instructions+0xcc> 2d8: R_PPC_REL24memset32 2dc: 4b ff ff d8 b 2b4
Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers
Jeff Layton wrote: > Correct. We'd lose some fidelity in currently stored timestamps, but as > Linus and Ted pointed out, anything below ~100ns granularity is > effectively just noise, as that's the floor overhead for calling into > the kernel. It's hard to argue that any application needs that sort of > timestamp resolution, at least with contemporary hardware. Albeit with the danger of making Steve French very happy;-), would it make sense to switch internally to Microsoft-style 64-bit timestamps with their 100ns granularity? David
[PATCH V2] tools/perf: Add perf binary dependent rule for shellcheck log in Makefile.perf
Add rule in new Makefile "tests/Makefile.tests" for running shellcheck on shell test scripts. This automates below shellcheck into the build. $ for F in $(find tests/shell/ -perm -o=x -name '*.sh'); do shellcheck -S warning $F; done Condition for shellcheck is added in Makefile.perf to avoid build breakage in the absence of shellcheck binary. Update Makefile.perf to contain new rule for "SHELLCHECK_TEST" which is for making shellcheck test as a dependency on perf binary. Added "tests/Makefile.tests" to run shellcheck on shellscripts in tests/shell. The make rule "SHLLCHECK_RUN" ensures that, every time during make, shellcheck will be run only on modified files during subsequent invocations. By this, if any newly added shell scripts or fixes in existing scripts breaks coding/formatting style, it will get captured during the perf build. Example build failure with present scripts in tests/shell: INSTALL libsubcmd_headers INSTALL libperf_headers INSTALL libapi_headers INSTALL libsymbol_headers INSTALL libbpf_headers make[3]: *** [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: output/tests/shell/record_sideband.dep] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: *** [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: output/tests/shell/test_arm_coresight.dep] Error 1 make[3]: *** [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: output/tests/shell/lock_contention.dep] Error 1 make[2]: *** [Makefile.perf:675: SHELLCHECK_TEST] Error 2 make[1]: *** [Makefile.perf:238: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 After this, for testing, changed "tests/shell/record.sh" to break shellcheck format. In the next make run, it is also captured: make[3]: *** [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: output/tests/shell/record_sideband.dep] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: *** [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: output/tests/shell/record.dep] Error 1 make[3]: *** [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: output/tests/shell/test_arm_coresight.dep] Error 1 make[3]: *** [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: output/tests/shell/lock_contention.dep] Error 1 make[2]: *** [Makefile.perf:675: SHELLCHECK_TEST] Error 2 make[1]: *** [Makefile.perf:238: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 Signed-off-by: Athira Rajeev --- Changelog: v1 -> v2: Version1 had shellcheck in feature check which is not required since shellcheck is already a binary. Presence of binary can be checked using: $(shell command -v shellcheck) Addressed these changes as suggested by Namhyung in V2 Feature test logic is removed in V2. Also added example for build breakage when shellcheck fails in commit message tools/perf/Makefile.perf| 14 +- tools/perf/tests/Makefile.tests | 24 2 files changed, 37 insertions(+), 1 deletion(-) create mode 100644 tools/perf/tests/Makefile.tests diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 98604e396ac3..56a66ca253ab 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -667,7 +667,18 @@ $(PERF_IN): prepare FORCE $(PMU_EVENTS_IN): FORCE prepare $(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=pmu-events obj=pmu-events -$(OUTPUT)perf: $(PERFLIBS) $(PERF_IN) $(PMU_EVENTS_IN) +# Runs shellcheck on perf test shell scripts + +SHELLCHECK := $(shell command -v shellcheck) +ifneq ($(SHELLCHECK),) +SHELLCHECK_TEST: FORCE prepare + $(Q)$(MAKE) -f $(srctree)/tools/perf/tests/Makefile.tests +else +SHELLCHECK_TEST: + @: +endif + +$(OUTPUT)perf: $(PERFLIBS) $(PERF_IN) $(PMU_EVENTS_IN) SHELLCHECK_TEST $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) \ $(PERF_IN) $(PMU_EVENTS_IN) $(LIBS) -o $@ @@ -1130,6 +1141,7 @@ bpf-skel-clean: $(call QUIET_CLEAN, bpf-skel) $(RM) -r $(SKEL_TMP_OUT) $(SKELETONS) clean:: $(LIBAPI)-clean $(LIBBPF)-clean $(LIBSUBCMD)-clean $(LIBSYMBOL)-clean $(LIBPERF)-clean fixdep-clean python-clean bpf-skel-clean tests-coresight-targets-clean + $(Q)$(MAKE) -f $(srctree)/tools/perf/tests/Makefile.tests clean $(call QUIET_CLEAN, core-objs) $(RM) $(LIBPERF_A) $(OUTPUT)perf-archive $(OUTPUT)perf-iostat $(LANG_BINDINGS) $(Q)find $(or $(OUTPUT),.) -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' -delete $(Q)$(RM) $(OUTPUT).config-detected diff --git a/tools/perf/tests/Makefile.tests b/tools/perf/tests/Makefile.tests new file mode 100644 index ..8011e99768a3 --- /dev/null +++ b/tools/perf/tests/Makefile.tests @@ -0,0 +1,24 @@ +#
Re: [PATCHv7 2/4] powerpc/setup: Loosen the mapping between cpu logical id and its seq in dt
Le 28/09/2023 à 22:36, Wen Xiong a écrit :
> Hi Pingfan,
>
> + avail = intserv_node->avail;
> + nthreads = intserv_node->len / sizeof(int);
> + for (j = 0; j < nthreads && cpu < nr_cpu_ids; j++) {
> set_cpu_present(cpu, avail);
> set_cpu_possible(cpu, true);
> - cpu_to_phys_id[cpu] = be32_to_cpu(intserv[j]);
> + cpu_to_phys_id[cpu] =
> be32_to_cpu(intserv_node->intserv[j]);
> + DBG("thread %d -> cpu %d (hard id %d)\n",
> + j, cpu, be32_to_cpu(intserv[j]));
>
> Intserv is not defined. Should "be32_to_cpu(intserv_node->intserv[j])?
> cpu++;
> }
> + }
Please don't top-post , see
https://docs.kernel.org/process/submitting-patches.html#use-trimmed-interleaved-replies-in-email-discussions
Make comments inside the patch directly, making sure that your mail
client is properly configured to add the standard > in front of all
lines of the quoted mail.
Christophe
>
> -Original Message-
> From: Pingfan Liu
> Sent: Monday, September 25, 2023 2:54 AM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Pingfan Liu ; Michael Ellerman ;
> Nicholas Piggin ; Christophe Leroy
> ; Mahesh Salgaonkar ; Wen
> Xiong ; Baoquan He ; Ming Lei
> ; ke...@lists.infradead.org
> Subject: [EXTERNAL] [PATCHv7 2/4] powerpc/setup: Loosen the mapping between
> cpu logical id and its seq in dt
>
> *** Idea ***
> For kexec -p, the boot cpu can be not the cpu0, this causes the problem of
> allocating memory for paca_ptrs[]. However, in theory, there is no
> requirement to assign cpu's logical id as its present sequence in the device
> tree. But there is something like cpu_first_thread_sibling(), which makes
> assumption on the mapping inside a core. Hence partially loosening the
> mapping, i.e. unbind the mapping of core while keep the mapping inside a core.
>
> *** Implement ***
> At this early stage, there are plenty of memory to utilize. Hence, this patch
> allocates interim memory to link the cpu info on a list, then reorder cpus by
> changing the list head. As a result, there is a rotate shift between the
> sequence number in dt and the cpu logical number.
>
> *** Result ***
> After this patch, a boot-cpu's logical id will always be mapped into the
> range [0,threads_per_core).
>
> Besides this, at this phase, all threads in the boot core are forced to be
> onlined. This restriction will be lifted in a later patch with extra effort.
>
> Signed-off-by: Pingfan Liu
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> Cc: Mahesh Salgaonkar
> Cc: Wen Xiong
> Cc: Baoquan He
> Cc: Ming Lei
> Cc: ke...@lists.infradead.org
> To: linuxppc-dev@lists.ozlabs.org
> ---
> arch/powerpc/kernel/prom.c | 25 +
> arch/powerpc/kernel/setup-common.c | 87 +++---
> 2 files changed, 85 insertions(+), 27 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c index
> ec82f5bda908..87272a2d8c10 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -76,7 +76,9 @@ u64 ppc64_rma_size;
> unsigned int boot_cpu_node_count __ro_after_init; #endif static
> phys_addr_t first_memblock_size;
> +#ifdef CONFIG_SMP
> static int __initdata boot_cpu_count;
> +#endif
>
> static int __init early_parse_mem(char *p) { @@ -331,8 +333,7 @@ static
> int __init early_init_dt_scan_cpus(unsigned long node,
> const __be32 *intserv;
> int i, nthreads;
> int len;
> - int found = -1;
> - int found_thread = 0;
> + bool found = false;
>
> /* We are scanning "cpu" nodes only */
> if (type == NULL || strcmp(type, "cpu") != 0) @@ -355,8 +356,15 @@
> static int __init early_init_dt_scan_cpus(unsigned long node,
> for (i = 0; i < nthreads; i++) {
> if (be32_to_cpu(intserv[i]) ==
> fdt_boot_cpuid_phys(initial_boot_params)) {
> - found = boot_cpu_count;
> - found_thread = i;
> + /*
> +* always map the boot-cpu logical id into the
> +* range of [0, thread_per_core)
> +*/
> + boot_cpuid = i;
> + found = true;
> + /* This works around the hole in paca_ptrs[]. */
> + if (nr_cpu_ids < nthreads)
> + set_nr_cpu_ids(nthreads);
> }
> #ifdef CONFIG_SMP
> /* logical cpu id is always 0 on UP kernels */ @@ -365,14
> +373,13 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
> }
>
> /* Not the boot CPU */
> - if (found < 0)
> + if (!found)
> return 0;
>
Re: [PATCH v2 1/2] mm: hugetlb: Add huge page size param to set_huge_pte_at()
Le 22/09/2023 à 13:58, Ryan Roberts a écrit :
> In order to fix a bug, arm64 needs to be told the size of the huge page
> for which the pte is being set in set_huge_pte_at(). Provide for this by
> adding an `unsigned long sz` parameter to the function. This follows the
> same pattern as huge_pte_clear().
>
> This commit makes the required interface modifications to the core mm as
> well as all arches that implement this function (arm64, parisc, powerpc,
> riscv, s390, sparc). The actual arm64 bug will be fixed in a separate
> commit.
>
> No behavioral changes intended.
>
> Signed-off-by: Ryan Roberts
> Cc: # 6.5+
Reviewed-by: Christophe Leroy # powerpc 8xx
> ---
> arch/arm64/include/asm/hugetlb.h | 2 +-
> arch/arm64/mm/hugetlbpage.c | 6 ++-
> arch/parisc/include/asm/hugetlb.h | 2 +-
> arch/parisc/mm/hugetlbpage.c | 2 +-
> .../include/asm/nohash/32/hugetlb-8xx.h | 3 +-
> arch/powerpc/mm/book3s64/hugetlbpage.c| 5 ++-
> arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 3 +-
> arch/powerpc/mm/nohash/8xx.c | 3 +-
> arch/powerpc/mm/pgtable.c | 3 +-
> arch/riscv/include/asm/hugetlb.h | 3 +-
> arch/riscv/mm/hugetlbpage.c | 3 +-
> arch/s390/include/asm/hugetlb.h | 6 ++-
> arch/s390/mm/hugetlbpage.c| 8 +++-
> arch/sparc/include/asm/hugetlb.h | 6 ++-
> arch/sparc/mm/hugetlbpage.c | 8 +++-
> include/asm-generic/hugetlb.h | 2 +-
> include/linux/hugetlb.h | 6 ++-
> mm/damon/vaddr.c | 3 +-
> mm/hugetlb.c | 43 +++
> mm/migrate.c | 7 ++-
> mm/rmap.c | 23 +++---
> mm/vmalloc.c | 2 +-
> 22 files changed, 100 insertions(+), 49 deletions(-)
>
> diff --git a/arch/arm64/include/asm/hugetlb.h
> b/arch/arm64/include/asm/hugetlb.h
> index f43a38ac1779..2ddc33d93b13 100644
> --- a/arch/arm64/include/asm/hugetlb.h
> +++ b/arch/arm64/include/asm/hugetlb.h
> @@ -28,7 +28,7 @@ pte_t arch_make_huge_pte(pte_t entry, unsigned int shift,
> vm_flags_t flags);
> #define arch_make_huge_pte arch_make_huge_pte
> #define __HAVE_ARCH_HUGE_SET_HUGE_PTE_AT
> extern void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
> - pte_t *ptep, pte_t pte);
> + pte_t *ptep, pte_t pte, unsigned long sz);
> #define __HAVE_ARCH_HUGE_PTEP_SET_ACCESS_FLAGS
> extern int huge_ptep_set_access_flags(struct vm_area_struct *vma,
> unsigned long addr, pte_t *ptep,
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 9c52718ea750..a7f8c8db3425 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -249,7 +249,7 @@ static inline struct folio
> *hugetlb_swap_entry_to_folio(swp_entry_t entry)
> }
>
> void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
> - pte_t *ptep, pte_t pte)
> + pte_t *ptep, pte_t pte, unsigned long sz)
> {
> size_t pgsize;
> int i;
> @@ -571,5 +571,7 @@ pte_t huge_ptep_modify_prot_start(struct vm_area_struct
> *vma, unsigned long addr
> void huge_ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long
> addr, pte_t *ptep,
> pte_t old_pte, pte_t pte)
> {
> - set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
> + unsigned long psize = huge_page_size(hstate_vma(vma));
> +
> + set_huge_pte_at(vma->vm_mm, addr, ptep, pte, psize);
> }
> diff --git a/arch/parisc/include/asm/hugetlb.h
> b/arch/parisc/include/asm/hugetlb.h
> index f7f078c2872c..72daacc472a0 100644
> --- a/arch/parisc/include/asm/hugetlb.h
> +++ b/arch/parisc/include/asm/hugetlb.h
> @@ -6,7 +6,7 @@
>
> #define __HAVE_ARCH_HUGE_SET_HUGE_PTE_AT
> void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
> - pte_t *ptep, pte_t pte);
> + pte_t *ptep, pte_t pte, unsigned long sz);
>
> #define __HAVE_ARCH_HUGE_PTEP_GET_AND_CLEAR
> pte_t huge_ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
> diff --git a/arch/parisc/mm/hugetlbpage.c b/arch/parisc/mm/hugetlbpage.c
> index a8a1a7c1e16e..a9f7e21f6656 100644
> --- a/arch/parisc/mm/hugetlbpage.c
> +++ b/arch/parisc/mm/hugetlbpage.c
> @@ -140,7 +140,7 @@ static void __set_huge_pte_at(struct mm_struct *mm,
> unsigned long addr,
> }
>
> void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
> - pte_t *ptep, pte_t entry)
> + pte_t *ptep, pte_t entry, unsigned long sz)
> {
> __set_huge_pte_at(mm, addr, ptep, entry);
> }
> diff --git
