* [PATCH v2] sound: Convert to using %pOFn instead of device_node.name
From: Rob Herring @ 2018-08-28 15:44 UTC (permalink / raw)
To: linux-kernel
Cc: Andy Shevchenko, Johannes Berg, Jaroslav Kysela, Takashi Iwai,
linuxppc-dev, alsa-devel
In-Reply-To: <20180828015252.28511-50-robh@kernel.org>
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: alsa-devel@alsa-project.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
v2:
- Fix error in strncmp
sound/aoa/soundbus/i2sbus/core.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/sound/aoa/soundbus/i2sbus/core.c b/sound/aoa/soundbus/i2sbus/core.c
index 000b58522106..bd7c5029fc59 100644
--- a/sound/aoa/soundbus/i2sbus/core.c
+++ b/sound/aoa/soundbus/i2sbus/core.c
@@ -157,18 +157,19 @@ static int i2sbus_add_dev(struct macio_dev *macio,
struct device_node *child = NULL, *sound = NULL;
struct resource *r;
int i, layout = 0, rlen, ok = force;
- static const char *rnames[] = { "i2sbus: %s (control)",
- "i2sbus: %s (tx)",
- "i2sbus: %s (rx)" };
+ char node_name[6];
+ static const char *rnames[] = { "i2sbus: %pOFn (control)",
+ "i2sbus: %pOFn (tx)",
+ "i2sbus: %pOFn (rx)" };
static irq_handler_t ints[] = {
i2sbus_bus_intr,
i2sbus_tx_intr,
i2sbus_rx_intr
};
- if (strlen(np->name) != 5)
+ if (snprintf(node_name, sizeof(node_name), "%pOFn", np) != 5)
return 0;
- if (strncmp(np->name, "i2s-", 4))
+ if (strncmp(node_name, "i2s-", 4))
return 0;
dev = kzalloc(sizeof(struct i2sbus_dev), GFP_KERNEL);
@@ -228,13 +229,13 @@ static int i2sbus_add_dev(struct macio_dev *macio,
dev->sound.pcmid = -1;
dev->macio = macio;
dev->control = control;
- dev->bus_number = np->name[4] - 'a';
+ dev->bus_number = node_name[4] - 'a';
INIT_LIST_HEAD(&dev->sound.codec_list);
for (i = aoa_resource_i2smmio; i <= aoa_resource_rxdbdma; i++) {
dev->interrupts[i] = -1;
snprintf(dev->rnames[i], sizeof(dev->rnames[i]),
- rnames[i], np->name);
+ rnames[i], np);
}
for (i = aoa_resource_i2smmio; i <= aoa_resource_rxdbdma; i++) {
int irq = irq_of_parse_and_map(np, i);
--
2.17.1
^ permalink raw reply related
* Re: Oops running iptables -F OUTPUT
From: Ard Biesheuvel @ 2018-08-28 16:09 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Andreas Schwab, <netdev@vger.kernel.org>, linuxppc-dev,
Jessica Yu, Michael Ellerman, Will Deacon, Ingo Molnar,
Andrew Morton, linux-arch
In-Reply-To: <CAKv+Gu8ROLamoxFZzbqrzSHq1cUQg5hn02HrKGB_0AT=EcBJpg@mail.gmail.com>
On 28 August 2018 at 15:56, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrot=
e:
> Hello Andreas, Nick,
>
> On 28 August 2018 at 06:06, Nicholas Piggin <nicholas.piggin@gmail.com> w=
rote:
>> On Mon, 27 Aug 2018 19:11:01 +0200
>> Andreas Schwab <schwab@linux-m68k.org> wrote:
>>
>>> I'm getting this Oops when running iptables -F OUTPUT:
>>>
>>> [ 91.139409] Unable to handle kernel paging request for data at addre=
ss 0xd0000001fff12f34
>>> [ 91.139414] Faulting instruction address: 0xd0000000016a5718
>>> [ 91.139419] Oops: Kernel access of bad area, sig: 11 [#1]
>>> [ 91.139426] BE SMP NR_CPUS=3D2 PowerMac
>>> [ 91.139434] Modules linked in: iptable_filter ip_tables x_tables bpf=
ilter nfsd auth_rpcgss lockd grace nfs_acl sunrpc tun af_packet snd_aoa_cod=
ec_tas snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_aoa_soundbus snd_pc=
m_oss snd_pcm snd_seq snd_timer snd_seq_device snd_mixer_oss snd sungem sr_=
mod firewire_ohci cdrom sungem_phy soundcore firewire_core pata_macio crc_i=
tu_t sg hid_generic usbhid linear md_mod ohci_pci ohci_hcd ehci_pci ehci_hc=
d usbcore usb_common dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log d=
m_mod sata_svw
>>> [ 91.139522] CPU: 1 PID: 3620 Comm: iptables Not tainted 4.19.0-rc1 #=
1
>>> [ 91.139526] NIP: d0000000016a5718 LR: d0000000016a569c CTR: c000000=
0006f560c
>>> [ 91.139531] REGS: c0000001fa577670 TRAP: 0300 Not tainted (4.19.0=
-rc1)
>>> [ 91.139534] MSR: 900000000200b032 <SF,HV,VEC,EE,FP,ME,IR,DR,RI> CR=
: 84002484 XER: 20000000
>>> [ 91.139553] DAR: d0000001fff12f34 DSISR: 40000000 IRQMASK: 0
>>> GPR00: d0000000016a569c c0000001fa5778f0 d0000000016b0400 0000000000000=
000
>>> GPR04: 0000000000000002 0000000000000000 80000001fa46418e c0000001fa0d0=
5c8
>>> GPR08: d0000000016b0400 d00037fffff13000 00000001ff3e7000 d0000000016a6=
fb8
>>> GPR12: c0000000006f560c c00000000ffff780 0000000000000000 0000000000000=
000
>>> GPR16: 0000000011635010 00003fffa1b7aa68 0000000000000000 0000000000000=
000
>>> GPR20: 0000000000000003 0000000010013918 00000000116350c0 c000000000b88=
990
>>> GPR24: c000000000b88ba4 0000000000000000 d0000001fff12f34 0000000000000=
000
>>> GPR28: d0000000016b8000 c0000001fa20f400 c0000001fa20f440 0000000000000=
000
>>> [ 91.139627] NIP [d0000000016a5718] .alloc_counters.isra.10+0xbc/0x14=
0 [ip_tables]
>>> [ 91.139634] LR [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140=
[ip_tables]
>>> [ 91.139638] Call Trace:
>>> [ 91.139645] [c0000001fa5778f0] [d0000000016a569c] .alloc_counters.is=
ra.10+0x40/0x140 [ip_tables] (unreliable)
>>> [ 91.139655] [c0000001fa5779b0] [d0000000016a5b54] .do_ipt_get_ctl+0x=
110/0x2ec [ip_tables]
>>> [ 91.139666] [c0000001fa577aa0] [c0000000006233e0] .nf_getsockopt+0x6=
8/0x88
>>> [ 91.139674] [c0000001fa577b40] [c000000000631608] .ip_getsockopt+0xb=
c/0x128
>>> [ 91.139682] [c0000001fa577bf0] [c00000000065adf4] .raw_getsockopt+0x=
18/0x5c
>>> [ 91.139690] [c0000001fa577c60] [c0000000005b5f60] .sock_common_getso=
ckopt+0x2c/0x40
>>> [ 91.139697] [c0000001fa577cd0] [c0000000005b3394] .__sys_getsockopt+=
0xa4/0xd0
>>> [ 91.139704] [c0000001fa577d80] [c0000000005b5ab0] .__se_sys_socketca=
ll+0x238/0x2b4
>>> [ 91.139712] [c0000001fa577e30] [c00000000000a31c] system_call+0x5c/0=
x70
>>> [ 91.139716] Instruction dump:
>>> [ 91.139721] 39290040 7d3d4a14 7fbe4840 409cff98 81380000 2b890001 41=
9d000c 393e0060
>>> [ 91.139736] 48000010 7d57c82a e93e0060 7d295214 <815a0000> 794807e1 =
41e20010 7c210b78
>>> [ 91.139752] ---[ end trace f5d1d5431651845d ]---
>>
>> This is due to 7290d58095 ("module: use relative references for
>> __ksymtab entries"). This part of kernel/module.c -
>>
>> /* Divert to percpu allocation if a percpu var. */
>> if (sym[i].st_shndx =3D=3D info->index.pcpu)
>> secbase =3D (unsigned long)mod_percpu(mod);
>> else
>> secbase =3D info->sechdrs[sym[i].st_shndx].sh_addr;
>> sym[i].st_value +=3D secbase;
>>
>> Causes the distance to the target to exceed 32-bits on powerpc, so
>> it doesn't fit in a rel32 reloc. Not sure how other archs cope.
>>
>
> Apologies for the breakage. It does indeed appear to affect all
> architectures, and I'm a bit puzzled why you are the first one to spot
> it.
>
> I will try to find a clean way to special case the per-CPU variable
> __ksymtab references in the generic module code, and if that is too
> cumbersome, we can switch to 64-bit relative references (or rather,
> native word size relative references) instead. Or revert the whole
> thing ...
OK, after a bit of digging, and confirming that the arm64
implementation works as expected (its module loader actually detects
overflows of the 32-bit place relative relocations, so the problem
definitely does not occur there), I think I found the explanation why
this occurs on powerpc and not on x86 or arm64.
Could you please check whether this change makes the issue go away?
(whitespace damage courtesy of Gmail)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.=
c
index 6a501b25dd85..57d09d5ceb1a 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -779,7 +779,6 @@ EXPORT_SYMBOL(__per_cpu_offset);
void __init setup_per_cpu_areas(void)
{
- const size_t dyn_size =3D PERCPU_MODULE_RESERVE + PERCPU_DYNAMIC_RE=
SERVE;
size_t atom_size;
unsigned long delta;
unsigned int cpu;
@@ -795,7 +794,9 @@ void __init setup_per_cpu_areas(void)
else
atom_size =3D 1 << 20;
- rc =3D pcpu_embed_first_chunk(0, dyn_size, atom_size, pcpu_cpu_dist=
ance,
+ rc =3D pcpu_embed_first_chunk(PERCPU_MODULE_RESERVE,
+ PERCPU_DYNAMIC_RESERVE,
+ atom_size, pcpu_cpu_distance,
pcpu_fc_alloc, pcpu_fc_free);
if (rc < 0)
panic("cannot initialize percpu area (err=3D%d)", rc);
The git log does not explain why power deviates from x86 and arm64 in
the way it initializes the percpu areas.
^ permalink raw reply related
* [PATCH 0/3] misc SLB patches
From: Nicholas Piggin @ 2018-08-28 16:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
These are a few bits and pieces I collected I'll get out of the
way ahead of the SLB rewrite in C patch and subsequent improvements.
Nicholas Piggin (3):
powerpc/64s/hash: Fix stab_rr off by one initialization
powerpc/64s/hash: Use POWER9 SLBIA IH=3 variant in switch_mm
powerpc/64s/hash: avoid the POWER5 < DD2.1 slb invalidate workaround
on POWER8/9
arch/powerpc/kernel/entry_64.S | 2 ++
arch/powerpc/mm/slb.c | 58 ++++++++++++++++++++++------------
arch/powerpc/xmon/xmon.c | 11 ++++---
3 files changed, 46 insertions(+), 25 deletions(-)
--
2.18.0
^ permalink raw reply
* [PATCH 1/3] powerpc/64s/hash: Fix stab_rr off by one initialization
From: Nicholas Piggin @ 2018-08-28 16:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180828165731.24320-1-npiggin@gmail.com>
This causes SLB alloation to start 1 beyond the start of the SLB.
There is no real problem because after it wraps it stats behaving
properly, it's just surprisig to see when looking at SLB traces.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/mm/slb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index 9f574e59d178..2f162c6e52d4 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -355,7 +355,7 @@ void slb_initialize(void)
#endif
}
- get_paca()->stab_rr = SLB_NUM_BOLTED;
+ get_paca()->stab_rr = SLB_NUM_BOLTED - 1;
lflags = SLB_VSID_KERNEL | linear_llp;
vflags = SLB_VSID_KERNEL | vmalloc_llp;
--
2.18.0
^ permalink raw reply related
* [PATCH 2/3] powerpc/64s/hash: Use POWER9 SLBIA IH=3 variant in switch_mm
From: Nicholas Piggin @ 2018-08-28 16:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180828165731.24320-1-npiggin@gmail.com>
POWER9 introduces SLBIA IH=3, which invalidates all SLB entries
and associated lookaside information that have a class value of
1, which Linux assigns to user addresses. This matches what
switch_slb wants, and allows a simple fast implementation that
avoids the slb_cache complexity.
As a side-effect, the POWER5 < DD2.1 SLB invalidation workaround
is avoided on POWER9.
Process context switching rate is improved about 2.2% for a
small process (that hits the slb cache).
Signed-of-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/mm/slb.c | 56 ++++++++++++++++++++++++++--------------
arch/powerpc/xmon/xmon.c | 11 +++++---
2 files changed, 43 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index 2f162c6e52d4..51afed85cfc3 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -238,29 +238,42 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
* which would update the slb_cache/slb_cache_ptr fields in the PACA.
*/
hard_irq_disable();
- offset = get_paca()->slb_cache_ptr;
- if (!mmu_has_feature(MMU_FTR_NO_SLBIE_B) &&
- offset <= SLB_CACHE_ENTRIES) {
- int i;
- asm volatile("isync" : : : "memory");
- for (i = 0; i < offset; i++) {
- slbie_data = (unsigned long)get_paca()->slb_cache[i]
- << SID_SHIFT; /* EA */
- slbie_data |= user_segment_size(slbie_data)
- << SLBIE_SSIZE_SHIFT;
- slbie_data |= SLBIE_C; /* C set for user addresses */
- asm volatile("slbie %0" : : "r" (slbie_data));
- }
- asm volatile("isync" : : : "memory");
+
+ if (cpu_has_feature(CPU_FTR_ARCH_300)) {
+ /*
+ * SLBIA IH=3 invalidates all Class=1 SLBEs and their
+ * associated lookaside structures, which matches what
+ * switch_slb wants. So ARCH_300 does not use the slb
+ * cache.
+ */
+ asm volatile("isync ; " PPC_SLBIA(3)" ; isync");
} else {
- __slb_flush_and_rebolt();
- }
+ offset = get_paca()->slb_cache_ptr;
+ if (!mmu_has_feature(MMU_FTR_NO_SLBIE_B) &&
+ offset <= SLB_CACHE_ENTRIES) {
+ int i;
+ asm volatile("isync" : : : "memory");
+ for (i = 0; i < offset; i++) {
+ /* EA */
+ slbie_data = (unsigned long)
+ get_paca()->slb_cache[i] << SID_SHIFT;
+ slbie_data |= user_segment_size(slbie_data)
+ << SLBIE_SSIZE_SHIFT;
+ slbie_data |= SLBIE_C; /* user slbs have C=1 */
+ asm volatile("slbie %0" : : "r" (slbie_data));
+ }
+ asm volatile("isync" : : : "memory");
+ } else {
+ __slb_flush_and_rebolt();
+ }
- /* Workaround POWER5 < DD2.1 issue */
- if (offset == 1 || offset > SLB_CACHE_ENTRIES)
- asm volatile("slbie %0" : : "r" (slbie_data));
+ /* Workaround POWER5 < DD2.1 issue */
+ if (offset == 1 || offset > SLB_CACHE_ENTRIES)
+ asm volatile("slbie %0" : : "r" (slbie_data));
+
+ get_paca()->slb_cache_ptr = 0;
+ }
- get_paca()->slb_cache_ptr = 0;
copy_mm_to_paca(mm);
/*
@@ -388,6 +401,9 @@ static void insert_slb_entry(unsigned long vsid, unsigned long ea,
enum slb_index index;
int slb_cache_index;
+ if (cpu_has_feature(CPU_FTR_ARCH_300))
+ return; /* ISAv3.0B and later does not use slb_cache */
+
/*
* We are irq disabled, hence should be safe to access PACA.
*/
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 379ae7222099..8c1d8b4bf6d5 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2393,10 +2393,13 @@ static void dump_one_paca(int cpu)
}
}
DUMP(p, vmalloc_sllp, "%#-*x");
- DUMP(p, slb_cache_ptr, "%#-*x");
- for (i = 0; i < SLB_CACHE_ENTRIES; i++)
- printf(" %-*s[%d] = 0x%016x\n",
- 22, "slb_cache", i, p->slb_cache[i]);
+
+ if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
+ DUMP(p, slb_cache_ptr, "%#-*x");
+ for (i = 0; i < SLB_CACHE_ENTRIES; i++)
+ printf(" %-*s[%d] = 0x%016x\n",
+ 22, "slb_cache", i, p->slb_cache[i]);
+ }
DUMP(p, rfi_flush_fallback_area, "%-*px");
#endif
--
2.18.0
^ permalink raw reply related
* [PATCH 3/3] powerpc/64s/hash: avoid the POWER5 < DD2.1 slb invalidate workaround on POWER8/9
From: Nicholas Piggin @ 2018-08-28 16:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180828165731.24320-1-npiggin@gmail.com>
I only have POWER8/9 to test, so just remove it for those.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/entry_64.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2206912ea4f0..77a888bfcb53 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -672,7 +672,9 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEGMENT)
isync
slbie r6
+BEGIN_FTR_SECTION
slbie r6 /* Workaround POWER5 < DD2.1 issue */
+END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
slbmte r7,r0
isync
2:
--
2.18.0
^ permalink raw reply related
* Re: Oops running iptables -F OUTPUT
From: Andreas Schwab @ 2018-08-28 17:28 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Nicholas Piggin, <netdev@vger.kernel.org>, linuxppc-dev,
Jessica Yu, Michael Ellerman, Will Deacon, Ingo Molnar,
Andrew Morton, linux-arch
In-Reply-To: <CAKv+Gu_hPaxrVtsBOoviRraYk4FWnT9zQVCVF=i27xd_nGHryw@mail.gmail.com>
On Aug 28 2018, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 6a501b25dd85..57d09d5ceb1a 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -779,7 +779,6 @@ EXPORT_SYMBOL(__per_cpu_offset);
>
> void __init setup_per_cpu_areas(void)
> {
> - const size_t dyn_size = PERCPU_MODULE_RESERVE + PERCPU_DYNAMIC_RESERVE;
> size_t atom_size;
> unsigned long delta;
> unsigned int cpu;
> @@ -795,7 +794,9 @@ void __init setup_per_cpu_areas(void)
> else
> atom_size = 1 << 20;
>
> - rc = pcpu_embed_first_chunk(0, dyn_size, atom_size, pcpu_cpu_distance,
> + rc = pcpu_embed_first_chunk(PERCPU_MODULE_RESERVE,
> + PERCPU_DYNAMIC_RESERVE,
> + atom_size, pcpu_cpu_distance,
> pcpu_fc_alloc, pcpu_fc_free);
> if (rc < 0)
> panic("cannot initialize percpu area (err=%d)", rc);
That didn't help.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v2] ASoC: Convert to using %pOFn instead of device_node.name
From: Mark Brown @ 2018-08-28 18:03 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, Andy Shevchenko, Timur Tabi, Nicolin Chen, Xiubo Li,
Fabio Estevam, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Carlo Caione, Kevin Hilman, Olivier Moysan, Arnaud Pouliquen,
Maxime Coquelin, Alexandre Torgue, alsa-devel, linuxppc-dev,
linux-arm-kernel, linux-amlogic
In-Reply-To: <20180828154433.5693-2-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 324 bytes --]
On Tue, Aug 28, 2018 at 10:44:28AM -0500, Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
Please don't send new patches in reply to existing threads, it makes it
harder to follow what the current versions of things are.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] soc: Convert to using %pOFn instead of device_node.name
From: Li Yang @ 2018-08-28 18:48 UTC (permalink / raw)
To: Rob Herring
Cc: lkml, Zhao Qiang, andy.gross, david.brown, Heiko Stuebner,
thierry.reding, Jon Hunter, Santosh Shilimkar, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-soc
In-Reply-To: <20180828015252.28511-43-robh@kernel.org>
On Mon, Aug 27, 2018 at 8:57 PM Rob Herring <robh@kernel.org> wrote:
>
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
Please forgive my ignorance, but what is this format specifier do
exactly? I cannot find anything listed in the printf specification
matching this. Is this something newly introduced?
Leo
^ permalink raw reply
* Re: FSL/NXP P5020: USB problems with the latest Git kernels
From: Darren Stevens @ 2018-08-28 19:13 UTC (permalink / raw)
To: Scott Wood; +Cc: Christian Zigotzky, linuxppc-dev
In-Reply-To: <07ad630cccbd33c81031f690fd17cdc30b662e49.camel@buserror.net>
Hello Scott
On 27/08/2018, Scott Wood wrote:
> On Mon, 2018-08-27 at 20:15 +0200, Christian Zigotzky wrote:
>> Hello,
>>
>> Our users tested the RC1 of kernel 4.19 on their P5020 boards today.
>> Unfortunately the USB bug still exists. With mem values bigger than 4096M,
>> the USB mouse and keyboard doesn't work. With the bootarg mem=4096M, the USB
>> devices work without any problems. Please compile the RC1 and test it on
>> your P5020 board. There is a problem with the memory management since
>> 22/08/18.
>
> I just tested 4.19-rc1 on a T4240 and got a similar problem with MMC. MMC and
> USB on these chips both have a 32-bit DMA limitation. I'll look into it.
I've run a bisect locally on my system and found the following bad commit:
# first bad commit: [1b1eeca7e4c19fa76d409d4c7b338dba21f2df45] init: allow initcall tables to be emitted using relative references
I can't see why this would fail though, and it only seems to affect fsl machines, and on mine it killed the onboard sata as well.
Hope this helps.
Regards
Darren
^ permalink raw reply
* Re: [PATCH] soc: Convert to using %pOFn instead of device_node.name
From: Tyrel Datwyler @ 2018-08-28 22:14 UTC (permalink / raw)
To: Li Yang, Rob Herring
Cc: Heiko Stuebner, linux-soc, lkml, Jon Hunter, david.brown,
thierry.reding, Santosh Shilimkar, andy.gross, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Zhao Qiang
In-Reply-To: <CADRPPNRvRKEuV=ZzH6yq6_7COvFSWy2ibAKoEt4YrzES2m9x2Q@mail.gmail.com>
On 08/28/2018 11:48 AM, Li Yang wrote:
> On Mon, Aug 27, 2018 at 8:57 PM Rob Herring <robh@kernel.org> wrote:
>>
>> In preparation to remove the node name pointer from struct device_node,
>> convert printf users to use the %pOFn format specifier.
>
> Please forgive my ignorance, but what is this format specifier do
> exactly? I cannot find anything listed in the printf specification
> matching this. Is this something newly introduced?
>
> Leo
>
>From Documentation/core-api/printk-formats.rst:
kobjects
--------
::
%pOF[fnpPcCF]
For printing kobject based structs (device nodes). Default behaviour is
equivalent to %pOFf.
- f - device node full_name
- n - device node name
- p - device node phandle
- P - device node path spec (name + @unit)
- F - device node flags
- c - major compatible string
- C - full compatible string
-Tyrel
^ permalink raw reply
* Re: [PATCH] soc: Convert to using %pOFn instead of device_node.name
From: Li Yang @ 2018-08-28 22:29 UTC (permalink / raw)
To: tyreld
Cc: Rob Herring, Heiko Stuebner, linuxppc-dev, lkml, Jon Hunter,
David Brown, Thierry Reding, Santosh Shilimkar, Andy Gross,
linux-soc,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Zhao Qiang
In-Reply-To: <a8594a1c-0d10-74c6-0e40-15d49ff876a3@linux.vnet.ibm.com>
On Tue, Aug 28, 2018 at 5:16 PM Tyrel Datwyler
<tyreld@linux.vnet.ibm.com> wrote:
>
> On 08/28/2018 11:48 AM, Li Yang wrote:
> > On Mon, Aug 27, 2018 at 8:57 PM Rob Herring <robh@kernel.org> wrote:
> >>
> >> In preparation to remove the node name pointer from struct device_node,
> >> convert printf users to use the %pOFn format specifier.
> >
> > Please forgive my ignorance, but what is this format specifier do
> > exactly? I cannot find anything listed in the printf specification
> > matching this. Is this something newly introduced?
> >
> > Leo
> >
>
> From Documentation/core-api/printk-formats.rst:
I was trying to find it in the standard c format specifier. :(
Thanks a lot for the pointer.
>
> kobjects
> --------
>
> ::
>
> %pOF[fnpPcCF]
>
>
> For printing kobject based structs (device nodes). Default behaviour is
> equivalent to %pOFf.
>
> - f - device node full_name
> - n - device node name
> - p - device node phandle
> - P - device node path spec (name + @unit)
> - F - device node flags
> - c - major compatible string
> - C - full compatible string
>
>
> -Tyrel
>
^ permalink raw reply
* Re: [PATCH 3/5] drivers: clk-qoriq: Add clockgen support for lx2160a
From: Stephen Boyd @ 2018-08-28 22:39 UTC (permalink / raw)
To: Vabhav Sharma, arnd, catalin.marinas, devicetree, gregkh,
kstewart, linux-arm-kernel, linux-clk, linux-kernel-owner,
linux-kernel, linux-pm, linuxppc-dev, mark.rutland, mturquette,
rjw, robh+dt, viresh.kumar, will.deacon, yamada.masahiro
Cc: linux, V.Sethi, udit.kumar, Yogesh Gaur, Tang Yuantian,
Vabhav Sharma
In-Reply-To: <1534747636-20064-4-git-send-email-vabhav.sharma@nxp.com>
Quoting Vabhav Sharma (2018-08-19 23:47:14)
> From: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> =
> Add clockgen support for lx2160a.
> Added entry for compat 'fsl,lx2160a-clockgen'.
> As LX2160A is 16 core, so modified value for NUM_CMUX
> =
> Signed-off-by: Tang Yuantian <andy.tang@nxp.com>
> Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* Re: [PATCH] soc: Convert to using %pOFn instead of device_node.name
From: Tyrel Datwyler @ 2018-08-28 22:46 UTC (permalink / raw)
To: Li Yang
Cc: Rob Herring, Heiko Stuebner, linux-soc, lkml, Jon Hunter,
David Brown, Thierry Reding, Santosh Shilimkar, Andy Gross,
linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Zhao Qiang
In-Reply-To: <CADRPPNSoP5K79wCr5QdJ-OR_W9aZrEkBiPqCXU7EWCfZsvaeuQ@mail.gmail.com>
On 08/28/2018 03:29 PM, Li Yang wrote:
> On Tue, Aug 28, 2018 at 5:16 PM Tyrel Datwyler
> <tyreld@linux.vnet.ibm.com> wrote:
>>
>> On 08/28/2018 11:48 AM, Li Yang wrote:
>>> On Mon, Aug 27, 2018 at 8:57 PM Rob Herring <robh@kernel.org> wrote:
>>>>
>>>> In preparation to remove the node name pointer from struct device_node,
>>>> convert printf users to use the %pOFn format specifier.
>>>
>>> Please forgive my ignorance, but what is this format specifier do
>>> exactly? I cannot find anything listed in the printf specification
>>> matching this. Is this something newly introduced?
>>>
>>> Leo
>>>
>>
>> From Documentation/core-api/printk-formats.rst:
>
> I was trying to find it in the standard c format specifier. :(
> Thanks a lot for the pointer.
>
No problem. Its worth a look through. The usual integer types are at the top, but that is followed by the pointer types which the kernel provides quite a few for a variety of things.
>>
>> kobjects
>> --------
>>
>> ::
>>
>> %pOF[fnpPcCF]
>>
>>
>> For printing kobject based structs (device nodes). Default behaviour is
>> equivalent to %pOFf.
>>
>> - f - device node full_name
>> - n - device node name
>> - p - device node phandle
>> - P - device node path spec (name + @unit)
>> - F - device node flags
>> - c - major compatible string
>> - C - full compatible string
>>
>>
>> -Tyrel
>>
>
^ permalink raw reply
* Re: [PATCH 1/2] soc: fsl: qbman: qman_portal: defer probing when qman is not available
From: Li Yang @ 2018-08-28 22:49 UTC (permalink / raw)
To: Roy Pledge
Cc: alexandre.belloni, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, lkml
In-Reply-To: <DB6PR0402MB27276B417034E7356B0CFA5886360@DB6PR0402MB2727.eurprd04.prod.outlook.com>
On Fri, Aug 24, 2018 at 9:54 AM Roy Pledge <roy.pledge@nxp.com> wrote:
>
> On 8/23/2018 5:36 PM, Alexandre Belloni wrote:
> > If the qman driver (qman_ccsr) doesn't probe or fail to probe before
> > qman_portal, qm_ccsr_start will be either NULL or a stale pointer to an
> > unmapped page.
> >
> > This leads to a crash when probing qman_portal as the init_pcfg function
> > calls qman_liodn_fixup that tries to read qman registers.
> >
> > Assume that qman didn't probe when the pool mask is 0.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Series applied to the fix branch of soc/fsl.
> > ---
> > drivers/soc/fsl/qbman/qman_portal.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
> > index a120002b630e..4fc80d2c8feb 100644
> > --- a/drivers/soc/fsl/qbman/qman_portal.c
> > +++ b/drivers/soc/fsl/qbman/qman_portal.c
> > @@ -277,6 +277,8 @@ static int qman_portal_probe(struct platform_device *pdev)
> > }
> >
> > pcfg->pools = qm_get_pools_sdqcr();
> > + if (pcfg->pools == 0)
> > + return -EPROBE_DEFER;
> >
> > spin_lock(&qman_lock);
> > cpu = cpumask_next_zero(-1, &portal_cpus);
>
> Reviewed-by: Roy Pledge <roy.pledge@nxp.com>
>
>
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Do not fail on TM_CAUSE_RESCHED
From: Gustavo Romero @ 2018-08-28 23:08 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev
In-Reply-To: <1534877787-24359-1-git-send-email-leitao@debian.org>
Hi Breno,
On 08/21/2018 03:56 PM, Breno Leitao wrote:
> There are cases where the test is not expecting to have the transaction
> aborted, but, the test process might have been rescheduled, either in the OS
> level or by KVM (if it is running on a KVM guest machine). The process
> reschedule will cause a treclaim/recheckpoint which will cause the transaction
> to doom, failing as soon as the process is rescheduled back to the CPU. This
> might cause the test to fail, but this is not a failure in essence.
>
> If that is the case, TEXASR[FC] is indicated with either
> TM_CAUSE_RESCHEDULE or TM_CAUSE_KVM_RESCHEDULE for KVM interruptions.
>
> In this scenario, ignore these two failures and avoid the whole test to return
> failure.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
Thanks for improving the code.
I understand that filtering out the aborts caused by the re-schedules is correct.
Only a nit:
> @@ -244,9 +245,12 @@ void *tm_una_ping(void *input)
>
> /*
> * Check if TM failed due to the cause we were expecting. 0xda is a
> - * TM_CAUSE_FAC_UNAV cause, otherwise it's an unexpected cause.
> + * TM_CAUSE_FAC_UNAV cause, otherwise it's an unexpected cause, unless
> + * it was caused by a reschedule.
> */
> - if (is_failure(cr_) && !failure_is_unavailable()) {
> +
> + if (is_failure(cr_) && !failure_is_unavailable()
> + & !failure_is_reschedule()) {
^---
It should read a short-circuit operator here instead of a bitwise operator.
Otherwise it LGTM.
Reviewed-by: Gustavo Romero <gromero@linux.ibm.com>
Best regards,
Gustavo
^ permalink raw reply
* Re: [PATCH 3/5] drivers: clk-qoriq: Add clockgen support for lx2160a
From: Scott Wood @ 2018-08-29 0:18 UTC (permalink / raw)
To: Vabhav Sharma, linux-kernel, devicetree, robh+dt, mark.rutland,
linuxppc-dev, linux-arm-kernel, mturquette, sboyd, rjw,
viresh.kumar, linux-clk, linux-pm, linux-kernel-owner,
catalin.marinas, will.deacon, gregkh, arnd, kstewart,
yamada.masahiro
Cc: Yogesh Gaur, Tang Yuantian, udit.kumar, linux, V.Sethi
In-Reply-To: <1534747636-20064-4-git-send-email-vabhav.sharma@nxp.com>
On Mon, 2018-08-20 at 12:17 +0530, Vabhav Sharma wrote:
> From: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
>
> Add clockgen support for lx2160a.
> Added entry for compat 'fsl,lx2160a-clockgen'.
> As LX2160A is 16 core, so modified value for NUM_CMUX
>
> Signed-off-by: Tang Yuantian <andy.tang@nxp.com>
> Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> ---
> drivers/clk/clk-qoriq.c | 14 +++++++++++++-
> drivers/cpufreq/qoriq-cpufreq.c | 1 +
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
> index 3a1812f..fc6e308 100644
> --- a/drivers/clk/clk-qoriq.c
> +++ b/drivers/clk/clk-qoriq.c
> @@ -60,7 +60,7 @@ struct clockgen_muxinfo {
> };
>
> #define NUM_HWACCEL 5
> -#define NUM_CMUX 8
> +#define NUM_CMUX 16
>
> struct clockgen;
>
> @@ -570,6 +570,17 @@ static const struct clockgen_chipinfo chipinfo[] = {
> .flags = CG_VER3 | CG_LITTLE_ENDIAN,
> },
> {
> + .compat = "fsl,lx2160a-clockgen",
> + .cmux_groups = {
> + &clockgen2_cmux_cga12, &clockgen2_cmux_cgb
> + },
> + .cmux_to_group = {
> + 0, 0, 0, 0, 1, 1, 1, 1, -1
> + },
> + .pll_mask = 0x37,
> + .flags = CG_VER3 | CG_LITTLE_ENDIAN,
> + },
Why are you increasing NUM_CMUX beyond 8 for a chip that only has 8 entries in
cmux_to_group?
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: add LX2160ARDB board support
From: Scott Wood @ 2018-08-29 0:28 UTC (permalink / raw)
To: Rob Herring, vabhav.sharma
Cc: Mark Rutland, Kate Stewart, linux-kernel-owner, Viresh Kumar,
Michael Turquette, Will Deacon, Masahiro Yamada, Sriram Dash,
linux-clk, Udit Kumar, Russell King, Catalin Marinas, devicetree,
Arnd Bergmann, open list:THERMAL, V.Sethi,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Stephen Boyd, Priyanka Jain, Rafael J. Wysocki,
linux-kernel@vger.kernel.org, Greg Kroah-Hartman, linuxppc-dev
In-Reply-To: <CAL_JsqKH4haGy2F2_2EP=evC8ip7DmGR8J4wzrO0wWnOLsaZqA@mail.gmail.com>
On Tue, 2018-08-21 at 15:45 -0500, Rob Herring wrote:
> On Mon, Aug 20, 2018 at 1:52 PM Vabhav Sharma <vabhav.sharma@nxp.com> wrote:
> > +/ {
> > + model = "NXP Layerscape LX2160ARDB";
> > + compatible = "fsl,lx2160a-rdb", "fsl,lx2160a";
> > +
> > + aliases {
> > + crypto = &crypto;
>
> Drop this. Aliases should be numbered, and this is not a standard
> alias name either.
Is this a new rule? In any case, U-Boot looks for a "crypto" alias.
-Scott
^ permalink raw reply
* RE: [PATCH 4/6] net/wan/fsl_ucc_hdlc: default hmask value
From: Qiang Zhao @ 2018-08-29 2:54 UTC (permalink / raw)
To: David Gounaris, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: David Gounaris
In-Reply-To: <20180828110921.2542-5-david.gounaris@infinera.com>
From: David Gounaris <david.gounaris@infinera.com>
Date: 2018/8/28 19:09
> Subject: [PATCH 4/6] net/wan/fsl_ucc_hdlc: default hmask value
>=20
> Set default HMASK to 0x0000 to use
> promiscuous mode in the hdlc controller.
>=20
> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>=20
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.h b/drivers/net/wan/fsl_ucc_hdl=
c.h
> index c21134c1f180..5bc3d1a6ca6e 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.h
> +++ b/drivers/net/wan/fsl_ucc_hdlc.h
> @@ -134,7 +134,7 @@ struct ucc_hdlc_private {
>=20
> #define HDLC_HEAD_MASK 0x0000
> #define DEFAULT_HDLC_HEAD 0xff44
> -#define DEFAULT_ADDR_MASK 0x00ff
> +#define DEFAULT_ADDR_MASK 0x0000
> #define DEFAULT_HDLC_ADDR 0x00ff
>=20
> #define BMR_GBL 0x20000000
> --
It is not proper to set default HMASK to 0x0000, how about to add a new pro=
perty standing for hmask into device tree,
If get this property from dtb, then set it with the value from dtb, otherwi=
se, set it with default HMASK ox00ff?
Best Regards
Qiang Zhao
^ permalink raw reply
* Re: Oops running iptables -F OUTPUT
From: Nicholas Piggin @ 2018-08-29 3:28 UTC (permalink / raw)
To: Andreas Schwab
Cc: netdev, linuxppc-dev, Ard Biesheuvel, Jessica Yu,
Michael Ellerman, Will Deacon, Ingo Molnar, Andrew Morton,
linux-arch, Linus Torvalds, x86, linux-arm-kernel
In-Reply-To: <20180828140632.593291cf@roar.ozlabs.ibm.com>
On Tue, 28 Aug 2018 14:06:32 +1000
Nicholas Piggin <nicholas.piggin@gmail.com> wrote:
> On Mon, 27 Aug 2018 19:11:01 +0200
> Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> > I'm getting this Oops when running iptables -F OUTPUT:
> >
> > [ 91.139409] Unable to handle kernel paging request for data at address 0xd0000001fff12f34
> > [ 91.139414] Faulting instruction address: 0xd0000000016a5718
> > [ 91.139419] Oops: Kernel access of bad area, sig: 11 [#1]
> > [ 91.139426] BE SMP NR_CPUS=2 PowerMac
> > [ 91.139434] Modules linked in: iptable_filter ip_tables x_tables bpfilter nfsd auth_rpcgss lockd grace nfs_acl sunrpc tun af_packet snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_aoa_soundbus snd_pcm_oss snd_pcm snd_seq snd_timer snd_seq_device snd_mixer_oss snd sungem sr_mod firewire_ohci cdrom sungem_phy soundcore firewire_core pata_macio crc_itu_t sg hid_generic usbhid linear md_mod ohci_pci ohci_hcd ehci_pci ehci_hcd usbcore usb_common dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod sata_svw
> > [ 91.139522] CPU: 1 PID: 3620 Comm: iptables Not tainted 4.19.0-rc1 #1
> > [ 91.139526] NIP: d0000000016a5718 LR: d0000000016a569c CTR: c0000000006f560c
> > [ 91.139531] REGS: c0000001fa577670 TRAP: 0300 Not tainted (4.19.0-rc1)
> > [ 91.139534] MSR: 900000000200b032 <SF,HV,VEC,EE,FP,ME,IR,DR,RI> CR: 84002484 XER: 20000000
> > [ 91.139553] DAR: d0000001fff12f34 DSISR: 40000000 IRQMASK: 0
> > GPR00: d0000000016a569c c0000001fa5778f0 d0000000016b0400 0000000000000000
> > GPR04: 0000000000000002 0000000000000000 80000001fa46418e c0000001fa0d05c8
> > GPR08: d0000000016b0400 d00037fffff13000 00000001ff3e7000 d0000000016a6fb8
> > GPR12: c0000000006f560c c00000000ffff780 0000000000000000 0000000000000000
> > GPR16: 0000000011635010 00003fffa1b7aa68 0000000000000000 0000000000000000
> > GPR20: 0000000000000003 0000000010013918 00000000116350c0 c000000000b88990
> > GPR24: c000000000b88ba4 0000000000000000 d0000001fff12f34 0000000000000000
> > GPR28: d0000000016b8000 c0000001fa20f400 c0000001fa20f440 0000000000000000
> > [ 91.139627] NIP [d0000000016a5718] .alloc_counters.isra.10+0xbc/0x140 [ip_tables]
> > [ 91.139634] LR [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables]
> > [ 91.139638] Call Trace:
> > [ 91.139645] [c0000001fa5778f0] [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables] (unreliable)
> > [ 91.139655] [c0000001fa5779b0] [d0000000016a5b54] .do_ipt_get_ctl+0x110/0x2ec [ip_tables]
> > [ 91.139666] [c0000001fa577aa0] [c0000000006233e0] .nf_getsockopt+0x68/0x88
> > [ 91.139674] [c0000001fa577b40] [c000000000631608] .ip_getsockopt+0xbc/0x128
> > [ 91.139682] [c0000001fa577bf0] [c00000000065adf4] .raw_getsockopt+0x18/0x5c
> > [ 91.139690] [c0000001fa577c60] [c0000000005b5f60] .sock_common_getsockopt+0x2c/0x40
> > [ 91.139697] [c0000001fa577cd0] [c0000000005b3394] .__sys_getsockopt+0xa4/0xd0
> > [ 91.139704] [c0000001fa577d80] [c0000000005b5ab0] .__se_sys_socketcall+0x238/0x2b4
> > [ 91.139712] [c0000001fa577e30] [c00000000000a31c] system_call+0x5c/0x70
> > [ 91.139716] Instruction dump:
> > [ 91.139721] 39290040 7d3d4a14 7fbe4840 409cff98 81380000 2b890001 419d000c 393e0060
> > [ 91.139736] 48000010 7d57c82a e93e0060 7d295214 <815a0000> 794807e1 41e20010 7c210b78
> > [ 91.139752] ---[ end trace f5d1d5431651845d ]---
>
> This is due to 7290d58095 ("module: use relative references for
> __ksymtab entries"). This part of kernel/module.c -
>
> /* Divert to percpu allocation if a percpu var. */
> if (sym[i].st_shndx == info->index.pcpu)
> secbase = (unsigned long)mod_percpu(mod);
> else
> secbase = info->sechdrs[sym[i].st_shndx].sh_addr;
> sym[i].st_value += secbase;
>
> Causes the distance to the target to exceed 32-bits on powerpc, so
> it doesn't fit in a rel32 reloc. Not sure how other archs cope.
Any progress on this one? I had a bit of a look but can't see a really
trivial fix and don't have a lot of time to work on it. Maybe use 64
bit relative offsets for per-cpu exports, or better might be apply the
per-cpu fixup when linking against the symbol rather than when writing
the module symbol table.
Until then I'd like to just remove HAVE_ARCH_PREL32_RELOCATIONS from
powerpc/Kconfig, but if other archs are going to have issues too, we
could just revert
271ca788774aa ("arch: enable relative relocations for arm64, power and x86")
arm64, x86 -- can the distance between your module percpu data link
location -> module percpu runtime allocation location exceed 31 bits?
Thanks,
Nick
^ permalink raw reply
* Re: Oops running iptables -F OUTPUT
From: Nicholas Piggin @ 2018-08-29 3:53 UTC (permalink / raw)
To: Andreas Schwab
Cc: netdev, linuxppc-dev, Ard Biesheuvel, Jessica Yu,
Michael Ellerman, Will Deacon, Ingo Molnar, Andrew Morton,
linux-arch, Linus Torvalds, x86, linux-arm-kernel
In-Reply-To: <20180829132827.6dbc4352@roar.ozlabs.ibm.com>
On Wed, 29 Aug 2018 13:28:27 +1000
Nicholas Piggin <npiggin@gmail.com> wrote:
> On Tue, 28 Aug 2018 14:06:32 +1000
> Nicholas Piggin <nicholas.piggin@gmail.com> wrote:
>
> > On Mon, 27 Aug 2018 19:11:01 +0200
> > Andreas Schwab <schwab@linux-m68k.org> wrote:
> >
> > > I'm getting this Oops when running iptables -F OUTPUT:
> > >
> > > [ 91.139409] Unable to handle kernel paging request for data at address 0xd0000001fff12f34
> > > [ 91.139414] Faulting instruction address: 0xd0000000016a5718
> > > [ 91.139419] Oops: Kernel access of bad area, sig: 11 [#1]
> > > [ 91.139426] BE SMP NR_CPUS=2 PowerMac
> > > [ 91.139434] Modules linked in: iptable_filter ip_tables x_tables bpfilter nfsd auth_rpcgss lockd grace nfs_acl sunrpc tun af_packet snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_aoa_soundbus snd_pcm_oss snd_pcm snd_seq snd_timer snd_seq_device snd_mixer_oss snd sungem sr_mod firewire_ohci cdrom sungem_phy soundcore firewire_core pata_macio crc_itu_t sg hid_generic usbhid linear md_mod ohci_pci ohci_hcd ehci_pci ehci_hcd usbcore usb_common dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod sata_svw
> > > [ 91.139522] CPU: 1 PID: 3620 Comm: iptables Not tainted 4.19.0-rc1 #1
> > > [ 91.139526] NIP: d0000000016a5718 LR: d0000000016a569c CTR: c0000000006f560c
> > > [ 91.139531] REGS: c0000001fa577670 TRAP: 0300 Not tainted (4.19.0-rc1)
> > > [ 91.139534] MSR: 900000000200b032 <SF,HV,VEC,EE,FP,ME,IR,DR,RI> CR: 84002484 XER: 20000000
> > > [ 91.139553] DAR: d0000001fff12f34 DSISR: 40000000 IRQMASK: 0
> > > GPR00: d0000000016a569c c0000001fa5778f0 d0000000016b0400 0000000000000000
> > > GPR04: 0000000000000002 0000000000000000 80000001fa46418e c0000001fa0d05c8
> > > GPR08: d0000000016b0400 d00037fffff13000 00000001ff3e7000 d0000000016a6fb8
> > > GPR12: c0000000006f560c c00000000ffff780 0000000000000000 0000000000000000
> > > GPR16: 0000000011635010 00003fffa1b7aa68 0000000000000000 0000000000000000
> > > GPR20: 0000000000000003 0000000010013918 00000000116350c0 c000000000b88990
> > > GPR24: c000000000b88ba4 0000000000000000 d0000001fff12f34 0000000000000000
> > > GPR28: d0000000016b8000 c0000001fa20f400 c0000001fa20f440 0000000000000000
> > > [ 91.139627] NIP [d0000000016a5718] .alloc_counters.isra.10+0xbc/0x140 [ip_tables]
> > > [ 91.139634] LR [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables]
> > > [ 91.139638] Call Trace:
> > > [ 91.139645] [c0000001fa5778f0] [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables] (unreliable)
> > > [ 91.139655] [c0000001fa5779b0] [d0000000016a5b54] .do_ipt_get_ctl+0x110/0x2ec [ip_tables]
> > > [ 91.139666] [c0000001fa577aa0] [c0000000006233e0] .nf_getsockopt+0x68/0x88
> > > [ 91.139674] [c0000001fa577b40] [c000000000631608] .ip_getsockopt+0xbc/0x128
> > > [ 91.139682] [c0000001fa577bf0] [c00000000065adf4] .raw_getsockopt+0x18/0x5c
> > > [ 91.139690] [c0000001fa577c60] [c0000000005b5f60] .sock_common_getsockopt+0x2c/0x40
> > > [ 91.139697] [c0000001fa577cd0] [c0000000005b3394] .__sys_getsockopt+0xa4/0xd0
> > > [ 91.139704] [c0000001fa577d80] [c0000000005b5ab0] .__se_sys_socketcall+0x238/0x2b4
> > > [ 91.139712] [c0000001fa577e30] [c00000000000a31c] system_call+0x5c/0x70
> > > [ 91.139716] Instruction dump:
> > > [ 91.139721] 39290040 7d3d4a14 7fbe4840 409cff98 81380000 2b890001 419d000c 393e0060
> > > [ 91.139736] 48000010 7d57c82a e93e0060 7d295214 <815a0000> 794807e1 41e20010 7c210b78
> > > [ 91.139752] ---[ end trace f5d1d5431651845d ]---
> >
> > This is due to 7290d58095 ("module: use relative references for
> > __ksymtab entries"). This part of kernel/module.c -
> >
> > /* Divert to percpu allocation if a percpu var. */
> > if (sym[i].st_shndx == info->index.pcpu)
> > secbase = (unsigned long)mod_percpu(mod);
> > else
> > secbase = info->sechdrs[sym[i].st_shndx].sh_addr;
> > sym[i].st_value += secbase;
> >
> > Causes the distance to the target to exceed 32-bits on powerpc, so
> > it doesn't fit in a rel32 reloc. Not sure how other archs cope.
>
> Any progress on this one? I had a bit of a look but can't see a really
> trivial fix and don't have a lot of time to work on it. Maybe use 64
> bit relative offsets for per-cpu exports, or better might be apply the
> per-cpu fixup when linking against the symbol rather than when writing
> the module symbol table.
>
> Until then I'd like to just remove HAVE_ARCH_PREL32_RELOCATIONS from
> powerpc/Kconfig, but if other archs are going to have issues too, we
> could just revert
>
> 271ca788774aa ("arch: enable relative relocations for arm64, power and x86")
>
> arm64, x86 -- can the distance between your module percpu data link
> location -> module percpu runtime allocation location exceed 31 bits?
[Sorry ignore this, I missed some mail, will reply in the thread]
Thanks,
Nick
^ permalink raw reply
* Re: Oops running iptables -F OUTPUT
From: Nicholas Piggin @ 2018-08-29 4:36 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Andreas Schwab, <netdev@vger.kernel.org>, linuxppc-dev,
Jessica Yu, Michael Ellerman, Will Deacon, Ingo Molnar,
Andrew Morton, linux-arch, Linus Torvalds
In-Reply-To: <CAKv+Gu_hPaxrVtsBOoviRraYk4FWnT9zQVCVF=i27xd_nGHryw@mail.gmail.com>
On Tue, 28 Aug 2018 18:09:09 +0200
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 28 August 2018 at 15:56, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > Hello Andreas, Nick,
> >
> > On 28 August 2018 at 06:06, Nicholas Piggin <nicholas.piggin@gmail.com> wrote:
> >> On Mon, 27 Aug 2018 19:11:01 +0200
> >> Andreas Schwab <schwab@linux-m68k.org> wrote:
> >>
> >>> I'm getting this Oops when running iptables -F OUTPUT:
> >>>
> >>> [ 91.139409] Unable to handle kernel paging request for data at address 0xd0000001fff12f34
> >>> [ 91.139414] Faulting instruction address: 0xd0000000016a5718
> >>> [ 91.139419] Oops: Kernel access of bad area, sig: 11 [#1]
> >>> [ 91.139426] BE SMP NR_CPUS=2 PowerMac
> >>> [ 91.139434] Modules linked in: iptable_filter ip_tables x_tables bpfilter nfsd auth_rpcgss lockd grace nfs_acl sunrpc tun af_packet snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_aoa_soundbus snd_pcm_oss snd_pcm snd_seq snd_timer snd_seq_device snd_mixer_oss snd sungem sr_mod firewire_ohci cdrom sungem_phy soundcore firewire_core pata_macio crc_itu_t sg hid_generic usbhid linear md_mod ohci_pci ohci_hcd ehci_pci ehci_hcd usbcore usb_common dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod sata_svw
> >>> [ 91.139522] CPU: 1 PID: 3620 Comm: iptables Not tainted 4.19.0-rc1 #1
> >>> [ 91.139526] NIP: d0000000016a5718 LR: d0000000016a569c CTR: c0000000006f560c
> >>> [ 91.139531] REGS: c0000001fa577670 TRAP: 0300 Not tainted (4.19.0-rc1)
> >>> [ 91.139534] MSR: 900000000200b032 <SF,HV,VEC,EE,FP,ME,IR,DR,RI> CR: 84002484 XER: 20000000
> >>> [ 91.139553] DAR: d0000001fff12f34 DSISR: 40000000 IRQMASK: 0
> >>> GPR00: d0000000016a569c c0000001fa5778f0 d0000000016b0400 0000000000000000
> >>> GPR04: 0000000000000002 0000000000000000 80000001fa46418e c0000001fa0d05c8
> >>> GPR08: d0000000016b0400 d00037fffff13000 00000001ff3e7000 d0000000016a6fb8
> >>> GPR12: c0000000006f560c c00000000ffff780 0000000000000000 0000000000000000
> >>> GPR16: 0000000011635010 00003fffa1b7aa68 0000000000000000 0000000000000000
> >>> GPR20: 0000000000000003 0000000010013918 00000000116350c0 c000000000b88990
> >>> GPR24: c000000000b88ba4 0000000000000000 d0000001fff12f34 0000000000000000
> >>> GPR28: d0000000016b8000 c0000001fa20f400 c0000001fa20f440 0000000000000000
> >>> [ 91.139627] NIP [d0000000016a5718] .alloc_counters.isra.10+0xbc/0x140 [ip_tables]
> >>> [ 91.139634] LR [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables]
> >>> [ 91.139638] Call Trace:
> >>> [ 91.139645] [c0000001fa5778f0] [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables] (unreliable)
> >>> [ 91.139655] [c0000001fa5779b0] [d0000000016a5b54] .do_ipt_get_ctl+0x110/0x2ec [ip_tables]
> >>> [ 91.139666] [c0000001fa577aa0] [c0000000006233e0] .nf_getsockopt+0x68/0x88
> >>> [ 91.139674] [c0000001fa577b40] [c000000000631608] .ip_getsockopt+0xbc/0x128
> >>> [ 91.139682] [c0000001fa577bf0] [c00000000065adf4] .raw_getsockopt+0x18/0x5c
> >>> [ 91.139690] [c0000001fa577c60] [c0000000005b5f60] .sock_common_getsockopt+0x2c/0x40
> >>> [ 91.139697] [c0000001fa577cd0] [c0000000005b3394] .__sys_getsockopt+0xa4/0xd0
> >>> [ 91.139704] [c0000001fa577d80] [c0000000005b5ab0] .__se_sys_socketcall+0x238/0x2b4
> >>> [ 91.139712] [c0000001fa577e30] [c00000000000a31c] system_call+0x5c/0x70
> >>> [ 91.139716] Instruction dump:
> >>> [ 91.139721] 39290040 7d3d4a14 7fbe4840 409cff98 81380000 2b890001 419d000c 393e0060
> >>> [ 91.139736] 48000010 7d57c82a e93e0060 7d295214 <815a0000> 794807e1 41e20010 7c210b78
> >>> [ 91.139752] ---[ end trace f5d1d5431651845d ]---
> >>
> >> This is due to 7290d58095 ("module: use relative references for
> >> __ksymtab entries"). This part of kernel/module.c -
> >>
> >> /* Divert to percpu allocation if a percpu var. */
> >> if (sym[i].st_shndx == info->index.pcpu)
> >> secbase = (unsigned long)mod_percpu(mod);
> >> else
> >> secbase = info->sechdrs[sym[i].st_shndx].sh_addr;
> >> sym[i].st_value += secbase;
> >>
> >> Causes the distance to the target to exceed 32-bits on powerpc, so
> >> it doesn't fit in a rel32 reloc. Not sure how other archs cope.
> >>
> >
> > Apologies for the breakage. It does indeed appear to affect all
> > architectures, and I'm a bit puzzled why you are the first one to spot
> > it.
> >
> > I will try to find a clean way to special case the per-CPU variable
> > __ksymtab references in the generic module code, and if that is too
> > cumbersome, we can switch to 64-bit relative references (or rather,
> > native word size relative references) instead. Or revert the whole
> > thing ...
>
> OK, after a bit of digging, and confirming that the arm64
> implementation works as expected (its module loader actually detects
> overflows of the 32-bit place relative relocations, so the problem
> definitely does not occur there), I think I found the explanation why
> this occurs on powerpc and not on x86 or arm64.
>
> Could you please check whether this change makes the issue go away?
> (whitespace damage courtesy of Gmail)
>
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 6a501b25dd85..57d09d5ceb1a 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -779,7 +779,6 @@ EXPORT_SYMBOL(__per_cpu_offset);
>
> void __init setup_per_cpu_areas(void)
> {
> - const size_t dyn_size = PERCPU_MODULE_RESERVE + PERCPU_DYNAMIC_RESERVE;
> size_t atom_size;
> unsigned long delta;
> unsigned int cpu;
> @@ -795,7 +794,9 @@ void __init setup_per_cpu_areas(void)
> else
> atom_size = 1 << 20;
>
> - rc = pcpu_embed_first_chunk(0, dyn_size, atom_size, pcpu_cpu_distance,
> + rc = pcpu_embed_first_chunk(PERCPU_MODULE_RESERVE,
> + PERCPU_DYNAMIC_RESERVE,
> + atom_size, pcpu_cpu_distance,
> pcpu_fc_alloc, pcpu_fc_free);
> if (rc < 0)
> panic("cannot initialize percpu area (err=%d)", rc);
>
> The git log does not explain why power deviates from x86 and arm64 in
> the way it initializes the percpu areas.
The reason for 64-bit powerpc is actually that modules are allocated in
vmalloc space which is a long way out from the linear map where the per
cpu embedded chunk is.
It does look like x86 and arm64 are probably okay because they set up a
module vmalloc area close to their kernel text in the linear map, which
should be close to per-cpu I guess.
I'm not entirely sure why pcpu setup is different on powerpc, but I
think the module vmalloc addresses bite first anyway.
Okay I'd say let's just remove powerpc for now.
Thanks,
Nick
^ permalink raw reply
* [PATCH] powerpc: disable support for relative ksymtab references
From: Ard Biesheuvel @ 2018-08-29 6:47 UTC (permalink / raw)
To: linuxppc-dev
Cc: nicholas.piggin, schwab, jeyu, mpe, will.deacon, mingo, akpm,
linux-arch, Ard Biesheuvel
The newly added code that emits ksymtab entries as pairs of 32-bit
relative references interacts poorly with the way powerpc lays out
its address space: when a module exports a per-CPU variable, the
primary module region covering the ksymtab entry -and thus the 32-bit
relative reference- is too far away from the actual per-CPU variable's
base address (to which the per-CPU offsets are applied to obtain the
respective address of each CPU's copy), resulting in corruption when
the module loader attempts to resolve symbol references of modules
that are loaded on top and link to the exported per-CPU symbol.
So let's disable this feature on powerpc. Even though it implements
CONFIG_RELOCATABLE, it does not implement CONFIG_RANDOMIZE_BASE and
so KASLR kernels (which are the main target of the feature) do not
exist on powerpc anyway.
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Suggested-by: Nicholas Piggin <nicholas.piggin@gmail.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/powerpc/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index db0b6eebbfa5..a80669209155 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -177,7 +177,6 @@ config PPC
select HAVE_ARCH_KGDB
select HAVE_ARCH_MMAP_RND_BITS
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
- select HAVE_ARCH_PREL32_RELOCATIONS
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
select HAVE_CBPF_JIT if !PPC64
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v7 1/2] powerpc: Detect the presence of big-cores via "ibm,thread-groups"
From: Michael Neuling @ 2018-08-29 7:04 UTC (permalink / raw)
To: Gautham R. Shenoy, Srikar Dronamraju, Michael Ellerman,
Benjamin Herrenschmidt, Vaidyanathan Srinivasan, Akshay Adiga,
Shilpasri G Bhat, Oliver O'Halloran, Nicholas Piggin,
Murilo Opsfelder Araujo, Anton Blanchard
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1534743704-4760-2-git-send-email-ego@linux.vnet.ibm.com>
> +What: /sys/devices/system/cpu/cpu[0-9]+/small_core_siblings
Shouldn't we put this in the topology/ subdir with with the other items lik=
e it?
Mikey
^ permalink raw reply
* Re: [PATCH 1/6] net/wan/fsl_ucc_hdlc: allow ucc index up to 4
From: Christophe LEROY @ 2018-08-29 7:09 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev
In-Reply-To: <917e8baf-3623-6fde-fed0-9ff859b72fea@c-s.fr>
Le 28/08/2018 à 15:34, Christophe LEROY a écrit :
>
>
> Le 28/08/2018 à 13:09, David Gounaris a écrit :
>> There is a need to allow higher indexes to be
>> able to support MPC83xx platforms. (UCC1-UCC5)
>
> As far as I can see, MPC8358 has 8 UCCs (ref
> https://www.nxp.com/products/processors-and-microcontrollers/power-architecture-processors/powerquicc-processors/powerquicc-ii-pro/powerquicc-ii-pro-processor-with-ddr2-tdm-pci-security-usb-quicc-engine-with-1-gb-ethernet-utopia:MPC8358E)
Indeed, the code should use UCC_MAX_NUM which is defined in
include/soc/fsl/qe/ucc.h
Christophe
>
>
> Christophe
>
>>
>> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
>> ---
>> drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c
>> b/drivers/net/wan/fsl_ucc_hdlc.c
>> index 5f0366a125e2..3c0e0a1d19ba 100644
>> --- a/drivers/net/wan/fsl_ucc_hdlc.c
>> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
>> @@ -1015,7 +1015,7 @@ static int ucc_hdlc_probe(struct platform_device
>> *pdev)
>> }
>> ucc_num = val - 1;
>> - if ((ucc_num > 3) || (ucc_num < 0)) {
>> + if ((ucc_num > 4) || (ucc_num < 0)) {
>> dev_err(&pdev->dev, ": Invalid UCC num\n");
>> return -EINVAL;
>> }
>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox