* [PATCH v1 2/2] arm64: dts: imx8mn-ddr4-evk: correct ldo1/ldo2 voltage range
From: Robin Gong @ 2020-05-21 11:26 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, festevam, Anson.Huang
Cc: linux-arm-kernel, devicetree, linux-imx, kernel, linux-kernel
In-Reply-To: <1590060368-2282-1-git-send-email-yibin.gong@nxp.com>
Correct ldo1 voltage range from wrong high group(3.0v~3.3v) to low group
(1.6v~1.9v) because the ldo1 should be 1.8v. Actually, two voltage groups
have been supported at bd718x7-regulator driver, hence, just corrrect the
voltage range to 1.6v~3.3v. For ldo2@0.8v, correct voltage range too.
Otherwise, ldo1 would be kept @3.0v and ldo2@0.9v which violate i.mx8mm
datasheet as the below warning log in kernel:
[ 0.995524] LDO1: Bringing 1800000uV into 3000000-3000000uV
[ 0.999196] LDO2: Bringing 800000uV into 900000-900000uV
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts | 4 ++--
arch/arm64/boot/dts/freescale/imx8mn-evk.dts | 9 +++++++++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
index d07e0e6..a1e5483 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
@@ -113,7 +113,7 @@
ldo1_reg: LDO1 {
regulator-name = "LDO1";
- regulator-min-microvolt = <3000000>;
+ regulator-min-microvolt = <1600000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
@@ -121,7 +121,7 @@
ldo2_reg: LDO2 {
regulator-name = "LDO2";
- regulator-min-microvolt = <900000>;
+ regulator-min-microvolt = <800000>;
regulator-max-microvolt = <900000>;
regulator-boot-on;
regulator-always-on;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-evk.dts
index 61f3519..117ff4b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-evk.dts
@@ -13,6 +13,15 @@
compatible = "fsl,imx8mn-evk", "fsl,imx8mn";
};
+&ecspi1 {
+ status = "okay";
+spidev0: spi@0 {
+ compatible = "ge,achc";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+};
+
&A53_0 {
/delete-property/operating-points-v2;
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 1/2] arm64: dts: imx8mm-evk: correct ldo1/ldo2 voltage range
From: Robin Gong @ 2020-05-21 11:26 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, festevam, Anson.Huang
Cc: linux-arm-kernel, devicetree, linux-imx, kernel, linux-kernel
Correct ldo1 voltage range from wrong high group(3.0v~3.3v) to low group
(1.6v~1.9v) because the ldo1 should be 1.8v. Actually, two voltage groups
have been supported at bd718x7-regulator driver, hence, just corrrect the
voltage range to 1.6v~3.3v. For ldo2@0.8v, correct voltage range too.
Otherwise, ldo1 would be kept @3.0v and ldo2@0.9v which violate i.mx8mm
datasheet as the below warning log in kernel:
[ 0.995524] LDO1: Bringing 1800000uV into 3000000-3000000uV
[ 0.999196] LDO2: Bringing 800000uV into 900000-900000uV
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
index e5ec832..0f1d7f8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
@@ -208,7 +208,7 @@
ldo1_reg: LDO1 {
regulator-name = "LDO1";
- regulator-min-microvolt = <3000000>;
+ regulator-min-microvolt = <1600000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
@@ -216,7 +216,7 @@
ldo2_reg: LDO2 {
regulator-name = "LDO2";
- regulator-min-microvolt = <900000>;
+ regulator-min-microvolt = <800000>;
regulator-max-microvolt = <900000>;
regulator-boot-on;
regulator-always-on;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] soc: fsl: qe: Replace one-element array and use struct_size() helper
From: Kees Cook @ 2020-05-21 3:24 UTC (permalink / raw)
To: Li Yang
Cc: Gustavo A. R. Silva, lkml, Gustavo A. R. Silva, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Qiang Zhao
In-Reply-To: <CADRPPNR-Croux9FgnrQJJmdF2jNnuAmC+2xMJSgSbkbRv9u8Mw@mail.gmail.com>
On Wed, May 20, 2020 at 06:52:21PM -0500, Li Yang wrote:
> On Mon, May 18, 2020 at 5:57 PM Kees Cook <keescook@chromium.org> wrote:
> > Hm, looking at this code, I see a few other things that need to be
> > fixed:
> >
> > 1) drivers/tty/serial/ucc_uart.c does not do a be32_to_cpu() conversion
> > on the length test (understandably, a little-endian system has never run
> > this code since it's ppc specific), but it's still wrong:
> >
> > if (firmware->header.length != fw->size) {
> >
> > compare to the firmware loader:
> >
> > length = be32_to_cpu(hdr->length);
> >
> > 2) drivers/soc/fsl/qe/qe.c does not perform bounds checking on the
> > per-microcode offsets, so the uploader might send data outside the
> > firmware buffer. Perhaps:
>
> We do validate the CRC for each microcode, it is unlikely the CRC
> check can pass if the offset or length is not correct. But you are
> probably right that it will be safer to check the boundary and fail
Right, but a malicious firmware file could still match CRC but trick the
kernel code.
> quicker before we actually start the CRC check. Will you come up with
> a formal patch or you want us to deal with it?
It sounds like Gustavo will be sending one, though I don't think either
of us have the hardware to test it with, so if you could do that part,
that would be great! :)
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64/cpufeature: Move BUG_ON() inside get_arm64_ftr_reg()
From: Anshuman Khandual @ 2020-05-21 3:15 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: mark.rutland, Mark Brown, linux-kernel, linux-arm-kernel,
Suzuki K Poulose
In-Reply-To: <20200520173953.GA27629@willie-the-truck>
On 05/20/2020 11:09 PM, Will Deacon wrote:
> On Wed, May 20, 2020 at 04:47:11PM +0100, Catalin Marinas wrote:
>> On Wed, May 20, 2020 at 01:20:13PM +0100, Will Deacon wrote:
>>> On Wed, May 20, 2020 at 06:52:54AM +0530, Anshuman Khandual wrote:
>>>> There is no way to proceed when requested register could not be searched in
>>>> arm64_ftr_reg[]. Requesting for a non present register would be an error as
>>>> well. Hence lets just BUG_ON() when the search fails in get_arm64_ftr_reg()
>>>> rather than checking for return value and doing the same in some individual
>>>> callers.
>>>>
>>>> But there are some callers that dont BUG_ON() upon search failure. It adds
>>>> an argument 'failsafe' that provides required switch between callers based
>>>> on whether they could proceed or not.
>>>>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> Cc: Will Deacon <will@kernel.org>
>>>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> Cc: Mark Brown <broonie@kernel.org>
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>>
>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>>> ---
>>>> Applies on next-20200518 that has recent cpufeature changes from Will.
>>>>
>>>> arch/arm64/kernel/cpufeature.c | 26 +++++++++++++-------------
>>>> 1 file changed, 13 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>>> index bc5048f152c1..62767cc540c3 100644
>>>> --- a/arch/arm64/kernel/cpufeature.c
>>>> +++ b/arch/arm64/kernel/cpufeature.c
>>>> @@ -557,7 +557,7 @@ static int search_cmp_ftr_reg(const void *id, const void *regp)
>>>> * - NULL on failure. It is upto the caller to decide
>>>> * the impact of a failure.
>>>> */
>>>> -static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id)
>>>> +static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id, bool failsafe)
>>>
>>> Generally, I'm not a big fan of boolean arguments because they are really
>>> opaque at the callsite. It also seems bogus to me that we don't trust the
>>> caller to pass a valid sys_id, but we trust it to get "failsafe" right,
>>> which seems to mean "I promise to check the result isn't NULL before
>>> dereferencing it."
>>>
>>> So I don't see how this patch improves anything. I'd actually be more
>>> inclined to stick a WARN() in get_arm64_ftr_reg() when it returns NULL and
>>> have the callers handle NULL by returning early, getting rid of all the
>>> BUG_ONs in here. Sure, the system might end up in a funny state, but we
>>> WARN()d about it and tried to keep going (and Linus has some strong opinions
>>> on this too).
>>
>> Such WARN can be triggered by the user via emulate_sys_reg(), so we
>> can't really have it in get_arm64_ftr_reg() without a 'failsafe' option.
>
> Ah yes, that would be bad. In which case, I don't think the existing code
> should change.
The existing code has BUG_ON() in three different callers doing exactly the
same thing that can easily be taken care in get_arm64_ftr_reg() itself. As
mentioned before an enum variable (as preferred - over a bool) can still
preserve the existing behavior for emulate_sys_reg().
IMHO these are very good reasons for us to change the code which will make
it cleaner while also removing three redundant BUG_ON() instances. Hence I
will request you to please reconsider this proposal.
- Anshuman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64/cpufeature: Move BUG_ON() inside get_arm64_ftr_reg()
From: Anshuman Khandual @ 2020-05-21 3:12 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland, Suzuki K Poulose, Catalin Marinas, linux-kernel,
Mark Brown, linux-arm-kernel
In-Reply-To: <20200520122012.GA25815@willie-the-truck>
On 05/20/2020 05:50 PM, Will Deacon wrote:
> Hi Anshuman,
>
> On Wed, May 20, 2020 at 06:52:54AM +0530, Anshuman Khandual wrote:
>> There is no way to proceed when requested register could not be searched in
>> arm64_ftr_reg[]. Requesting for a non present register would be an error as
>> well. Hence lets just BUG_ON() when the search fails in get_arm64_ftr_reg()
>> rather than checking for return value and doing the same in some individual
>> callers.
>>
>> But there are some callers that dont BUG_ON() upon search failure. It adds
>> an argument 'failsafe' that provides required switch between callers based
>> on whether they could proceed or not.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Cc: Mark Brown <broonie@kernel.org>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Applies on next-20200518 that has recent cpufeature changes from Will.
>>
>> arch/arm64/kernel/cpufeature.c | 26 +++++++++++++-------------
>> 1 file changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index bc5048f152c1..62767cc540c3 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -557,7 +557,7 @@ static int search_cmp_ftr_reg(const void *id, const void *regp)
>> * - NULL on failure. It is upto the caller to decide
>> * the impact of a failure.
>> */
>> -static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id)
>> +static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id, bool failsafe)
>
> Generally, I'm not a big fan of boolean arguments because they are really
> opaque at the callsite. It also seems bogus to me that we don't trust the
If preferred, we could replace with an enum variable here with some
more context e.g
enum ftr_reg_search {
FTR_REG_SEARCH_SAFE,
FTR_REG_SEARCH_UNSAFE,
};
> caller to pass a valid sys_id, but we trust it to get "failsafe" right,
If we really trust the callers, then why BUG_ON() checks are present in
the first place. Because it is always prudent to protect against the
unexpected.
> which seems to mean "I promise to check the result isn't NULL before
> dereferencing it."
Not sure I got this. Do you mean all the present BUG_ON() are trying to
check that returned arm64_ftr_reg is valid before dereferencing it ? If
there is real trust on the callers that a non present sys_id will never
get requested, then all present BUG_ON() instances should never be there.
Either we trust the callers - drop all BUG_ON() and WARN_ON() instances
or we dont - consolidate BUG_ON() and WARN_ON() instances appropriately.
>
> So I don't see how this patch improves anything. I'd actually be more
It consolidates multiple BUG_ON() in various callers which are not really
required. Code consolidation and reduction especially BUG_ON() instances,
is invariably a good thing.
> inclined to stick a WARN() in get_arm64_ftr_reg() when it returns NULL and
AFAICS in emulate_sys_reg() where the user can send non-present sys_id
registers that eventually gets emulated, should not expect an WARN_ON()
as it did not do anything wrong.
> have the callers handle NULL by returning early, getting rid of all the
> BUG_ONs in here. Sure, the system might end up in a funny state, but we
> WARN()d about it and tried to keep going (and Linus has some strong opinions
> on this too).
Sure, we could go with an WARN_ON() instead, if acceptable and preferred.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 0/3] arm64: perf: Add support for Perf NMI interrupts
From: Song Bao Hua (Barry Song) @ 2020-05-21 3:00 UTC (permalink / raw)
To: Alexandru Elisei, Mark Rutland, Lecopzer Chen
Cc: Sumit Garg, Jian-Lin Chen, Will Deacon,
alexander.shishkin@linux.intel.com, Catalin Marinas,
yj.chiang@mediatek.com, Linux Kernel Mailing List,
acme@kernel.org, Linuxarm, Peter Zijlstra, mingo@redhat.com,
linux-mediatek@lists.infradead.org, linux-arm-kernel,
matthias.bgg@gmail.com, namhyung@kernel.org, jolsa@redhat.com,
julien.thierry.kdev@gmail.com
In-Reply-To: <8a1022c0-da2b-c83d-81cd-44b11149496b@arm.com>
> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-bounces@lists.infradead.org]
> On Behalf Of Alexandru Elisei
> Sent: Wednesday, May 20, 2020 10:31 PM>
> Hi,
>
> On 5/18/20 12:17 PM, Alexandru Elisei wrote:
> > Hi,
> >
> > On 5/18/20 11:45 AM, Mark Rutland wrote:
> >> Hi all,
> >>
> >> On Mon, May 18, 2020 at 02:26:00PM +0800, Lecopzer Chen wrote:
> >>> HI Sumit,
> >>>
> >>> Thanks for your information.
> >>>
> >>> I've already implemented IPI (same as you did [1], little difference
> >>> in detail), hardlockup detector and perf in last year(2019) for
> >>> debuggability.
> >>> And now we tend to upstream to reduce kernel maintaining effort.
> >>> I'm glad if someone in ARM can do this work :)
> >>>
> >>> Hi Julien,
> >>>
> >>> Does any Arm maintainers can proceed this action?
> >> Alexandru (Cc'd) has been rebasing and reworking Julien's patches,
> >> which is my preferred approach.
> >>
> >> I understand that's not quite ready for posting since he's
> >> investigating some of the nastier subtleties (e.g. mutual exclusion
> >> with the NMI), but maybe we can put the work-in-progress patches
> >> somewhere in the mean time.
> >>
> >> Alexandru, do you have an idea of what needs to be done, and/or when
> >> you expect you could post that?
> > I'm currently working on rebasing the patches on top of 5.7-rc5, when
> > I have something usable I'll post a link (should be a couple of days).
> > After that I will address the review comments, and I plan to do a
> > thorough testing because I'm not 100% confident that some of the
> > assumptions around the locks that were removed are correct. My guess is
> this will take a few weeks.
>
> Pushed a WIP branch on linux-arm.org [1]:
>
> git clone -b WIP-pmu-nmi git://linux-arm.org/linux-ae
>
> Practically untested, I only did perf record on a defconfig kernel running on the
> model.
>
> [1]
> http://www.linux-arm.org/git?p=linux-ae.git;a=shortlog;h=refs/heads/WIP-pm
> u-nmi
Fortunately, it does work. I used this tree to perf annotate arm_smmu_cmdq_issue_cmdlist() which
is completely disabling IRQ. Luckily, it reports correct data. Before that, it reported all time was spent by
the code which enabled IRQ .
Barry
>
> Thanks,
> Alex
> >
> > Thanks,
> > Alex
> >> Thanks,
> >> Mark.
> >>
> >>> This is really useful in debugging.
> >>> Thank you!!
> >>>
> >>>
> >>>
> >>> [1] https://lkml.org/lkml/2020/4/24/328
> >>>
> >>>
> >>> Lecopzer
> >>>
> >>> Sumit Garg <sumit.garg@linaro.org> 於 2020年5月18日 週一 下午
> 1:46寫道：
> >>>> + Julien
> >>>>
> >>>> Hi Lecopzer,
> >>>>
> >>>> On Sat, 16 May 2020 at 18:20, Lecopzer Chen <lecopzer@gmail.com>
> wrote:
> >>>>> These series implement Perf NMI funxtionality and depends on
> >>>>> Pseudo NMI [1] which has been upstreamed.
> >>>>>
> >>>>> In arm64 with GICv3, Pseudo NMI was implemented for NMI-like
> interruts.
> >>>>> That can be extended to Perf NMI which is the prerequisite for
> >>>>> hard-lockup detector which had already a standard interface inside
> Linux.
> >>>>>
> >>>>> Thus the first step we need to implement perf NMI interface and
> >>>>> make sure it works fine.
> >>>>>
> >>>> This is something that is already implemented via Julien's
> >>>> patch-set [1]. Its v4 has been floating since July, 2019 and I
> >>>> couldn't find any major blocking comments but not sure why things
> >>>> haven't progressed further.
> >>>>
> >>>> Maybe Julien or Arm maintainers can provide updates on existing
> >>>> patch-set [1] and how we should proceed further with this
> >>>> interesting feature.
> >>>>
> >>>> And regarding hard-lockup detection, I have been able to enable it
> >>>> based on perf NMI events using Julien's perf patch-set [1]. Have a
> >>>> look at the patch here [2].
> >>>>
> >>>> [1] https://patchwork.kernel.org/cover/11047407/
> >>>> [2]
> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2020-May/7322
> >>>> 27.html
> >>>>
> >>>> -Sumit
> >>>>
> >>>>> Perf NMI has been test by dd if=/dev/urandom of=/dev/null like the
> >>>>> link [2] did.
> >>>>>
> >>>>> [1] https://lkml.org/lkml/2019/1/31/535
> >>>>> [2] https://www.linaro.org/blog/debugging-arm-kernels-using-nmifiq
> >>>>>
> >>>>>
> >>>>> Lecopzer Chen (3):
> >>>>> arm_pmu: Add support for perf NMI interrupts registration
> >>>>> arm64: perf: Support NMI context for perf event ISR
> >>>>> arm64: Kconfig: Add support for the Perf NMI
> >>>>>
> >>>>> arch/arm64/Kconfig | 10 +++++++
> >>>>> arch/arm64/kernel/perf_event.c | 36 ++++++++++++++++++------
> >>>>> drivers/perf/arm_pmu.c | 51
> ++++++++++++++++++++++++++++++----
> >>>>> include/linux/perf/arm_pmu.h | 6 ++++
> >>>>> 4 files changed, 88 insertions(+), 15 deletions(-)
> >>>>>
> >>>>> --
> >>>>> 2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Florian Fainelli @ 2020-05-21 2:45 UTC (permalink / raw)
To: Arnd Bergmann, Russell King - ARM Linux admin
Cc: Doug Berger, Stephen Boyd, Kevin Cernekee, Mike Rapoport,
Gregory Fong, Linux ARM
In-Reply-To: <CAK8P3a32gDzqLBeBs8CtT9fhRncQNsJ0nrN=2Ws4DAWe3nOCZA@mail.gmail.com>
On 5/19/2020 1:42 PM, Arnd Bergmann wrote:
> On Tue, May 19, 2020 at 6:54 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
>> On Tue, May 19, 2020 at 05:32:52PM +0200, Arnd Bergmann wrote:
>>> On Tue, May 19, 2020 at 5:27 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
>>>> On Tue, May 19, 2020 at 04:04:52PM +0100, Russell King - ARM Linux admin wrote:
>>>>> There are cases where the reason to use sparsemem is not an optional
>>>>> one but is out of necessity - they require the page array to be split
>>>>> up in order to boot successfully.
>>>>>
>>>>> With that in mind, flatmem becomes an "optimisation" over sparsemem.
>>>>
>>>> At the moment, there are three platforms that enable SPARSEMEM: ARCH_EP93XX,
>>>> ARCH_RPC and ARCH_SA1100. All the rest have FLATMEM implcitly selected.
>>>>
>>>> I do not intend to change that, I am only going add an ability to select
>>>> the memory model for ARCH_MULTIPLATFORM.
>>>>
>>>> I'll respin the series on the list before adding the patches to the
>>>> patch system.
>>>
>>> I think we'll make EP93xx part of multiplatform at some point, IIRC
>>> only the missing clock driver is stopping us at the moment, and I already
>>> discussed with Linus Walleij how that can be done.
>>>
>>> My guess is that ep93xx is one platform on which sparsemem is
>>> just an optimization to reduce the initial memory consumption, but
>>> we should verify that when we get there.
>>
>> When you have a platform where the memory is segmented into separate
>> blocks widely spaced, sparsemem is not an optimisation. For example,
>> If you have four blocks spaced across 1GB, that requires about
>> 256Ki struct page's. Assuming 32 byte struct page, that requires 8MiB
>> of contiguous memory.
>
> I checked the datasheet: ep93xx has four chip-selects, each of them
> with their own 256MB memory area. Most boards we support use only
> the last chipselect, but those that have more than one would waste
> up to 2MB per additional memory chip, which is not nice but doesn't
> make it a hard requirement as long as the kernel can fit into the first one.
>
> However, the chips has a second problem: depending on the
> specific memory configuration, only every other 2/4/8MB within
> that range may actually be used, so the mem_map[] array would
> double its size in practice and (worse) the kernel would likely
> not fit into the first section without sparsemem.
>
> This means we should indeed treat it as a requirement for ep93xx.
That is already captured with the select ARCH_SPARSEMEM_ENABLE or the
ARCH_EP93XX entry.
Should we just make it possible for multi platform users to override the
memory model in their configuration file and later we just default
ARCH_MULTI_V7 to sparsemem?
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 3/3] arm64: Expose FAR_EL1 tag bits in sigcontext
From: Peter Collingbourne @ 2020-05-21 2:29 UTC (permalink / raw)
To: Catalin Marinas, Evgenii Stepanov, Kostya Serebryany,
Vincenzo Frascino, Dave Martin, Will Deacon, Oleg Nesterov,
Eric W. Biederman
Cc: Andrey Konovalov, Kevin Brodsky, Peter Collingbourne, Linux ARM,
Richard Henderson
In-Reply-To: <20200521022943.195898-1-pcc@google.com>
The kernel currently clears the tag bits (i.e. bits 56-63) in the fault
address exposed via siginfo.si_addr and sigcontext.fault_address. However,
the tag bits may be needed by tools in order to accurately diagnose
memory errors, such as HWASan [1] or future tools based on the Memory
Tagging Extension (MTE).
We should not stop clearing these bits in the existing fault address fields,
because there may be existing userspace applications that are expecting the tag
bits to be cleared. Instead, create a fault_addr_top_byte_context in sigcontext
(similar to the existing esr_context), and store the tag bits of FAR_EL1 there.
[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
Signed-off-by: Peter Collingbourne <pcc@google.com>
---
v6:
- move fault address and fault code into the kernel_siginfo data structure
- split the patch in three since it was getting large and now has
generic and arch-specific parts
v5:
- add padding to fault_addr_top_byte_context in order to ensure the correct
size and preserve sp alignment
v4:
- expose only the tag bits in the context instead of the entire FAR_EL1
- remove mention of the new context from the sigcontext.__reserved[] note
v3:
- add documentation to tagged-pointers.rst
- update comments in sigcontext.h
v2:
- revert changes to hw_breakpoint.c
- rename set_thread_esr to set_thread_far_esr
Documentation/arm64/tagged-pointers.rst | 17 ++++++++++------
arch/arm64/include/asm/signal.h | 3 +++
arch/arm64/include/asm/traps.h | 4 ++--
arch/arm64/include/uapi/asm/sigcontext.h | 24 +++++++++++++++++------
arch/arm64/kernel/debug-monitors.c | 2 +-
arch/arm64/kernel/ptrace.c | 2 +-
arch/arm64/kernel/signal.c | 25 ++++++++++++++++++++++++
arch/arm64/kernel/traps.c | 10 ++++++----
arch/arm64/mm/fault.c | 8 ++++----
9 files changed, 71 insertions(+), 24 deletions(-)
diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst
index eab4323609b9..c6e9592a9dea 100644
--- a/Documentation/arm64/tagged-pointers.rst
+++ b/Documentation/arm64/tagged-pointers.rst
@@ -53,12 +53,17 @@ visibility.
Preserving tags
---------------
-Non-zero tags are not preserved when delivering signals. This means that
-signal handlers in applications making use of tags cannot rely on the
-tag information for user virtual addresses being maintained for fields
-inside siginfo_t. One exception to this rule is for signals raised in
-response to watchpoint debug exceptions, where the tag information will
-be preserved.
+Non-zero tags are not preserved in the fault address fields
+siginfo.si_addr or sigcontext.fault_address when delivering
+signals. This means that signal handlers in applications making use
+of tags cannot rely on the tag information for user virtual addresses
+being maintained in these fields. One exception to this rule is for
+signals raised in response to watchpoint debug exceptions, where the
+tag information will be preserved.
+
+The fault address tag is preserved in the fault_addr_top_byte field of
+the signal frame record fault_addr_top_byte_context, which is present
+for signals raised in response to data aborts and instruction aborts.
The architecture prevents the use of a tagged PC, so the upper byte will
be set to a sign-extension of bit 55 on exception return.
diff --git a/arch/arm64/include/asm/signal.h b/arch/arm64/include/asm/signal.h
index f5c001b0a125..c80eb3b3ea40 100644
--- a/arch/arm64/include/asm/signal.h
+++ b/arch/arm64/include/asm/signal.h
@@ -9,6 +9,9 @@ struct arch_private_siginfo {
/* FAR_EL1 value */
unsigned long fault_address;
+ /* Mask of defined bits in the top byte of FAR_EL1 */
+ unsigned char fault_address_top_byte_mask;
+
/* Sanitized ESR_EL1 value, or FSR/syscall number in compat mode */
unsigned long error_code;
};
diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
index 5ed5be5347e6..981b930b1e6f 100644
--- a/arch/arm64/include/asm/traps.h
+++ b/arch/arm64/include/asm/traps.h
@@ -27,8 +27,8 @@ void unregister_undef_hook(struct undef_hook *hook);
void force_signal_inject(int signal, int code, unsigned long address);
void arm64_notify_segfault(unsigned long addr);
void arm64_force_sig_fault(int signo, int code, void __user *addr,
- unsigned long far, unsigned long esr,
- const char *str);
+ unsigned long far, unsigned char far_tb_mask,
+ unsigned long esr, const char *str);
void arm64_force_sig_mceerr(int code, void __user *addr, short lsb,
unsigned long far, unsigned long esr,
const char *str);
diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
index 8b0ebce92427..6ce5e1bb7efd 100644
--- a/arch/arm64/include/uapi/asm/sigcontext.h
+++ b/arch/arm64/include/uapi/asm/sigcontext.h
@@ -44,11 +44,12 @@ struct sigcontext {
*
* 0x210 fpsimd_context
* 0x10 esr_context
+ * 0x10 fault_addr_top_byte_context
* 0x8a0 sve_context (vl <= 64) (optional)
* 0x20 extra_context (optional)
* 0x10 terminator (null _aarch64_ctx)
*
- * 0x510 (reserved for future allocation)
+ * 0x500 (reserved for future allocation)
*
* New records that can exceed this space need to be opt-in for userspace, so
* that an expanded signal frame is not generated unexpectedly. The mechanism
@@ -94,17 +95,28 @@ struct esr_context {
__u64 esr;
};
+/* Top byte of fault address (normally not exposed via si_addr) */
+#define FAULT_ADDR_TOP_BYTE_MAGIC 0x46544201
+
+struct fault_addr_top_byte_context {
+ struct _aarch64_ctx head;
+ __u8 flags;
+ __u8 fault_addr_top_byte;
+ __u8 fault_addr_top_byte_mask;
+ __u8 __reserved[5];
+};
+
/*
* extra_context: describes extra space in the signal frame for
* additional structures that don't fit in sigcontext.__reserved[].
*
* Note:
*
- * 1) fpsimd_context, esr_context and extra_context must be placed in
- * sigcontext.__reserved[] if present. They cannot be placed in the
- * extra space. Any other record can be placed either in the extra
- * space or in sigcontext.__reserved[], unless otherwise specified in
- * this file.
+ * 1) fpsimd_context, esr_context, fault_addr_top_byte_context and
+ * extra_context must be placed in sigcontext.__reserved[] if present.
+ * They cannot be placed in the extra space. Any other record can be
+ * placed either in the extra space or in sigcontext.__reserved[],
+ * unless otherwise specified in this file.
*
* 2) There must not be more than one extra_context.
*
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 498e6393b2ca..575a907cd4fc 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -232,7 +232,7 @@ static void send_user_sigtrap(int si_code)
local_irq_enable();
arm64_force_sig_fault(SIGTRAP, si_code,
- (void __user *)instruction_pointer(regs), 0, 0,
+ (void __user *)instruction_pointer(regs), 0, 0, 0,
"User debug trap");
}
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 51bb8bcaf24b..9b20284df88b 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -198,7 +198,7 @@ static void ptrace_hbptriggered(struct perf_event *bp,
}
#endif
arm64_force_sig_fault(SIGTRAP, TRAP_HWBKPT,
- (void __user *)(bkpt->trigger), 0, 0,
+ (void __user *)(bkpt->trigger), 0, 0, 0,
desc);
}
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 10d7e9832a89..f6783de54412 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -55,6 +55,7 @@ struct rt_sigframe_user_layout {
unsigned long fpsimd_offset;
unsigned long esr_offset;
+ unsigned long ftb_offset;
unsigned long sve_offset;
unsigned long extra_offset;
unsigned long end_offset;
@@ -383,6 +384,7 @@ static int parse_user_sigframe(struct user_ctxs *user,
break;
case ESR_MAGIC:
+ case FAULT_ADDR_TOP_BYTE_MAGIC:
/* ignore */
break;
@@ -582,6 +584,14 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
sizeof(struct esr_context));
if (err)
return err;
+ }
+
+ if (add_all || info->arch.fault_address_top_byte_mask) {
+ err = sigframe_alloc(
+ user, &user->ftb_offset,
+ sizeof(struct fault_addr_top_byte_context));
+ if (err)
+ return err;
}
if (system_supports_sve()) {
@@ -644,6 +654,21 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user,
__put_user_error(info->arch.error_code, &esr_ctx->esr, err);
}
+ if (err == 0 && user->ftb_offset) {
+ struct fault_addr_top_byte_context __user *ftb_ctx =
+ apply_user_offset(user, user->ftb_offset);
+
+ __put_user_error(FAULT_ADDR_TOP_BYTE_MAGIC,
+ &ftb_ctx->head.magic, err);
+ __put_user_error(sizeof(*ftb_ctx), &ftb_ctx->head.size, err);
+ __put_user_error(0, &ftb_ctx->flags, err);
+ __put_user_error((info->arch.fault_address >> 56) &
+ info->arch.fault_address_top_byte_mask,
+ &ftb_ctx->fault_addr_top_byte, err);
+ __put_user_error(info->arch.fault_address_top_byte_mask,
+ &ftb_ctx->fault_addr_top_byte_mask, err);
+ }
+
/* Scalable Vector Extension state, if present */
if (system_supports_sve() && err == 0 && user->sve_offset) {
struct sve_context __user *sve_ctx =
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 4545fe067ea9..8154f2562f74 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -295,8 +295,8 @@ static unsigned long esr_to_error_code(unsigned long esr, unsigned long far)
}
void arm64_force_sig_fault(int signo, int code, void __user *addr,
- unsigned long far, unsigned long esr,
- const char *str)
+ unsigned long far, unsigned char far_tb_mask,
+ unsigned long esr, const char *str)
{
arm64_show_signal(signo, esr, str);
if (signo == SIGKILL) {
@@ -309,6 +309,7 @@ void arm64_force_sig_fault(int signo, int code, void __user *addr,
info.si_code = code;
info.si_addr = addr;
info.arch.fault_address = far;
+ info.arch.fault_address_top_byte_mask = far_tb_mask;
info.arch.error_code = esr_to_error_code(esr, far);
force_sig_info(&info);
}
@@ -329,6 +330,7 @@ void arm64_force_sig_mceerr(int code, void __user *addr, short lsb,
info.si_addr = addr;
info.si_addr_lsb = lsb;
info.arch.fault_address = far;
+ info.arch.fault_address_top_byte_mask = 0xff;
info.arch.error_code = esr_to_error_code(esr, far);
force_sig_info(&info);
}
@@ -346,7 +348,7 @@ void arm64_notify_die(const char *str, struct pt_regs *regs,
{
if (user_mode(regs)) {
WARN_ON(regs != current_pt_regs());
- arm64_force_sig_fault(signo, sicode, addr, 0, esr, str);
+ arm64_force_sig_fault(signo, sicode, addr, 0, 0, esr, str);
} else {
die(str, regs, esr);
}
@@ -893,7 +895,7 @@ void bad_el0_sync(struct pt_regs *regs, int reason, unsigned int esr)
{
void __user *pc = (void __user *)instruction_pointer(regs);
- arm64_force_sig_fault(SIGILL, ILL_ILLOPC, pc, 0, esr,
+ arm64_force_sig_fault(SIGILL, ILL_ILLOPC, pc, 0, 0, esr,
"Bad EL0 synchronous exception");
}
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a7bada1392b3..1ba95f308c10 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -332,7 +332,7 @@ static void do_bad_area(unsigned long far, unsigned int esr,
if (user_mode(regs)) {
const struct fault_info *inf = esr_to_fault_info(esr);
arm64_force_sig_fault(inf->sig, inf->code, (void __user *)addr,
- far, esr, inf->name);
+ far, 0xff, esr, inf->name);
} else {
__do_kernel_fault(addr, esr, regs);
}
@@ -520,8 +520,8 @@ static int __kprobes do_page_fault(unsigned long far, unsigned int esr,
* We had some memory, but were unable to successfully fix up
* this page fault.
*/
- arm64_force_sig_fault(SIGBUS, BUS_ADRERR, (void __user *)addr, far, esr,
- inf->name);
+ arm64_force_sig_fault(SIGBUS, BUS_ADRERR, (void __user *)addr,
+ far, 0xff, esr, inf->name);
} else if (fault & (VM_FAULT_HWPOISON_LARGE | VM_FAULT_HWPOISON)) {
unsigned int lsb;
@@ -538,7 +538,7 @@ static int __kprobes do_page_fault(unsigned long far, unsigned int esr,
*/
arm64_force_sig_fault(SIGSEGV,
fault == VM_FAULT_BADACCESS ? SEGV_ACCERR : SEGV_MAPERR,
- (void __user *)addr, far, esr,
+ (void __user *)addr, far, 0xff, esr,
inf->name);
}
--
2.26.2.761.g0e0b3e54be-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 2/3] arm64: Move fault address and fault code into kernel_siginfo
From: Peter Collingbourne @ 2020-05-21 2:29 UTC (permalink / raw)
To: Catalin Marinas, Evgenii Stepanov, Kostya Serebryany,
Vincenzo Frascino, Dave Martin, Will Deacon, Oleg Nesterov,
Eric W. Biederman
Cc: Andrey Konovalov, Kevin Brodsky, Peter Collingbourne, Linux ARM,
Richard Henderson
In-Reply-To: <20200521022943.195898-1-pcc@google.com>
Previously this data was being stored in thread_struct, which is
error-prone because the data is associated with the signal itself
and not the task, and as a result it could get out of sync with the
signal that is currently being delivered. To avoid this problem,
move the fields to kernel_siginfo using the newly-introduced generic
support for doing so.
The new fields store the raw FAR_EL1 and ESR_EL1 values instead of
the cooked ones as we were doing before. For FAR_EL1 this will be
necessary in order to expose the high bits of FAR_EL1 in sigcontext
in an upcoming change. Do the same for ESR_EL1 for consistency and
to make the code less error-prone.
While here, fix an apparent compat bug where, when delivering a
SIGILL signal in response to an invalid syscall, the syscall number
was being interpreted as an ESR_EL1 value and translated into an
FSR before being stored in sigcontext.error_code, rather than being
stored in error_code directly, as was the intention (and the behaviour
of the code in arch/arm). This is achieved by moving the error_code
translation early so that the syscall number can avoid it.
Signed-off-by: Peter Collingbourne <pcc@google.com>
---
arch/arm64/include/asm/exception.h | 2 +-
arch/arm64/include/asm/processor.h | 2 -
arch/arm64/include/asm/signal.h | 16 ++++
arch/arm64/include/asm/traps.h | 8 +-
arch/arm64/kernel/debug-monitors.c | 4 +-
arch/arm64/kernel/entry-common.c | 2 -
arch/arm64/kernel/probes/uprobes.c | 18 ++---
arch/arm64/kernel/ptrace.c | 2 +-
arch/arm64/kernel/signal.c | 17 +++--
arch/arm64/kernel/signal32.c | 15 ++--
arch/arm64/kernel/sys_compat.c | 9 ++-
arch/arm64/kernel/traps.c | 117 ++++++++++++++++++++++++-----
arch/arm64/mm/fault.c | 111 +++++++--------------------
13 files changed, 183 insertions(+), 140 deletions(-)
create mode 100644 arch/arm64/include/asm/signal.h
diff --git a/arch/arm64/include/asm/exception.h b/arch/arm64/include/asm/exception.h
index 7a6e81ca23a8..90e772d9b2cd 100644
--- a/arch/arm64/include/asm/exception.h
+++ b/arch/arm64/include/asm/exception.h
@@ -32,7 +32,7 @@ static inline u32 disr_to_esr(u64 disr)
}
asmlinkage void enter_from_user_mode(void);
-void do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs);
+void do_mem_abort(unsigned long far, unsigned int esr, struct pt_regs *regs);
void do_undefinstr(struct pt_regs *regs);
asmlinkage void bad_mode(struct pt_regs *regs, int reason, unsigned int esr);
void do_debug_exception(unsigned long addr_if_watchpoint, unsigned int esr,
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 240fe5e5b720..b326bfbcea62 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -144,8 +144,6 @@ struct thread_struct {
void *sve_state; /* SVE registers, if any */
unsigned int sve_vl; /* SVE vector length */
unsigned int sve_vl_onexec; /* SVE vl after next exec */
- unsigned long fault_address; /* fault info */
- unsigned long fault_code; /* ESR_EL1 value */
struct debug_info debug; /* debugging */
#ifdef CONFIG_ARM64_PTR_AUTH
struct ptrauth_keys_user keys_user;
diff --git a/arch/arm64/include/asm/signal.h b/arch/arm64/include/asm/signal.h
new file mode 100644
index 000000000000..f5c001b0a125
--- /dev/null
+++ b/arch/arm64/include/asm/signal.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM64_SIGNAL_H
+#define _ASM_ARM64_SIGNAL_H
+
+#include <uapi/asm/signal.h>
+
+#define __ARCH_HAS_PRIVATE_SIGINFO
+struct arch_private_siginfo {
+ /* FAR_EL1 value */
+ unsigned long fault_address;
+
+ /* Sanitized ESR_EL1 value, or FSR/syscall number in compat mode */
+ unsigned long error_code;
+};
+
+#endif
diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
index cee5928e1b7d..5ed5be5347e6 100644
--- a/arch/arm64/include/asm/traps.h
+++ b/arch/arm64/include/asm/traps.h
@@ -26,8 +26,12 @@ void register_undef_hook(struct undef_hook *hook);
void unregister_undef_hook(struct undef_hook *hook);
void force_signal_inject(int signal, int code, unsigned long address);
void arm64_notify_segfault(unsigned long addr);
-void arm64_force_sig_fault(int signo, int code, void __user *addr, const char *str);
-void arm64_force_sig_mceerr(int code, void __user *addr, short lsb, const char *str);
+void arm64_force_sig_fault(int signo, int code, void __user *addr,
+ unsigned long far, unsigned long esr,
+ const char *str);
+void arm64_force_sig_mceerr(int code, void __user *addr, short lsb,
+ unsigned long far, unsigned long esr,
+ const char *str);
void arm64_force_sig_ptrace_errno_trap(int errno, void __user *addr, const char *str);
/*
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 48222a4760c2..498e6393b2ca 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -232,8 +232,8 @@ static void send_user_sigtrap(int si_code)
local_irq_enable();
arm64_force_sig_fault(SIGTRAP, si_code,
- (void __user *)instruction_pointer(regs),
- "User debug trap");
+ (void __user *)instruction_pointer(regs), 0, 0,
+ "User debug trap");
}
static int single_step_handler(unsigned long unused, unsigned int esr,
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index c839b5bf1904..045b4f518836 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -22,7 +22,6 @@ static void notrace el1_abort(struct pt_regs *regs, unsigned long esr)
unsigned long far = read_sysreg(far_el1);
local_daif_inherit(regs);
- far = untagged_addr(far);
do_mem_abort(far, esr, regs);
}
NOKPROBE_SYMBOL(el1_abort);
@@ -104,7 +103,6 @@ static void notrace el0_da(struct pt_regs *regs, unsigned long esr)
user_exit_irqoff();
local_daif_restore(DAIF_PROCCTX);
- far = untagged_addr(far);
do_mem_abort(far, esr, regs);
}
NOKPROBE_SYMBOL(el0_da);
diff --git a/arch/arm64/kernel/probes/uprobes.c b/arch/arm64/kernel/probes/uprobes.c
index a412d8edbcd2..5bbcd2e813f0 100644
--- a/arch/arm64/kernel/probes/uprobes.c
+++ b/arch/arm64/kernel/probes/uprobes.c
@@ -9,8 +9,6 @@
#include "decode-insn.h"
-#define UPROBE_INV_FAULT_CODE UINT_MAX
-
void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
void *src, unsigned long len)
{
@@ -63,9 +61,6 @@ int arch_uprobe_pre_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
{
struct uprobe_task *utask = current->utask;
- /* Initialize with an invalid fault code to detect if ol insn trapped */
- current->thread.fault_code = UPROBE_INV_FAULT_CODE;
-
/* Instruction points to execute ol */
instruction_pointer_set(regs, utask->xol_vaddr);
@@ -78,7 +73,7 @@ int arch_uprobe_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
{
struct uprobe_task *utask = current->utask;
- WARN_ON_ONCE(current->thread.fault_code != UPROBE_INV_FAULT_CODE);
+ WARN_ON_ONCE(arch_uprobe_xol_was_trapped(current));
/* Instruction points to execute next to breakpoint address */
instruction_pointer_set(regs, utask->vaddr + 4);
@@ -89,13 +84,16 @@ int arch_uprobe_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
}
bool arch_uprobe_xol_was_trapped(struct task_struct *t)
{
+ struct sigqueue *q;
+
/*
* Between arch_uprobe_pre_xol and arch_uprobe_post_xol, if an xol
- * insn itself is trapped, then detect the case with the help of
- * invalid fault code which is being set in arch_uprobe_pre_xol
+ * insn itself is trapped, then detect the case by checking for
+ * non-zero esr_el1 in the task's pending signals.
*/
- if (t->thread.fault_code != UPROBE_INV_FAULT_CODE)
- return true;
+ list_for_each_entry (q, &t->pending.list, list)
+ if (q->info.arch.error_code)
+ return true;
return false;
}
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index b3d3005d9515..51bb8bcaf24b 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -198,7 +198,7 @@ static void ptrace_hbptriggered(struct perf_event *bp,
}
#endif
arm64_force_sig_fault(SIGTRAP, TRAP_HWBKPT,
- (void __user *)(bkpt->trigger),
+ (void __user *)(bkpt->trigger), 0, 0,
desc);
}
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 339882db5a91..10d7e9832a89 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -566,6 +566,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
* of the task.
*/
static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
+ struct kernel_siginfo *info,
bool add_all)
{
int err;
@@ -576,7 +577,7 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
return err;
/* fault information, if valid */
- if (add_all || current->thread.fault_code) {
+ if (add_all || info->arch.error_code) {
err = sigframe_alloc(user, &user->esr_offset,
sizeof(struct esr_context));
if (err)
@@ -605,7 +606,8 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
}
static int setup_sigframe(struct rt_sigframe_user_layout *user,
- struct pt_regs *regs, sigset_t *set)
+ struct pt_regs *regs, sigset_t *set,
+ struct kernel_siginfo *info)
{
int i, err = 0;
struct rt_sigframe __user *sf = user->sigframe;
@@ -621,7 +623,8 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user,
__put_user_error(regs->pc, &sf->uc.uc_mcontext.pc, err);
__put_user_error(regs->pstate, &sf->uc.uc_mcontext.pstate, err);
- __put_user_error(current->thread.fault_address, &sf->uc.uc_mcontext.fault_address, err);
+ __put_user_error(untagged_addr(info->arch.fault_address),
+ &sf->uc.uc_mcontext.fault_address, err);
err |= __copy_to_user(&sf->uc.uc_sigmask, set, sizeof(*set));
@@ -638,7 +641,7 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user,
__put_user_error(ESR_MAGIC, &esr_ctx->head.magic, err);
__put_user_error(sizeof(*esr_ctx), &esr_ctx->head.size, err);
- __put_user_error(current->thread.fault_code, &esr_ctx->esr, err);
+ __put_user_error(info->arch.error_code, &esr_ctx->esr, err);
}
/* Scalable Vector Extension state, if present */
@@ -701,7 +704,7 @@ static int get_sigframe(struct rt_sigframe_user_layout *user,
int err;
init_user_layout(user);
- err = setup_sigframe_layout(user, false);
+ err = setup_sigframe_layout(user, &ksig->info, false);
if (err)
return err;
@@ -758,7 +761,7 @@ static int setup_rt_frame(int usig, struct ksignal *ksig, sigset_t *set,
__put_user_error(NULL, &frame->uc.uc_link, err);
err |= __save_altstack(&frame->uc.uc_stack, regs->sp);
- err |= setup_sigframe(&user, regs, set);
+ err |= setup_sigframe(&user, regs, set, &ksig->info);
if (err == 0) {
setup_return(regs, &ksig->ka, &user, usig);
if (ksig->ka.sa.sa_flags & SA_SIGINFO) {
@@ -958,7 +961,7 @@ void __init minsigstksz_setup(void)
* If this fails, SIGFRAME_MAXSZ needs to be enlarged. It won't
* be big enough, but it's our best guess:
*/
- if (WARN_ON(setup_sigframe_layout(&user, true)))
+ if (WARN_ON(setup_sigframe_layout(&user, 0, true)))
return;
signal_minsigstksz = sigframe_size(&user) +
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 82feca6f7052..b302689b6651 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -37,8 +37,6 @@ struct compat_vfp_sigframe {
#define VFP_MAGIC 0x56465001
#define VFP_STORAGE_SIZE sizeof(struct compat_vfp_sigframe)
-#define FSR_WRITE_SHIFT (11)
-
struct compat_aux_sigframe {
struct compat_vfp_sigframe vfp;
@@ -384,7 +382,8 @@ static void compat_setup_return(struct pt_regs *regs, struct k_sigaction *ka,
}
static int compat_setup_sigframe(struct compat_sigframe __user *sf,
- struct pt_regs *regs, sigset_t *set)
+ struct pt_regs *regs, sigset_t *set,
+ struct kernel_siginfo *info)
{
struct compat_aux_sigframe __user *aux;
unsigned long psr = pstate_to_compat_psr(regs->pstate);
@@ -409,10 +408,8 @@ static int compat_setup_sigframe(struct compat_sigframe __user *sf,
__put_user_error(psr, &sf->uc.uc_mcontext.arm_cpsr, err);
__put_user_error((compat_ulong_t)0, &sf->uc.uc_mcontext.trap_no, err);
- /* set the compat FSR WnR */
- __put_user_error(!!(current->thread.fault_code & ESR_ELx_WNR) <<
- FSR_WRITE_SHIFT, &sf->uc.uc_mcontext.error_code, err);
- __put_user_error(current->thread.fault_address, &sf->uc.uc_mcontext.fault_address, err);
+ __put_user_error(info->arch.error_code, &sf->uc.uc_mcontext.error_code, err);
+ __put_user_error(info->arch.fault_address, &sf->uc.uc_mcontext.fault_address, err);
__put_user_error(set->sig[0], &sf->uc.uc_mcontext.oldmask, err);
err |= put_sigset_t(&sf->uc.uc_sigmask, set);
@@ -447,7 +444,7 @@ int compat_setup_rt_frame(int usig, struct ksignal *ksig,
err |= __compat_save_altstack(&frame->sig.uc.uc_stack, regs->compat_sp);
- err |= compat_setup_sigframe(&frame->sig, regs, set);
+ err |= compat_setup_sigframe(&frame->sig, regs, set, &ksig->info);
if (err == 0) {
compat_setup_return(regs, &ksig->ka, frame->sig.retcode, frame, usig);
@@ -471,7 +468,7 @@ int compat_setup_frame(int usig, struct ksignal *ksig, sigset_t *set,
__put_user_error(0x5ac3c35a, &frame->uc.uc_flags, err);
- err |= compat_setup_sigframe(frame, regs, set);
+ err |= compat_setup_sigframe(frame, regs, set, &ksig->info);
if (err == 0)
compat_setup_return(regs, &ksig->ka, frame->retcode, frame, usig);
diff --git a/arch/arm64/kernel/sys_compat.c b/arch/arm64/kernel/sys_compat.c
index 3c18c2454089..d7a0b93a8d9f 100644
--- a/arch/arm64/kernel/sys_compat.c
+++ b/arch/arm64/kernel/sys_compat.c
@@ -69,6 +69,7 @@ do_compat_cache_op(unsigned long start, unsigned long end, int flags)
long compat_arm_syscall(struct pt_regs *regs, int scno)
{
void __user *addr;
+ struct kernel_siginfo info;
switch (scno) {
/*
@@ -114,7 +115,11 @@ long compat_arm_syscall(struct pt_regs *regs, int scno)
addr = (void __user *)instruction_pointer(regs) -
(compat_thumb_mode(regs) ? 2 : 4);
- arm64_notify_die("Oops - bad compat syscall(2)", regs,
- SIGILL, ILL_ILLTRP, addr, scno);
+ clear_siginfo(&info);
+ info.si_signo = SIGILL;
+ info.si_code = ILL_ILLTRP;
+ info.si_addr = addr;
+ info.arch.error_code = scno;
+ force_sig_info(&info);
return 0;
}
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index cf402be5c573..4545fe067ea9 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -44,6 +44,8 @@
#include <asm/system_misc.h>
#include <asm/sysreg.h>
+#define FSR_WRITE_SHIFT (11)
+
static const char *handler[]= {
"Synchronous Abort",
"IRQ",
@@ -209,12 +211,11 @@ void die(const char *str, struct pt_regs *regs, int err)
do_exit(SIGSEGV);
}
-static void arm64_show_signal(int signo, const char *str)
+static void arm64_show_signal(int signo, unsigned long esr, const char *str)
{
static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
DEFAULT_RATELIMIT_BURST);
struct task_struct *tsk = current;
- unsigned int esr = tsk->thread.fault_code;
struct pt_regs *regs = task_pt_regs(tsk);
/* Leave if the signal won't be shown */
@@ -225,7 +226,7 @@ static void arm64_show_signal(int signo, const char *str)
pr_info("%s[%d]: unhandled exception: ", tsk->comm, task_pid_nr(tsk));
if (esr)
- pr_cont("%s, ESR 0x%08x, ", esr_get_class_string(esr), esr);
+ pr_cont("%s, ESR 0x%08lx, ", esr_get_class_string(esr), esr);
pr_cont("%s", str);
print_vma_addr(KERN_CONT " in ", regs->pc);
@@ -233,42 +234,121 @@ static void arm64_show_signal(int signo, const char *str)
__show_regs(regs);
}
+static unsigned long esr_to_error_code(unsigned long esr, unsigned long far)
+{
+ /*
+ * If the faulting address is in the kernel, we must sanitize the ESR.
+ * From userspace's point of view, kernel-only mappings don't exist
+ * at all, so we report them as level 0 translation faults.
+ * (This is not quite the way that "no mapping there at all" behaves:
+ * an alignment fault not caused by the memory type would take
+ * precedence over translation fault for a real access to empty
+ * space. Unfortunately we can't easily distinguish "alignment fault
+ * not caused by memory type" from "alignment fault caused by memory
+ * type", so we ignore this wrinkle and just return the translation
+ * fault.)
+ */
+ if (!is_ttbr0_addr(untagged_addr(far))) {
+ switch (ESR_ELx_EC(esr)) {
+ case ESR_ELx_EC_DABT_LOW:
+ /*
+ * These bits provide only information about the
+ * faulting instruction, which userspace knows already.
+ * We explicitly clear bits which are architecturally
+ * RES0 in case they are given meanings in future.
+ * We always report the ESR as if the fault was taken
+ * to EL1 and so ISV and the bits in ISS[23:14] are
+ * clear. (In fact it always will be a fault to EL1.)
+ */
+ esr &= ESR_ELx_EC_MASK | ESR_ELx_IL |
+ ESR_ELx_CM | ESR_ELx_WNR;
+ esr |= ESR_ELx_FSC_FAULT;
+ break;
+ case ESR_ELx_EC_IABT_LOW:
+ /*
+ * Claim a level 0 translation fault.
+ * All other bits are architecturally RES0 for faults
+ * reported with that DFSC value, so we clear them.
+ */
+ esr &= ESR_ELx_EC_MASK | ESR_ELx_IL;
+ esr |= ESR_ELx_FSC_FAULT;
+ break;
+ default:
+ /*
+ * This should never happen (entry.S only brings us
+ * into this code for insn and data aborts from a lower
+ * exception level). Fail safe by not providing an ESR
+ * context record at all.
+ */
+ WARN(1, "ESR 0x%x is not DABT or IABT from EL0\n", esr);
+ esr = 0;
+ break;
+ }
+ }
+
+ if (is_compat_task()) {
+ /* Use the compat FSR WnR */
+ return !!(esr & ESR_ELx_WNR) << FSR_WRITE_SHIFT;
+ }
+
+ return esr;
+}
+
void arm64_force_sig_fault(int signo, int code, void __user *addr,
+ unsigned long far, unsigned long esr,
const char *str)
{
- arm64_show_signal(signo, str);
- if (signo == SIGKILL)
+ arm64_show_signal(signo, esr, str);
+ if (signo == SIGKILL) {
force_sig(SIGKILL);
- else
- force_sig_fault(signo, code, addr);
+ } else {
+ struct kernel_siginfo info;
+ clear_siginfo(&info);
+ info.si_signo = signo;
+ info.si_errno = 0;
+ info.si_code = code;
+ info.si_addr = addr;
+ info.arch.fault_address = far;
+ info.arch.error_code = esr_to_error_code(esr, far);
+ force_sig_info(&info);
+ }
}
void arm64_force_sig_mceerr(int code, void __user *addr, short lsb,
+ unsigned long far, unsigned long esr,
const char *str)
{
- arm64_show_signal(SIGBUS, str);
- force_sig_mceerr(code, addr, lsb);
+ struct kernel_siginfo info;
+
+ arm64_show_signal(SIGBUS, esr, str);
+
+ clear_siginfo(&info);
+ info.si_signo = SIGBUS;
+ info.si_errno = 0;
+ info.si_code = code;
+ info.si_addr = addr;
+ info.si_addr_lsb = lsb;
+ info.arch.fault_address = far;
+ info.arch.error_code = esr_to_error_code(esr, far);
+ force_sig_info(&info);
}
void arm64_force_sig_ptrace_errno_trap(int errno, void __user *addr,
const char *str)
{
- arm64_show_signal(SIGTRAP, str);
+ arm64_show_signal(SIGTRAP, 0, str);
force_sig_ptrace_errno_trap(errno, addr);
}
void arm64_notify_die(const char *str, struct pt_regs *regs,
int signo, int sicode, void __user *addr,
- int err)
+ int esr)
{
if (user_mode(regs)) {
WARN_ON(regs != current_pt_regs());
- current->thread.fault_address = 0;
- current->thread.fault_code = err;
-
- arm64_force_sig_fault(signo, sicode, addr, str);
+ arm64_force_sig_fault(signo, sicode, addr, 0, esr, str);
} else {
- die(str, regs, err);
+ die(str, regs, esr);
}
}
@@ -813,10 +893,7 @@ void bad_el0_sync(struct pt_regs *regs, int reason, unsigned int esr)
{
void __user *pc = (void __user *)instruction_pointer(regs);
- current->thread.fault_address = 0;
- current->thread.fault_code = esr;
-
- arm64_force_sig_fault(SIGILL, ILL_ILLOPC, pc,
+ arm64_force_sig_fault(SIGILL, ILL_ILLOPC, pc, 0, esr,
"Bad EL0 synchronous exception");
}
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index c9cedc0432d2..a7bada1392b3 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -41,7 +41,7 @@
#include <asm/traps.h>
struct fault_info {
- int (*fn)(unsigned long addr, unsigned int esr,
+ int (*fn)(unsigned long far, unsigned int esr,
struct pt_regs *regs);
int sig;
int code;
@@ -320,75 +320,19 @@ static void __do_kernel_fault(unsigned long addr, unsigned int esr,
die_kernel_fault(msg, addr, esr, regs);
}
-static void set_thread_esr(unsigned long address, unsigned int esr)
+static void do_bad_area(unsigned long far, unsigned int esr,
+ struct pt_regs *regs)
{
- current->thread.fault_address = address;
+ unsigned long addr = untagged_addr(far);
- /*
- * If the faulting address is in the kernel, we must sanitize the ESR.
- * From userspace's point of view, kernel-only mappings don't exist
- * at all, so we report them as level 0 translation faults.
- * (This is not quite the way that "no mapping there at all" behaves:
- * an alignment fault not caused by the memory type would take
- * precedence over translation fault for a real access to empty
- * space. Unfortunately we can't easily distinguish "alignment fault
- * not caused by memory type" from "alignment fault caused by memory
- * type", so we ignore this wrinkle and just return the translation
- * fault.)
- */
- if (!is_ttbr0_addr(current->thread.fault_address)) {
- switch (ESR_ELx_EC(esr)) {
- case ESR_ELx_EC_DABT_LOW:
- /*
- * These bits provide only information about the
- * faulting instruction, which userspace knows already.
- * We explicitly clear bits which are architecturally
- * RES0 in case they are given meanings in future.
- * We always report the ESR as if the fault was taken
- * to EL1 and so ISV and the bits in ISS[23:14] are
- * clear. (In fact it always will be a fault to EL1.)
- */
- esr &= ESR_ELx_EC_MASK | ESR_ELx_IL |
- ESR_ELx_CM | ESR_ELx_WNR;
- esr |= ESR_ELx_FSC_FAULT;
- break;
- case ESR_ELx_EC_IABT_LOW:
- /*
- * Claim a level 0 translation fault.
- * All other bits are architecturally RES0 for faults
- * reported with that DFSC value, so we clear them.
- */
- esr &= ESR_ELx_EC_MASK | ESR_ELx_IL;
- esr |= ESR_ELx_FSC_FAULT;
- break;
- default:
- /*
- * This should never happen (entry.S only brings us
- * into this code for insn and data aborts from a lower
- * exception level). Fail safe by not providing an ESR
- * context record at all.
- */
- WARN(1, "ESR 0x%x is not DABT or IABT from EL0\n", esr);
- esr = 0;
- break;
- }
- }
-
- current->thread.fault_code = esr;
-}
-
-static void do_bad_area(unsigned long addr, unsigned int esr, struct pt_regs *regs)
-{
/*
* If we are in kernel mode at this point, we have no context to
* handle this fault with.
*/
if (user_mode(regs)) {
const struct fault_info *inf = esr_to_fault_info(esr);
-
- set_thread_esr(addr, esr);
arm64_force_sig_fault(inf->sig, inf->code, (void __user *)addr,
- inf->name);
+ far, esr, inf->name);
} else {
__do_kernel_fault(addr, esr, regs);
}
@@ -439,7 +383,7 @@ static bool is_write_abort(unsigned int esr)
return (esr & ESR_ELx_WNR) && !(esr & ESR_ELx_CM);
}
-static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
+static int __kprobes do_page_fault(unsigned long far, unsigned int esr,
struct pt_regs *regs)
{
const struct fault_info *inf;
@@ -447,6 +391,7 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
vm_fault_t fault, major = 0;
unsigned long vm_flags = VM_ACCESS_FLAGS;
unsigned int mm_flags = FAULT_FLAG_DEFAULT;
+ unsigned long addr = untagged_addr(far);
if (kprobe_page_fault(regs, esr))
return 0;
@@ -570,13 +515,12 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
}
inf = esr_to_fault_info(esr);
- set_thread_esr(addr, esr);
if (fault & VM_FAULT_SIGBUS) {
/*
* We had some memory, but were unable to successfully fix up
* this page fault.
*/
- arm64_force_sig_fault(SIGBUS, BUS_ADRERR, (void __user *)addr,
+ arm64_force_sig_fault(SIGBUS, BUS_ADRERR, (void __user *)addr, far, esr,
inf->name);
} else if (fault & (VM_FAULT_HWPOISON_LARGE | VM_FAULT_HWPOISON)) {
unsigned int lsb;
@@ -586,7 +530,7 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
lsb = hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
arm64_force_sig_mceerr(BUS_MCEERR_AR, (void __user *)addr, lsb,
- inf->name);
+ far, esr, inf->name);
} else {
/*
* Something tried to access memory that isn't in our memory
@@ -594,7 +538,7 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
*/
arm64_force_sig_fault(SIGSEGV,
fault == VM_FAULT_BADACCESS ? SEGV_ACCERR : SEGV_MAPERR,
- (void __user *)addr,
+ (void __user *)addr, far, esr,
inf->name);
}
@@ -605,30 +549,32 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
return 0;
}
-static int __kprobes do_translation_fault(unsigned long addr,
+static int __kprobes do_translation_fault(unsigned long far,
unsigned int esr,
struct pt_regs *regs)
{
+ unsigned long addr = untagged_addr(far);
+
if (is_ttbr0_addr(addr))
- return do_page_fault(addr, esr, regs);
+ return do_page_fault(far, esr, regs);
- do_bad_area(addr, esr, regs);
+ do_bad_area(far, esr, regs);
return 0;
}
-static int do_alignment_fault(unsigned long addr, unsigned int esr,
+static int do_alignment_fault(unsigned long far, unsigned int esr,
struct pt_regs *regs)
{
- do_bad_area(addr, esr, regs);
+ do_bad_area(far, esr, regs);
return 0;
}
-static int do_bad(unsigned long addr, unsigned int esr, struct pt_regs *regs)
+static int do_bad(unsigned long far, unsigned int esr, struct pt_regs *regs)
{
return 1; /* "fault" */
}
-static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
+static int do_sea(unsigned long far, unsigned int esr, struct pt_regs *regs)
{
const struct fault_info *inf;
void __user *siaddr;
@@ -644,7 +590,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
if (esr & ESR_ELx_FnV)
siaddr = NULL;
else
- siaddr = (void __user *)addr;
+ siaddr = (void __user *)untagged_addr(far);
arm64_notify_die(inf->name, regs, inf->sig, inf->code, siaddr, esr);
return 0;
@@ -717,11 +663,12 @@ static const struct fault_info fault_info[] = {
{ do_bad, SIGKILL, SI_KERNEL, "unknown 63" },
};
-void do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs)
+void do_mem_abort(unsigned long far, unsigned int esr, struct pt_regs *regs)
{
const struct fault_info *inf = esr_to_fault_info(esr);
+ unsigned long addr = untagged_addr(far);
- if (!inf->fn(addr, esr, regs))
+ if (!inf->fn(far, esr, regs))
return;
if (!user_mode(regs)) {
@@ -730,8 +677,8 @@ void do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs)
show_pte(addr);
}
- arm64_notify_die(inf->name, regs,
- inf->sig, inf->code, (void __user *)addr, esr);
+ arm64_notify_die(inf->name, regs, inf->sig, inf->code,
+ (void __user *)addr, esr);
}
NOKPROBE_SYMBOL(do_mem_abort);
@@ -744,8 +691,8 @@ NOKPROBE_SYMBOL(do_el0_irq_bp_hardening);
void do_sp_pc_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs)
{
- arm64_notify_die("SP/PC alignment exception", regs,
- SIGBUS, BUS_ADRALN, (void __user *)addr, esr);
+ arm64_notify_die("SP/PC alignment exception", regs, SIGBUS, BUS_ADRALN,
+ (void __user *)addr, esr);
}
NOKPROBE_SYMBOL(do_sp_pc_abort);
@@ -871,8 +818,8 @@ void do_debug_exception(unsigned long addr_if_watchpoint, unsigned int esr,
arm64_apply_bp_hardening();
if (inf->fn(addr_if_watchpoint, esr, regs)) {
- arm64_notify_die(inf->name, regs,
- inf->sig, inf->code, (void __user *)pc, esr);
+ arm64_notify_die(inf->name, regs, inf->sig, inf->code,
+ (void __user *)pc, esr);
}
debug_exception_exit(regs);
--
2.26.2.761.g0e0b3e54be-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 1/3] signal: Allow architectures to store arch-specific data in kernel_siginfo
From: Peter Collingbourne @ 2020-05-21 2:29 UTC (permalink / raw)
To: Catalin Marinas, Evgenii Stepanov, Kostya Serebryany,
Vincenzo Frascino, Dave Martin, Will Deacon, Oleg Nesterov,
Eric W. Biederman
Cc: Andrey Konovalov, Kevin Brodsky, Peter Collingbourne, Linux ARM,
Richard Henderson
In-Reply-To: <20200521022943.195898-1-pcc@google.com>
In some cases we would like to store architecture-specific data in
the kernel's siginfo but not in the userspace one. This is generally
data is conceptually part of siginfo but is not stored there for one
reason or another. For example, on arm64, the arch-specific fault
code register ESR_EL1 is exposed to signal handlers, but since it is
associated with many different types of signals it does not fit well
into siginfo and appears in sigcontext instead.
Currently this data is stored in thread_struct, which is error-prone
because the data is associated with the signal itself and not the task,
and as a result it could get out of sync with the signal that is
currently being delivered.
To help avoid these types of errors, introduce a way for architectures
to store architecture-specific data in the kernel_siginfo. This part
of the kernel_siginfo is not exposed to userspace so the architecture
can use it in any way that it likes without ABI concerns. A follow-up
change will start using this mechanism on arm64 to store the fault
code and fault address.
Signed-off-by: Peter Collingbourne <pcc@google.com>
---
include/linux/signal.h | 2 --
include/linux/signal_types.h | 3 +++
kernel/signal.c | 17 +++++++++++++----
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/include/linux/signal.h b/include/linux/signal.h
index 05bacd2ab135..34bf18932e9b 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -22,8 +22,6 @@ static inline void clear_siginfo(kernel_siginfo_t *info)
memset(info, 0, sizeof(*info));
}
-#define SI_EXPANSION_SIZE (sizeof(struct siginfo) - sizeof(struct kernel_siginfo))
-
int copy_siginfo_to_user(siginfo_t __user *to, const kernel_siginfo_t *from);
int copy_siginfo_from_user(kernel_siginfo_t *to, const siginfo_t __user *from);
diff --git a/include/linux/signal_types.h b/include/linux/signal_types.h
index f8a90ae9c6ec..a8635eeb890b 100644
--- a/include/linux/signal_types.h
+++ b/include/linux/signal_types.h
@@ -11,6 +11,9 @@
typedef struct kernel_siginfo {
__SIGINFO;
+#ifdef __ARCH_HAS_PRIVATE_SIGINFO
+ struct arch_private_siginfo arch;
+#endif
} kernel_siginfo_t;
/*
diff --git a/kernel/signal.c b/kernel/signal.c
index 284fc1600063..a33df2280ed5 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3180,15 +3180,21 @@ enum siginfo_layout siginfo_layout(unsigned sig, int si_code)
return layout;
}
+struct shared_siginfo {
+ __SIGINFO;
+};
+
+#define SI_EXPANSION_SIZE (sizeof(struct siginfo) - sizeof(struct shared_siginfo))
+
static inline char __user *si_expansion(const siginfo_t __user *info)
{
- return ((char __user *)info) + sizeof(struct kernel_siginfo);
+ return ((char __user *)info) + sizeof(struct shared_siginfo);
}
int copy_siginfo_to_user(siginfo_t __user *to, const kernel_siginfo_t *from)
{
char __user *expansion = si_expansion(to);
- if (copy_to_user(to, from , sizeof(struct kernel_siginfo)))
+ if (copy_to_user(to, from , sizeof(struct shared_siginfo)))
return -EFAULT;
if (clear_user(expansion, SI_EXPANSION_SIZE))
return -EFAULT;
@@ -3198,6 +3204,9 @@ int copy_siginfo_to_user(siginfo_t __user *to, const kernel_siginfo_t *from)
static int post_copy_siginfo_from_user(kernel_siginfo_t *info,
const siginfo_t __user *from)
{
+#ifdef __ARCH_HAS_PRIVATE_SIGINFO
+ memset(&info->arch, 0, sizeof(info->arch));
+#endif
if (unlikely(!known_siginfo_layout(info->si_signo, info->si_code))) {
char __user *expansion = si_expansion(from);
char buf[SI_EXPANSION_SIZE];
@@ -3221,7 +3230,7 @@ static int post_copy_siginfo_from_user(kernel_siginfo_t *info,
static int __copy_siginfo_from_user(int signo, kernel_siginfo_t *to,
const siginfo_t __user *from)
{
- if (copy_from_user(to, from, sizeof(struct kernel_siginfo)))
+ if (copy_from_user(to, from, sizeof(struct shared_siginfo)))
return -EFAULT;
to->si_signo = signo;
return post_copy_siginfo_from_user(to, from);
@@ -3229,7 +3238,7 @@ static int __copy_siginfo_from_user(int signo, kernel_siginfo_t *to,
int copy_siginfo_from_user(kernel_siginfo_t *to, const siginfo_t __user *from)
{
- if (copy_from_user(to, from, sizeof(struct kernel_siginfo)))
+ if (copy_from_user(to, from, sizeof(struct shared_siginfo)))
return -EFAULT;
return post_copy_siginfo_from_user(to, from);
}
--
2.26.2.761.g0e0b3e54be-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 0/3] arm64: Expose FAR_EL1 tag bits in sigcontext
From: Peter Collingbourne @ 2020-05-21 2:29 UTC (permalink / raw)
To: Catalin Marinas, Evgenii Stepanov, Kostya Serebryany,
Vincenzo Frascino, Dave Martin, Will Deacon, Oleg Nesterov,
Eric W. Biederman
Cc: Andrey Konovalov, Kevin Brodsky, Peter Collingbourne, Linux ARM,
Richard Henderson
In-Reply-To: <CAMn1gO7VWBcbMvqNeyBdfpO71kfhrZbHwkOC0JeSX13_HUMmWA@mail.gmail.com>
The kernel currently clears the tag bits (i.e. bits 56-63) in the fault
address exposed via siginfo.si_addr and sigcontext.fault_address. However,
the tag bits may be needed by tools in order to accurately diagnose
memory errors, such as HWASan [1] or future tools based on the Memory
Tagging Extension (MTE).
We should not stop clearing these bits in the existing fault address fields,
because there may be existing userspace applications that are expecting the tag
bits to be cleared. Instead, create a fault_addr_top_byte_context in sigcontext
(similar to the existing esr_context), and store the tag bits of FAR_EL1 there.
[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
Peter Collingbourne (3):
signal: Allow architectures to store arch-specific data in
kernel_siginfo
arm64: Move fault address and fault code into kernel_siginfo
arm64: Expose FAR_EL1 tag bits in sigcontext
Documentation/arm64/tagged-pointers.rst | 17 ++--
arch/arm64/include/asm/exception.h | 2 +-
arch/arm64/include/asm/processor.h | 2 -
arch/arm64/include/asm/signal.h | 19 ++++
arch/arm64/include/asm/traps.h | 8 +-
arch/arm64/include/uapi/asm/sigcontext.h | 24 +++--
arch/arm64/kernel/debug-monitors.c | 4 +-
arch/arm64/kernel/entry-common.c | 2 -
arch/arm64/kernel/probes/uprobes.c | 18 ++--
arch/arm64/kernel/ptrace.c | 2 +-
arch/arm64/kernel/signal.c | 42 ++++++--
arch/arm64/kernel/signal32.c | 15 ++-
arch/arm64/kernel/sys_compat.c | 9 +-
arch/arm64/kernel/traps.c | 121 +++++++++++++++++++----
arch/arm64/mm/fault.c | 111 ++++++---------------
include/linux/signal.h | 2 -
include/linux/signal_types.h | 3 +
kernel/signal.c | 17 +++-
18 files changed, 259 insertions(+), 159 deletions(-)
create mode 100644 arch/arm64/include/asm/signal.h
--
2.26.2.761.g0e0b3e54be-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6] arm64: Expose FAR_EL1 tag bits in sigcontext
From: Peter Collingbourne @ 2020-05-21 2:28 UTC (permalink / raw)
To: Dave Martin
Cc: Eric W. Biederman, Andrey Konovalov, Kevin Brodsky, Oleg Nesterov,
Kostya Serebryany, Linux ARM, Catalin Marinas, Vincenzo Frascino,
Will Deacon, Evgenii Stepanov, Richard Henderson
In-Reply-To: <20200520092558.GI5031@arm.com>
On Wed, May 20, 2020 at 2:26 AM Dave Martin <Dave.Martin@arm.com> wrote:
>
> On Wed, May 20, 2020 at 09:55:03AM +0100, Will Deacon wrote:
> > On Tue, May 19, 2020 at 03:00:12PM -0700, Peter Collingbourne wrote:
> > > On Mon, May 18, 2020 at 2:53 AM Dave Martin <Dave.Martin@arm.com> wrote:
> > > > On Thu, May 14, 2020 at 05:58:21PM -0700, Peter Collingbourne wrote:
> > > > > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> > > > > index baa88dc02e5c..5867f2fdbe64 100644
> > > > > --- a/arch/arm64/kernel/signal.c
> > > > > +++ b/arch/arm64/kernel/signal.c
> > > > > @@ -648,6 +648,7 @@ static int setup_sigframe(struct
> > > > > rt_sigframe_user_layout *user,
> > > > > __put_user_error(ESR_MAGIC, &esr_ctx->head.magic, err);
> > > > > __put_user_error(sizeof(*esr_ctx), &esr_ctx->head.size, err);
> > > > > __put_user_error(current->thread.fault_code,
> > > > > &esr_ctx->esr, err);
> > > > > + current->thread.fault_code = 0;
> > > >
> > > > Perhaps, but we'd need to be careful. For example, can we run out of
> > > > user stack before this and deliver a SIGSEGV, but with the old
> > > > fault_code still set? Then we'd emit the old fault code with the
> > > > new "can't deliver signal" signal, which doesn't make sense.
> > > >
> > > > Stuff may also go wrong with signal prioritisation.
> > > >
> > > > If a higher-priority signal (say SIGINT) comes in after a data abort
> > > > enters the kernel but before the resulting SIGSEGV is dequeued for
> > > > delivery, wouldn't we deliver SIGINT first, with the bogus fault code?
> > > > With your change we'd then have cleared the fault code by the time we
> > > > deliver the SIGSEGV it actually relates to, if I've understood right.
> > > >
> > > > Today, I think we just attach that fault code to every signal that's
> > > > delivered until something overwrites or resets it, which means that
> > > > a signal that needs fault_code gets it, at the expense of attaching
> > > > it to a bunch of other random signals too.
> > > >
> > > >
> > > > Checking the signal number and si_code might help us to know what we
> > > > should be doing with fault_code. We need to have sure userspace can't
> > > > trick us with a non kernel generated signal here. It would also be
> > > > necessary to check how PTRACE_SETSIGINFO interacts with this.
> > >
> > > With these possible interactions in mind I think we should store the
> > > fault code and fault address in kernel_siginfo instead of
> > > thread_struct (and clear these fields when we receive a siginfo from
> > > userspace, i.e. in copy_siginfo_from_user which is used by
> > > ptrace(PTRACE_SETSIGINFO) among other places). That way, the
> > > information is clearly associated with the signal itself and not the
> > > thread, so we don't need to worry about our signal being delivered out
> > > of order.
> >
> > Hmm, I can't see a way to do that that isn't horribly invasive in the core
> > signal code. Can you?
I think I've come up with a way that doesn't seem to be too invasive.
See patch #1 of the series that I'm about to send out.
> > But generally, I agree: the per-thread handling of fault_address and
> > fault_code appears to be quite broken in the face of signal prioritisation
> > and signals that don't correspond directly to hardware trap. It would be
> > nice to have some tests for this...
> >
> > If we want to pile on more bodges, perhaps we could stash the signal number
> > to which the fault_{address,code} relate, and then check that at delivery
> > and clear on a match. I hate it.
>
> I agree with Daniel's suggestion in principle, but I was also concerned
> about whether it would be too invasive elsewhere.
>
> Question though: does the core code take special care to make sure that
> a force_sig cannot be outprioritised by a regular signal? If so,
> perhaps we get away with it. I ask this, because the same same issue
> may be hitting other arches otherwise.
Not as far as I can tell. There does appear to be prioritisation for
synchronous signals [1] but as far as I can tell nothing to
distinguish one of these signals from one with the same signal number
sent from userspace (e.g. via kill(2)).
Peter
[1] https://github.com/torvalds/linux/blob/b85051e755b0e9d6dd8f17ef1da083851b83287d/kernel/signal.c#L222
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/12] OPP: Allow required-opps even if the device doesn't have power-domains
From: andrew-sh.cheng @ 2020-05-21 1:50 UTC (permalink / raw)
To: Matthias Brugger
Cc: Mark Rutland, Nishanth Menon, Saravana Kannan, srv_heupstream,
linux-pm, Stephen Boyd, Viresh Kumar, Mark Brown,
Rafael J . Wysocki, Liam Girdwood, Rob Herring, linux-kernel,
Chanwoo Choi, Kyungmin Park, MyungJoo Ham, linux-mediatek,
linux-arm-kernel, devicetree
In-Reply-To: <b667fff9-50ae-bff2-ae17-1cf0ca1a08a5@gmail.com>
On Wed, 2020-05-20 at 16:54 +0200, Matthias Brugger wrote:
>
> On 20/05/2020 05:42, Andrew-sh.Cheng wrote:
> > From: Saravana Kannan <saravanak@google.com>
> >
> > A Device-A can have a (minimum) performance requirement on another
> > Device-B to be able to function correctly. This performance requirement
> > on Device-B can also change based on the current performance level of
> > Device-A.
> >
> > The existing required-opps feature fits well to describe this need. So,
> > instead of limiting required-opps to point to only PM-domain devices,
> > allow it to point to any device.
> >
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
>
> Please check all patches, they are missing your
> Signed-off-by
>
> Regards,
> Matthias
Hi Matthias,
I modify patch [6/12] to meet kernel-5.7 data structure and add
signed-off.
For [1/12] to [5/12], I didn't modify them.
Should I also add signed-off ?
BR,
Andrew-sh.Cheng
>
> > ---
> > drivers/opp/core.c | 2 +-
> > drivers/opp/of.c | 11 -----------
> > 2 files changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > index ba43e6a3dc0a..51403c1f2481 100644
> > --- a/drivers/opp/core.c
> > +++ b/drivers/opp/core.c
> > @@ -755,7 +755,7 @@ static int _set_required_opps(struct device *dev,
> > return 0;
> >
> > /* Single genpd case */
> > - if (!genpd_virt_devs) {
> > + if (!genpd_virt_devs && required_opp_tables[0]->is_genpd) {
> > pstate = likely(opp) ? opp->required_opps[0]->pstate : 0;
> > ret = dev_pm_genpd_set_performance_state(dev, pstate);
> > if (ret) {
> > diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> > index 9cd8f0adacae..6d33de668a7b 100644
> > --- a/drivers/opp/of.c
> > +++ b/drivers/opp/of.c
> > @@ -195,17 +195,6 @@ static void _opp_table_alloc_required_tables(struct opp_table *opp_table,
> >
> > if (IS_ERR(required_opp_tables[i]))
> > goto free_required_tables;
> > -
> > - /*
> > - * We only support genpd's OPPs in the "required-opps" for now,
> > - * as we don't know how much about other cases. Error out if the
> > - * required OPP doesn't belong to a genpd.
> > - */
> > - if (!required_opp_tables[i]->is_genpd) {
> > - dev_err(dev, "required-opp doesn't belong to genpd: %pOF\n",
> > - required_np);
> > - goto free_required_tables;
> > - }
> > }
> >
> > goto put_np;
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/4] rcu/kasan: record and print call_rcu() call stack
From: Walter Wu @ 2020-05-21 1:45 UTC (permalink / raw)
To: Andrey Konovalov
Cc: wsd_upstream, Paul E . McKenney, Linux Memory Management List,
Lai Jiangshan, Josh Triplett, kasan-dev, LKML, Joel Fernandes,
linux-mediatek, Alexander Potapenko, Linux ARM, Matthias Brugger,
Andrey Ryabinin, Andrew Morton, Dmitry Vyukov, Mathieu Desnoyers
In-Reply-To: <CAAeHK+wyg90Tw_Fp+A1vkW3rK+WKwPi_oS4T4SVL-fEYYaU0Lw@mail.gmail.com>
> On Wed, May 20, 2020 at 2:34 PM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > This feature will record the last two call_rcu() call stacks and
> > prints up to 2 call_rcu() call stacks in KASAN report.
> >
> > When call_rcu() is called, we store the call_rcu() call stack into
> > slub alloc meta-data, so that the KASAN report can print rcu stack.
> >
> > [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> > [2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ
> >
> > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > Acked-by: Paul E. McKenney <paulmck@kernel.org>
> > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Cc: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Alexander Potapenko <glider@google.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Josh Triplett <josh@joshtriplett.org>
> > Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> > Cc: Lai Jiangshan <jiangshanlai@gmail.com>
> > Cc: Joel Fernandes <joel@joelfernandes.org>
> > Cc: Andrey Konovalov <andreyknvl@google.com>
> > ---
> > include/linux/kasan.h | 2 ++
> > kernel/rcu/tree.c | 2 ++
> > mm/kasan/common.c | 4 ++--
> > mm/kasan/generic.c | 21 +++++++++++++++++++++
> > mm/kasan/kasan.h | 10 ++++++++++
> > mm/kasan/report.c | 24 ++++++++++++++++++++++++
> > 6 files changed, 61 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index 31314ca7c635..23b7ee00572d 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -174,11 +174,13 @@ static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0; }
> >
> > void kasan_cache_shrink(struct kmem_cache *cache);
> > void kasan_cache_shutdown(struct kmem_cache *cache);
> > +void kasan_record_aux_stack(void *ptr);
> >
> > #else /* CONFIG_KASAN_GENERIC */
> >
> > static inline void kasan_cache_shrink(struct kmem_cache *cache) {}
> > static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
> > +static inline void kasan_record_aux_stack(void *ptr) {}
> >
> > #endif /* CONFIG_KASAN_GENERIC */
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 06548e2ebb72..36a4ff7f320b 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -57,6 +57,7 @@
> > #include <linux/slab.h>
> > #include <linux/sched/isolation.h>
> > #include <linux/sched/clock.h>
> > +#include <linux/kasan.h>
> > #include "../time/tick-internal.h"
> >
> > #include "tree.h"
> > @@ -2668,6 +2669,7 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func)
> > head->func = func;
> > head->next = NULL;
> > local_irq_save(flags);
> > + kasan_record_aux_stack(head);
> > rdp = this_cpu_ptr(&rcu_data);
> >
> > /* Add the callback to our list. */
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 2906358e42f0..8bc618289bb1 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -41,7 +41,7 @@
> > #include "kasan.h"
> > #include "../slab.h"
> >
> > -static inline depot_stack_handle_t save_stack(gfp_t flags)
> > +depot_stack_handle_t kasan_save_stack(gfp_t flags)
> > {
> > unsigned long entries[KASAN_STACK_DEPTH];
> > unsigned int nr_entries;
> > @@ -54,7 +54,7 @@ static inline depot_stack_handle_t save_stack(gfp_t flags)
> > static inline void set_track(struct kasan_track *track, gfp_t flags)
> > {
> > track->pid = current->pid;
> > - track->stack = save_stack(flags);
> > + track->stack = kasan_save_stack(flags);
> > }
> >
> > void kasan_enable_current(void)
> > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > index 56ff8885fe2e..8acf48882ba2 100644
> > --- a/mm/kasan/generic.c
> > +++ b/mm/kasan/generic.c
> > @@ -325,3 +325,24 @@ DEFINE_ASAN_SET_SHADOW(f2);
> > DEFINE_ASAN_SET_SHADOW(f3);
> > DEFINE_ASAN_SET_SHADOW(f5);
> > DEFINE_ASAN_SET_SHADOW(f8);
> > +
> > +void kasan_record_aux_stack(void *addr)
> > +{
> > + struct page *page = kasan_addr_to_page(addr);
> > + struct kmem_cache *cache;
> > + struct kasan_alloc_meta *alloc_info;
> > + void *object;
> > +
> > + if (!(page && PageSlab(page)))
> > + return;
> > +
> > + cache = page->slab_cache;
> > + object = nearest_obj(cache, page, addr);
> > + alloc_info = get_alloc_info(cache, object);
> > +
> > + /*
> > + * record the last two call_rcu() call stacks.
> > + */
> > + alloc_info->aux_stack[1] = alloc_info->aux_stack[0];
> > + alloc_info->aux_stack[0] = kasan_save_stack(GFP_NOWAIT);
> > +}
> > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > index e8f37199d885..a7391bc83070 100644
> > --- a/mm/kasan/kasan.h
> > +++ b/mm/kasan/kasan.h
> > @@ -104,7 +104,15 @@ struct kasan_track {
> >
> > struct kasan_alloc_meta {
> > struct kasan_track alloc_track;
> > +#ifdef CONFIG_KASAN_GENERIC
> > + /*
> > + * call_rcu() call stack is stored into struct kasan_alloc_meta.
> > + * The free stack is stored into struct kasan_free_meta.
> > + */
> > + depot_stack_handle_t aux_stack[2];
> > +#else
> > struct kasan_track free_track[KASAN_NR_FREE_STACKS];
> > +#endif
> > #ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > u8 free_pointer_tag[KASAN_NR_FREE_STACKS];
> > u8 free_track_idx;
> > @@ -159,6 +167,8 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
> >
> > struct page *kasan_addr_to_page(const void *addr);
> >
> > +depot_stack_handle_t kasan_save_stack(gfp_t flags);
> > +
> > #if defined(CONFIG_KASAN_GENERIC) && \
> > (defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
> > void quarantine_put(struct kasan_free_meta *info, struct kmem_cache *cache);
> > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > index 80f23c9da6b0..29a801d5cd74 100644
> > --- a/mm/kasan/report.c
> > +++ b/mm/kasan/report.c
> > @@ -105,6 +105,17 @@ static void end_report(unsigned long *flags)
> > kasan_enable_current();
> > }
> >
> > +#ifdef CONFIG_KASAN_GENERIC
> > +static void print_stack(depot_stack_handle_t stack)
> > +{
> > + unsigned long *entries;
> > + unsigned int nr_entries;
> > +
> > + nr_entries = stack_depot_fetch(stack, &entries);
> > + stack_trace_print(entries, nr_entries, 0);
> > +}
> > +#endif
>
> The idea of moving it here was to reuse print_stack() in print_track() :)
>
Ok. I see. Next patch will fix it.
> > +
> > static void print_track(struct kasan_track *track, const char *prefix)
> > {
> > pr_err("%s by task %u:\n", prefix, track->pid);
> > @@ -192,6 +203,19 @@ static void describe_object(struct kmem_cache *cache, void *object,
> > free_track = kasan_get_free_track(cache, object, tag);
> > print_track(free_track, "Freed");
> > pr_err("\n");
> > +
> > +#ifdef CONFIG_KASAN_GENERIC
> > + if (alloc_info->aux_stack[0]) {
> > + pr_err("Last call_rcu():\n");
> > + print_stack(alloc_info->aux_stack[0]);
> > + pr_err("\n");
> > + }
> > + if (alloc_info->aux_stack[1]) {
> > + pr_err("Second to last call_rcu():\n");
> > + print_stack(alloc_info->aux_stack[1]);
> > + pr_err("\n");
> > + }
> > +#endif
> > }
> >
> > describe_object_addr(cache, object, addr);
> > --
> > 2.18.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200520123434.3888-1-walter-zh.wu%40mediatek.com.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] [media] mtk-mdp: use pm_runtime in MDP component driver
From: Eizan Miyamoto @ 2020-05-21 1:36 UTC (permalink / raw)
To: Enric Balletbo Serra
Cc: Andrew-CT Chen, Minghsiu Tsai, LKML, Houlong Wei, Eizan Miyamoto,
moderated list:ARM/Mediatek SoC support, Matthias Brugger,
Mauro Carvalho Chehab, Linux ARM, linux-media
In-Reply-To: <CAFqH_50_Py7Diu5bwmjLBPGiy3F5J5qNGmtrbH7i7aTUaHif9A@mail.gmail.com>
On Thu, May 7, 2020 at 3:07 AM Enric Balletbo Serra <eballetbo@gmail.com> wrote:
>
> Hi Eizan,
>
> Thank you for the patch.
>
> Missatge de Eizan Miyamoto <eizan@chromium.org> del dia dc., 6 de maig
> 2020 a les 10:42:
> >
> > Without this change, the MDP components are not fully integrated into
> > the runtime power management subsystem, and the MDP driver does not
> > work.
> >
> > For each of the component device drivers to be able to call
> > pm_runtime_get/put_sync() a pointer to the component's device struct
> > had to be added to struct mtk_mdp_comp, set by mtk_mdp_comp_init().
> >
> > Note that the dev argument to mtk_mdp_comp_clock_on/off() has been
> > removed. Those functions used to be called from the "master" mdp driver
> > in mtk_mdp_core.c, but the component's device pointer no longer
> > corresponds to the mdp master device pointer, which is not the right
> > device to pass to pm_runtime_put/get_sync() which we had to add to get
> > the driver to work properly.
> >
> > Signed-off-by: Eizan Miyamoto <eizan@chromium.org>
> > ---
> >
> > Changes in v2:
>
> Ah, I guess this change log corresponds to the first patch.
>
> > - remove empty mtk_mdp_comp_init
> > - update documentation for enum mtk_mdp_comp_type
> > - remove comma after last element of mtk_mdp_comp_driver_dt_match
> >
> > drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 22 ++++++++++++++-----
> > drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 6 +++--
> > drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 6 ++---
> > 3 files changed, 23 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> > index 5b4d482df778..228c58f92c8c 100644
> > --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> > +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> > @@ -15,6 +15,7 @@
> > #include <linux/of_platform.h>
> > #include <soc/mediatek/smi.h>
> > #include <linux/platform_device.h>
> > +#include <linux/pm_runtime.h>
> >
> > #include "mtk_mdp_comp.h"
> > #include "mtk_mdp_core.h"
> > @@ -53,7 +54,7 @@ static const struct of_device_id mtk_mdp_comp_driver_dt_match[] = {
> > };
> > MODULE_DEVICE_TABLE(of, mtk_mdp_comp_driver_dt_match);
> >
> > -void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
> > +void mtk_mdp_comp_clock_on(struct mtk_mdp_comp *comp)
> > {
> > int i, err;
> >
> > @@ -62,25 +63,31 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
> > if (err) {
> > enum mtk_mdp_comp_type comp_type =
> > (enum mtk_mdp_comp_type)
> > - of_device_get_match_data(dev);
> > - dev_err(dev,
> > + of_device_get_match_data(comp->dev);
> > + dev_err(comp->dev,
> > "failed to get larb, err %d. type:%d\n",
> > err, comp_type);
> > }
> > }
> >
> > + err = pm_runtime_get_sync(comp->dev);
> > + if (err < 0)
> > + dev_err(comp->dev,
> > + "failed to runtime get, err %d.\n",
> > + err);
>
> Should you really ignore this error? If that's the case I'd just call
> pm_runtime_get_sync() without adding the logic to just print an error
> message.
This is mostly consistent with style elsewhere, e.g., in mtk_mdp_m2m.c
mtk_mdp_m2m_start_streaming and mtk_mdp_m2m_stop_streaming.
>
> > +
> > for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> > if (IS_ERR(comp->clk[i]))
> > continue;
> > err = clk_prepare_enable(comp->clk[i]);
> > if (err)
> > - dev_err(dev,
> > + dev_err(comp->dev,
> > "failed to enable clock, err %d. i:%d\n",
> > err, i);
>
> Although ignoring errors seems to be a common pattern in this file and
> I know you did not introduce this.
Maybe the issue is that since no action is taken, logging at the 'error' log
level is not the right thing? IOW, should it be changed to an informational
message instead? Nevertheless, I think we should defer these changes to a
follow-up patch instead.
>
> > }
> > }
> >
> > -void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp)
> > +void mtk_mdp_comp_clock_off(struct mtk_mdp_comp *comp)
> > {
> > int i;
> >
> > @@ -92,6 +99,8 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp)
> >
> > if (comp->larb_dev)
> > mtk_smi_larb_put(comp->larb_dev);
> > +
> > + pm_runtime_put_sync(comp->dev);
> > }
> >
> > static int mtk_mdp_comp_bind(struct device *dev, struct device *master,
> > @@ -101,6 +110,7 @@ static int mtk_mdp_comp_bind(struct device *dev, struct device *master,
> > struct mtk_mdp_dev *mdp = data;
> >
> > mtk_mdp_register_component(mdp, comp);
> > + pm_runtime_enable(dev);
> >
> > return 0;
> > }
> > @@ -111,6 +121,7 @@ static void mtk_mdp_comp_unbind(struct device *dev, struct device *master,
> > struct mtk_mdp_dev *mdp = data;
> > struct mtk_mdp_comp *comp = dev_get_drvdata(dev);
> >
> > + pm_runtime_disable(dev);
> > mtk_mdp_unregister_component(mdp, comp);
> > }
> >
> > @@ -129,6 +140,7 @@ int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev)
> > (enum mtk_mdp_comp_type)of_device_get_match_data(dev);
> >
> > INIT_LIST_HEAD(&comp->node);
> > + comp->dev = dev;
> >
> > for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> > comp->clk[i] = of_clk_get(node, i);
> > diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> > index b5a18fe567aa..de158d3712f6 100644
> > --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> > +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> > @@ -12,17 +12,19 @@
> > * @node: list node to track sibing MDP components
> > * @clk: clocks required for component
> > * @larb_dev: SMI device required for component
> > + * @dev: component's device
> > */
> > struct mtk_mdp_comp {
> > struct list_head node;
> > struct clk *clk[2];
> > struct device *larb_dev;
> > + struct device *dev;
> > };
> >
> > int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev);
> >
> > -void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp);
> > -void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp);
> > +void mtk_mdp_comp_clock_on(struct mtk_mdp_comp *comp);
> > +void mtk_mdp_comp_clock_off(struct mtk_mdp_comp *comp);
> >
> > extern struct platform_driver mtk_mdp_component_driver;
> >
> > diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > index 539a7942e3cb..133d107aa4e6 100644
> > --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > @@ -52,20 +52,18 @@ MODULE_DEVICE_TABLE(of, mtk_mdp_of_ids);
> >
> > static void mtk_mdp_clock_on(struct mtk_mdp_dev *mdp)
> > {
> > - struct device *dev = &mdp->pdev->dev;
> > struct mtk_mdp_comp *comp_node;
> >
> > list_for_each_entry(comp_node, &mdp->comp_list, node)
> > - mtk_mdp_comp_clock_on(dev, comp_node);
> > + mtk_mdp_comp_clock_on(comp_node);
> > }
> >
> > static void mtk_mdp_clock_off(struct mtk_mdp_dev *mdp)
> > {
> > - struct device *dev = &mdp->pdev->dev;
> > struct mtk_mdp_comp *comp_node;
> >
> > list_for_each_entry(comp_node, &mdp->comp_list, node)
> > - mtk_mdp_comp_clock_off(dev, comp_node);
> > + mtk_mdp_comp_clock_off(comp_node);
> > }
> >
> > static void mtk_mdp_wdt_worker(struct work_struct *work)
> > --
> > 2.26.2.526.g744177e7f7-goog
> >
> >
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 3/3] Rockchip soc32 changes for 5.8
From: Heiko Stuebner @ 2020-05-21 1:18 UTC (permalink / raw)
To: arm; +Cc: linux-rockchip, soc, linux-arm-kernel
In-Reply-To: <1970481.V9vR1fIhX2@phil>
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v5.8-rockchip-soc32-1
for you to fetch changes up to 0b973c65d2f2da049252bc8370e4cf037b99c7e9:
ARM: rockchip: fix spelling mistake "to" -> "too" (2020-04-13 09:40:45 +0200)
----------------------------------------------------------------
A spelling fix and stop using clk_provider.h when of_clk.h is enough
as the soc file is only a clock user, not a provider.
----------------------------------------------------------------
Colin Ian King (1):
ARM: rockchip: fix spelling mistake "to" -> "too"
Geert Uytterhoeven (1):
ARM: rockchip: Replace <linux/clk-provider.h> by <linux/of_clk.h>
arch/arm/mach-rockchip/platsmp.c | 2 +-
arch/arm/mach-rockchip/rockchip.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/3] Rockchip dt32 changes for 5.8
From: Heiko Stuebner @ 2020-05-21 1:17 UTC (permalink / raw)
To: arm; +Cc: linux-rockchip, soc, linux-arm-kernel
In-Reply-To: <1970481.V9vR1fIhX2@phil>
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v5.8-rockchip-dts32-1
for you to fetch changes up to 54b1a4e070330c3fba5becfb0b619bf360bc2657:
ARM: dts: rockchip: add rga node for rk322x (2020-05-19 00:50:21 +0200)
----------------------------------------------------------------
RGA node for rk322x, wifi node for rk3229-xms6 and some cleanups.
----------------------------------------------------------------
Johan Jonker (2):
ARM: dts: rockchip: rename and label gpio-led subnodes
ARM: dts: rockchip: remove identical #include from rk3288.dtsi
Justin Swartz (3):
ARM: dts: enable WLAN for Mecer Xtreme Mini S6
ARM: dts: remove disable-wp from rk3229-xms6 emmc
ARM: dts: rockchip: add rga node for rk322x
arch/arm/boot/dts/rk3036-kylin.dts | 2 +-
arch/arm/boot/dts/rk3066a-mk808.dts | 2 +-
arch/arm/boot/dts/rk3188-radxarock.dts | 6 +++---
arch/arm/boot/dts/rk3229-xms6.dts | 19 +++++++++++++++++--
arch/arm/boot/dts/rk322x.dtsi | 10 ++++++++++
arch/arm/boot/dts/rk3288-firefly-reload.dts | 12 ++++++------
arch/arm/boot/dts/rk3288-firefly.dtsi | 12 ++++++------
arch/arm/boot/dts/rk3288-miqi.dts | 2 +-
arch/arm/boot/dts/rk3288-phycore-som.dtsi | 6 +++---
arch/arm/boot/dts/rk3288-rock2-square.dts | 4 ++--
arch/arm/boot/dts/rk3288-tinker.dtsi | 6 +++---
arch/arm/boot/dts/rk3288.dtsi | 1 -
12 files changed, 53 insertions(+), 29 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 1/3] Rockchip dt64 changes for 5.8
From: Heiko Stuebner @ 2020-05-21 1:17 UTC (permalink / raw)
To: arm; +Cc: linux-rockchip, soc, linux-arm-kernel
Hi Arnd, Kevin, Olof,
please find below some Rockchip devicetree changes for 5.8
Please pull!
Thanks
Heiko
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v5.8-rockchip-dts64-1
for you to fetch changes up to b2cb68e864222eb3cc1d7c3c06edc40469699983:
arm64: dts: rockchip: fix pinctrl-names for gpio-leds node on rk3326-odroid-go2 (2020-05-21 02:16:51 +0200)
----------------------------------------------------------------
New soc variant the rk3326 which is essentially a px30 with only one
display controller and a new board using it, the Odroid Advance Go.
sdcard regulator for the rockpro64 and a lot of devicetree fixes
making the dt-binding check a lot happier.
----------------------------------------------------------------
Boris Brezillon (1):
arm64: dts: rockchip: Define the rockchip Video Decoder node on rk3399
Heiko Stuebner (3):
arm64: dts: rockchip: add core devicetree for rk3326
dt-bindings: Add binding for Hardkernel Odroid Go Advance
arm64: dts: rockchip: add Odroid Advance Go
Johan Jonker (17):
arm64: dts: rockchip: remove bus-width from mmc nodes in rk3308-roc-cc
arm64: dts: rockchip: remove #sound-dai-cells from &i2s1 node of rk3399-pinebook-pro.dts
arm64: dts: rockchip: remove #sound-dai-cells from &spdif node of rk3399-hugsun-x99.dts
arm64: dts: rockchip: replace RK_FUNC defines in rk3326-odroid-go2
include: dt-bindings: rockchip: remove unused defines
arm64: dts: rockchip: fix phy nodename for rk3328
arm64: dts: rockchip: fix rtl8211f nodename for rk3328 Beelink A1
arm64: dts: rockchip: fix rtl8211e nodename for rk3399-nanopi4
arm64: dts: rockchip: fix &pinctrl phy sub nodename for rk3399-nanopi4
arm64: dts: rockchip: fix rtl8211e nodename for rk3399-orangepi
arm64: dts: rockchip: fix &pinctrl phy sub nodename for rk3399-orangepi
arm64: dts: rockchip: fix defines in pd_vio node for rk3399
arm64: dts: rockchip: rename and label gpio-led subnodes
arm64: dts: rockchip: remove disable-wp from rk3308-roc-cc emmc node
arm64: dts: rockchip: add bus-width properties to mmc nodes for px30
arm64: dts: rockchip: fix pd_tcpc0 and pd_tcpc1 node position on rk3399
arm64: dts: rockchip: fix pinctrl-names for gpio-leds node on rk3326-odroid-go2
Tobias Schramm (1):
arm64: dts: rockchip: add micro SD card regulator to rockpro64
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/px30.dtsi | 3 +
arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts | 7 +-
arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts | 557 +++++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3326.dtsi | 15 +
arch/arm64/boot/dts/rockchip/rk3328-a1.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 4 +-
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 4 +-
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 +-
arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 4 +-
.../boot/dts/rockchip/rk3368-orion-r68-meta.dts | 4 +-
arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3399-ficus.dts | 29 +-
arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 10 +-
arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts | 7 +-
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 4 +-
arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts | 4 +-
.../boot/dts/rockchip/rk3399-pinebook-pro.dts | 11 +-
arch/arm64/boot/dts/rockchip/rk3399-rock960.dts | 29 +-
arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 27 +
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 34 +-
include/dt-bindings/pinctrl/rockchip.h | 11 -
23 files changed, 691 insertions(+), 85 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
create mode 100644 arch/arm64/boot/dts/rockchip/rk3326.dtsi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3] arm64/cpufeature: Validate hypervisor capabilities during CPU hotplug
From: Anshuman Khandual @ 2020-05-21 0:48 UTC (permalink / raw)
To: Will Deacon, linux-arm-kernel
Cc: catalin.marinas, Marc Zyngier, linux-kernel, kvmarm
In-Reply-To: <158998676494.231372.15074477766045633803.b4-ty@kernel.org>
On 05/20/2020 11:24 PM, Will Deacon wrote:
> On Tue, 12 May 2020 07:27:27 +0530, Anshuman Khandual wrote:
>> This validates hypervisor capabilities like VMID width, IPA range for any
>> hot plug CPU against system finalized values. KVM's view of the IPA space
>> is used while allowing a given CPU to come up. While here, it factors out
>> get_vmid_bits() for general use.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Marc Zyngier <maz@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: James Morse <james.morse@arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: kvmarm@lists.cs.columbia.edu
>> Cc: linux-kernel@vger.kernel.org
>
> Applied to arm64 (for-next/cpufeature), thanks!
>
> [1/1] arm64/cpufeature: Validate hypervisor capabilities during CPU hotplug
> https://git.kernel.org/arm64/c/c73433fc630c
>
> But please note that I made some changes to verify_hyp_capabilities() so
> that it's (a) static and (b) uses IS_ENABLED to avoid the dummy function
> definition. I also extended the IS_ENABLED_check so that it doesn't
> conflict with the KVM kconfig changes from Fuad. Please shout if you think
> I'm still missing something.
Normally I would have expected get_kvm_ipa_limit() to be unavailable without
CONFIG_KVM_ARM_HOST, causing a build failure. But it does compile correctly.
Probably the compiler does not really look for get_kvm_ipa_limit() definition
after an early check and bailout on !IS_ENABLED(CONFIG_KVM_ARM_HOST).
Nonetheless, changes looks good. Thank you.
- Anshuman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: fix pinctrl-names for gpio-leds node on rk3326-odroid-go2
From: Heiko Stuebner @ 2020-05-21 0:17 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, Heiko Stuebner, linux-kernel, linux-rockchip, robh+dt,
linux-arm-kernel
In-Reply-To: <20200519111444.2208-1-jbx6244@gmail.com>
On Tue, 19 May 2020 13:14:44 +0200, Johan Jonker wrote:
> The 'pinctrl-names' property should contain a list of names
> to the assigned states. The value 'led_pins' in the gpio-leds
> node on rk3326-odroid-go2 is not a state that is normally used,
> so change it the common name 'default'.
Applied, thanks!
[1/1] arm64: dts: rockchip: fix pinctrl-names for gpio-leds node on rk3326-odroid-go2
commit: b2cb68e864222eb3cc1d7c3c06edc40469699983
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: bcm: HR2: Fix PPI interrupt types
From: Florian Fainelli @ 2020-05-21 0:16 UTC (permalink / raw)
To: Hamish Martin, robh+dt, rjui, sbranden; +Cc: devicetree, linux-arm-kernel
In-Reply-To: <20200520043042.7281-1-hamish.martin@alliedtelesis.co.nz>
On 5/19/2020 9:30 PM, Hamish Martin wrote:
> These error messages are output when booting on a BCM HR2 system:
> GIC: PPI11 is secure or misconfigured
> GIC: PPI13 is secure or misconfigured
>
> Per ARM documentation these interrupts are triggered on a rising edge.
> See ARM Cortex A-9 MPCore Technical Reference Manual, Revision r4p1,
> Section 3.3.8 Interrupt Configuration Registers.
>
> The same issue was resolved for NSP systems in commit 5f1aa51c7a1e
> ("ARM: dts: NSP: Fix PPI interrupt types").
>
> Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
> ---
Applied to devicetree/fixes, please copy
bcm-kernel-feedback-list@broadcom.com so we can have our CI pick up this
patch. Thanks!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 1/1] Broadcom devicetree fixes for 5.7 (part 2)
From: Florian Fainelli @ 2020-05-21 0:12 UTC (permalink / raw)
To: Florian Fainelli, soc, arnd, olof
Cc: Stefan Wahren, khilman, bcm-kernel-feedback-list,
linux-arm-kernel, Vincent Stehlé
In-Reply-To: <20200424224915.3541-1-f.fainelli@gmail.com>
Hi Arnd, Olof,
On 4/24/2020 3:49 PM, Florian Fainelli wrote:
> The following changes since commit 90444b958461a5f8fc299ece0fe17eab15cba1e1:
>
> ARM: dts: bcm283x: Disable dsi0 node (2020-04-16 13:58:02 -0700)
>
> are available in the Git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.7/devicetree-fixes-part2
>
> for you to fetch changes up to 2c972731a3d74a336519fb158fbe863caad5c421:
>
> ARM: dts: bcm2835-rpi-zero-w: Fix led polarity (2020-04-24 12:50:37 -0700)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM-based SoCs Device Tree fixes for
> 5.7, please pull the following:
>
> - Vincent fixes the polarity of the ACT LED on the Raspberry Pi Zero W
> board
>
> ----------------------------------------------------------------
> Vincent Stehlé (1):
> ARM: dts: bcm2835-rpi-zero-w: Fix led polarity
If you have not pulled this already (I could not find it in
linux-next/master or Linus' master), there is another one coming with
another fix.
Thanks!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
From: Suman Anna @ 2020-05-21 0:10 UTC (permalink / raw)
To: Bjorn Andersson, Rob Herring, Mathieu Poirier
Cc: devicetree, Lokesh Vutla, linux-remoteproc, linux-kernel,
Suman Anna, linux-arm-kernel
In-Reply-To: <20200521001006.2725-1-s-anna@ti.com>
Some Texas Instruments K3 family of SoCs have one of more Digital Signal
Processor (DSP) subsystems that are comprised of either a TMS320C66x
CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
Add the device tree bindings document for the C66x DSP devices on these
SoCs. The added example illustrates the DT nodes for the first C66x DSP
device present on the K3 J721E family of SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2:
- Updated the example to include the root-node to fix the bot errors from v1
- Added maxItems to resets, mboxes, memory-region, sram properties
- Changed the ti,sci-proc-ids $ref to uint-array from uint-matrix
- Addressed the minor review comments from Mathieu
v1: https://patchwork.kernel.org/patch/11458571/
.../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 190 ++++++++++++++++++
1 file changed, 190 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
new file mode 100644
index 000000000000..cdf649655838
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
@@ -0,0 +1,190 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI K3 DSP devices
+
+maintainers:
+ - Suman Anna <s-anna@ti.com>
+
+description: |
+ The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems
+ that are used to offload some of the processor-intensive tasks or algorithms,
+ for achieving various system level goals.
+
+ These processor sub-systems usually contain additional sub-modules like
+ L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external memory
+ controller, a dedicated local power/sleep controller etc. The DSP processor
+ cores in the K3 SoCs are usually either a TMS320C66x CorePac processor or a
+ TMS320C71x CorePac processor.
+
+ Each DSP Core sub-system is represented as a single DT node. Each node has a
+ number of required or optional properties that enable the OS running on the
+ host processor (Arm CorePac) to perform the device management of the remote
+ processor and to communicate with the remote processor.
+
+properties:
+ compatible:
+ const: ti,j721e-c66-dsp
+ description:
+ Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
+
+ reg:
+ description: |
+ Should contain an entry for each value in 'reg-names'.
+ Each entry should have the memory region's start address
+ and the size of the region, the representation matching
+ the parent node's '#address-cells' and '#size-cells' values.
+ minItems: 3
+ maxItems: 3
+
+ reg-names:
+ description: |
+ Should contain strings with the names of the specific internal
+ memory regions, and should be defined in this order
+ maxItems: 3
+ items:
+ - const: l2sram
+ - const: l1pram
+ - const: l1dram
+
+ ti,sci:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Should be a phandle to the TI-SCI System Controller node
+
+ ti,sci-dev-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Should contain the TI-SCI device id corresponding to the DSP core.
+ Please refer to the corresponding System Controller documentation
+ for valid values for the DSP cores.
+
+ ti,sci-proc-ids:
+ description: Should contain a single tuple of <proc_id host_id>.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - maxItems: 1
+ items:
+ items:
+ - description: TI-SCI processor id for the DSP core device
+ - description: TI-SCI host id to which processor control
+ ownership should be transferred to
+
+ resets:
+ description: |
+ Should contain the phandle to the reset controller node
+ managing the local resets for this device, and a reset
+ specifier. Please refer to the following reset bindings
+ for the reset argument specifier,
+ Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+ maxItems: 1
+
+ firmware-name:
+ description: |
+ Should contain the name of the default firmware image
+ file located on the firmware search path
+
+ mboxes:
+ description: |
+ OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+ communication with the remote processor. This property should match
+ with the sub-mailbox node used in the firmware image. The specifier
+ format is as per the bindings,
+ Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
+ maxItems: 1
+
+ memory-region:
+ minItems: 2
+ maxItems: 8
+ description: |
+ phandle to the reserved memory nodes to be associated with the remoteproc
+ device. There should be at least two reserved memory nodes defined - the
+ first one would be used for dynamic DMA allocations like vrings and vring
+ buffers, and the remaining ones used for the firmware image sections. The
+ reserved memory nodes should be carveout nodes, and should be defined as
+ per the bindings in
+ Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+
+# Optional properties:
+# --------------------
+
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 4
+ description: |
+ phandles to one or more reserved on-chip SRAM regions. The regions
+ should be defined as child nodes of the respective SRAM node, and
+ should be defined as per the generic bindings in,
+ Documentation/devicetree/bindings/sram/sram.yaml
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-proc-ids
+ - resets
+ - firmware-name
+ - mboxes
+ - memory-region
+
+additionalProperties: false
+
+examples:
+ - |
+ / {
+ model = "Texas Instruments K3 J721E SoC";
+ compatible = "ti,j721e";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ /* DSP Carveout reserved memory nodes */
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ c66_0_dma_memory_region: c66-dma-memory@a6000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa6000000 0x00 0x100000>;
+ no-map;
+ };
+
+ c66_0_memory_region: c66-memory@a6100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa6100000 0x00 0xf00000>;
+ no-map;
+ };
+ };
+
+ cbass_main: bus@100000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */
+ <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */
+ <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */
+
+ /* J721E C66_0 DSP node */
+ c66_0: dsp@4d80800000 {
+ compatible = "ti,j721e-c66-dsp";
+ reg = <0x4d 0x80800000 0x00 0x00048000>,
+ <0x4d 0x80e00000 0x00 0x00008000>,
+ <0x4d 0x80f00000 0x00 0x00008000>;
+ reg-names = "l2sram", "l1pram", "l1dram";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <142>;
+ ti,sci-proc-ids = <0x03 0xFF>;
+ resets = <&k3_reset 142 1>;
+ firmware-name = "j7-c66_0-fw";
+ memory-region = <&c66_0_dma_memory_region>,
+ <&c66_0_memory_region>;
+ mboxes = <&mailbox0_cluster3 &mbox_c66_0>;
+ };
+ };
+ };
--
2.26.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/4] remoteproc/k3-dsp: Add support for L2RAM loading on C66x DSPs
From: Suman Anna @ 2020-05-21 0:10 UTC (permalink / raw)
To: Bjorn Andersson, Rob Herring, Mathieu Poirier
Cc: devicetree, Lokesh Vutla, linux-remoteproc, linux-kernel,
Suman Anna, linux-arm-kernel
In-Reply-To: <20200521001006.2725-1-s-anna@ti.com>
The resets for the DSP processors on K3 SoCs are managed through the
Power and Sleep Controller (PSC) module. Each DSP typically has two
resets - a global module reset for powering on the device, and a local
reset that affects only the CPU while allowing access to the other
sub-modules within the DSP processor sub-systems.
The C66x DSPs have two levels of internal RAMs that can be used to
boot from, and the firmware loading into these RAMs require the
local reset to be asserted with the device powered on/enabled using
the module reset. Enhance the K3 DSP remoteproc driver to add support
for loading into the internal RAMs. The local reset is deasserted on
SoC power-on-reset, so logic has to be added in probe in remoteproc
mode to balance the remoteproc state-machine.
Note that the local resets are a no-op on C71x cores, and the hardware
does not supporting loading into its internal RAMs.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2:
- Dropped the local-reset no-op checks from k3_dsp_rproc_prepare/unprepare()
callbacks. The logic will be adjusted back in the C71 patch series.
- The C71 local reset references are also removed from the comments for the
k3_dsp_rproc_prepare() function.
v1: https://patchwork.kernel.org/patch/11458579/
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 72 +++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
index e4036f5992fe..610fbbf85ee6 100644
--- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
@@ -174,6 +174,9 @@ static int k3_dsp_rproc_reset(struct k3_dsp_rproc *kproc)
return ret;
}
+ if (kproc->data->uses_lreset)
+ return ret;
+
ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
kproc->ti_sci_id);
if (ret) {
@@ -191,6 +194,9 @@ static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
struct device *dev = kproc->dev;
int ret;
+ if (kproc->data->uses_lreset)
+ goto lreset;
+
ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
kproc->ti_sci_id);
if (ret) {
@@ -198,6 +204,7 @@ static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
return ret;
}
+lreset:
ret = reset_control_deassert(kproc->reset);
if (ret) {
dev_err(dev, "local-reset deassert failed, ret = %d\n", ret);
@@ -209,6 +216,53 @@ static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
return ret;
}
+/*
+ * The C66x DSP cores have a local reset that affects only the CPU, and a
+ * generic module reset that powers on the device and allows the DSP internal
+ * memories to be accessed while the local reset is asserted. This function is
+ * used to release the global reset on C66x DSPs to allow loading into the DSP
+ * internal RAMs. The .prepare() ops is invoked by remoteproc core before any
+ * firmware loading, and is followed by the .start() ops after loading to
+ * actually let the C66x DSP cores run.
+ */
+static int k3_dsp_rproc_prepare(struct rproc *rproc)
+{
+ struct k3_dsp_rproc *kproc = rproc->priv;
+ struct device *dev = kproc->dev;
+ int ret;
+
+ ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
+ kproc->ti_sci_id);
+ if (ret)
+ dev_err(dev, "module-reset deassert failed, cannot enable internal RAM loading, ret = %d\n",
+ ret);
+
+ return ret;
+}
+
+/*
+ * This function implements the .unprepare() ops and performs the complimentary
+ * operations to that of the .prepare() ops. The function is used to assert the
+ * global reset on applicable C66x cores. This completes the second portion of
+ * powering down the C66x DSP cores. The cores themselves are only halted in the
+ * .stop() callback through the local reset, and the .unprepare() ops is invoked
+ * by the remoteproc core after the remoteproc is stopped to balance the global
+ * reset.
+ */
+static int k3_dsp_rproc_unprepare(struct rproc *rproc)
+{
+ struct k3_dsp_rproc *kproc = rproc->priv;
+ struct device *dev = kproc->dev;
+ int ret;
+
+ ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
+ kproc->ti_sci_id);
+ if (ret)
+ dev_err(dev, "module-reset assert failed, ret = %d\n", ret);
+
+ return ret;
+}
+
/*
* Power up the DSP remote processor.
*
@@ -352,6 +406,8 @@ static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
}
static const struct rproc_ops k3_dsp_rproc_ops = {
+ .prepare = k3_dsp_rproc_prepare,
+ .unprepare = k3_dsp_rproc_unprepare,
.start = k3_dsp_rproc_start,
.stop = k3_dsp_rproc_stop,
.kick = k3_dsp_rproc_kick,
@@ -614,6 +670,22 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
goto release_tsp;
}
+ /*
+ * ensure the DSP local reset is asserted to ensure the DSP doesn't
+ * execute bogus code in .prepare() when the module reset is released.
+ */
+ if (data->uses_lreset) {
+ ret = reset_control_status(kproc->reset);
+ if (ret < 0) {
+ dev_err(dev, "failed to get reset status, status = %d\n",
+ ret);
+ goto release_mem;
+ } else if (ret == 0) {
+ dev_warn(dev, "local reset is deasserted for device\n");
+ k3_dsp_rproc_reset(kproc);
+ }
+ }
+
ret = rproc_add(rproc);
if (ret) {
dev_err(dev, "failed to add register device with remoteproc core, status = %d\n",
--
2.26.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/4] TI K3 DSP remoteproc driver for C66x DSPs
From: Suman Anna @ 2020-05-21 0:10 UTC (permalink / raw)
To: Bjorn Andersson, Rob Herring, Mathieu Poirier
Cc: devicetree, Lokesh Vutla, linux-remoteproc, linux-kernel,
Suman Anna, linux-arm-kernel
Hi All,
The following is v2 of the K3 DSP remoteproc driver supporting the C66x DSPs
on the TI K3 J721E SoCs. The patches are based on the latest commit on the
rproc-next branch, 7dcef3988eed ("remoteproc: Fix an error code in
devm_rproc_alloc()").
v2 includes a new remoteproc core patch (patch 1) that adds an OF helper
for parsing the firmware-name property. This is refactored out to avoid
replicating the code in various remoteproc drivers. Please see the
individual patches for detailed changes.
The main dependent patches from the previous series are now staged in
rproc-next branch. The only dependency for this series is the common
ti-sci-proc helper between R5 and DSP drivers [1]. Please see the initial
cover-letter [2] for v1 details.
regards
Suman
[1] https://patchwork.kernel.org/patch/11456379/
[2] https://patchwork.kernel.org/cover/11458573/
Suman Anna (4):
remoteproc: Introduce rproc_of_parse_firmware() helper
dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
remoteproc/k3-dsp: Add a remoteproc driver of K3 C66x DSPs
remoteproc/k3-dsp: Add support for L2RAM loading on C66x DSPs
.../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 190 +++++
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/remoteproc_core.c | 23 +
drivers/remoteproc/remoteproc_internal.h | 2 +
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 773 ++++++++++++++++++
6 files changed, 1002 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
create mode 100644 drivers/remoteproc/ti_k3_dsp_remoteproc.c
--
2.26.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox