* Re: [PATCH] powerpc/papr_scm: Add PAPR command family to pass-through command-set
From: Ira Weiny @ 2020-09-28 15:45 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Santosh Sivaraj, linux-nvdimm, Aneesh Kumar K . V,
Verma, Vishal L, Oliver O'Halloran, Dan Williams,
linuxppc-dev
In-Reply-To: <87pn662gc3.fsf@vajain21.in.ibm.com>
On Mon, Sep 28, 2020 at 06:44:52PM +0530, Vaibhav Jain wrote:
> Hi Dan, Ira and Vishal,
>
> Can you please take a look at this patch. Without it the functionality
> to report nvdimm health via ndctl breaks on 5.9
Sorry...
>
> Thanks,
> ~ Vaibhav
>
> Vaibhav Jain <vaibhav@linux.ibm.com> writes:
>
> > Add NVDIMM_FAMILY_PAPR to the list of valid 'dimm_family_mask'
> > acceptable by papr_scm. This is needed as since commit
> > 92fe2aa859f5 ("libnvdimm: Validate command family indices") libnvdimm
> > performs a validation of 'nd_cmd_pkg.nd_family' received as part of
> > ND_CMD_CALL processing to ensure only known command families can use
> > the general ND_CMD_CALL pass-through functionality.
> >
> > Without this change the ND_CMD_CALL pass-through targeting
> > NVDIMM_FAMILY_PAPR error out with -EINVAL.
> >
> > Fixes: 92fe2aa859f5 ("libnvdimm: Validate command family indices")
> > Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
LGTM
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> > ---
> > arch/powerpc/platforms/pseries/papr_scm.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> > index 5493bc847bd08..27268370dee00 100644
> > --- a/arch/powerpc/platforms/pseries/papr_scm.c
> > +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> > @@ -898,6 +898,9 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> > p->bus_desc.of_node = p->pdev->dev.of_node;
> > p->bus_desc.provider_name = kstrdup(p->pdev->name, GFP_KERNEL);
> >
> > + /* Set the dimm command family mask to accept PDSMs */
> > + set_bit(NVDIMM_FAMILY_PAPR, &p->bus_desc.dimm_family_mask);
> > +
> > if (!p->bus_desc.provider_name)
> > return -ENOMEM;
> >
> > --
> > 2.26.2
> >
^ permalink raw reply
* Re: [PATCH v8 2/8] powerpc/vdso: Remove __kernel_datapage_offset and simplify __get_datapage()
From: Dmitry Safonov @ 2020-09-28 15:08 UTC (permalink / raw)
To: Christophe Leroy, Will Deacon, Michael Ellerman
Cc: nathanl, linux-arch, Arnd Bergmann, open list, Paul Mackerras,
Andy Lutomirski, Thomas Gleixner, Vincenzo Frascino, linuxppc-dev
In-Reply-To: <ad72ffd3-a552-cc98-7545-d30285fd5219@csgroup.eu>
On 9/27/20 8:43 AM, Christophe Leroy wrote:
>
>
> Le 21/09/2020 à 13:26, Will Deacon a écrit :
>> On Fri, Aug 28, 2020 at 12:14:28PM +1000, Michael Ellerman wrote:
>>> Dmitry Safonov <0x7f454c46@gmail.com> writes:
[..]
>>>> I'll cook a patch for vm_special_mapping if you don't mind :-)
>>>
>>> That would be great, thanks!
>>
>> I lost track of this one. Is there a patch kicking around to resolve
>> this,
>> or is the segfault expected behaviour?
>>
>
> IIUC dmitry said he will cook a patch. I have not seen any patch yet.
Yes, sorry about the delay - I was a bit busy with xfrm patches.
I'll send patches for .close() this week, working on them now.
> AFAIKS, among the architectures having VDSO sigreturn trampolines, only
> SH, X86 and POWERPC provide alternative trampoline on stack when VDSO is
> not there.
>
> All other architectures just having a VDSO don't expect VDSO to not be
> mapped.
>
> As far as nowadays stacks are mapped non-executable, getting a segfaut
> is expected behaviour. However, I think we should really make it
> cleaner. Today it segfaults because it is still pointing to the VDSO
> trampoline that has been unmapped. But should the user map some other
> code at the same address, we'll run in the weed on signal return instead
> of segfaulting.
+1.
> So VDSO unmapping should really be properly managed, the reference
> should be properly cleared in order to segfault in a controllable manner.
>
> Only powerpc has a hook to properly clear the VDSO pointer when VDSO is
> unmapped.
Thanks,
Dmitry
^ permalink raw reply
* Re: [PATCH] tpm: of: avoid __va() translation for event log address
From: Jarkko Sakkinen @ 2020-09-28 14:09 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Linux Kernel Mailing List, Jason Gunthorpe, Paul Mackerras,
linux-integrity, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
Peter Huewe
In-Reply-To: <CAMj1kXGxNgixUEocma-9F3fYgdJJJADh=bvyrCziXkuArErWdA@mail.gmail.com>
On Mon, Sep 28, 2020 at 08:20:18AM +0200, Ard Biesheuvel wrote:
> On Mon, 28 Sep 2020 at 07:56, Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
> >
> >
> >
> > Le 28/09/2020 à 01:44, Jarkko Sakkinen a écrit :
> > > On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote:
> > >> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
> > >>> On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> > >>>> On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> > >>>> <jarkko.sakkinen@linux.intel.com> wrote:
> > >>>>>
> > >>>>> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> > >>>>>> The TPM event log is provided to the OS by the firmware, by loading
> > >>>>>> it into an area in memory and passing the physical address via a node
> > >>>>>> in the device tree.
> > >>>>>>
> > >>>>>> Currently, we use __va() to access the memory via the kernel's linear
> > >>>>>> map: however, it is not guaranteed that the linear map covers this
> > >>>>>> particular address, as we may be running under HIGHMEM on a 32-bit
> > >>>>>> architecture, or running firmware that uses a memory type for the
> > >>>>>> event log that is omitted from the linear map (such as EfiReserved).
> > >>>>>
> > >>>>> Makes perfect sense to the level that I wonder if this should have a
> > >>>>> fixes tag and/or needs to be backported to the stable kernels?
> > >>>>>
> > >>>>
> > >>>> AIUI, the code was written specifically for ppc64, which is a
> > >>>> non-highmem, non-EFI architecture. However, when we start reusing this
> > >>>> driver for ARM, this issue could pop up.
> > >>>>
> > >>>> The code itself has been refactored a couple of times, so I think it
> > >>>> will require different versions of the patch for different generations
> > >>>> of stable kernels.
> > >>>>
> > >>>> So perhaps just add Cc: <stable@vger.kernel.org>, and wait and see how
> > >>>> far back it applies cleanly?
> > >>>
> > >>> Yeah, I think I'll cc it with some note before the diffstat.
> > >>>
> > >>> I'm thinking to cap it to only 5.x kernels (at least first) unless it is
> > >>> dead easy to backport below that.
> > >>
> > >> I have this vauge recollection of pointing at this before and being
> > >> told that it had to be __va for some PPC reason?
> > >>
> > >> Do check with the PPC people first, I see none on the CC list.
> > >>
> > >> Jason
> > >
> > > Thanks, added arch/powerpc maintainers.
> > >
> >
> > As far as I can see, memremap() won't work on PPC32 at least:
> >
> > IIUC, memremap() calls arch_memremap_wb()
> > arch_memremap_wb() calls ioremap_cache()
> > In case of failure, then ioremap_wt() and ioremap_wc() are tried.
> >
> > All ioremap calls end up in __ioremap_caller() which will return NULL in case you try to ioremap RAM.
> >
> > So the statement "So instead, use memremap(), which will reuse the linear mapping if
> > it is valid, or create another mapping otherwise." seems to be wrong, at least for PPC32.
> >
> > Even for PPC64 which doesn't seem to have the RAM check, I can't see that it will "reuse the linear
> > mapping".
> >
>
> It is there, please look again. Before any of the above happens,
> memremap() will call try_ram_remap() for regions that are covered by a
> IORESOURCE_SYSTEM_RAM, and map it using __va() if its PFN is valid and
> it is not highmem.
>
> So as far as I can tell, this change has no effect on PPC at all
> unless its RAM is not described as IORESOURCE_SYSTEM_RAM.
Any chance for someone to test this on PPC32?
/Jarkko
^ permalink raw reply
* Re: [PATCH 1/5] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr1-alt-addr' property
From: Rob Herring @ 2020-09-28 13:56 UTC (permalink / raw)
To: Ran Wang
Cc: devicetree@vger.kernel.org, Biwen Li, Shawn Guo,
linux-kernel@vger.kernel.org, Leo Li,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM6PR04MB5413BB2F8D044B2312DAEC4FF1380@AM6PR04MB5413.eurprd04.prod.outlook.com>
On Wed, Sep 23, 2020 at 1:44 AM Ran Wang <ran.wang_1@nxp.com> wrote:
>
> Hi Rob,
>
> On Wednesday, September 23, 2020 10:33 AM, Rob Herring wrote:
> >
> > On Wed, Sep 16, 2020 at 04:18:27PM +0800, Ran Wang wrote:
> > > From: Biwen Li <biwen.li@nxp.com>
> > >
> > > The 'fsl,ippdexpcr1-alt-addr' property is used to handle an errata
> > > A-008646 on LS1021A
> > >
> > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > ---
> > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 19
> > > +++++++++++++++++++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > index 5a33619..1be58a3 100644
> > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > @@ -34,6 +34,11 @@ Chassis Version Example Chips
> > > Optional properties:
> > > - little-endian : RCPM register block is Little Endian. Without it RCPM
> > > will be Big Endian (default case).
> > > + - fsl,ippdexpcr1-alt-addr : The property is related to a hardware issue
> > > + on SoC LS1021A and only needed on SoC LS1021A.
> > > + Must include 2 entries:
> > > + The first entry must be a link to the SCFG device node.
> > > + The 2nd entry must be offset of register IPPDEXPCR1 in SCFG.
> >
> > You don't need a DT change for this. You can find SCFG node by its compatible
> > string and then the offset should be known given this issue is only on 1 SoC.
>
> Did you mean that RCPM driver just to access IPPDEXPCR1 shadowed register in SCFG
> directly without fetching it's offset info. from DT?
Yes. There's only 1 possible value of the offset because there's only
one SoC, so the driver can hardcode the offset. And I assume there's
only one SCFG node, so you can find it by its compatible string
(of_find_compatible_node).
Rob
^ permalink raw reply
* Re: [PATCH] powerpc/papr_scm: Add PAPR command family to pass-through command-set
From: Vaibhav Jain @ 2020-09-28 13:14 UTC (permalink / raw)
To: linuxppc-dev, linux-nvdimm
Cc: Santosh Sivaraj, Aneesh Kumar K . V, Verma, Vishal L,
Oliver O'Halloran, Dan Williams, Ira Weiny
In-Reply-To: <20200913211904.24472-1-vaibhav@linux.ibm.com>
Hi Dan, Ira and Vishal,
Can you please take a look at this patch. Without it the functionality
to report nvdimm health via ndctl breaks on 5.9
Thanks,
~ Vaibhav
Vaibhav Jain <vaibhav@linux.ibm.com> writes:
> Add NVDIMM_FAMILY_PAPR to the list of valid 'dimm_family_mask'
> acceptable by papr_scm. This is needed as since commit
> 92fe2aa859f5 ("libnvdimm: Validate command family indices") libnvdimm
> performs a validation of 'nd_cmd_pkg.nd_family' received as part of
> ND_CMD_CALL processing to ensure only known command families can use
> the general ND_CMD_CALL pass-through functionality.
>
> Without this change the ND_CMD_CALL pass-through targeting
> NVDIMM_FAMILY_PAPR error out with -EINVAL.
>
> Fixes: 92fe2aa859f5 ("libnvdimm: Validate command family indices")
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> arch/powerpc/platforms/pseries/papr_scm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index 5493bc847bd08..27268370dee00 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -898,6 +898,9 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> p->bus_desc.of_node = p->pdev->dev.of_node;
> p->bus_desc.provider_name = kstrdup(p->pdev->name, GFP_KERNEL);
>
> + /* Set the dimm command family mask to accept PDSMs */
> + set_bit(NVDIMM_FAMILY_PAPR, &p->bus_desc.dimm_family_mask);
> +
> if (!p->bus_desc.provider_name)
> return -ENOMEM;
>
> --
> 2.26.2
>
^ permalink raw reply
* [PATCH] powerpc: net: bpf_jit_comp: Fix misuse of fallthrough
From: zhe.he @ 2020-09-28 9:00 UTC (permalink / raw)
To: gustavo, netdev, bpf, linuxppc-dev, linux-kernel, zhe.he
From: He Zhe <zhe.he@windriver.com>
The user defined label following "fallthrough" is not considered by GCC
and causes build failure.
kernel-source/include/linux/compiler_attributes.h:208:41: error: attribute
'fallthrough' not preceding a case label or default label [-Werror]
208 define fallthrough _attribute((fallthrough_))
^~~~~~~~~~~~~
Signed-off-by: He Zhe <zhe.he@windriver.com>
---
arch/powerpc/net/bpf_jit_comp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 78d61f97371e..e809cb5a1631 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -475,7 +475,6 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
case BPF_JMP | BPF_JSET | BPF_K:
case BPF_JMP | BPF_JSET | BPF_X:
true_cond = COND_NE;
- fallthrough;
cond_branch:
/* same targets, can avoid doing the test :) */
if (filter[i].jt == filter[i].jf) {
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] tpm: of: avoid __va() translation for event log address
From: Ard Biesheuvel @ 2020-09-28 6:20 UTC (permalink / raw)
To: Christophe Leroy
Cc: Linux Kernel Mailing List, Jarkko Sakkinen, Jason Gunthorpe,
Paul Mackerras, linux-integrity,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Peter Huewe
In-Reply-To: <9be9c7e7-c424-d241-2255-ad854221bd2e@csgroup.eu>
On Mon, 28 Sep 2020 at 07:56, Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 28/09/2020 à 01:44, Jarkko Sakkinen a écrit :
> > On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote:
> >> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
> >>> On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> >>>> On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> >>>> <jarkko.sakkinen@linux.intel.com> wrote:
> >>>>>
> >>>>> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> >>>>>> The TPM event log is provided to the OS by the firmware, by loading
> >>>>>> it into an area in memory and passing the physical address via a node
> >>>>>> in the device tree.
> >>>>>>
> >>>>>> Currently, we use __va() to access the memory via the kernel's linear
> >>>>>> map: however, it is not guaranteed that the linear map covers this
> >>>>>> particular address, as we may be running under HIGHMEM on a 32-bit
> >>>>>> architecture, or running firmware that uses a memory type for the
> >>>>>> event log that is omitted from the linear map (such as EfiReserved).
> >>>>>
> >>>>> Makes perfect sense to the level that I wonder if this should have a
> >>>>> fixes tag and/or needs to be backported to the stable kernels?
> >>>>>
> >>>>
> >>>> AIUI, the code was written specifically for ppc64, which is a
> >>>> non-highmem, non-EFI architecture. However, when we start reusing this
> >>>> driver for ARM, this issue could pop up.
> >>>>
> >>>> The code itself has been refactored a couple of times, so I think it
> >>>> will require different versions of the patch for different generations
> >>>> of stable kernels.
> >>>>
> >>>> So perhaps just add Cc: <stable@vger.kernel.org>, and wait and see how
> >>>> far back it applies cleanly?
> >>>
> >>> Yeah, I think I'll cc it with some note before the diffstat.
> >>>
> >>> I'm thinking to cap it to only 5.x kernels (at least first) unless it is
> >>> dead easy to backport below that.
> >>
> >> I have this vauge recollection of pointing at this before and being
> >> told that it had to be __va for some PPC reason?
> >>
> >> Do check with the PPC people first, I see none on the CC list.
> >>
> >> Jason
> >
> > Thanks, added arch/powerpc maintainers.
> >
>
> As far as I can see, memremap() won't work on PPC32 at least:
>
> IIUC, memremap() calls arch_memremap_wb()
> arch_memremap_wb() calls ioremap_cache()
> In case of failure, then ioremap_wt() and ioremap_wc() are tried.
>
> All ioremap calls end up in __ioremap_caller() which will return NULL in case you try to ioremap RAM.
>
> So the statement "So instead, use memremap(), which will reuse the linear mapping if
> it is valid, or create another mapping otherwise." seems to be wrong, at least for PPC32.
>
> Even for PPC64 which doesn't seem to have the RAM check, I can't see that it will "reuse the linear
> mapping".
>
It is there, please look again. Before any of the above happens,
memremap() will call try_ram_remap() for regions that are covered by a
IORESOURCE_SYSTEM_RAM, and map it using __va() if its PFN is valid and
it is not highmem.
So as far as I can tell, this change has no effect on PPC at all
unless its RAM is not described as IORESOURCE_SYSTEM_RAM.
^ permalink raw reply
* Re: [PATCH] tpm: of: avoid __va() translation for event log address
From: Christophe Leroy @ 2020-09-28 5:56 UTC (permalink / raw)
To: Jarkko Sakkinen, Jason Gunthorpe, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: linux-integrity, linuxppc-dev, Ard Biesheuvel, Peter Huewe,
Linux Kernel Mailing List
In-Reply-To: <20200927234434.GA5283@linux.intel.com>
Le 28/09/2020 à 01:44, Jarkko Sakkinen a écrit :
> On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote:
>> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
>>> On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
>>>> On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
>>>> <jarkko.sakkinen@linux.intel.com> wrote:
>>>>>
>>>>> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
>>>>>> The TPM event log is provided to the OS by the firmware, by loading
>>>>>> it into an area in memory and passing the physical address via a node
>>>>>> in the device tree.
>>>>>>
>>>>>> Currently, we use __va() to access the memory via the kernel's linear
>>>>>> map: however, it is not guaranteed that the linear map covers this
>>>>>> particular address, as we may be running under HIGHMEM on a 32-bit
>>>>>> architecture, or running firmware that uses a memory type for the
>>>>>> event log that is omitted from the linear map (such as EfiReserved).
>>>>>
>>>>> Makes perfect sense to the level that I wonder if this should have a
>>>>> fixes tag and/or needs to be backported to the stable kernels?
>>>>>
>>>>
>>>> AIUI, the code was written specifically for ppc64, which is a
>>>> non-highmem, non-EFI architecture. However, when we start reusing this
>>>> driver for ARM, this issue could pop up.
>>>>
>>>> The code itself has been refactored a couple of times, so I think it
>>>> will require different versions of the patch for different generations
>>>> of stable kernels.
>>>>
>>>> So perhaps just add Cc: <stable@vger.kernel.org>, and wait and see how
>>>> far back it applies cleanly?
>>>
>>> Yeah, I think I'll cc it with some note before the diffstat.
>>>
>>> I'm thinking to cap it to only 5.x kernels (at least first) unless it is
>>> dead easy to backport below that.
>>
>> I have this vauge recollection of pointing at this before and being
>> told that it had to be __va for some PPC reason?
>>
>> Do check with the PPC people first, I see none on the CC list.
>>
>> Jason
>
> Thanks, added arch/powerpc maintainers.
>
As far as I can see, memremap() won't work on PPC32 at least:
IIUC, memremap() calls arch_memremap_wb()
arch_memremap_wb() calls ioremap_cache()
In case of failure, then ioremap_wt() and ioremap_wc() are tried.
All ioremap calls end up in __ioremap_caller() which will return NULL in case you try to ioremap RAM.
So the statement "So instead, use memremap(), which will reuse the linear mapping if
it is valid, or create another mapping otherwise." seems to be wrong, at least for PPC32.
Even for PPC64 which doesn't seem to have the RAM check, I can't see that it will "reuse the linear
mapping".
Christophe
^ permalink raw reply
* Re: [PATCH -next] ocxl: simplify the return expression of free_function_dev()
From: Andrew Donnellan @ 2020-09-28 1:24 UTC (permalink / raw)
To: Qinglang Miao, Frederic Barrat, Arnd Bergmann, Greg Kroah-Hartman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20200921131047.92526-1-miaoqinglang@huawei.com>
On 21/9/20 11:10 pm, Qinglang Miao wrote:
> Simplify the return expression.
>
> Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Looks good
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH] tpm: of: avoid __va() translation for event log address
From: Jarkko Sakkinen @ 2020-09-27 23:44 UTC (permalink / raw)
To: Jason Gunthorpe, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linux-integrity, linuxppc-dev, Ard Biesheuvel, Peter Huewe,
Linux Kernel Mailing List
In-Reply-To: <20200925120018.GH9916@ziepe.ca>
On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote:
> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> > > On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> > > <jarkko.sakkinen@linux.intel.com> wrote:
> > > >
> > > > On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> > > > > The TPM event log is provided to the OS by the firmware, by loading
> > > > > it into an area in memory and passing the physical address via a node
> > > > > in the device tree.
> > > > >
> > > > > Currently, we use __va() to access the memory via the kernel's linear
> > > > > map: however, it is not guaranteed that the linear map covers this
> > > > > particular address, as we may be running under HIGHMEM on a 32-bit
> > > > > architecture, or running firmware that uses a memory type for the
> > > > > event log that is omitted from the linear map (such as EfiReserved).
> > > >
> > > > Makes perfect sense to the level that I wonder if this should have a
> > > > fixes tag and/or needs to be backported to the stable kernels?
> > > >
> > >
> > > AIUI, the code was written specifically for ppc64, which is a
> > > non-highmem, non-EFI architecture. However, when we start reusing this
> > > driver for ARM, this issue could pop up.
> > >
> > > The code itself has been refactored a couple of times, so I think it
> > > will require different versions of the patch for different generations
> > > of stable kernels.
> > >
> > > So perhaps just add Cc: <stable@vger.kernel.org>, and wait and see how
> > > far back it applies cleanly?
> >
> > Yeah, I think I'll cc it with some note before the diffstat.
> >
> > I'm thinking to cap it to only 5.x kernels (at least first) unless it is
> > dead easy to backport below that.
>
> I have this vauge recollection of pointing at this before and being
> told that it had to be __va for some PPC reason?
>
> Do check with the PPC people first, I see none on the CC list.
>
> Jason
Thanks, added arch/powerpc maintainers.
/Jarkko
^ permalink raw reply
* Re: [PATCH] rpadlpar_io:Add MODULE_DESCRIPTION entries to kernel modules
From: Oliver O'Halloran @ 2020-09-27 23:32 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tyrel Datwyler, linux-pci, Linux Kernel Mailing List,
Mamatha Inamdar, Bjorn Helgaas, linuxppc-dev
In-Reply-To: <20200925194335.GA2453596@bjorn-Precision-5520>
On Sat, Sep 26, 2020 at 5:43 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Thu, Sep 24, 2020 at 04:41:39PM +1000, Oliver O'Halloran wrote:
> > On Thu, Sep 24, 2020 at 3:15 PM Mamatha Inamdar
> > <mamatha4@linux.vnet.ibm.com> wrote:
> > >
> > > This patch adds a brief MODULE_DESCRIPTION to rpadlpar_io kernel modules
> > > (descriptions taken from Kconfig file)
> > >
> > > Signed-off-by: Mamatha Inamdar <mamatha4@linux.vnet.ibm.com>
> > > ---
> > > drivers/pci/hotplug/rpadlpar_core.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
> > > index f979b70..bac65ed 100644
> > > --- a/drivers/pci/hotplug/rpadlpar_core.c
> > > +++ b/drivers/pci/hotplug/rpadlpar_core.c
> > > @@ -478,3 +478,4 @@ static void __exit rpadlpar_io_exit(void)
> > > module_init(rpadlpar_io_init);
> > > module_exit(rpadlpar_io_exit);
> > > MODULE_LICENSE("GPL");
> > > +MODULE_DESCRIPTION("RPA Dynamic Logical Partitioning driver for I/O slots");
> >
> > RPA as a spec was superseded by PAPR in the early 2000s. Can we rename
> > this already?
> >
> > The only potential problem I can see is scripts doing: modprobe
> > rpadlpar_io or similar
> >
> > However, we should be able to fix that with a module alias.
>
> Is MODULE_DESCRIPTION() connected with how modprobe works?
I don't think so. The description is just there as an FYI.
> If this patch just improves documentation, without breaking users of
> modprobe, I'm fine with it, even if it would be nice to rename to PAPR
> or something in the future.
Right, the change in this patch is just a documentation fix and
shouldn't cause any problems.
I was suggesting renaming the module itself since the term "RPA" is
only used in this hotplug driver and some of the corresponding PHB add
/ remove handling in arch/powerpc/platforms/pseries/. We can make that
change in a follow up though.
> But, please use "git log --oneline drivers/pci/hotplug/rpadlpar*" and
> match the style, and also look through the rest of drivers/pci/ to see
> if we should do the same thing to any other modules.
>
> Bjorn
^ permalink raw reply
* Re: [PATCH v3 2/5] powerpc: apm82181: create shared dtsi for APM bluestone
From: Christian Lamparter @ 2020-09-27 17:42 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Arnd Bergmann, Chris Blake, Paul Mackerras,
Andy Shevchenko, linuxppc-dev
In-Reply-To: <CAL_Jsq+x0jFh-2jVt9pVek6a2=UCv0z0sBJpuh5irxeQG+tbUg@mail.gmail.com>
On Tue, Sep 22, 2020 at 9:14 PM Rob Herring <robh@kernel.org> wrote:
>
> On Sat, Sep 19, 2020 at 2:23 PM Christian Lamparter <chunkeey@gmail.com> wrote:
> >
> > On 2020-09-15 03:05, Rob Herring wrote:
> > > On Sun, Sep 06, 2020 at 12:06:12AM +0200, Christian Lamparter wrote:
> > >> This patch adds an DTSI-File that can be used by various device-tree
> > >> files for APM82181-based devices.
> > >>
> > >> Some of the nodes (like UART, PCIE, SATA) are used by the uboot and
> > >> need to stick with the naming-conventions of the old times'.
> > >> I've added comments whenever this was the case.
> > >>
> > >> Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
> > >> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> > >> ---
> > >> rfc v1 -> v2:
> > >> - removed PKA (this CryptoPU will need driver)
> > >> - stick with compatibles, nodes, ... from either
> > >> Bluestone (APM82181) or Canyonlands (PPC460EX).
> > >> - add labels for NAND and NOR to help with access.
> > >> v2 -> v3:
> > >> - nodename of pciex@d.... was changed to pcie@d..
> > >> due to upstream patch.
> > >> - use simple-bus on the ebc, opb and plb nodes
> > >> ---
> > >> arch/powerpc/boot/dts/apm82181.dtsi | 466 ++++++++++++++++++++++++++++
> > >> 1 file changed, 466 insertions(+)
> > >> create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi
> > >>
> > >> diff --git a/arch/powerpc/boot/dts/apm82181.dtsi b/arch/powerpc/boot/dts/apm82181.dtsi
> > >> new file mode 100644
> > >> index 000000000000..60283430978d
> > >> --- /dev/null
> > >> +++ b/arch/powerpc/boot/dts/apm82181.dtsi
> > >> @@ -0,0 +1,466 @@
> > >> +// SPDX-License-Identifier: GPL-2.0-or-later
> > >> +/*
> > >> + * Device Tree template include for various APM82181 boards.
> > >> + *
> > >> + * The SoC is an evolution of the PPC460EX predecessor.
> > >> + * This is why dt-nodes from the canyonlands EBC, OPB, USB,
> > >> + * DMA, SATA, EMAC, ... ended up in here.
> > >> + *
> > >> + * Copyright (c) 2010, Applied Micro Circuits Corporation
> > >> + * Author: Tirumala R Marri <tmarri@apm.com>,
> > >> + * Christian Lamparter <chunkeey@gmail.com>,
> > >> + * Chris Blake <chrisrblake93@gmail.com>
> > >> + */
> > >> +
> > >> +#include <dt-bindings/dma/dw-dmac.h>
> > >> +#include <dt-bindings/input/input.h>
> > >> +#include <dt-bindings/interrupt-controller/irq.h>
> > >> +#include <dt-bindings/gpio/gpio.h>
> > >> +
> > >> +/ {
> > >> + #address-cells = <2>;
> > >> + #size-cells = <1>;
> > >> + dcr-parent = <&{/cpus/cpu@0}>;
> > >> +
> > >> + aliases {
> > >> + ethernet0 = &EMAC0; /* needed for BSP u-boot */
> > >> + };
> > >> +
> > >> + cpus {
> > >> + #address-cells = <1>;
> > >> + #size-cells = <0>;
> > >> +
> > >> + CPU0: cpu@0 {
> > >> + device_type = "cpu";
> > >> + model = "PowerPC,apm82181";
> > >
> > > This doesn't match the existing bluestone dts file.
> > >
> > > Please separate any restructuring from changes.
> >
> >
> > "I see" (I'm including your comment of the dt-binding as well).
> >
> > I'm getting the vibe that I better should not touch that bluestone.dts.
>
> I don't know about that.
k, understood.
>
> > An honestly, looking at the series and patches that the APM-engineers
> > posted back in the day, I can see why this well is so poisoned... and
> > stuff like SATA/AHBDMA/USB/GPIO/CPM/... was missing.
> >
> > As for the devices. In the spirit of Arnd Bergmann's post of
> > <https://lkml.org/lkml/2020/3/30/195>
> >
> > |It would be nice to move over the the bluestone .dts to the apm82181.dtsi file
> > |when that gets added, if only to ensure they use the same description for each
> > |node, but that shouldn't stop the addition of the new file if that is needed for
> > |distros to make use of a popular device.
> > |I see a couple of additional files in openwrt.
> >
> > I mean I don't have the bluestone dev board, just the consumer devices.
>
> This stuff is old enough, I'd guess no one cares about a dev board.
> But we should figure that out and document that with any changes.
>
> > Would it be possible to support those? I can start from a "skeleton" apm82181.dtsi
> > This would just include CPU, Memory (SD-RAM+L2C+OCM), UIC (Interrupt-Controller),
> > the PLB+OBP+EBC Busses and UART. Just enough to make a board "boot from ram".
>
> This skeleton would be chunks moved over or duplicated? I don't think
> we want 2 of the same thing.
My Idea was copying the working apm82181.dtsi we have in OpenWrt
and stripping the nodes we added for SATA, USB, GPIO and the likes.
so the remaining nodes would be very close to what bluestone.dts had.
The main differences would be:
- It's a bit smaller since I made a separate patch for the NOR/NAND on the EBC.
Reason being that the SoC uses glue-logic for mapping NOR/NAND (and other
external peripherals like the GPIOs on the WD) into the memory and I thought
this needed some explanation as to why this weird thing works.
- it would already use the dt-bindings/interrupt-controller/irq.h macros
for LEVEL/EDGE cell values
- it contains valuable comments about the uboot. Because ethernet0 alias
and the /plb/obc/ebc node-name requirements).
- UART are using 16750 compatible (as per hardware docs)
>
> The order I would go is split into an apm82181.dtsi with 0 changes to
> the built dtb(s). Then make changes/additions you need. As far as
> changes to existing bindings, it's only an ABI if someone notices.
This will rewriting the history, as the development of apm82181.dtsi
did happen differently (basically, each device started with its own full dts.
But early on in 2016 we merged the common nodes and switched over
to the macros). This is fine though, I'll need some time to rebase and rewrite
the patches.
(Note: I've already wrote a patch for a the apm82181 dwc USB binding for
this: <https://www.spinics.net/lists/devicetree/msg378884.html>. Not sure
about uic, sata and dw-dma as these drivers each use a common binding.
I hope there's some leeway for this old stuff.)
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH v2] i2c: cpm: Fix i2c_ram structure
From: Wolfram Sang @ 2020-09-27 13:15 UTC (permalink / raw)
To: nicolas.vincent; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <20200923140840.8700-1-nicolas.vincent@vossloh.com>
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
On Wed, Sep 23, 2020 at 04:08:40PM +0200, nico.vince@gmail.com wrote:
> From: Nicolas VINCENT <nicolas.vincent@vossloh.com>
>
> the i2c_ram structure is missing the sdmatmp field mentionned in
> datasheet for MPC8272 at paragraph 36.5. With this field missing, the
> hardware would write past the allocated memory done through
> cpm_muram_alloc for the i2c_ram structure and land in memory allocated
> for the buffers descriptors corrupting the cbd_bufaddr field. Since this
> field is only set during setup(), the first i2c transaction would work
> and the following would send data read from an arbitrary memory
> location.
>
> Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>
Fixes tag aded and applied to for-current, thanks everyone!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v1 30/30] powerpc/vdso: Cleanup vdso.h
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
Rename the guard define to _ASM_POWERPC_VDSO_H
And remove useless #ifdef __KERNEL__
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/vdso.h | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/vdso.h b/arch/powerpc/include/asm/vdso.h
index 2448419cb3e5..8542e9bbeead 100644
--- a/arch/powerpc/include/asm/vdso.h
+++ b/arch/powerpc/include/asm/vdso.h
@@ -1,8 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __PPC64_VDSO_H__
-#define __PPC64_VDSO_H__
-
-#ifdef __KERNEL__
+#ifndef _ASM_POWERPC_VDSO_H
+#define _ASM_POWERPC_VDSO_H
/* Default map addresses for 32bit vDSO */
#define VDSO32_MBASE 0x100000
@@ -54,6 +52,4 @@ int vdso_getcpu_init(void);
#endif /* __ASSEMBLY__ */
-#endif /* __KERNEL__ */
-
-#endif /* __PPC64_VDSO_H__ */
+#endif /* _ASM_POWERPC_VDSO_H */
--
2.25.0
^ permalink raw reply related
* [PATCH v1 29/30] powerpc/vdso: Remove VDSO32_LBASE and VDSO64_LBASE
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
VDSO32_LBASE and VDSO64_LBASE are 0. Remove them to simplify code.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/vdso.h | 4 ----
arch/powerpc/kernel/vdso32/vdso32.lds.S | 2 +-
arch/powerpc/kernel/vdso64/vdso64.lds.S | 2 +-
3 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/vdso.h b/arch/powerpc/include/asm/vdso.h
index a97384909fe5..2448419cb3e5 100644
--- a/arch/powerpc/include/asm/vdso.h
+++ b/arch/powerpc/include/asm/vdso.h
@@ -4,10 +4,6 @@
#ifdef __KERNEL__
-/* Default link addresses for the vDSOs */
-#define VDSO32_LBASE 0x0
-#define VDSO64_LBASE 0x0
-
/* Default map addresses for 32bit vDSO */
#define VDSO32_MBASE 0x100000
diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index 7b476a6f2dba..2636b359c9ce 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -17,7 +17,7 @@ ENTRY(_start)
SECTIONS
{
PROVIDE(_vdso_datapage = . - PAGE_SIZE);
- . = VDSO32_LBASE + SIZEOF_HEADERS;
+ . = SIZEOF_HEADERS;
.hash : { *(.hash) } :text
.gnu.hash : { *(.gnu.hash) }
diff --git a/arch/powerpc/kernel/vdso64/vdso64.lds.S b/arch/powerpc/kernel/vdso64/vdso64.lds.S
index a543826cd857..f256525e633f 100644
--- a/arch/powerpc/kernel/vdso64/vdso64.lds.S
+++ b/arch/powerpc/kernel/vdso64/vdso64.lds.S
@@ -17,7 +17,7 @@ ENTRY(_start)
SECTIONS
{
PROVIDE(_vdso_datapage = . - PAGE_SIZE);
- . = VDSO64_LBASE + SIZEOF_HEADERS;
+ . = SIZEOF_HEADERS;
.hash : { *(.hash) } :text
.gnu.hash : { *(.gnu.hash) }
--
2.25.0
^ permalink raw reply related
* [PATCH v1 28/30] powerpc/vdso: Remove DBG()
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
DBG() is not used anymore. Remove it.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index e5a9b60274ba..4e3858bb2b24 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -33,14 +33,6 @@
#include <asm/vdso_datapage.h>
#include <asm/setup.h>
-#undef DEBUG
-
-#ifdef DEBUG
-#define DBG(fmt...) printk(fmt)
-#else
-#define DBG(fmt...)
-#endif
-
/* The alignment of the vDSO */
#define VDSO_ALIGNMENT (1 << 16)
--
2.25.0
^ permalink raw reply related
* [PATCH v1 27/30] powerpc/vdso: Remove vdso_ready
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
There is no way to get out of vdso_init() prematuraly anymore.
Remove vdso_ready as it will always be 1.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 14fbcc76a629..e5a9b60274ba 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -47,8 +47,6 @@
extern char vdso32_start, vdso32_end;
extern char vdso64_start, vdso64_end;
-static int vdso_ready;
-
/*
* The vdso data page (aka. systemcfg for old ppc64 fans) is here.
* Once the early boot kernel code no longer needs to muck around
@@ -171,9 +169,6 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
mm->context.vdso = NULL;
- if (!vdso_ready)
- return 0;
-
if (mmap_write_lock_killable(mm))
return -EINTR;
@@ -312,7 +307,6 @@ static int __init vdso_init(void)
vdso64_spec.pages = vdso_setup_pages(&vdso64_start, &vdso64_end);
smp_wmb();
- vdso_ready = 1;
return 0;
}
--
2.25.0
^ permalink raw reply related
* [PATCH v1 26/30] powerpc/vdso: Remove vdso_setup()
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
vdso_fixup_features() cannot fail anymore and that's
the only function called by vdso_setup().
vdso_setup() has become trivial and can be removed.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 21 ++-------------------
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 0cb320b72923..14fbcc76a629 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -192,7 +192,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
do_##type##_fixups((value), __start, __end); \
} while (0)
-static int __init vdso_fixup_features(void)
+static void __init vdso_fixup_features(void)
{
#ifdef CONFIG_PPC64
VDSO_DO_FIXUPS(feature, cur_cpu_spec->cpu_features, 64, ftr_fixup);
@@ -209,16 +209,6 @@ static int __init vdso_fixup_features(void)
#endif /* CONFIG_PPC64 */
VDSO_DO_FIXUPS(lwsync, cur_cpu_spec->cpu_features, 32, lwsync_fixup);
#endif
-
- return 0;
-}
-
-static __init int vdso_setup(void)
-{
- if (vdso_fixup_features())
- return -1;
-
- return 0;
}
/*
@@ -313,14 +303,7 @@ static int __init vdso_init(void)
vdso_setup_syscall_map();
- /*
- * Initialize the vDSO images in memory, that is do necessary
- * fixups of vDSO symbols, locate trampolines, etc...
- */
- if (vdso_setup()) {
- printk(KERN_ERR "vDSO setup failure, not enabled !\n");
- return 0;
- }
+ vdso_fixup_features();
if (IS_ENABLED(CONFIG_VDSO32))
vdso32_spec.pages = vdso_setup_pages(&vdso32_start, &vdso32_end);
--
2.25.0
^ permalink raw reply related
* [PATCH v1 24/30] powerpc/vdso: Remove symbol section information in struct lib32/64_elfinfo
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
The members related to the symbol section in struct lib32_elfinfo and
struct lib64_elfinfo are not used anymore, removed them.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 90 --------------------------------------
1 file changed, 90 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index fa1cbddfb978..f7b477da0b8a 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -70,17 +70,11 @@ struct vdso_arch_data *vdso_data = &vdso_data_store.data;
struct lib32_elfinfo
{
Elf32_Ehdr *hdr; /* ptr to ELF */
- Elf32_Sym *dynsym; /* ptr to .dynsym section */
- unsigned long dynsymsize; /* size of .dynsym section */
- char *dynstr; /* ptr to .dynstr section */
};
struct lib64_elfinfo
{
Elf64_Ehdr *hdr;
- Elf64_Sym *dynsym;
- unsigned long dynsymsize;
- char *dynstr;
};
static int vdso_mremap(const struct vm_special_mapping *sm, struct vm_area_struct *new_vma,
@@ -208,59 +202,6 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
return rc;
}
-#ifdef CONFIG_VDSO32
-static void * __init find_section32(Elf32_Ehdr *ehdr, const char *secname,
- unsigned long *size)
-{
- Elf32_Shdr *sechdrs;
- unsigned int i;
- char *secnames;
-
- /* Grab section headers and strings so we can tell who is who */
- sechdrs = (void *)ehdr + ehdr->e_shoff;
- secnames = (void *)ehdr + sechdrs[ehdr->e_shstrndx].sh_offset;
-
- /* Find the section they want */
- for (i = 1; i < ehdr->e_shnum; i++) {
- if (strcmp(secnames+sechdrs[i].sh_name, secname) == 0) {
- if (size)
- *size = sechdrs[i].sh_size;
- return (void *)ehdr + sechdrs[i].sh_offset;
- }
- }
- *size = 0;
- return NULL;
-}
-#endif /* CONFIG_VDSO32 */
-
-
-#ifdef CONFIG_PPC64
-
-static void * __init find_section64(Elf64_Ehdr *ehdr, const char *secname,
- unsigned long *size)
-{
- Elf64_Shdr *sechdrs;
- unsigned int i;
- char *secnames;
-
- /* Grab section headers and strings so we can tell who is who */
- sechdrs = (void *)ehdr + ehdr->e_shoff;
- secnames = (void *)ehdr + sechdrs[ehdr->e_shstrndx].sh_offset;
-
- /* Find the section they want */
- for (i = 1; i < ehdr->e_shnum; i++) {
- if (strcmp(secnames+sechdrs[i].sh_name, secname) == 0) {
- if (size)
- *size = sechdrs[i].sh_size;
- return (void *)ehdr + sechdrs[i].sh_offset;
- }
- }
- if (size)
- *size = 0;
- return NULL;
-}
-#endif /* CONFIG_PPC64 */
-
#define VDSO_DO_FIXUPS(type, value, bits, sec) do { \
void *__start = (void *)VDSO##bits##_SYMBOL(&vdso##bits##_start, sec##_start); \
void *__end = (void *)VDSO##bits##_SYMBOL(&vdso##bits##_start, sec##_end); \
@@ -268,34 +209,6 @@ static void * __init find_section64(Elf64_Ehdr *ehdr, const char *secname,
do_##type##_fixups((value), __start, __end); \
} while (0)
-static __init int vdso_do_find_sections(struct lib32_elfinfo *v32,
- struct lib64_elfinfo *v64)
-{
- /*
- * Locate symbol tables & text section
- */
-
-#ifdef CONFIG_VDSO32
- v32->dynsym = find_section32(v32->hdr, ".dynsym", &v32->dynsymsize);
- v32->dynstr = find_section32(v32->hdr, ".dynstr", NULL);
- if (v32->dynsym == NULL || v32->dynstr == NULL) {
- printk(KERN_ERR "vDSO32: required symbol section not found\n");
- return -1;
- }
-#endif
-
-#ifdef CONFIG_PPC64
- v64->dynsym = find_section64(v64->hdr, ".dynsym", &v64->dynsymsize);
- v64->dynstr = find_section64(v64->hdr, ".dynstr", NULL);
- if (v64->dynsym == NULL || v64->dynstr == NULL) {
- printk(KERN_ERR "vDSO64: required symbol section not found\n");
- return -1;
- }
-#endif /* CONFIG_PPC64 */
-
- return 0;
-}
-
static __init int vdso_fixup_features(struct lib32_elfinfo *v32,
struct lib64_elfinfo *v64)
{
@@ -325,9 +238,6 @@ static __init int vdso_setup(void)
v32.hdr = vdso32_kbase;
v64.hdr = vdso64_kbase;
- if (vdso_do_find_sections(&v32, &v64))
- return -1;
-
if (vdso_fixup_features(&v32, &v64))
return -1;
--
2.25.0
^ permalink raw reply related
* [PATCH v1 25/30] powerpc/vdso: Remove lib32_elfinfo and lib64_elfinfo
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
lib32_elfinfo and lib64_elfinfo are not used anymore, remove them.
Also remove vdso32_kbase and vdso64_kbase while removing the
last use.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 29 ++---------------------------
1 file changed, 2 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index f7b477da0b8a..0cb320b72923 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -44,11 +44,8 @@
/* The alignment of the vDSO */
#define VDSO_ALIGNMENT (1 << 16)
-static void *vdso32_kbase;
-
extern char vdso32_start, vdso32_end;
extern char vdso64_start, vdso64_end;
-static void *vdso64_kbase = &vdso64_start;
static int vdso_ready;
@@ -63,20 +60,6 @@ static union {
} vdso_data_store __page_aligned_data;
struct vdso_arch_data *vdso_data = &vdso_data_store.data;
-/*
- * Some infos carried around for each of them during parsing at
- * boot time.
- */
-struct lib32_elfinfo
-{
- Elf32_Ehdr *hdr; /* ptr to ELF */
-};
-
-struct lib64_elfinfo
-{
- Elf64_Ehdr *hdr;
-};
-
static int vdso_mremap(const struct vm_special_mapping *sm, struct vm_area_struct *new_vma,
unsigned long text_size)
{
@@ -209,8 +192,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
do_##type##_fixups((value), __start, __end); \
} while (0)
-static __init int vdso_fixup_features(struct lib32_elfinfo *v32,
- struct lib64_elfinfo *v64)
+static int __init vdso_fixup_features(void)
{
#ifdef CONFIG_PPC64
VDSO_DO_FIXUPS(feature, cur_cpu_spec->cpu_features, 64, ftr_fixup);
@@ -233,12 +215,7 @@ static __init int vdso_fixup_features(struct lib32_elfinfo *v32,
static __init int vdso_setup(void)
{
- struct lib32_elfinfo v32;
- struct lib64_elfinfo v64;
-
- v32.hdr = vdso32_kbase;
- v64.hdr = vdso64_kbase;
- if (vdso_fixup_features(&v32, &v64))
+ if (vdso_fixup_features())
return -1;
return 0;
@@ -334,8 +311,6 @@ static int __init vdso_init(void)
vdso_data->icache_log_block_size = ppc64_caches.l1i.log_block_size;
#endif /* CONFIG_PPC64 */
- vdso32_kbase = &vdso32_start;
-
vdso_setup_syscall_map();
/*
--
2.25.0
^ permalink raw reply related
* [PATCH v1 23/30] powerpc/vdso: Remove unused text member in struct lib32/64_elfinfo
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
The text member in struct lib32_elfinfo and struct lib64_elfinfo
is not used, remove it.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 5e4e3546f034..fa1cbddfb978 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -73,7 +73,6 @@ struct lib32_elfinfo
Elf32_Sym *dynsym; /* ptr to .dynsym section */
unsigned long dynsymsize; /* size of .dynsym section */
char *dynstr; /* ptr to .dynstr section */
- unsigned long text; /* offset of .text section in .so */
};
struct lib64_elfinfo
@@ -82,7 +81,6 @@ struct lib64_elfinfo
Elf64_Sym *dynsym;
unsigned long dynsymsize;
char *dynstr;
- unsigned long text;
};
static int vdso_mremap(const struct vm_special_mapping *sm, struct vm_area_struct *new_vma,
@@ -273,8 +271,6 @@ static void * __init find_section64(Elf64_Ehdr *ehdr, const char *secname,
static __init int vdso_do_find_sections(struct lib32_elfinfo *v32,
struct lib64_elfinfo *v64)
{
- void *sect;
-
/*
* Locate symbol tables & text section
*/
@@ -286,12 +282,6 @@ static __init int vdso_do_find_sections(struct lib32_elfinfo *v32,
printk(KERN_ERR "vDSO32: required symbol section not found\n");
return -1;
}
- sect = find_section32(v32->hdr, ".text", NULL);
- if (sect == NULL) {
- printk(KERN_ERR "vDSO32: the .text section was not found\n");
- return -1;
- }
- v32->text = sect - vdso32_kbase;
#endif
#ifdef CONFIG_PPC64
@@ -301,12 +291,6 @@ static __init int vdso_do_find_sections(struct lib32_elfinfo *v32,
printk(KERN_ERR "vDSO64: required symbol section not found\n");
return -1;
}
- sect = find_section64(v64->hdr, ".text", NULL);
- if (sect == NULL) {
- printk(KERN_ERR "vDSO64: the .text section was not found\n");
- return -1;
- }
- v64->text = sect - vdso64_kbase;
#endif /* CONFIG_PPC64 */
return 0;
--
2.25.0
^ permalink raw reply related
* [PATCH v1 20/30] powerpc/vdso: Remove __kernel_datapage_offset
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
__kernel_datapage_offset is not used anymore, remove it.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 39 -------------------------
arch/powerpc/kernel/vdso32/datapage.S | 3 --
arch/powerpc/kernel/vdso32/vdso32.lds.S | 5 ----
arch/powerpc/kernel/vdso64/datapage.S | 3 --
arch/powerpc/kernel/vdso64/vdso64.lds.S | 5 ----
5 files changed, 55 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index e732776bac0a..611977010e2d 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -494,42 +494,6 @@ static __init void vdso_setup_trampolines(struct lib32_elfinfo *v32,
vdso32_rt_sigtramp = find_function32(v32, "__kernel_sigtramp_rt32");
}
-static __init int vdso_fixup_datapage(struct lib32_elfinfo *v32,
- struct lib64_elfinfo *v64)
-{
-#ifdef CONFIG_VDSO32
- Elf32_Sym *sym32;
-#endif
-#ifdef CONFIG_PPC64
- Elf64_Sym *sym64;
-
- sym64 = find_symbol64(v64, "__kernel_datapage_offset");
- if (sym64 == NULL) {
- printk(KERN_ERR "vDSO64: Can't find symbol "
- "__kernel_datapage_offset !\n");
- return -1;
- }
- *((int *)(vdso64_kbase + sym64->st_value - VDSO64_LBASE)) =
- -PAGE_SIZE -
- (sym64->st_value - VDSO64_LBASE);
-#endif /* CONFIG_PPC64 */
-
-#ifdef CONFIG_VDSO32
- sym32 = find_symbol32(v32, "__kernel_datapage_offset");
- if (sym32 == NULL) {
- printk(KERN_ERR "vDSO32: Can't find symbol "
- "__kernel_datapage_offset !\n");
- return -1;
- }
- *((int *)(vdso32_kbase + (sym32->st_value - VDSO32_LBASE))) =
- -PAGE_SIZE -
- (sym32->st_value - VDSO32_LBASE);
-#endif
-
- return 0;
-}
-
-
static __init int vdso_fixup_features(struct lib32_elfinfo *v32,
struct lib64_elfinfo *v64)
{
@@ -595,9 +559,6 @@ static __init int vdso_setup(void)
if (vdso_do_find_sections(&v32, &v64))
return -1;
- if (vdso_fixup_datapage(&v32, &v64))
- return -1;
-
if (vdso_fixup_features(&v32, &v64))
return -1;
diff --git a/arch/powerpc/kernel/vdso32/datapage.S b/arch/powerpc/kernel/vdso32/datapage.S
index 91a153b34714..0513a2eabec8 100644
--- a/arch/powerpc/kernel/vdso32/datapage.S
+++ b/arch/powerpc/kernel/vdso32/datapage.S
@@ -13,9 +13,6 @@
#include <asm/vdso_datapage.h>
.text
- .global __kernel_datapage_offset;
-__kernel_datapage_offset:
- .long 0
/*
* void *__kernel_get_syscall_map(unsigned int *syscall_count) ;
diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index c70f5dac8c98..7b476a6f2dba 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -148,11 +148,6 @@ VERSION
{
VDSO_VERSION_STRING {
global:
- /*
- * Has to be there for the kernel to find
- */
- __kernel_datapage_offset;
-
__kernel_get_syscall_map;
#ifndef CONFIG_PPC_BOOK3S_601
__kernel_gettimeofday;
diff --git a/arch/powerpc/kernel/vdso64/datapage.S b/arch/powerpc/kernel/vdso64/datapage.S
index 941b735df069..00760dc69d68 100644
--- a/arch/powerpc/kernel/vdso64/datapage.S
+++ b/arch/powerpc/kernel/vdso64/datapage.S
@@ -13,9 +13,6 @@
#include <asm/vdso_datapage.h>
.text
-.global __kernel_datapage_offset;
-__kernel_datapage_offset:
- .long 0
/*
* void *__kernel_get_syscall_map(unsigned int *syscall_count) ;
diff --git a/arch/powerpc/kernel/vdso64/vdso64.lds.S b/arch/powerpc/kernel/vdso64/vdso64.lds.S
index a049000eacfe..a543826cd857 100644
--- a/arch/powerpc/kernel/vdso64/vdso64.lds.S
+++ b/arch/powerpc/kernel/vdso64/vdso64.lds.S
@@ -148,11 +148,6 @@ VERSION
{
VDSO_VERSION_STRING {
global:
- /*
- * Has to be there for the kernel to find
- */
- __kernel_datapage_offset;
-
__kernel_get_syscall_map;
__kernel_gettimeofday;
__kernel_clock_gettime;
--
2.25.0
^ permalink raw reply related
* [PATCH v1 22/30] powerpc/vdso: Remove vdso_patches[] and associated functions
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
vdso_patches[] is now empty, remove it and remove
all functions that depends on it.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 161 -------------------------------------
1 file changed, 161 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index ec0f1aae0cad..5e4e3546f034 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -41,9 +41,6 @@
#define DBG(fmt...)
#endif
-/* Max supported size for symbol names */
-#define MAX_SYMNAME 64
-
/* The alignment of the vDSO */
#define VDSO_ALIGNMENT (1 << 16)
@@ -66,22 +63,6 @@ static union {
} vdso_data_store __page_aligned_data;
struct vdso_arch_data *vdso_data = &vdso_data_store.data;
-/* Format of the patch table */
-struct vdso_patch_def
-{
- unsigned long ftr_mask, ftr_value;
- const char *gen_name;
- const char *fix_name;
-};
-
-/* Table of functions to patch based on the CPU type/revision
- *
- * Currently, we only change sync_dicache to do nothing on processors
- * with a coherent icache
- */
-static struct vdso_patch_def vdso_patches[] = {
-};
-
/*
* Some infos carried around for each of them during parsing at
* boot time.
@@ -252,62 +233,6 @@ static void * __init find_section32(Elf32_Ehdr *ehdr, const char *secname,
*size = 0;
return NULL;
}
-
-static Elf32_Sym * __init find_symbol32(struct lib32_elfinfo *lib,
- const char *symname)
-{
- unsigned int i;
- char name[MAX_SYMNAME], *c;
-
- for (i = 0; i < (lib->dynsymsize / sizeof(Elf32_Sym)); i++) {
- if (lib->dynsym[i].st_name == 0)
- continue;
- strlcpy(name, lib->dynstr + lib->dynsym[i].st_name,
- MAX_SYMNAME);
- c = strchr(name, '@');
- if (c)
- *c = 0;
- if (strcmp(symname, name) == 0)
- return &lib->dynsym[i];
- }
- return NULL;
-}
-
-static int __init vdso_do_func_patch32(struct lib32_elfinfo *v32,
- struct lib64_elfinfo *v64,
- const char *orig, const char *fix)
-{
- Elf32_Sym *sym32_gen, *sym32_fix;
-
- sym32_gen = find_symbol32(v32, orig);
- if (sym32_gen == NULL) {
- printk(KERN_ERR "vDSO32: Can't find symbol %s !\n", orig);
- return -1;
- }
- if (fix == NULL) {
- sym32_gen->st_name = 0;
- return 0;
- }
- sym32_fix = find_symbol32(v32, fix);
- if (sym32_fix == NULL) {
- printk(KERN_ERR "vDSO32: Can't find symbol %s !\n", fix);
- return -1;
- }
- sym32_gen->st_value = sym32_fix->st_value;
- sym32_gen->st_size = sym32_fix->st_size;
- sym32_gen->st_info = sym32_fix->st_info;
- sym32_gen->st_other = sym32_fix->st_other;
- sym32_gen->st_shndx = sym32_fix->st_shndx;
-
- return 0;
-}
-#else /* !CONFIG_VDSO32 */
-static int __init vdso_do_func_patch32(struct lib32_elfinfo *v32,
- struct lib64_elfinfo *v64,
- const char *orig, const char *fix)
-{
- return 0;
-}
#endif /* CONFIG_VDSO32 */
@@ -336,56 +261,6 @@ static void * __init find_section64(Elf64_Ehdr *ehdr, const char *secname,
*size = 0;
return NULL;
}
-
-static Elf64_Sym * __init find_symbol64(struct lib64_elfinfo *lib,
- const char *symname)
-{
- unsigned int i;
- char name[MAX_SYMNAME], *c;
-
- for (i = 0; i < (lib->dynsymsize / sizeof(Elf64_Sym)); i++) {
- if (lib->dynsym[i].st_name == 0)
- continue;
- strlcpy(name, lib->dynstr + lib->dynsym[i].st_name,
- MAX_SYMNAME);
- c = strchr(name, '@');
- if (c)
- *c = 0;
- if (strcmp(symname, name) == 0)
- return &lib->dynsym[i];
- }
- return NULL;
-}
-
-static int __init vdso_do_func_patch64(struct lib32_elfinfo *v32,
- struct lib64_elfinfo *v64,
- const char *orig, const char *fix)
-{
- Elf64_Sym *sym64_gen, *sym64_fix;
-
- sym64_gen = find_symbol64(v64, orig);
- if (sym64_gen == NULL) {
- printk(KERN_ERR "vDSO64: Can't find symbol %s !\n", orig);
- return -1;
- }
- if (fix == NULL) {
- sym64_gen->st_name = 0;
- return 0;
- }
- sym64_fix = find_symbol64(v64, fix);
- if (sym64_fix == NULL) {
- printk(KERN_ERR "vDSO64: Can't find symbol %s !\n", fix);
- return -1;
- }
- sym64_gen->st_value = sym64_fix->st_value;
- sym64_gen->st_size = sym64_fix->st_size;
- sym64_gen->st_info = sym64_fix->st_info;
- sym64_gen->st_other = sym64_fix->st_other;
- sym64_gen->st_shndx = sym64_fix->st_shndx;
-
- return 0;
-}
-
#endif /* CONFIG_PPC64 */
#define VDSO_DO_FIXUPS(type, value, bits, sec) do { \
@@ -459,39 +334,6 @@ static __init int vdso_fixup_features(struct lib32_elfinfo *v32,
return 0;
}
-static __init int vdso_fixup_alt_funcs(struct lib32_elfinfo *v32,
- struct lib64_elfinfo *v64)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(vdso_patches); i++) {
- struct vdso_patch_def *patch = &vdso_patches[i];
- int match = (cur_cpu_spec->cpu_features & patch->ftr_mask)
- == patch->ftr_value;
- if (!match)
- continue;
-
- DBG("replacing %s with %s...\n", patch->gen_name,
- patch->fix_name ? "NONE" : patch->fix_name);
-
- /*
- * Patch the 32 bits and 64 bits symbols. Note that we do not
- * patch the "." symbol on 64 bits.
- * It would be easy to do, but doesn't seem to be necessary,
- * patching the OPD symbol is enough.
- */
- vdso_do_func_patch32(v32, v64, patch->gen_name,
- patch->fix_name);
-#ifdef CONFIG_PPC64
- vdso_do_func_patch64(v32, v64, patch->gen_name,
- patch->fix_name);
-#endif /* CONFIG_PPC64 */
- }
-
- return 0;
-}
-
-
static __init int vdso_setup(void)
{
struct lib32_elfinfo v32;
@@ -505,9 +347,6 @@ static __init int vdso_setup(void)
if (vdso_fixup_features(&v32, &v64))
return -1;
- if (vdso_fixup_alt_funcs(&v32, &v64))
- return -1;
-
return 0;
}
--
2.25.0
^ permalink raw reply related
* [PATCH v1 21/30] powerpc/vdso: Remove runtime generated sigtramp offsets
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
Signal trampoline offsets are now generated at buildtime.
Runtime generated offsets are not used anymore, remove them.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/vdso.h | 5 ---
arch/powerpc/kernel/vdso.c | 59 ---------------------------------
2 files changed, 64 deletions(-)
diff --git a/arch/powerpc/include/asm/vdso.h b/arch/powerpc/include/asm/vdso.h
index f5257b7f17d0..a97384909fe5 100644
--- a/arch/powerpc/include/asm/vdso.h
+++ b/arch/powerpc/include/asm/vdso.h
@@ -27,11 +27,6 @@
#define VDSO32_SYMBOL(base, name) ((unsigned long)(base) + (vdso32_offset_##name))
-/* Offsets relative to thread->vdso_base */
-extern unsigned long vdso64_rt_sigtramp;
-extern unsigned long vdso32_sigtramp;
-extern unsigned long vdso32_rt_sigtramp;
-
int vdso_getcpu_init(void);
#else /* __ASSEMBLY__ */
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 611977010e2d..ec0f1aae0cad 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -48,15 +48,10 @@
#define VDSO_ALIGNMENT (1 << 16)
static void *vdso32_kbase;
-unsigned long vdso32_sigtramp;
-unsigned long vdso32_rt_sigtramp;
extern char vdso32_start, vdso32_end;
extern char vdso64_start, vdso64_end;
static void *vdso64_kbase = &vdso64_start;
-#ifdef CONFIG_PPC64
-unsigned long vdso64_rt_sigtramp;
-#endif /* CONFIG_PPC64 */
static int vdso_ready;
@@ -278,22 +273,6 @@ static Elf32_Sym * __init find_symbol32(struct lib32_elfinfo *lib,
return NULL;
}
-/* Note that we assume the section is .text and the symbol is relative to
- * the library base
- */
-static unsigned long __init find_function32(struct lib32_elfinfo *lib,
- const char *symname)
-{
- Elf32_Sym *sym = find_symbol32(lib, symname);
-
- if (sym == NULL) {
- printk(KERN_WARNING "vDSO32: function %s not found !\n",
- symname);
- return 0;
- }
- return sym->st_value - VDSO32_LBASE;
-}
-
static int __init vdso_do_func_patch32(struct lib32_elfinfo *v32,
struct lib64_elfinfo *v64,
const char *orig, const char *fix)
@@ -323,12 +302,6 @@ static int __init vdso_do_func_patch32(struct lib32_elfinfo *v32,
return 0;
}
#else /* !CONFIG_VDSO32 */
-static unsigned long __init find_function32(struct lib32_elfinfo *lib,
- const char *symname)
-{
- return 0;
-}
-
static int __init vdso_do_func_patch32(struct lib32_elfinfo *v32,
struct lib64_elfinfo *v64,
const char *orig, const char *fix)
@@ -384,22 +357,6 @@ static Elf64_Sym * __init find_symbol64(struct lib64_elfinfo *lib,
return NULL;
}
-/* Note that we assume the section is .text and the symbol is relative to
- * the library base
- */
-static unsigned long __init find_function64(struct lib64_elfinfo *lib,
- const char *symname)
-{
- Elf64_Sym *sym = find_symbol64(lib, symname);
-
- if (sym == NULL) {
- printk(KERN_WARNING "vDSO64: function %s not found !\n",
- symname);
- return 0;
- }
- return sym->st_value - VDSO64_LBASE;
-}
-
static int __init vdso_do_func_patch64(struct lib32_elfinfo *v32,
struct lib64_elfinfo *v64,
const char *orig, const char *fix)
@@ -480,20 +437,6 @@ static __init int vdso_do_find_sections(struct lib32_elfinfo *v32,
return 0;
}
-static __init void vdso_setup_trampolines(struct lib32_elfinfo *v32,
- struct lib64_elfinfo *v64)
-{
- /*
- * Find signal trampolines
- */
-
-#ifdef CONFIG_PPC64
- vdso64_rt_sigtramp = find_function64(v64, "__kernel_sigtramp_rt64");
-#endif
- vdso32_sigtramp = find_function32(v32, "__kernel_sigtramp32");
- vdso32_rt_sigtramp = find_function32(v32, "__kernel_sigtramp_rt32");
-}
-
static __init int vdso_fixup_features(struct lib32_elfinfo *v32,
struct lib64_elfinfo *v64)
{
@@ -565,8 +508,6 @@ static __init int vdso_setup(void)
if (vdso_fixup_alt_funcs(&v32, &v64))
return -1;
- vdso_setup_trampolines(&v32, &v64);
-
return 0;
}
--
2.25.0
^ permalink raw reply related
* [PATCH v1 18/30] powerpc/vdso: Merge __kernel_sync_dicache_p5() into __kernel_sync_dicache()
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
__kernel_sync_dicache_p5() is an alternative to
__kernel_sync_dicache() when cpu has CPU_FTR_COHERENT_ICACHE
Remove this alternative function and merge
__kernel_sync_dicache_p5() into __kernel_sync_dicache() using
standard CPU feature fixup.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 4 ----
arch/powerpc/kernel/vdso32/cacheflush.S | 17 ++++++-----------
arch/powerpc/kernel/vdso32/vdso32.lds.S | 1 -
arch/powerpc/kernel/vdso64/cacheflush.S | 16 ++++++----------
arch/powerpc/kernel/vdso64/vdso64.lds.S | 1 -
5 files changed, 12 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index ba2b935a67f6..3a4fbcc0d1be 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -87,10 +87,6 @@ struct vdso_patch_def
* with a coherent icache
*/
static struct vdso_patch_def vdso_patches[] = {
- {
- CPU_FTR_COHERENT_ICACHE, CPU_FTR_COHERENT_ICACHE,
- "__kernel_sync_dicache", "__kernel_sync_dicache_p5"
- },
};
/*
diff --git a/arch/powerpc/kernel/vdso32/cacheflush.S b/arch/powerpc/kernel/vdso32/cacheflush.S
index 017843bf5382..f340e82d1981 100644
--- a/arch/powerpc/kernel/vdso32/cacheflush.S
+++ b/arch/powerpc/kernel/vdso32/cacheflush.S
@@ -24,11 +24,15 @@
*/
V_FUNCTION_BEGIN(__kernel_sync_dicache)
.cfi_startproc
+BEGIN_FTR_SECTION
+ b 3f
+END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
#ifdef CONFIG_PPC64
mflr r12
.cfi_register lr,r12
get_datapage r10
mtlr r12
+ .cfi_restore lr
#endif
#ifdef CONFIG_PPC64
@@ -84,20 +88,11 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache)
isync
li r3,0
blr
- .cfi_endproc
-V_FUNCTION_END(__kernel_sync_dicache)
-
-
-/*
- * POWER5 version of __kernel_sync_dicache
- */
-V_FUNCTION_BEGIN(__kernel_sync_dicache_p5)
- .cfi_startproc
+3:
crclr cr0*4+so
sync
isync
li r3,0
blr
.cfi_endproc
-V_FUNCTION_END(__kernel_sync_dicache_p5)
-
+V_FUNCTION_END(__kernel_sync_dicache)
diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index dd9f262e07c6..c70f5dac8c98 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -163,7 +163,6 @@ VERSION
__kernel_get_tbfreq;
#endif
__kernel_sync_dicache;
- __kernel_sync_dicache_p5;
__kernel_sigtramp32;
__kernel_sigtramp_rt32;
#if defined(CONFIG_PPC64) || !defined(CONFIG_SMP)
diff --git a/arch/powerpc/kernel/vdso64/cacheflush.S b/arch/powerpc/kernel/vdso64/cacheflush.S
index 61985de5758f..76c3c8cf8ece 100644
--- a/arch/powerpc/kernel/vdso64/cacheflush.S
+++ b/arch/powerpc/kernel/vdso64/cacheflush.S
@@ -23,10 +23,14 @@
*/
V_FUNCTION_BEGIN(__kernel_sync_dicache)
.cfi_startproc
+BEGIN_FTR_SECTION
+ b 3f
+END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
mflr r12
.cfi_register lr,r12
get_datapage r10
mtlr r12
+ .cfi_restore lr
lwz r7,CFG_DCACHE_BLOCKSZ(r10)
addi r5,r7,-1
@@ -61,19 +65,11 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache)
isync
li r3,0
blr
- .cfi_endproc
-V_FUNCTION_END(__kernel_sync_dicache)
-
-
-/*
- * POWER5 version of __kernel_sync_dicache
- */
-V_FUNCTION_BEGIN(__kernel_sync_dicache_p5)
- .cfi_startproc
+3:
crclr cr0*4+so
sync
isync
li r3,0
blr
.cfi_endproc
-V_FUNCTION_END(__kernel_sync_dicache_p5)
+V_FUNCTION_END(__kernel_sync_dicache)
diff --git a/arch/powerpc/kernel/vdso64/vdso64.lds.S b/arch/powerpc/kernel/vdso64/vdso64.lds.S
index e950bf68783a..a049000eacfe 100644
--- a/arch/powerpc/kernel/vdso64/vdso64.lds.S
+++ b/arch/powerpc/kernel/vdso64/vdso64.lds.S
@@ -159,7 +159,6 @@ VERSION
__kernel_clock_getres;
__kernel_get_tbfreq;
__kernel_sync_dicache;
- __kernel_sync_dicache_p5;
__kernel_sigtramp_rt64;
__kernel_getcpu;
__kernel_time;
--
2.25.0
^ permalink raw reply related
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