Re: [PATCH v6 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
Hi Xiaowei, Hi Shawn,
> LS1028a implements 2 PCIe 3.0 controllers.
Patch 1/3 and 3/3 are in Linus' tree but nobody seems to care about this patch
anymore :(
This doesn't work well with the IOMMU, because the iommu-map property is
missing. The bootloader needs the &smmu phandle to fixup the entry. See
below.
Shawn, will you add this patch to your tree once its fixed, considering it
just adds the device tree node for the LS1028A?
>
> Signed-off-by: Xiaowei Bao
> Signed-off-by: Hou Zhiqiang
> ---
> v2:
> - Fix up the legacy INTx allocate failed issue.
> v3:
> - No change.
> v4:
> - Remove the num-lanes property.
> v5:
> - Add the num-viewport property.
> v6:
> - move num-viewport to 8.
>
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 52
> ++
> 1 file changed, 52 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 72b9a75..c043b1d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -625,6 +625,58 @@
> };
> };
>
> + pcie@340 {
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010 /* controller
> registers */
> +0x80 0x 0x0 0x2000>; /*
> configuration space */
> + reg-names = "regs", "config";
> + interrupts = , /* PME
> interrupt */
> + ; /* aer
> interrupt */
> + interrupt-names = "pme", "aer";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + dma-coherent;
> + num-viewport = <8>;
> + bus-range = <0x0 0xff>;
> + ranges = <0x8100 0x0 0x 0x80 0x0001 0x0
> 0x0001 /* downstream I/O */
> + 0x8200 0x0 0x4000 0x80 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> + msi-parent = <&its>;
iommu-map = <0 &smmu 0 0>; /* fixed up by bootloader */
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = < 0 0 1 &gic 0 0 GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 2 &gic 0 0 GIC_SPI 110
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 3 &gic 0 0 GIC_SPI 111
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 4 &gic 0 0 GIC_SPI 112
> IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + pcie@350 {
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0350 0x0 0x0010 /* controller
> registers */
> +0x88 0x 0x0 0x2000>; /*
> configuration space */
> + reg-names = "regs", "config";
> + interrupts = ,
> + ;
> + interrupt-names = "pme", "aer";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + dma-coherent;
> + num-viewport = <8>;
> + bus-range = <0x0 0xff>;
> + ranges = <0x8100 0x0 0x 0x88 0x0001 0x0
> 0x0001 /* downstream I/O */
> + 0x8200 0x0 0x4000 0x88 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> + msi-parent = <&its>;
likewise
With these two fixes:
Tested-by: Michael Walle
-michael
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = < 0 0 1 &gic 0 0 GIC_SPI 114
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 2 &gic 0 0 GIC_SPI 115
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 3 &gic 0 0 GIC_SPI 116
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 4 &gic 0 0 GIC_SPI 117
> IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> pcie@1f000 { /* Integrated Endpoint Root Complex */
> compatible = "pci-host-ecam-generic";
> reg = <0x01 0xf000 0x0 0x10>;
> --
> 2.9.5
>
>
Re: [PATCH v6 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
On Mon, Feb 24, 2020 at 09:11:05AM +0100, Michael Walle wrote: > Hi Xiaowei, Hi Shawn, > > > LS1028a implements 2 PCIe 3.0 controllers. > > Patch 1/3 and 3/3 are in Linus' tree but nobody seems to care about this patch > anymore :( > > This doesn't work well with the IOMMU, because the iommu-map property is > missing. The bootloader needs the &smmu phandle to fixup the entry. See > below. > > Shawn, will you add this patch to your tree once its fixed, considering it > just adds the device tree node for the LS1028A? The patch/thread is a bit aged. You may want to send an updated patch for discussion. Shawn > > > > > Signed-off-by: Xiaowei Bao > > Signed-off-by: Hou Zhiqiang
Re: [PATCH v2 3/3] ASoC: fsl_easrc: Add EASRC ASoC CPU DAI and platform drivers
Hi
> >
> > Signed-off-by: Shengjiu Wang
> > ---
> > sound/soc/fsl/Kconfig | 10 +
> > sound/soc/fsl/Makefile |2 +
> > sound/soc/fsl/fsl_asrc_common.h |1 +
> > sound/soc/fsl/fsl_easrc.c | 2265 +++
> > sound/soc/fsl/fsl_easrc.h | 668 +
> > sound/soc/fsl/fsl_easrc_dma.c | 440 ++
>
> I see a 90% similarity between fsl_asrc_dma and fsl_easrc_dma files.
> Would it be possible reuse the existing code? Could share structures from
> my point of view, just like it reuses "enum asrc_pair_index", I know
> differentiating "pair" and "context" is a big point here though.
>
> A possible quick solution for that, off the top of my head, could be:
>
> 1) in fsl_asrc_common.h
>
> struct fsl_asrc {
>
> };
>
> struct fsl_asrc_pair {
>
> };
>
> 2) in fsl_easrc.h
>
> /* Renaming shared structures */
> #define fsl_easrc fsl_asrc
> #define fsl_easrc_context fsl_asrc_pair
>
> May be a good idea to see if others have some opinion too.
>
We need to modify the fsl_asrc and fsl_asrc_pair, let them
To be used by both driver, also we need to put the specific
Definition for each module to same struct, right?
>
> > +static const struct regmap_config fsl_easrc_regmap_config = {
> > + .readable_reg = fsl_easrc_readable_reg,
> > + .volatile_reg = fsl_easrc_volatile_reg,
> > + .writeable_reg = fsl_easrc_writeable_reg,
>
> Can we use regmap_range and regmap_access_table?
>
Can the regmap_range support discontinuous registers? The
reg_stride = 4.
Best regards
Wang shengjiu
Re: [PATCH v6 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
Hi Shawn, all, Am 2020-02-24 09:43, schrieb Shawn Guo: On Mon, Feb 24, 2020 at 09:11:05AM +0100, Michael Walle wrote: Hi Xiaowei, Hi Shawn, > LS1028a implements 2 PCIe 3.0 controllers. Patch 1/3 and 3/3 are in Linus' tree but nobody seems to care about this patch anymore :( This doesn't work well with the IOMMU, because the iommu-map property is missing. The bootloader needs the &smmu phandle to fixup the entry. See below. Shawn, will you add this patch to your tree once its fixed, considering it just adds the device tree node for the LS1028A? The patch/thread is a bit aged. You may want to send an updated patch for discussion. So should I just pick up the patch add my two fixes and send it again? What about the Signed-off-by tags? Leave them? Replace them? Add mine? -michael
Re: [5.6.0-rc2-next-20200218/powerpc] Boot failure on POWER9
On Sat 22-02-20 03:38:11, Cristopher Lameter wrote: > On Tue, 18 Feb 2020, Michal Hocko wrote: > > > Anyway, I do not think it is expected that kmalloc_node just blows up > > on those nodes. The page allocator simply falls back to the closest > > node. Something for kmalloc maintainers I believe. > > That is the case for an unconstrained allocation. kmalloc_node means that > you want memory from that node. And If there is no such node then it is an > error. Hmm, nasty. Is there any reason why kmalloc_node behaves differently from the page allocator? > > A short summary. kmalloc_node blows up when trying to allocate from a > > memory less node. > > Use kmalloc instead? And set a memory allocation policy? The current code (memcg_expand_one_shrinker_map resp. memcg_alloc_shrinker_maps) already use kvmalloc. Kirill's patch wanted to make those data structure on the respective node and kvmalloc_node sounded like the right thing to do. It comes as a surprise that the kernel simply blows up on a memory less node rather than falling back to a close node gracefully. I suspect this already happens when the target node is out of memory, right? How would a memory allocation policy help in this case btw.? -- Michal Hocko SUSE Labs
Re: [PATCH v3 2/7] mm/memory_hotplug: Rename mhp_restrictions to mhp_params
On 21.02.20 19:24, Logan Gunthorpe wrote: > The mhp_restrictions struct really doesn't specify anything resembling > a restriction anymore so rename it to be mhp_params as it is a list > of extended parameters. > > Signed-off-by: Logan Gunthorpe Reviewed-by: David Hildenbrand -- Thanks, David / dhildenb
RE: [PATCH v6 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
Hi Michael and Shawn, I'll update the patch with iommu-map property. Thanks, Zhiqiang > -Original Message- > From: Michael Walle > Sent: 2020年2月24日 16:54 > To: Shawn Guo > Cc: Xiaowei Bao ; Z.q. Hou > ; bhelg...@google.com; > devicet...@vger.kernel.org; Leo Li ; > linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; > linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; > lorenzo.pieral...@arm.com; mark.rutl...@arm.com; M.h. Lian > ; Mingkai Hu ; > robh...@kernel.org; Roy Zang > Subject: Re: [PATCH v6 2/3] arm64: dts: ls1028a: Add PCIe controller DT > nodes > > Hi Shawn, all, > > Am 2020-02-24 09:43, schrieb Shawn Guo: > > On Mon, Feb 24, 2020 at 09:11:05AM +0100, Michael Walle wrote: > >> Hi Xiaowei, Hi Shawn, > >> > >> > LS1028a implements 2 PCIe 3.0 controllers. > >> > >> Patch 1/3 and 3/3 are in Linus' tree but nobody seems to care about > >> this patch anymore :( > >> > >> This doesn't work well with the IOMMU, because the iommu-map property > >> is missing. The bootloader needs the &smmu phandle to fixup the > >> entry. > >> See > >> below. > >> > >> Shawn, will you add this patch to your tree once its fixed, > >> considering it just adds the device tree node for the LS1028A? > > > > The patch/thread is a bit aged. You may want to send an updated patch > > for discussion. > > So should I just pick up the patch add my two fixes and send it again? > What about > the Signed-off-by tags? Leave them? Replace them? Add mine? > > -michael
Re: [PATCH][next] soc: fsl: dpio: fix dereference of pointer p before null check
On Fri, Feb 21, 2020 at 11:11:43PM +, Colin King wrote: > --- > drivers/soc/fsl/dpio/qbman-portal.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/soc/fsl/dpio/qbman-portal.c > b/drivers/soc/fsl/dpio/qbman-portal.c > index 740ee0d19582..d1f49caa5b13 100644 > --- a/drivers/soc/fsl/dpio/qbman-portal.c > +++ b/drivers/soc/fsl/dpio/qbman-portal.c > @@ -249,10 +249,11 @@ struct qbman_swp *qbman_swp_init(const struct > qbman_swp_desc *d) > u32 mask_size; > u32 eqcr_pi; > > - spin_lock_init(&p->access_spinlock); > - > if (!p) > return NULL; > + > + spin_lock_init(&p->access_spinlock); Allocations in the declaration blog are not super common in the kernel, but they're more bug prone. Generally, it's not beautiful to call a function which can fail in the allocation block. regards, dan carpenter
Re: [PATCH v3 6/7] mm/memory_hotplug: Add pgprot_t to mhp_params
On 21.02.20 19:25, Logan Gunthorpe wrote:
> devm_memremap_pages() is currently used by the PCI P2PDMA code to create
> struct page mappings for IO memory. At present, these mappings are created
> with PAGE_KERNEL which implies setting the PAT bits to be WB. However, on
> x86, an mtrr register will typically override this and force the cache
> type to be UC-. In the case firmware doesn't set this register it is
> effectively WB and will typically result in a machine check exception
> when it's accessed.
>
> Other arches are not currently likely to function correctly seeing they
> don't have any MTRR registers to fall back on.
>
> To solve this, provide a way to specify the pgprot value explicitly to
> arch_add_memory().
>
> Of the arches that support MEMORY_HOTPLUG: x86_64, and arm64 need a simple
> change to pass the pgprot_t down to their respective functions which set
> up the page tables. For x86_32, set the page tables explicitly using
> _set_memory_prot() (seeing they are already mapped). For ia64, s390 and
> sh, reject anything but PAGE_KERNEL settings -- this should be fine,
> for now, seeing these architectures don't support ZONE_DEVICE.
>
> A check in __add_pages() is also added to ensure the pgprot parameter was
> set for all arches.
>
> Cc: Dan Williams
> Signed-off-by: Logan Gunthorpe
> Acked-by: David Hildenbrand
> Acked-by: Michal Hocko
[...]
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index c5df1b3dada0..30d6c1b8847e 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -56,9 +56,11 @@ enum {
> /*
> * Extended parameters for memory hotplug:
> * altmap: alternative allocator for memmap array (optional)
> + * pgprot: page protection flags to apply to newly added page tables
> (required)
s/added/created/?
--
Thanks,
David / dhildenb
Re: [PATCH 1/2] powerpc/powernv: Treat an empty reboot string as default
On Mon, Feb 24, 2020 at 01:32:28PM +1100, Alexey Kardashevskiy wrote: > On 17/02/2020 13:48, Oliver O'Halloran wrote: > > Treat an empty reboot cmd string the same as a NULL string. This squashes a > > spurious unsupported reboot message that sometimes gets out when using > > xmon. > > - if (!cmd) > > + if (!cmd || !strlen(cmd)) > > nit: this does not matter here in practice but > > if (!cmd || cmd[0] == '\0') > > is faster (you do not care about the length anyway) and safer (@cmd can > potentially be endless) ;) No it isn't, this compiles to identical machine code. (I tested with GCC 9, and going back until 4.6 -- the generated code becomes progressively worse (unrelated to this code, fwiw), but identical for both cases all the time). Segher
Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
Hi Amit,
On Fri, Feb 21, 2020 at 2:36 PM Amit Kachhap wrote:
>
> Hi Bhupesh,
>
> On 1/13/20 5:44 PM, Bhupesh Sharma wrote:
> > Hi James,
> >
> > On 01/11/2020 12:30 AM, Dave Anderson wrote:
> >>
> >> - Original Message -
> >>> Hi Bhupesh,
> >>>
> >>> On 25/12/2019 19:01, Bhupesh Sharma wrote:
> On 12/12/2019 04:02 PM, James Morse wrote:
> > On 29/11/2019 19:59, Bhupesh Sharma wrote:
> >> vabits_actual variable on arm64 indicates the actual VA space size,
> >> and allows a single binary to support both 48-bit and 52-bit VA
> >> spaces.
> >>
> >> If the ARMv8.2-LVA optional feature is present, and we are running
> >> with a 64KB page size; then it is possible to use 52-bits of address
> >> space for both userspace and kernel addresses. However, any kernel
> >> binary that supports 52-bit must also be able to fall back to 48-bit
> >> at early boot time if the hardware feature is not present.
> >>
> >> Since TCR_EL1.T1SZ indicates the size offset of the memory region
> >> addressed by TTBR1_EL1 (and hence can be used for determining the
> >> vabits_actual value) it makes more sense to export the same in
> >> vmcoreinfo rather than vabits_actual variable, as the name of the
> >> variable can change in future kernel versions, but the architectural
> >> constructs like TCR_EL1.T1SZ can be used better to indicate intended
> >> specific fields to user-space.
> >>
> >> User-space utilities like makedumpfile and crash-utility, need to
> >> read/write this value from/to vmcoreinfo
> >
> > (write?)
>
> Yes, also write so that the vmcoreinfo from an (crashing) arm64
> system can
> be used for
> analysis of the root-cause of panic/crash on say an x86_64 host using
> utilities like
> crash-utility/gdb.
> >>>
> >>> I read this as as "User-space [...] needs to write to vmcoreinfo".
> >
> > That's correct. But for writing to vmcore dump in the kdump kernel, we
> > need to read the symbols from the vmcoreinfo in the primary kernel.
> >
> >> for determining if a virtual address lies in the linear map range.
> >
> > I think this is a fragile example. The debugger shouldn't need to know
> > this.
>
> Well that the current user-space utility design, so I am not sure we
> can
> tweak that too much.
>
> >> The user-space computation for determining whether an address lies in
> >> the linear map range is the same as we have in kernel-space:
> >>
> >> #define __is_lm_address(addr)(!(((u64)addr) &
> >> BIT(vabits_actual -
> >> 1)))
> >
> > This was changed with 14c127c957c1 ("arm64: mm: Flip kernel VA
> > space"). If
> > user-space
> > tools rely on 'knowing' the kernel memory layout, they must have to
> > constantly be fixed
> > and updated. This is a poor argument for adding this to something that
> > ends up as ABI.
>
> See above. The user-space has to rely on some ABI/guaranteed
> hardware-symbols which can be
> used for 'determining' the kernel memory layout.
> >>>
> >>> I disagree. Everything and anything in the kernel will change. The
> >>> ABI rules apply to
> >>> stuff exposed via syscalls and kernel filesystems. It does not apply
> >>> to kernel internals,
> >>> like the memory layout we used yesterday. 14c127c957c1 is a case in
> >>> point.
> >>>
> >>> A debugger trying to rely on this sort of thing would have to play
> >>> catchup whenever it
> >>> changes.
> >>
> >> Exactly. That's the whole point.
> >>
> >> The crash utility and makedumpfile are not in the same league as other
> >> user-space tools.
> >> They have always had to "play catchup" precisely because they depend
> >> upon kernel internals,
> >> which constantly change.
> >
> > I agree with you and DaveA here. Software user-space debuggers are
> > dependent on kernel internals (which can change from time-to-time) and
> > will have to play catch-up (which has been the case since the very start).
> >
> > Unfortunately we don't have any clear ABI for software debugging tools -
> > may be something to look for in future.
> >
> > A case in point is gdb/kgdb, which still needs to run with KASLR
> > turned-off (nokaslr) for debugging, as it confuses gdb which resolve
> > kernel symbol address from symbol table of vmlinux. But we can
> > work-around the same in makedumpfile/crash by reading the 'kaslr_offset'
> > value. And I have several users telling me now they cannot use gdb on
> > KASLR enabled kernel to debug panics, but can makedumpfile + crash
> > combination to achieve the same.
> >
> > So, we should be looking to fix these utilities which are broken since
> > the 52-bit changes for arm64. Accordingly, I will try to send the v6
> > soon while incorporating the comments posted on the v5.
>
> Any update on the next v6 version. Since this patch series is fixing the
> current broken kdump so need t
Re: vdso function descriptors (VDS64_HAS_DESCRIPTORS)?
On Sat, 2020-02-22 at 18:07 -0600, Segher Boessenkool wrote: > > > > so I don't believe they are ever used by default -- in this case > > V_FUNCTION_BEGIN doesn't add to the .opd section with .name, .TOC base, > > etc. > > > > Manually setting VDS64_HAS_DESCRIPTORS results in a vdso64.so in which > > binutils tools like readelf properly report functions with symbol type > > FUNC instead of NOTYPE. > > > > Are there pieces of the build/etc toolchain unprepared for function > > descriptors? I'm just trying to figure out why the code defaults to > > unsetting them. > > Because direct calls are faster than indirect calls? Ben might have a > fuller explanation, cc:ing him. I don't remember why :-) I think I didn't want to mess with the OPD fixup in glibc back then. Ben.
Re: [RFC PATCH v2 02/12] powerpc/ptrace: drop unnecessary #ifdefs CONFIG_PPC64
Christophe Leroy writes:
> Drop a bunch of #ifdefs CONFIG_PPC64 that are not vital.
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/include/asm/ptrace.h | 9 -
> arch/powerpc/include/uapi/asm/ptrace.h | 12
> arch/powerpc/kernel/ptrace/ptrace.c| 24 +++-
> 3 files changed, 11 insertions(+), 34 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ptrace.h
> b/arch/powerpc/include/asm/ptrace.h
> index faa5a338ac5a..1506a9c61d50 100644
> --- a/arch/powerpc/include/asm/ptrace.h
> +++ b/arch/powerpc/include/asm/ptrace.h
> @@ -36,11 +36,10 @@ struct pt_regs
> unsigned long link;
> unsigned long xer;
> unsigned long ccr;
> -#ifdef CONFIG_PPC64
> - unsigned long softe;
> -#else
> - unsigned long mq;
> -#endif
> + union {
> + unsigned long softe;
> + unsigned long mq;
> + };
> unsigned long trap;
> unsigned long dar;
> unsigned long dsisr;
> diff --git a/arch/powerpc/include/uapi/asm/ptrace.h
> b/arch/powerpc/include/uapi/asm/ptrace.h
> index f5f1ccc740fc..37d7befbb8dc 100644
> --- a/arch/powerpc/include/uapi/asm/ptrace.h
> +++ b/arch/powerpc/include/uapi/asm/ptrace.h
> @@ -43,12 +43,11 @@ struct pt_regs
> unsigned long link;
> unsigned long xer;
> unsigned long ccr;
> -#ifdef __powerpc64__
> - unsigned long softe;/* Soft enabled/disabled */
> -#else
> - unsigned long mq; /* 601 only (not used at present) */
> + union {
> + unsigned long softe;/* Soft enabled/disabled */
> + unsigned long mq; /* 601 only (not used at present) */
> /* Used on APUS to hold IPL value. */
> -#endif
> + };
As Andreas pointed out this is not safe as this is a uapi header.
> unsigned long trap; /* Reason for being here */
> /* N.B. for critical exceptions on 4xx, the dar and dsisr
> fields are overloaded to hold srr0 and srr1. */
> @@ -105,11 +104,8 @@ struct pt_regs
> #define PT_LNK 36
> #define PT_XER 37
> #define PT_CCR 38
> -#ifndef __powerpc64__
> #define PT_MQ39
> -#else
> #define PT_SOFTE 39
> -#endif
I'd also rather leave that as it is.
There's a slim chance it could break some code that already has either
of those defined.
If you need them both defined to make other code work in the kernel
that's fine, in the kernel header we can do:
// Ensure these are always defined inside the kernel to avoid #ifdefs
#ifdef CONFIG_PPC64
#define PT_MQ 39
#else
#define PT_SOFTE 39
#endif
> #define PT_TRAP 40
> #define PT_DAR 41
> #define PT_DSISR 42
> diff --git a/arch/powerpc/kernel/ptrace/ptrace.c
> b/arch/powerpc/kernel/ptrace/ptrace.c
> index 684b0b315c32..0afb223c4d57 100644
> --- a/arch/powerpc/kernel/ptrace/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace/ptrace.c
> @@ -113,11 +113,8 @@ static const struct pt_regs_offset regoffset_table[] = {
> REG_OFFSET_NAME(link),
> REG_OFFSET_NAME(xer),
> REG_OFFSET_NAME(ccr),
> -#ifdef CONFIG_PPC64
> REG_OFFSET_NAME(softe),
> -#else
> REG_OFFSET_NAME(mq),
> -#endif
Pretty sure that will cause breakage. The offset is ABI.
cheers
Re: [RFC PATCH v2 04/12] powerpc/ptrace: split out VSX related functions.
Christophe Leroy writes: > diff --git a/arch/powerpc/kernel/ptrace/ptrace-novsx.c > b/arch/powerpc/kernel/ptrace/ptrace-novsx.c > new file mode 100644 > index ..55fbbb4aa9d7 > --- /dev/null > +++ b/arch/powerpc/kernel/ptrace/ptrace-novsx.c > @@ -0,0 +1,83 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include I suspect we probably don't need all those headers anymore. But I guess we'll clean them up in future, as it's very tedious work to trim the list. > + > +#include It's preferable to use: #include "ptrace-decl.h" cheers
Re: [RFC PATCH v2 00/12] Reduce ifdef mess in ptrace
Christophe Leroy writes: > Le 24/02/2020 à 03:15, Michael Neuling a écrit : >> Christophe, >>> Le 28/06/2019 à 17:47, Christophe Leroy a écrit : The purpose of this series is to reduce the amount of #ifdefs in ptrace.c >>> >>> Any feedback on this series which aims at fixing the issue you opened at >>> https://github.com/linuxppc/issues/issues/128 ? >> >> Yeah, sorry my bad. You did all the hard work and I ignored it. >> >> I like the approach and is a long the lines I was thinking. Putting it in a >> ptrace subdir, splitting out adv_debug_regs, TM, SPE, Alitivec, VSX. >> ppc_gethwdinfo() looks a lot nicer now too (that was some of the worst of >> it). >> >> I've not gone through it with a fine tooth comb though. There is (rightly) a >> lot >> of code moved around which could have introduced some issues. >> >> It applies on v5.2 but are you planning on updating it to a newer base? >> > > As you noticed there is a lot of code moved around, and rebasing > produces a lot of conflicts. So I didn't want to spend hours to rebase > and rebase without being sure it was the right approach. > > Now that I got a positive feedback I'll consider rebasing it, hopping > that Michael will pick it up. I would love to. cheers
Re: [PATCH 3/7] docs: fix broken references to text files
On Saturday, February 22, 2020 10:00:03 AM CET Mauro Carvalho Chehab wrote: > Several references got broken due to txt to ReST conversion. > > Several of them can be automatically fixed with: > > scripts/documentation-file-ref-check --fix > > Signed-off-by: Mauro Carvalho Chehab > --- > 26) If any ioctl's are added by the patch, then also update > -``Documentation/ioctl/ioctl-number.rst``. > +``Documentation/userspace-api/ioctl/ioctl-number.rst``. > > 27) If your modified source code depends on or uses any of the kernel > APIs or features that are related to the following ``Kconfig`` symbols, > diff --git a/Documentation/translations/it_IT/process/submit-checklist.rst > b/Documentation/translations/it_IT/process/submit-checklist.rst index > 995ee69fab11..3e575502690f 100644 > --- a/Documentation/translations/it_IT/process/submit-checklist.rst > +++ b/Documentation/translations/it_IT/process/submit-checklist.rst > @@ -117,7 +117,7 @@ sottomissione delle patch, in particolare > sorgenti che ne spieghi la logica: cosa fanno e perché. > > 25) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate > -``Documentation/ioctl/ioctl-number.rst``. > +``Documentation/userspace-api/ioctl/ioctl-number.rst``. Acked-By: Federico Vaga
Re: [PATCH] powerpc: Include .BTF section
"Naveen N. Rao" writes:
> Michael Ellerman wrote:
>> "Naveen N. Rao" writes:
>>> Selecting CONFIG_DEBUG_INFO_BTF results in the below warning from ld:
>>> ld: warning: orphan section `.BTF' from `.btf.vmlinux.bin.o' being placed
>>> in section `.BTF'
>>>
>>> Include .BTF section in vmlinux explicitly to fix the same.
>>
>> I don't see any other architectures doing this in their linker script.
>> Why are we special?
>
> I think this is due to commit 83a092cf95f28 ("powerpc: Link warning for
> orphan sections"):
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83a092cf95f28
Oh haha, right :}
> PS: I also see a linker warning for '.gnu.hash' if I enable
> CONFIG_RELOCATABLE, but I couldn't decipher what that was for, and if it
> should be retained.
Yeah, Joel tried to remove it but it caused breakage:
https://lore.kernel.org/linuxppc-dev/87d0pwqweg@concordia.ellerman.id.au/
I never got around to looking at it.
cheers
Re: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)
On Thu, Feb 20, 2020 at 10:48:33AM +0100, Jiri Slaby wrote:
> On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote:
> > The ioreadX() helpers have inconsistent interface. On some architectures
> > void *__iomem address argument is a pointer to const, on some not.
> >
> > Implementations of ioreadX() do not modify the memory under the address
> > so they can be converted to a "const" version for const-safety and
> > consistency among architectures.
> >
> > Signed-off-by: Krzysztof Kozlowski
> > Acked-by: Kalle Valo
> > ---
> > drivers/net/wireless/ath/ath5k/ahb.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath5k/ahb.c
> > b/drivers/net/wireless/ath/ath5k/ahb.c
> > index 2c9cec8b53d9..8bd01df369fb 100644
> > --- a/drivers/net/wireless/ath/ath5k/ahb.c
> > +++ b/drivers/net/wireless/ath/ath5k/ahb.c
> > @@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device *pdev)
> >
> > if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
> > /* Enable WMAC AHB arbitration */
> > - reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
> > + reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
>
> While I understand why the parameter of ioread32 should be const, I
> don't see a reason for these casts on the users' side. What does it
> bring except longer code to read?
Because the argument is an int:
drivers/net/wireless/ath/ath5k/ahb.c: In function ‘ath_ahb_probe’:
drivers/net/wireless/ath/ath5k/ahb.c:141:18: warning: passing argument 1 of
‘ioread32’ makes pointer from integer without a cast [-Wint-conversion]
reg = ioread32(AR5K_AR2315_AHB_ARB_CTL);
Best regards,
Krzysztof
Re: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)
Hi Krzysztof,
On Mon, Feb 24, 2020 at 1:47 PM Krzysztof Kozlowski wrote:
> On Thu, Feb 20, 2020 at 10:48:33AM +0100, Jiri Slaby wrote:
> > On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote:
> > > The ioreadX() helpers have inconsistent interface. On some architectures
> > > void *__iomem address argument is a pointer to const, on some not.
> > >
> > > Implementations of ioreadX() do not modify the memory under the address
> > > so they can be converted to a "const" version for const-safety and
> > > consistency among architectures.
> > >
> > > Signed-off-by: Krzysztof Kozlowski
> > > Acked-by: Kalle Valo
> > > ---
> > > drivers/net/wireless/ath/ath5k/ahb.c | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/ath/ath5k/ahb.c
> > > b/drivers/net/wireless/ath/ath5k/ahb.c
> > > index 2c9cec8b53d9..8bd01df369fb 100644
> > > --- a/drivers/net/wireless/ath/ath5k/ahb.c
> > > +++ b/drivers/net/wireless/ath/ath5k/ahb.c
> > > @@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device
> > > *pdev)
> > >
> > > if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
> > > /* Enable WMAC AHB arbitration */
> > > - reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
> > > + reg = ioread32((const void __iomem *)
> > > AR5K_AR2315_AHB_ARB_CTL);
> >
> > While I understand why the parameter of ioread32 should be const, I
> > don't see a reason for these casts on the users' side. What does it
> > bring except longer code to read?
>
> Because the argument is an int:
>
> drivers/net/wireless/ath/ath5k/ahb.c: In function ‘ath_ahb_probe’:
> drivers/net/wireless/ath/ath5k/ahb.c:141:18: warning: passing argument 1 of
> ‘ioread32’ makes pointer from integer without a cast [-Wint-conversion]
>reg = ioread32(AR5K_AR2315_AHB_ARB_CTL);
That's an argument for keeping the cast to "void __iomem *", not for
adding the "const", right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)
From: Geert Uytterhoeven
> Sent: 24 February 2020 12:54
> To: Krzysztof Kozlowski
...
> > > > diff --git a/drivers/net/wireless/ath/ath5k/ahb.c
> > > > b/drivers/net/wireless/ath/ath5k/ahb.c
> > > > index 2c9cec8b53d9..8bd01df369fb 100644
> > > > --- a/drivers/net/wireless/ath/ath5k/ahb.c
> > > > +++ b/drivers/net/wireless/ath/ath5k/ahb.c
> > > > @@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device
> > > > *pdev)
> > > >
> > > > if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
> > > > /* Enable WMAC AHB arbitration */
> > > > - reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
> > > > + reg = ioread32((const void __iomem *)
> > > > AR5K_AR2315_AHB_ARB_CTL);
> > >
> > > While I understand why the parameter of ioread32 should be const, I
> > > don't see a reason for these casts on the users' side. What does it
> > > bring except longer code to read?
> >
> > Because the argument is an int:
> >
> > drivers/net/wireless/ath/ath5k/ahb.c: In function ‘ath_ahb_probe’:
> > drivers/net/wireless/ath/ath5k/ahb.c:141:18: warning: passing argument 1 of
> > ‘ioread32’ makes pointer
> from integer without a cast [-Wint-conversion]
> >reg = ioread32(AR5K_AR2315_AHB_ARB_CTL);
>
> That's an argument for keeping the cast to "void __iomem *", not for
> adding the "const", right?
Or more likely change the definitions to use a struct for the layout.
That also stops the constants being used in the wrong place.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)
On Mon, Feb 24, 2020 at 01:54:00PM +0100, Geert Uytterhoeven wrote:
> Hi Krzysztof,
>
> On Mon, Feb 24, 2020 at 1:47 PM Krzysztof Kozlowski wrote:
> > On Thu, Feb 20, 2020 at 10:48:33AM +0100, Jiri Slaby wrote:
> > > On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote:
> > > > The ioreadX() helpers have inconsistent interface. On some
> > > > architectures
> > > > void *__iomem address argument is a pointer to const, on some not.
> > > >
> > > > Implementations of ioreadX() do not modify the memory under the address
> > > > so they can be converted to a "const" version for const-safety and
> > > > consistency among architectures.
> > > >
> > > > Signed-off-by: Krzysztof Kozlowski
> > > > Acked-by: Kalle Valo
> > > > ---
> > > > drivers/net/wireless/ath/ath5k/ahb.c | 10 +-
> > > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/net/wireless/ath/ath5k/ahb.c
> > > > b/drivers/net/wireless/ath/ath5k/ahb.c
> > > > index 2c9cec8b53d9..8bd01df369fb 100644
> > > > --- a/drivers/net/wireless/ath/ath5k/ahb.c
> > > > +++ b/drivers/net/wireless/ath/ath5k/ahb.c
> > > > @@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device
> > > > *pdev)
> > > >
> > > > if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
> > > > /* Enable WMAC AHB arbitration */
> > > > - reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
> > > > + reg = ioread32((const void __iomem *)
> > > > AR5K_AR2315_AHB_ARB_CTL);
> > >
> > > While I understand why the parameter of ioread32 should be const, I
> > > don't see a reason for these casts on the users' side. What does it
> > > bring except longer code to read?
> >
> > Because the argument is an int:
> >
> > drivers/net/wireless/ath/ath5k/ahb.c: In function ‘ath_ahb_probe’:
> > drivers/net/wireless/ath/ath5k/ahb.c:141:18: warning: passing argument 1 of
> > ‘ioread32’ makes pointer from integer without a cast [-Wint-conversion]
> >reg = ioread32(AR5K_AR2315_AHB_ARB_CTL);
>
> That's an argument for keeping the cast to "void __iomem *", not for
> adding the "const", right?
Yes, correct. Maybe I misunderstood the question... The const on the
other hand does not have to be in the cast. It is merely for making it
consistent with interface. It is not required. I also mentioned it in
the cover letter:
"PAtches 5-9 are optional cleanup, without actual impact"
Feel free to ignore this one if it is not worth the effort.
Best regards,
Krzysztof
Re: vdso function descriptors (VDS64_HAS_DESCRIPTORS)?
On 2/24/20 5:17 AM, Benjamin Herrenschmidt wrote: On Sat, 2020-02-22 at 18:07 -0600, Segher Boessenkool wrote: so I don't believe they are ever used by default -- in this case V_FUNCTION_BEGIN doesn't add to the .opd section with .name, .TOC base, etc. Manually setting VDS64_HAS_DESCRIPTORS results in a vdso64.so in which binutils tools like readelf properly report functions with symbol type FUNC instead of NOTYPE. Are there pieces of the build/etc toolchain unprepared for function descriptors? I'm just trying to figure out why the code defaults to unsetting them. Because direct calls are faster than indirect calls? Ben might have a fuller explanation, cc:ing him. I don't remember why :-) I think I didn't want to mess with the OPD fixup in glibc back then. Does it make sense to just drop the unused VDS64_HAS_DESCRIPTORS code then? -- Joe
Re: vdso function descriptors (VDS64_HAS_DESCRIPTORS)?
On Mon, 2020-02-24 at 10:20 -0500, Joe Lawrence wrote: > On > > I don't remember why :-) I think I didn't want to mess with the OPD > > fixup in glibc back then. > > > > Does it make sense to just drop the unused VDS64_HAS_DESCRIPTORS code > then? I'd think so yes. Cheers, Ben.
[PATCH] crypto: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva
---
drivers/crypto/caam/caamalg.c | 2 +-
drivers/crypto/caam/caamalg_qi.c | 4 ++--
drivers/crypto/caam/caamalg_qi2.h | 6 +++---
drivers/crypto/caam/caamhash.c | 2 +-
drivers/crypto/cavium/nitrox/nitrox_main.c | 2 +-
drivers/crypto/chelsio/chcr_core.h | 2 +-
drivers/crypto/mediatek/mtk-sha.c | 2 +-
drivers/crypto/nx/nx.h | 2 +-
drivers/crypto/omap-sham.c | 4 ++--
include/crypto/if_alg.h| 2 +-
10 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 03797f9b1050..b7bb7c30adeb 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -909,7 +909,7 @@ struct skcipher_edesc {
bool bklog;
dma_addr_t sec4_sg_dma;
struct sec4_sg_entry *sec4_sg;
- u32 hw_desc[0];
+ u32 hw_desc[];
};
static void caam_unmap(struct device *dev, struct scatterlist *src,
diff --git a/drivers/crypto/caam/caamalg_qi.c b/drivers/crypto/caam/caamalg_qi.c
index 4a29e0ef9d63..27e36bdf6163 100644
--- a/drivers/crypto/caam/caamalg_qi.c
+++ b/drivers/crypto/caam/caamalg_qi.c
@@ -783,7 +783,7 @@ struct aead_edesc {
unsigned int assoclen;
dma_addr_t assoclen_dma;
struct caam_drv_req drv_req;
- struct qm_sg_entry sgt[0];
+ struct qm_sg_entry sgt[];
};
/*
@@ -803,7 +803,7 @@ struct skcipher_edesc {
int qm_sg_bytes;
dma_addr_t qm_sg_dma;
struct caam_drv_req drv_req;
- struct qm_sg_entry sgt[0];
+ struct qm_sg_entry sgt[];
};
static struct caam_drv_ctx *get_drv_ctx(struct caam_ctx *ctx,
diff --git a/drivers/crypto/caam/caamalg_qi2.h
b/drivers/crypto/caam/caamalg_qi2.h
index 706736776b47..f29cb7bd7dd3 100644
--- a/drivers/crypto/caam/caamalg_qi2.h
+++ b/drivers/crypto/caam/caamalg_qi2.h
@@ -114,7 +114,7 @@ struct aead_edesc {
dma_addr_t qm_sg_dma;
unsigned int assoclen;
dma_addr_t assoclen_dma;
- struct dpaa2_sg_entry sgt[0];
+ struct dpaa2_sg_entry sgt[];
};
/*
@@ -132,7 +132,7 @@ struct skcipher_edesc {
dma_addr_t iv_dma;
int qm_sg_bytes;
dma_addr_t qm_sg_dma;
- struct dpaa2_sg_entry sgt[0];
+ struct dpaa2_sg_entry sgt[];
};
/*
@@ -146,7 +146,7 @@ struct ahash_edesc {
dma_addr_t qm_sg_dma;
int src_nents;
int qm_sg_bytes;
- struct dpaa2_sg_entry sgt[0];
+ struct dpaa2_sg_entry sgt[];
};
/**
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 2fe852853d40..943bc0296267 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -536,7 +536,7 @@ struct ahash_edesc {
int sec4_sg_bytes;
bool bklog;
u32 hw_desc[DESC_JOB_IO_LEN_MAX / sizeof(u32)] cacheline_aligned;
- struct sec4_sg_entry sec4_sg[0];
+ struct sec4_sg_entry sec4_sg[];
};
static inline void ahash_unmap(struct device *dev,
diff --git a/drivers/crypto/cavium/nitrox/nitrox_main.c
b/drivers/crypto/cavium/nitrox/nitrox_main.c
index c4632d84c9a1..e91be9b8b083 100644
--- a/drivers/crypto/cavium/nitrox/nitrox_main.c
+++ b/drivers/crypto/cavium/nitrox/nitrox_main.c
@@ -71,7 +71,7 @@ struct ucode {
char version[VERSION_LEN - 1];
__be32 code_size;
u8 raz[12];
- u64 code[0];
+ u64 code[];
};
/**
diff --git a/drivers/crypto/chelsio/chcr_core.h
b/drivers/crypto/chelsio/chcr_core.h
index b41ef1abfe74..e480096754b5 100644
--- a/drivers/crypto/chelsio/chcr_core.h
+++ b/drivers/crypto/chelsio/chcr_core.h
@@ -68,7 +68,7 @@ struct _key_ctx {
__be32 ctx_hdr;
u8 salt[MAX_SALT];
__be64 iv_to_auth;
- unsigned char key[0];
+ unsigned char key[];
};
#define KEYCTX_TX_WR_IV_S 55
diff --git a/drivers/crypto/mediatek/mtk-
[PATCH][next] toshiba: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/ethernet/toshiba/ps3_gelic_net.h | 2 +-
drivers/net/ethernet/toshiba/ps3_gelic_wireless.h | 2 +-
drivers/net/ethernet/toshiba/spider_net.h | 2 +-
drivers/net/ethernet/toshiba/tc35815.c| 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.h
b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
index 805903dbddcc..68f324ed4eaf 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.h
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
@@ -308,7 +308,7 @@ struct gelic_port {
struct gelic_card *card;
struct net_device *netdev;
enum gelic_port_type type;
- long priv[0]; /* long for alignment */
+ long priv[]; /* long for alignment */
};
static inline struct gelic_card *port_to_card(struct gelic_port *p)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.h
b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.h
index 4041d946b649..1f203d1ae8db 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.h
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.h
@@ -158,7 +158,7 @@ struct gelic_eurus_scan_info {
__be32 reserved2;
__be32 reserved3;
__be32 reserved4;
- u8 elements[0]; /* ie */
+ u8 elements[]; /* ie */
} __packed;
/* the hypervisor returns bbs up to 16 */
diff --git a/drivers/net/ethernet/toshiba/spider_net.h
b/drivers/net/ethernet/toshiba/spider_net.h
index c0c68cbc898c..05b1a0736835 100644
--- a/drivers/net/ethernet/toshiba/spider_net.h
+++ b/drivers/net/ethernet/toshiba/spider_net.h
@@ -470,7 +470,7 @@ struct spider_net_card {
struct spider_net_extra_stats spider_stats;
/* Must be last item in struct */
- struct spider_net_descr darray[0];
+ struct spider_net_descr darray[];
};
#endif
diff --git a/drivers/net/ethernet/toshiba/tc35815.c
b/drivers/net/ethernet/toshiba/tc35815.c
index 3fd43d30b20d..b50c3ec3495b 100644
--- a/drivers/net/ethernet/toshiba/tc35815.c
+++ b/drivers/net/ethernet/toshiba/tc35815.c
@@ -367,7 +367,7 @@ struct TxFD {
struct RxFD {
struct FDesc fd;
- struct BDesc bd[0]; /* variable length */
+ struct BDesc bd[]; /* variable length */
};
struct FrFD {
--
2.25.0
[PATCH v2] powerpc/kprobes: Blacklist functions running with MMU disabled on PPC32
kprobe does not handle events happening in real mode, all functions running with MMU disabled have to be blacklisted. As already done for PPC64, do it for PPC32. Signed-off-by: Christophe Leroy --- v2: - Don't rename nonrecoverable as local, mark it noprobe instead. - Add missing linux/kprobes.h include in pq2.c --- arch/powerpc/include/asm/ppc_asm.h | 10 +++ arch/powerpc/kernel/cpu_setup_6xx.S | 4 +- arch/powerpc/kernel/entry_32.S | 65 arch/powerpc/kernel/fpu.S| 1 + arch/powerpc/kernel/idle_6xx.S | 2 +- arch/powerpc/kernel/idle_e500.S | 2 +- arch/powerpc/kernel/l2cr_6xx.S | 2 +- arch/powerpc/kernel/misc.S | 2 + arch/powerpc/kernel/misc_32.S| 4 +- arch/powerpc/kernel/swsusp_32.S | 6 +- arch/powerpc/kernel/vector.S | 1 + arch/powerpc/mm/book3s32/hash_low.S | 38 ++-- arch/powerpc/mm/mem.c| 2 + arch/powerpc/platforms/52xx/lite5200_sleep.S | 2 + arch/powerpc/platforms/82xx/pq2.c| 3 + arch/powerpc/platforms/83xx/suspend-asm.S| 1 + arch/powerpc/platforms/powermac/cache.S | 2 + arch/powerpc/platforms/powermac/sleep.S | 13 ++-- 18 files changed, 86 insertions(+), 74 deletions(-) diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h index 6b03dff61a05..e8f34ba89497 100644 --- a/arch/powerpc/include/asm/ppc_asm.h +++ b/arch/powerpc/include/asm/ppc_asm.h @@ -267,8 +267,18 @@ GLUE(.,name): .pushsection "_kprobe_blacklist","aw"; \ PPC_LONG (entry) ; \ .popsection +#define _NOKPROBE_ENTRY(entry) \ + _ASM_NOKPROBE_SYMBOL(entry) \ + _ENTRY(entry) +#define _NOKPROBE_GLOBAL(entry)\ + _ASM_NOKPROBE_SYMBOL(entry) \ + _GLOBAL(entry) #else #define _ASM_NOKPROBE_SYMBOL(entry) +#define _NOKPROBE_ENTRY(entry) \ + _ENTRY(entry) +#define _NOKPROBE_GLOBAL(entry)\ + _GLOBAL(entry) #endif #define FUNC_START(name) _GLOBAL(name) diff --git a/arch/powerpc/kernel/cpu_setup_6xx.S b/arch/powerpc/kernel/cpu_setup_6xx.S index f6517f67265a..1cb947268546 100644 --- a/arch/powerpc/kernel/cpu_setup_6xx.S +++ b/arch/powerpc/kernel/cpu_setup_6xx.S @@ -276,7 +276,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_NO_DPM) * in some 750 cpus where using a not yet initialized FPU register after * power on reset may hang the CPU */ -_GLOBAL(__init_fpu_registers) +_NOKPROBE_GLOBAL(__init_fpu_registers) mfmsr r10 ori r11,r10,MSR_FP mtmsr r11 @@ -381,7 +381,7 @@ _GLOBAL(__save_cpu_setup) * restore CPU state as backed up by the previous * function. This does not include cache setting */ -_GLOBAL(__restore_cpu_setup) +_NOKPROBE_GLOBAL(__restore_cpu_setup) /* Some CR fields are volatile, we back it up all */ mfcrr7 diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 16af0d8d90a8..f788d586254d 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -44,24 +44,21 @@ .align 12 #ifdef CONFIG_BOOKE - .globl mcheck_transfer_to_handler -mcheck_transfer_to_handler: +_NOKPROBE_ENTRY(mcheck_transfer_to_handler) mfspr r0,SPRN_DSRR0 stw r0,_DSRR0(r11) mfspr r0,SPRN_DSRR1 stw r0,_DSRR1(r11) /* fall through */ - .globl debug_transfer_to_handler -debug_transfer_to_handler: +_NOKPROBE_ENTRY(debug_transfer_to_handler) mfspr r0,SPRN_CSRR0 stw r0,_CSRR0(r11) mfspr r0,SPRN_CSRR1 stw r0,_CSRR1(r11) /* fall through */ - .globl crit_transfer_to_handler -crit_transfer_to_handler: +_NOKPROBE_ENTRY(crit_transfer_to_handler) #ifdef CONFIG_PPC_BOOK3E_MMU mfspr r0,SPRN_MAS0 stw r0,MAS0(r11) @@ -97,8 +94,7 @@ crit_transfer_to_handler: #endif #ifdef CONFIG_40x - .globl crit_transfer_to_handler -crit_transfer_to_handler: +_NOKPROBE_ENTRY(crit_transfer_to_handler) lwz r0,crit_r10@l(0) stw r0,GPR10(r11) lwz r0,crit_r11@l(0) @@ -124,13 +120,11 @@ crit_transfer_to_handler: * Note that we rely on the caller having set cr0.eq iff the exception * occurred in kernel mode (i.e. MSR:PR = 0). */ - .globl transfer_to_handler_full -transfer_to_handler_full: +_NOKPROBE_ENTRY(transfer_to_handler_full) SAVE_NVGPRS(r11) /* fall through */ - .globl transfer_to_handler -transfer_to_handler: +_NOKPROBE_ENTRY(transfer_to_handler) stw r2,GPR2(r11) stw r12,_NIP(r11) stw r9,_MSR(r11) @@ -194,8 +188,7 @@ transfer_to_handler: bt- 31-TLF_
[PATCH] powerpc/kprobes: Use probe_address() to read instructions
In order to avoid Oopses, use probe_address() to read the
instruction at the address where the trap happened.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/kprobes.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index 84567406b53d..a35320b79e16 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -276,14 +276,18 @@ int kprobe_handler(struct pt_regs *regs)
p = get_kprobe(addr);
if (!p) {
- if (*addr != BREAKPOINT_INSTRUCTION) {
+ unsigned int instr;
+
+ if (probe_kernel_address(addr, instr))
+ goto no_kprobe;
+
+ if (instr != BREAKPOINT_INSTRUCTION) {
/*
* PowerPC has multiple variants of the "trap"
* instruction. If the current instruction is a
* trap variant, it could belong to someone else
*/
- kprobe_opcode_t cur_insn = *addr;
- if (is_trap(cur_insn))
+ if (is_trap(instr))
goto no_kprobe;
/*
* The breakpoint instruction was removed right
--
2.25.0
[PATCH] powerpc/vdso: remove deprecated VDS64_HAS_DESCRIPTORS references
The original 2005 patch that introduced the powerpc vdso, pre-git
("ppc64: Implement a vDSO and use it for signal trampoline") notes that:
... symbols exposed by the vDSO aren't "normal" function symbols, apps
can't be expected to link against them directly, the vDSO's are both
seen as if they were linked at 0 and the symbols just contain offsets
to the various functions. This is done on purpose to avoid a
relocation step (ppc64 functions normally have descriptors with abs
addresses in them). When glibc uses those functions, it's expected to
use it's own trampolines that know how to reach them.
Despite that explanation, there remains dead #ifdef
VDS64_HAS_DESCRIPTORS code-blocks that provide alternate function
definitions that setup function descriptors.
Since VDS64_HAS_DESCRIPTORS has been unused for all these years, we
might as well finally remove it from the codebase.
Link: https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204430.html
Link: https://lore.kernel.org/lkml/1108002773.7733.196.camel@gaston/
Signed-off-by: Joe Lawrence
---
arch/powerpc/include/asm/vdso.h | 24
arch/powerpc/kernel/vdso.c | 5 -
2 files changed, 29 deletions(-)
diff --git a/arch/powerpc/include/asm/vdso.h b/arch/powerpc/include/asm/vdso.h
index b5e1f8f8a05c..2ff884853f97 100644
--- a/arch/powerpc/include/asm/vdso.h
+++ b/arch/powerpc/include/asm/vdso.h
@@ -13,9 +13,6 @@
#define VDSO_VERSION_STRINGLINUX_2.6.15
-/* Define if 64 bits VDSO has procedure descriptors */
-#undef VDS64_HAS_DESCRIPTORS
-
#ifndef __ASSEMBLY__
/* Offsets relative to thread->vdso_base */
@@ -28,25 +25,6 @@ int vdso_getcpu_init(void);
#else /* __ASSEMBLY__ */
#ifdef __VDSO64__
-#ifdef VDS64_HAS_DESCRIPTORS
-#define V_FUNCTION_BEGIN(name) \
- .globl name;\
-.section ".opd","a"; \
-.align 3; \
- name: \
- .quad .name,.TOC.@tocbase,0;\
- .previous; \
- .globl .name; \
- .type .name,@function; \
- .name: \
-
-#define V_FUNCTION_END(name) \
- .size .name,.-.name;
-
-#define V_LOCAL_FUNC(name) (.name)
-
-#else /* VDS64_HAS_DESCRIPTORS */
-
#define V_FUNCTION_BEGIN(name) \
.globl name;\
name: \
@@ -55,8 +33,6 @@ int vdso_getcpu_init(void);
.size name,.-name;
#define V_LOCAL_FUNC(name) (name)
-
-#endif /* VDS64_HAS_DESCRIPTORS */
#endif /* __VDSO64__ */
#ifdef __VDSO32__
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index b9a108411c0d..d3b77c15f9ce 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -391,12 +391,7 @@ static unsigned long __init find_function64(struct
lib64_elfinfo *lib,
symname);
return 0;
}
-#ifdef VDS64_HAS_DESCRIPTORS
- return *((u64 *)(vdso64_kbase + sym->st_value - VDSO64_LBASE)) -
- VDSO64_LBASE;
-#else
return sym->st_value - VDSO64_LBASE;
-#endif
}
static int __init vdso_do_func_patch64(struct lib32_elfinfo *v32,
--
2.21.1
Re: [PATCH][next] toshiba: Replace zero-length array with flexible-array member
From: "Gustavo A. R. Silva"
Date: Mon, 24 Feb 2020 10:32:52 -0600
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on.
>
> Also, notice that, dynamic memory allocations won't be affected by
> this change:
>
> "Flexible array members have incomplete type, and so the sizeof operator
> may not be applied. As a quirk of the original implementation of
> zero-length arrays, sizeof evaluates to zero."[1]
>
> This issue was found with the help of Coccinelle.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva
Applied.
[PATCH 1/8] powerpc: Update MAINTAINERS
A while back Paul pointed out I'd been maintaining the tree more or less solo for over five years, so perhaps it's time to update the MAINTAINERS entry. Ben & Paul still wrote most of the code, so keep them as Reviewers so they still get Cc'ed on things. But if you're wondering why your patch hasn't been merged that's my fault. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Signed-off-by: Michael Ellerman --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index fcd79fc38928..339bc3e53862 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9601,9 +9601,9 @@ F:arch/powerpc/platforms/powermac/ F: drivers/macintosh/ LINUX FOR POWERPC (32-BIT AND 64-BIT) -M: Benjamin Herrenschmidt -M: Paul Mackerras M: Michael Ellerman +R: Benjamin Herrenschmidt +R: Paul Mackerras W: https://github.com/linuxppc/linux/wiki L: linuxppc-dev@lists.ozlabs.org Q: http://patchwork.ozlabs.org/project/linuxppc-dev/list/ -- 2.21.1
[PATCH 2/8] powerpc: Update wiki link in MAINTAINERS
The wiki has moved, update the link. Signed-off-by: Michael Ellerman --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 339bc3e53862..435e4efc9a32 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9604,7 +9604,7 @@ LINUX FOR POWERPC (32-BIT AND 64-BIT) M: Michael Ellerman R: Benjamin Herrenschmidt R: Paul Mackerras -W: https://github.com/linuxppc/linux/wiki +W: https://github.com/linuxppc/wiki/wiki L: linuxppc-dev@lists.ozlabs.org Q: http://patchwork.ozlabs.org/project/linuxppc-dev/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git -- 2.21.1
[PATCH 3/8] powerpc: Remove PA SEMI MAINTAINERS entries
The PA SEMI entries have been orphaned for 3 ½ years, so fold them into the main POWERPC entry. The result of get_maintainer.pl is more or less unchanged. Cc: Olof Johansson Signed-off-by: Michael Ellerman --- MAINTAINERS | 19 ++- 1 file changed, 2 insertions(+), 17 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 435e4efc9a32..5c4f37c41188 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9621,6 +9621,8 @@ F:drivers/crypto/vmx/ F: drivers/i2c/busses/i2c-opal.c F: drivers/net/ethernet/ibm/ibmveth.* F: drivers/net/ethernet/ibm/ibmvnic.* +F: drivers/*/*/*pasemi* +F: drivers/*/*pasemi* F: drivers/pci/hotplug/pnv_php.c F: drivers/pci/hotplug/rpa* F: drivers/rtc/rtc-opal.c @@ -9675,13 +9677,6 @@ S: Orphan F: arch/powerpc/*/*virtex* F: arch/powerpc/*/*/*virtex* -LINUX FOR POWERPC PA SEMI PWRFICIENT -L: linuxppc-dev@lists.ozlabs.org -S: Orphan -F: arch/powerpc/platforms/pasemi/ -F: drivers/*/*pasemi* -F: drivers/*/*/*pasemi* - LINUX KERNEL DUMP TEST MODULE (LKDTM) M: Kees Cook S: Maintained @@ -12541,16 +12536,6 @@ W: http://wireless.kernel.org/en/users/Drivers/p54 S: Maintained F: drivers/net/wireless/intersil/p54/ -PA SEMI ETHERNET DRIVER -L: net...@vger.kernel.org -S: Orphan -F: drivers/net/ethernet/pasemi/* - -PA SEMI SMBUS DRIVER -L: linux-...@vger.kernel.org -S: Orphan -F: drivers/i2c/busses/i2c-pasemi.c - PACKING M: Vladimir Oltean L: net...@vger.kernel.org -- 2.21.1
[PATCH 4/8] powerpc: Mark 4xx as Orphan in MAINTAINERS
The 4xx platforms are no longer maintained. Cc: Alistair Popple Cc: Matt Porter Signed-off-by: Michael Ellerman --- MAINTAINERS | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5c4f37c41188..939da2ac08db 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9645,11 +9645,8 @@ F: arch/powerpc/platforms/512x/ F: arch/powerpc/platforms/52xx/ LINUX FOR POWERPC EMBEDDED PPC4XX -M: Alistair Popple -M: Matt Porter -W: http://www.penguinppc.org/ L: linuxppc-dev@lists.ozlabs.org -S: Maintained +S: Orphan F: arch/powerpc/platforms/40x/ F: arch/powerpc/platforms/44x/ -- 2.21.1
[PATCH 5/8] powerpc: Drop XILINX MAINTAINERS entry
This has been orphaned for ~7 years, remove it. Cc: Grant Likely Signed-off-by: Michael Ellerman --- MAINTAINERS | 6 -- 1 file changed, 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 939da2ac08db..d5db5cac5a39 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9668,12 +9668,6 @@ L: linuxppc-dev@lists.ozlabs.org S: Maintained F: arch/powerpc/platforms/8xx/ -LINUX FOR POWERPC EMBEDDED XILINX VIRTEX -L: linuxppc-dev@lists.ozlabs.org -S: Orphan -F: arch/powerpc/*/*virtex* -F: arch/powerpc/*/*/*virtex* - LINUX KERNEL DUMP TEST MODULE (LKDTM) M: Kees Cook S: Maintained -- 2.21.1
[PATCH 6/8] powerpc: Update MPC5XXX MAINTAINERS entry
It's several years since the last commit from Anatolij, so mark MPC5XXX as "Odd Fixes" rather than "Maintained". Also the git link no longer works so remove it. Cc: Anatolij Gustschin Signed-off-by: Michael Ellerman --- MAINTAINERS | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d5db5cac5a39..a46e19aadcbc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9639,8 +9639,7 @@ N:pseries LINUX FOR POWERPC EMBEDDED MPC5XXX M: Anatolij Gustschin L: linuxppc-dev@lists.ozlabs.org -T: git git://git.denx.de/linux-denx-agust.git -S: Maintained +S: Odd Fixes F: arch/powerpc/platforms/512x/ F: arch/powerpc/platforms/52xx/ -- 2.21.1
[PATCH 7/8] powerpc: Update powermac MAINTAINERS entry
Ben is no longer actively maintaining the powermac code, but we know where to find him if something really needs attention. The www.penguinppc.org link is dead so remove it. Cc: Benjamin Herrenschmidt Signed-off-by: Michael Ellerman --- MAINTAINERS | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index a46e19aadcbc..febffee28d00 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9594,9 +9594,8 @@ F:include/uapi/linux/lightnvm.h LINUX FOR POWER MACINTOSH M: Benjamin Herrenschmidt -W: http://www.penguinppc.org/ L: linuxppc-dev@lists.ozlabs.org -S: Maintained +S: Odd Fixes F: arch/powerpc/platforms/powermac/ F: drivers/macintosh/ -- 2.21.1
[PATCH 8/8] powerpc: Update 83xx/85xx MAINTAINERS entry
Scott said he was still maintaining this "sort of", so change the status to Odd Fixes. Kumar has long ago moved on to greener pastures. Remove the dead penguinppc.org link. Cc: Scott Wood Cc: Kumar Gala Signed-off-by: Michael Ellerman --- MAINTAINERS | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index febffee28d00..2e917116ef6a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9650,11 +9650,9 @@ F: arch/powerpc/platforms/44x/ LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX M: Scott Wood -M: Kumar Gala -W: http://www.penguinppc.org/ L: linuxppc-dev@lists.ozlabs.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git -S: Maintained +S: Odd fixes F: arch/powerpc/platforms/83xx/ F: arch/powerpc/platforms/85xx/ F: Documentation/devicetree/bindings/powerpc/fsl/ -- 2.21.1
Re: [PATCH] powerpc/vdso: remove deprecated VDS64_HAS_DESCRIPTORS references
Joe Lawrence writes:
> The original 2005 patch that introduced the powerpc vdso, pre-git
> ("ppc64: Implement a vDSO and use it for signal trampoline") notes that:
>
> ... symbols exposed by the vDSO aren't "normal" function symbols, apps
> can't be expected to link against them directly, the vDSO's are both
> seen as if they were linked at 0 and the symbols just contain offsets
> to the various functions. This is done on purpose to avoid a
> relocation step (ppc64 functions normally have descriptors with abs
> addresses in them). When glibc uses those functions, it's expected to
> use it's own trampolines that know how to reach them.
For the archives, that's here:
https://github.com/mpe/linux-fullhistory/commit/5f2dd691b62da9d9cc54b938f8b29c22c93cb805
And reproduced below.
cheers
commit 5f2dd691b62da9d9cc54b938f8b29c22c93cb805
Author: Benjamin Herrenschmidt
AuthorDate: Fri Mar 4 17:33:32 2005 -0800
Commit: Linus Torvalds
CommitDate: Fri Mar 4 17:33:32 2005 -0800
[PATCH] ppc64: Implement a vDSO and use it for signal trampoline
This patch adds to the ppc64 kernel a virtual .so (vDSO) that is mapped
into every process space, similar to the x86 vsyscall page. However, the
implementation is very different (and doesn't use the gate area mecanism).
Actually, it contains two implementations, a 32 bits and a 64 bits one.
These vDSO's are currently mapped at 0x10 (+1Mb) when possible (when a
process load section isn't already there). In the future, we can randomize
that address, or even imagine having a special phdr entry letting apps that
wnat finer control over their address space to put it elsewhere (or not at
all).
The implementation adds a hook to binfmt_elf to let the architecture add a
real VMA to the process space instead of using the gate area mecanism.
This mecanism wasn't very suitable for ppc, we couldn't just "shove" PTE
entries mapping kernel addresses into userland without expensive changes to
our hash table management. Instead, I made the vDSO be a normal VMA which,
additionally, means it supports copy-on-write semantics if made writable
via ptrace/mprotect, thus allowing breakpoints in the vDSO code.
The current implementation of the vDSOs contain the signal trampolines with
appropriate DWARF informations, which enable us to use non-executable
stacks (patches to come later) along with a few more functions that we hope
glibc will soon make good use of (this is the "hard" part now :) Note that
the symbols exposed by the vDSO aren't "normal" function symbols, apps
can't be expected to link against them directly, the vDSO's are both seen
as if they were linked at 0 and the symbols just contain offsets to the
various functions. This is done on purpose to avoid a relocation step
(ppc64 functions normally have descriptors with abs addresses in them).
When glibc uses those functions, it's expected to use it's own trampolines
that know how to reach them.
In some cases, the vDSO contains several versions of a given function (for
various CPUs), the kernel will "patch" the symbol table at boot to make it
point to the appropriate one transparently. What is currently implemented
is:
- int __kernel_gettimeofday(struct timeval *tv, struct timezone *tz);
This is a fully userland implementation of gettimeofday, with no barriers
and no locks, and providing 100% equivalent results to the syscall version
- void __kernel_sync_dicache(unsigned long start, unsigned long end)
This function sync's the data and instruction caches (for making data
executable), it is expected that userland loaders use this instead of
doing it themselves, as the kernel will provide optimized versions for the
current CPU. Currently, the vDSO procides a full one for all CPUs prior
to POWER5 and a nop one for POWER5 which implements hardware snooping at
the L1 level. In the future, an intermediate implementation may be done
for the POWER4 and 970 which don't need the "dcbst" loop (the L1D cache is
write-through on those).
- void *__kernel_get_syscall_map(unsigned int *syscall_count);
Returns a pointer to a map of implemented syscalls on the currently
running kernel. The map is agnostic to the size of "long", unlike kernel
bitops, it stores bits from top to bottom so that memory actually contains
a linear bitmap check for syscall N by testing bit (0x8000 >> (N &
0x1f)) of * 32 bits int at N >> 5.
Note about backward compatibility issues: A bug in the ppc64 libgcc
unwinder makes it unable to unwind stacks properly accross signals if the
signal trampoline isn't on the stack. This has been fixed in CVS for gcc
4.0 and will be soon on the stable branch, but the problem exist will all
currently used version
Re: [PATCH 4/8] powerpc: Mark 4xx as Orphan in MAINTAINERS
Acked-by: Alistair Popple On Tuesday, 25 February 2020 10:31:42 AM AEDT Michael Ellerman wrote: > The 4xx platforms are no longer maintained. > > Cc: Alistair Popple > Cc: Matt Porter > Signed-off-by: Michael Ellerman > --- > MAINTAINERS | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5c4f37c41188..939da2ac08db 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9645,11 +9645,8 @@ F: arch/powerpc/platforms/512x/ > F: arch/powerpc/platforms/52xx/ > > LINUX FOR POWERPC EMBEDDED PPC4XX > -M: Alistair Popple > -M: Matt Porter > -W: http://www.penguinppc.org/ > L: linuxppc-dev@lists.ozlabs.org > -S: Maintained > +S: Orphan > F: arch/powerpc/platforms/40x/ > F: arch/powerpc/platforms/44x/
Re: [PATCH 3/8] powerpc: Remove PA SEMI MAINTAINERS entries
On Mon, Feb 24, 2020 at 3:31 PM Michael Ellerman wrote: > > The PA SEMI entries have been orphaned for 3 ½ years, so fold them > into the main POWERPC entry. The result of get_maintainer.pl is more > or less unchanged. > > Cc: Olof Johansson > Signed-off-by: Michael Ellerman Acked-by: Olof Johansson -Olof
Re: [PATCH][next] toshiba: Replace zero-length array with flexible-array member
On 2/24/20 8:32 AM, Gustavo A. R. Silva wrote: > The current codebase makes use of the zero-length array language > extension to the C90 standard, but the preferred mechanism to declare > variable-length types such as these ones is a flexible array member[1][2], > introduced in C99: Seems fine. Acked-by: Geoff Levand
Re: [PATCH 5/8] powerpc: Drop XILINX MAINTAINERS entry
On 24/02/2020 23:31, Michael Ellerman wrote: This has been orphaned for ~7 years, remove it. Cc: Grant Likely Signed-off-by: Michael Ellerman Acked-by: Grant Likely --- MAINTAINERS | 6 -- 1 file changed, 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 939da2ac08db..d5db5cac5a39 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9668,12 +9668,6 @@ L: linuxppc-dev@lists.ozlabs.org S:Maintained F:arch/powerpc/platforms/8xx/ -LINUX FOR POWERPC EMBEDDED XILINX VIRTEX -L: linuxppc-dev@lists.ozlabs.org -S: Orphan -F: arch/powerpc/*/*virtex* -F: arch/powerpc/*/*/*virtex* - LINUX KERNEL DUMP TEST MODULE (LKDTM) M:Kees Cook S:Maintained
Re: [PATCH 1/2] powerpc/powernv: Treat an empty reboot string as default
On 24/02/2020 21:04, Segher Boessenkool wrote: > On Mon, Feb 24, 2020 at 01:32:28PM +1100, Alexey Kardashevskiy wrote: >> On 17/02/2020 13:48, Oliver O'Halloran wrote: >>> Treat an empty reboot cmd string the same as a NULL string. This squashes a >>> spurious unsupported reboot message that sometimes gets out when using >>> xmon. > >>> - if (!cmd) >>> + if (!cmd || !strlen(cmd)) >> >> nit: this does not matter here in practice but >> >> if (!cmd || cmd[0] == '\0') >> >> is faster (you do not care about the length anyway) and safer (@cmd can >> potentially be endless) ;) > > No it isn't, this compiles to identical machine code. (I tested with > GCC 9, and going back until 4.6 -- the generated code becomes > progressively worse (unrelated to this code, fwiw), but identical for > both cases all the time). oh cool, I did not think gcc is that smart. -- Alexey
Re: [PATCH v3 11/27] powerpc: Enable the OpenCAPI Persistent Memory driver for powernv_defconfig
On 21/2/20 2:27 pm, Alastair D'Silva wrote: From: Alastair D'Silva This patch enables the OpenCAPI Persistent Memory driver, as well as DAX support, for the 'powernv' platform. defconfig, not platform DAX is not a strict requirement for the functioning of the driver, but it is likely that a user will want to create a DAX device on top of their persistent memory device. Signed-off-by: Alastair D'Silva Otherwise Reviewed-by: Andrew Donnellan -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
[PATCH] powerpc/64s: Fix section mismatch warnings from boot code
We currently have two section mismatch warnings: The function __boot_from_prom() references the function __init prom_init(). The function start_here_common() references the function __init start_kernel(). The warnings are correct, we do have branches from non-init code into init code, which is freed after boot. But we don't expect to ever execute any of that early boot code after boot, if we did that would be a bug. In particular calling into OF after boot would be fatal because OF is no longer resident. So for now fix the warnings by marking the relevant functions as __REF, which puts them in the ".ref.text" section. This causes some reordering of the functions in the final link: @@ -217,10 +217,9 @@ c000b088 t generic_secondary_common_init c000b124 t __mmu_off c000b14c t __start_initialization_multiplatform -c000b1ac t __boot_from_prom -c000b1ec t __after_prom_start -c000b260 t p_end -c000b27c T copy_and_flush +c000b1ac t __after_prom_start +c000b220 t p_end +c000b23c T copy_and_flush c000b300 T __secondary_start c000b300 t copy_to_here c000b344 t start_secondary_prolog @@ -228,8 +227,9 @@ c000b36c t enable_64b_mode c000b388 T relative_toc c000b3a8 t p_toc -c000b3b0 t start_here_common -c000b3d0 t start_here_multiplatform +c000b3b0 t __boot_from_prom +c000b3f0 t start_here_multiplatform +c000b480 t start_here_common c000b880 T system_call_common c000b974 t system_call c000b9dc t system_call_exit In particular __boot_from_prom moves after copy_to_here, which means it's not copied to zero in the first stage of copy of the kernel to zero. But that's OK, because we only call __boot_from_prom before we do the copy, so it makes no difference when it's copied. The call sequence is: __start -> __start_initialization_multiplatform -> __boot_from_prom -> __start -> __start_initialization_multiplatform -> __after_prom_start -> copy_and_flush -> copy_and_flush (relocated to 0) -> start_here_multiplatform -> early_setup Reported-by: Mauricio Faria de Oliveira Reported-by: Roman Bolshakov Signed-off-by: Michael Ellerman --- arch/powerpc/kernel/head_64.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index ad79fddb974d..ddfbd02140d9 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -537,6 +537,7 @@ _GLOBAL(generic_secondary_smp_init) b __after_prom_start #endif /* CONFIG_PPC_BOOK3E */ +__REF __boot_from_prom: #ifdef CONFIG_PPC_OF_BOOT_TRAMPOLINE /* Save parameters */ @@ -574,6 +575,7 @@ _GLOBAL(generic_secondary_smp_init) /* We never return. We also hit that trap if trying to boot * from OF while CONFIG_PPC_OF_BOOT_TRAMPOLINE isn't selected */ trap + .previous __after_prom_start: #ifdef CONFIG_RELOCATABLE @@ -977,7 +979,6 @@ __REF RFI b . /* prevent speculative execution */ - .previous /* This is where all platforms converge execution */ start_here_common: @@ -1001,6 +1002,7 @@ __REF /* Not reached */ trap EMIT_BUG_ENTRY 0b, __FILE__, __LINE__, 0 + .previous /* * We put a few things here that have to be page-aligned. -- 2.21.1
Re: [linux-next/mainline][bisected 3acac06][ppc] Oops when unloading mpt3sas driver
On Fri, 2020-01-17 at 18:21 +0530, Abdul Haleem wrote: > On Thu, 2020-01-16 at 09:44 -0800, Christoph Hellwig wrote: > > Hi Abdul, > > > > I think the problem is that mpt3sas has some convoluted logic to do > > some DMA allocations with a 32-bit coherent mask, and then switches > > to a 63 or 64 bit mask, which is not supported by the DMA API. > > > > Can you try the patch below? > > Thank you Christoph, with the given patch applied the bug is not seen. > > rmmod of mpt3sas driver is successful, no kernel Oops > > Reported-and-tested-by: Abdul Haleem Hi Christoph, I see the patch is under discussion, will this be merged upstream any time soon ? as boot is broken on our machines with out your patch. -- Regard's Abdul Haleem IBM Linux Technology Centre
Re: [PATCH 1/2] cpufreq/powernv: Fix use-after-free
On Thu, Feb 06, 2020 at 05:26:21PM +1100, Oliver O'Halloran wrote:
> The cpufreq driver has a use-after-free that we can hit if:
>
> a) There's an OCC message pending when the notifier is registered, and
> b) The cpufreq driver fails to register with the core.
>
> When a) occurs the notifier schedules a workqueue item to handle the
> message. The backing work_struct is located on chips[].throttle and when b)
> happens we clean up by freeing the array. Once we get to the (now free)
> queued item and the kernel crashes.
>
> Cc: Vaidyanathan Srinivasan
> Fixes: c5e29ea ("cpufreq: powernv: Fix bugs in powernv_cpufreq_{init/exit}")
> Signed-off-by: Oliver O'Halloran
Thanks for this fix Oliver.
Reviewed-by: Gautham R. Shenoy
> ---
> drivers/cpufreq/powernv-cpufreq.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c
> b/drivers/cpufreq/powernv-cpufreq.c
> index 56f4bc0..1806b1d 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -1080,6 +1080,12 @@ static int init_chip_info(void)
>
> static inline void clean_chip_info(void)
> {
> + int i;
> +
> + /* flush any pending work items */
> + if (chips)
> + for (i = 0; i < nr_chips; i++)
> + cancel_work_sync(&chips[i].throttle);
> kfree(chips);
> }
>
> --
> 2.9.5
>
Re: [PATCH 2/2] cpufreq/powernv: Fix unsafe notifiers
On Thu, Feb 06, 2020 at 05:26:22PM +1100, Oliver O'Halloran wrote:
> The PowerNV cpufreq driver registers two notifiers: one to catch throttle
> messages from the OCC and one to bump the CPU frequency back to normal
> before a reboot. Both require the cpufreq driver to be registered in order
> to function since the notifier callbacks use various cpufreq_*() functions.
>
> Right now we register both notifiers before we've initialised the driver.
> This seems to work, but we should head off any protential problems by
> registering the notifiers after the driver is initialised.
>
> Cc: Vaidyanathan Srinivasan
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Gautham R. Shenoy
> ---
> drivers/cpufreq/powernv-cpufreq.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c
> b/drivers/cpufreq/powernv-cpufreq.c
> index 1806b1d..03798c4 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -1114,9 +1114,6 @@ static int __init powernv_cpufreq_init(void)
> if (rc)
> goto out;
>
> - register_reboot_notifier(&powernv_cpufreq_reboot_nb);
> - opal_message_notifier_register(OPAL_MSG_OCC, &powernv_cpufreq_opal_nb);
> -
> if (powernv_pstate_info.wof_enabled)
> powernv_cpufreq_driver.boost_enabled = true;
> else
> @@ -1125,15 +1122,17 @@ static int __init powernv_cpufreq_init(void)
> rc = cpufreq_register_driver(&powernv_cpufreq_driver);
> if (rc) {
> pr_info("Failed to register the cpufreq driver (%d)\n", rc);
> - goto cleanup_notifiers;
> + goto cleanup;
> }
>
> if (powernv_pstate_info.wof_enabled)
> cpufreq_enable_boost_support();
>
> + register_reboot_notifier(&powernv_cpufreq_reboot_nb);
> + opal_message_notifier_register(OPAL_MSG_OCC, &powernv_cpufreq_opal_nb);
> +
> return 0;
> -cleanup_notifiers:
> - unregister_all_notifiers();
> +cleanup:
> clean_chip_info();
> out:
> pr_info("Platform driver disabled. System does not support PState
> control\n");
> --
> 2.9.5
>
Re: [PATCH 1/2] cpufreq/powernv: Fix use-after-free
On 6/2/20 5:26 pm, Oliver O'Halloran wrote:
The cpufreq driver has a use-after-free that we can hit if:
a) There's an OCC message pending when the notifier is registered, and
b) The cpufreq driver fails to register with the core.
When a) occurs the notifier schedules a workqueue item to handle the
message. The backing work_struct is located on chips[].throttle and when b)
happens we clean up by freeing the array. Once we get to the (now free)
queued item and the kernel crashes.
Cc: Vaidyanathan Srinivasan
Fixes: c5e29ea ("cpufreq: powernv: Fix bugs in powernv_cpufreq_{init/exit}")
Signed-off-by: Oliver O'Halloran
This sounds like it needs to go to stable.
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
