* Re: [PATCH v4 0/4] Add device links to clocks
From: Stephen Boyd @ 2019-08-14 18:41 UTC (permalink / raw)
To: Miquel Raynal
Cc: Gregory Clement, Antoine Tenart, Michael Turquette, linux-kernel,
Russell King, Nadav Haklai, Thomas Petazzoni, Maxime Chevallier,
linux-clk, linux-arm-kernel
In-Reply-To: <20190727105330.44cc7f2f@xps13>
Quoting Miquel Raynal (2019-07-27 01:53:30)
>
> I know this series might have side effects despite the consequent
> amount of time spent to write and test it, but I also think the
> clk subsystem would really benefit from such change and handling
> suspend to RAM support would be greatly enhanced. You seemed
> interested at first and now not anymore, could I know why? I got
> inspired by the regulators subsystem. It is not an idea of mine
> that device links should be bring to clocks. Regulators are almost
> as used as clocks so I really understand your fears but why not
> applying this to -next very early during the -rc cycles and see
> what happens? You'll have plenty of time to ask me to fix things
> or even drop it off.
>
Ok, I'm back on this topic. Let me look at the latest code and see how
it works on a qcom platform I have in hand. If the device links look OK
then it should be good. I also want to make sure we're not holding a
nested pile of locks when we're adding the device links so that we don't
get some weird lockdep problems.
_______________________________________________
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 1/2] arm64: Add initial support for E0PD
From: Mark Brown @ 2019-08-14 18:31 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Brown, linux-arm-kernel, Suzuki K Poulose
In-Reply-To: <20190814183103.33707-1-broonie@kernel.org>
Kernel Page Table Isolation (KPTI) is used to mitigate some speculation
based security issues by ensuring that the kernel is not mapped when
userspace is running but this approach is expensive and is incompatible
with SPE. E0PD, introduced in the ARMv8.5 extensions, provides an
alternative to this which ensures that accesses from userspace to the
kernel's half of the memory map to always fault with constant time,
preventing timing attacks without requiring constant unmapping and
remapping or preventing legitimate accesses.
This initial patch does not yet integrate with KPTI, this will be dealt
with in followup patches. Ideally we could ensure that by default we
don't use KPTI on CPUs where E0PD is present.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Tweak the Kconfig text as suggested by Will.
arch/arm64/Kconfig | 15 ++++++++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/pgtable-hwdef.h | 2 ++
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/kernel/cpufeature.c | 27 ++++++++++++++++++++++++++
5 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 12de5c6075ec..7bf403405c99 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1392,6 +1392,21 @@ config ARM64_PTR_AUTH
endmenu
+menu "ARMv8.5 architectural features"
+
+config ARM64_E0PD
+ bool "Enable support for E0PD"
+ default y
+ help
+ E0PD (part of the ARMv8.5 extensions) allows us to ensure
+ that EL0 accesses made via TTBR1 always fault in constant time,
+ providing benefits to KPTI with lower overhead and without
+ disrupting legitimate access to kernel memory such as SPE.
+
+ This option enables E0PD for TTBR1 where available.
+
+endmenu
+
config ARM64_SVE
bool "ARM Scalable Vector Extension support"
default y
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index f19fe4b9acc4..f25388981075 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -52,7 +52,8 @@
#define ARM64_HAS_IRQ_PRIO_MASKING 42
#define ARM64_HAS_DCPODP 43
#define ARM64_WORKAROUND_1463225 44
+#define ARM64_HAS_E0PD 45
-#define ARM64_NCAPS 45
+#define ARM64_NCAPS 46
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
index db92950bb1a0..1a2708ebcae8 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -292,6 +292,8 @@
#define TCR_HD (UL(1) << 40)
#define TCR_NFD0 (UL(1) << 53)
#define TCR_NFD1 (UL(1) << 54)
+#define TCR_E0PD0 (UL(1) << 55)
+#define TCR_E0PD1 (UL(1) << 56)
/*
* TTBR.
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 1df45c7ffcf7..37a0926536d3 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -652,6 +652,7 @@
#define ID_AA64MMFR1_VMIDBITS_16 2
/* id_aa64mmfr2 */
+#define ID_AA64MMFR2_E0PD_SHIFT 60
#define ID_AA64MMFR2_FWB_SHIFT 40
#define ID_AA64MMFR2_AT_SHIFT 32
#define ID_AA64MMFR2_LVA_SHIFT 16
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9323bcc40a58..62b01fc35ef6 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -219,6 +219,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
};
static const struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_E0PD_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_FWB_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_AT_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_LVA_SHIFT, 4, 0),
@@ -1244,6 +1245,19 @@ static void cpu_enable_address_auth(struct arm64_cpu_capabilities const *cap)
}
#endif /* CONFIG_ARM64_PTR_AUTH */
+#ifdef CONFIG_ARM64_E0PD
+static void cpu_enable_e0pd(struct arm64_cpu_capabilities const *cap)
+{
+ /*
+ * The cpu_enable() callback gets called even on CPUs that
+ * don't detect the feature so we need to verify if we can
+ * enable.
+ */
+ if (this_cpu_has_cap(ARM64_HAS_E0PD))
+ sysreg_clear_set(tcr_el1, 0, TCR_E0PD1);
+}
+#endif /* CONFIG_ARM64_E0PD */
+
#ifdef CONFIG_ARM64_PSEUDO_NMI
static bool enable_pseudo_nmi;
@@ -1559,6 +1573,19 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.sign = FTR_UNSIGNED,
.min_field_value = 1,
},
+#endif
+#ifdef CONFIG_ARM64_E0PD
+ {
+ .desc = "E0PD",
+ .capability = ARM64_HAS_E0PD,
+ .type = ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE,
+ .sys_reg = SYS_ID_AA64MMFR2_EL1,
+ .sign = FTR_UNSIGNED,
+ .field_pos = ID_AA64MMFR2_E0PD_SHIFT,
+ .matches = has_cpuid_feature,
+ .min_field_value = 1,
+ .cpu_enable = cpu_enable_e0pd,
+ },
#endif
{},
};
--
2.20.1
_______________________________________________
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 2/2] arm64: Don't use KPTI where we have E0PD
From: Mark Brown @ 2019-08-14 18:31 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Brown, linux-arm-kernel, Suzuki K Poulose
In-Reply-To: <20190814183103.33707-1-broonie@kernel.org>
Since E0PD is intended to fulfil the same role as KPTI we don't need to
use KPTI on CPUs where E0PD is available, we can rely on E0PD instead.
Change the check that forces KPTI on when KASLR is enabled to check for
E0PD before doing so, CPUs with E0PD are not expected to be affected by
meltdown so should not need to enable KPTI for other reasons.
Since we repeat the KPTI check for all CPUs we will still enable KPTI if
any of the CPUs in the system lacks E0PD. Since KPTI itself is not changed
by this patch once we enable KPTI we will do so for all CPUs. This is safe
but not optimally performant for such systems.
In order to ensure that we don't install any non-global mappings in
cases where we use E0PD for the system instead we add a check for E0PD
to the early checks in arm64_kernel_use_ng_mappings(), not installing NG
mappings if the current CPU has E0PD. This will incur an overhead on
systems where the boot CPU has E0PD but some others do not, however it
is expected that systems with very large memories which benefit most
from this optimization will be symmetric.
KPTI can still be forced on from the command line if required.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Added a check in arm64_kernel_use_ng_mappings() to suppress non-global
mappings when E0PD is present and KPTI isn't forced on.
arch/arm64/include/asm/mmu.h | 13 ++++++++++++-
arch/arm64/kernel/cpufeature.c | 2 +-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index fd6161336653..85552f6fceda 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -38,6 +38,7 @@ static inline bool arm64_kernel_unmapped_at_el0(void)
static inline bool arm64_kernel_use_ng_mappings(void)
{
bool tx1_bug;
+ u64 ftr;
/* What's a kpti? Use global mappings if we don't know. */
if (!IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0))
@@ -59,7 +60,7 @@ static inline bool arm64_kernel_use_ng_mappings(void)
* KASLR is enabled so we're going to be enabling kpti on non-broken
* CPUs regardless of their susceptibility to Meltdown. Rather
* than force everybody to go through the G -> nG dance later on,
- * just put down non-global mappings from the beginning.
+ * just put down non-global mappings from the beginning...
*/
if (!IS_ENABLED(CONFIG_CAVIUM_ERRATUM_27456)) {
tx1_bug = false;
@@ -74,6 +75,16 @@ static inline bool arm64_kernel_use_ng_mappings(void)
tx1_bug = __cpus_have_const_cap(ARM64_WORKAROUND_CAVIUM_27456);
}
+ /*
+ * ...unless we have E0PD in which case we may use that in
+ * preference to unmapping the kernel.
+ */
+ if (IS_ENABLED(CONFIG_ARM64_E0PD)) {
+ ftr = read_sysreg_s(SYS_ID_AA64MMFR2_EL1);
+ if ((ftr >> ID_AA64MMFR2_E0PD_SHIFT) & 0xf)
+ return false;
+ }
+
return !tx1_bug && kaslr_offset() > 0;
}
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 62b01fc35ef6..6bed144867ad 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1003,7 +1003,7 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
/* Useful for KASLR robustness */
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && kaslr_offset() > 0) {
- if (!__kpti_forced) {
+ if (!__kpti_forced && !this_cpu_has_cap(ARM64_HAS_E0PD)) {
str = "KASLR";
__kpti_forced = 1;
}
--
2.20.1
_______________________________________________
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/2] arm64: E0PD support
From: Mark Brown @ 2019-08-14 18:31 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon; +Cc: linux-arm-kernel, Suzuki K Poulose
This series adds support for E0PD. We enable E0PD unconditionally where
present and on systems where all the CPUs in the system support E0PD we
will not automatically enable KPTI for KASLR. The integration with KPTI
is safe but not optimal for big.LITTLE systems where only some CPUs
support E0PD since for them it will still use KPTI even on the CPUs that
have E0PD, I've not yet come up with something I like for integrating
support for them with the command line overrides.
Mark Brown (2):
arm64: Add initial support for E0PD
arm64: Don't use KPTI where we have E0PD
arch/arm64/Kconfig | 15 +++++++++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/mmu.h | 13 ++++++++++++-
arch/arm64/include/asm/pgtable-hwdef.h | 2 ++
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/kernel/cpufeature.c | 29 ++++++++++++++++++++++++++++-
6 files changed, 60 insertions(+), 3 deletions(-)
_______________________________________________
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 1/6] arm64: unexport set_memory_x and set_memory_nx
From: Christoph Hellwig @ 2019-08-14 18:22 UTC (permalink / raw)
To: Will Deacon
Cc: Dave Hansen, Peter Zijlstra, Catalin Marinas, x86, linux-kernel,
Andy Lutomirski, Christoph Hellwig, linux-arm-kernel
In-Reply-To: <20190814165029.yfmpopn34vxpnmte@willie-the-truck>
On Wed, Aug 14, 2019 at 05:50:29PM +0100, Will Deacon wrote:
> arm64 allmodconfig and defconfig are happy with this, so I'll pick it up
> for 5.4 if that's ok with you?
Sounds great.
_______________________________________________
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 04/15] iommu/arm-smmu: Rework cb_base handling
From: Will Deacon @ 2019-08-14 18:05 UTC (permalink / raw)
To: Robin Murphy
Cc: robdclark, joro, bjorn.andersson, iommu, vivek.gautam,
gregory.clement, linux-arm-kernel
In-Reply-To: <f4dccad78815ca0a2dd7926be7052759d099b920.1565369764.git.robin.murphy@arm.com>
On Fri, Aug 09, 2019 at 06:07:41PM +0100, Robin Murphy wrote:
> To keep register-access quirks manageable, we want to structure things
> to avoid needing too many individual overrides. It seems fairly clean to
> have a single interface which handles both global and context registers
> in terms of the architectural pages, so the first preparatory step is to
> rework cb_base into a page number rather than an absolute address.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu.c | 22 ++++++++++++----------
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index d9a93e5f422f..463bc8d98adb 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -95,7 +95,7 @@
> #endif
>
> /* Translation context bank */
> -#define ARM_SMMU_CB(smmu, n) ((smmu)->cb_base + ((n) << (smmu)->pgshift))
> +#define ARM_SMMU_CB(smmu, n) ((smmu)->base + (((smmu)->cb_base + (n)) << (smmu)->pgshift))
>
> #define MSI_IOVA_BASE 0x8000000
> #define MSI_IOVA_LENGTH 0x100000
> @@ -168,8 +168,8 @@ struct arm_smmu_device {
> struct device *dev;
>
> void __iomem *base;
> - void __iomem *cb_base;
> - unsigned long pgshift;
> + unsigned int cb_base;
I think this is now a misnomer. Would you be able to rename it cb_pfn or
something, please?
Otherwise, this seems fine.
Will
_______________________________________________
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 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Mathieu Poirier @ 2019-08-14 18:04 UTC (permalink / raw)
To: Igor Lubashev
Cc: Suzuki K Poulose, Peter Zijlstra, Alexey Budankov,
Linux Kernel Mailing List, Arnaldo Carvalho de Melo, James Morris,
Alexander Shishkin, Ingo Molnar, Namhyung Kim, Jiri Olsa,
linux-arm-kernel
In-Reply-To: <291d2cda6ee75b4cd4c9ce717c177db18bf03a31.1565188228.git.ilubashe@akamai.com>
On Wed, 7 Aug 2019 at 08:44, Igor Lubashev <ilubashe@akamai.com> wrote:
>
> Kernel is using CAP_SYSLOG capability instead of uid==0 and euid==0 when
> checking kptr_restrict. Make perf do the same.
>
> Also, the kernel is a more restrictive than "no restrictions" in case of
> kptr_restrict==0, so add the same logic to perf.
>
> Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
> ---
> tools/perf/util/symbol.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 173f3378aaa0..046271103499 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -4,6 +4,7 @@
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
> +#include <linux/capability.h>
> #include <linux/kernel.h>
> #include <linux/mman.h>
> #include <linux/time64.h>
> @@ -15,8 +16,10 @@
> #include <inttypes.h>
> #include "annotate.h"
> #include "build-id.h"
> +#include "cap.h"
> #include "util.h"
> #include "debug.h"
> +#include "event.h"
> #include "machine.h"
> #include "map.h"
> #include "symbol.h"
> @@ -890,7 +893,11 @@ bool symbol__restricted_filename(const char *filename,
> {
> bool restricted = false;
>
> - if (symbol_conf.kptr_restrict) {
> + /* Per kernel/kallsyms.c:
> + * we also restrict when perf_event_paranoid > 1 w/o CAP_SYSLOG
> + */
> + if (symbol_conf.kptr_restrict ||
> + (perf_event_paranoid() > 1 && !perf_cap__capable(CAP_SYSLOG))) {
> char *r = realpath(filename, NULL);
>
# echo 0 > /proc/sys/kernel/kptr_restrict
# ./tools/perf/perf record -e instructions:k uname
perf: Segmentation fault
Obtained 10 stack frames.
./tools/perf/perf(sighandler_dump_stack+0x44) [0x55af9e5da5d4]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7fd31efb6f20]
./tools/perf/perf(perf_event__synthesize_kernel_mmap+0xa7) [0x55af9e590337]
./tools/perf/perf(+0x1cf5be) [0x55af9e50c5be]
./tools/perf/perf(cmd_record+0x1022) [0x55af9e50dff2]
./tools/perf/perf(+0x23f98d) [0x55af9e57c98d]
./tools/perf/perf(+0x23fc9e) [0x55af9e57cc9e]
./tools/perf/perf(main+0x369) [0x55af9e4f6bc9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7fd31ef99b97]
./tools/perf/perf(_start+0x2a) [0x55af9e4f704a]
Segmentation fault
I can reproduce this on both x86 and ARM64.
> if (r != NULL) {
> @@ -2190,9 +2197,9 @@ static bool symbol__read_kptr_restrict(void)
> char line[8];
>
> if (fgets(line, sizeof(line), fp) != NULL)
> - value = ((geteuid() != 0) || (getuid() != 0)) ?
> - (atoi(line) != 0) :
> - (atoi(line) == 2);
> + value = perf_cap__capable(CAP_SYSLOG) ?
> + (atoi(line) >= 2) :
> + (atoi(line) != 0);
>
> fclose(fp);
> }
> --
> 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
* Re: [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Steve Capper @ 2019-08-14 17:53 UTC (permalink / raw)
To: Mark Rutland
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, Catalin Marinas,
bhsharma@redhat.com, maz@kernel.org, Andrey Ryabinin, nd,
Will Deacon, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190814160324.GE51963@lakrids.cambridge.arm.com>
On Wed, Aug 14, 2019 at 05:03:24PM +0100, Mark Rutland wrote:
> On Wed, Aug 14, 2019 at 04:57:11PM +0100, Will Deacon wrote:
> > On Wed, Aug 14, 2019 at 04:20:18PM +0100, Mark Rutland wrote:
> > > On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> > > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > > > index b2400f9c1213..2b7db0d41498 100644
> > > > --- a/arch/arm64/Makefile
> > > > +++ b/arch/arm64/Makefile
> > > > @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > > KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > >
> > > > -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> > > > -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> > > > -# in 32-bit arithmetic
> > > > -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> > > > - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> > > > - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> > > > - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> > > > -
> > > > export TEXT_OFFSET GZFLAGS
> > > >
> > > > core-y += arch/arm64/kernel/ arch/arm64/mm/
> > >
> > > I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
> > > CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
> > > CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
> > > CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
> > > regardless.
> > >
> > > I think that's by accident rather than by design, but to
> > > minimize/localize the fixup, how about the below? I can send a cleanup
> > > patch for scripts/Makefile.kasan later.
> >
> > How much work is that? I've dropped this stuff from -next for now, so we
> > have time to fix it properly as long as it's not going to take weeks.
>
> I wrote it first, so no effort; patch below.
>
> Andrey, would you be happy with this?
>
> Thanks,
> Mark.
FWIW, this one worked well for me too (52-bit VA runtime, SW TAGS +
GENERIC both inlined).
Tested-by: Steve Capper <steve.capper@arm.com>
Cheers,
--
Steve
_______________________________________________
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/15] iommu/arm-smmu: Convert GR0 registers to bitfields
From: Robin Murphy @ 2019-08-14 17:35 UTC (permalink / raw)
To: Will Deacon
Cc: gregory.clement, iommu, bjorn.andersson, robdclark, vivek.gautam,
joro, linux-arm-kernel
In-Reply-To: <20190814172030.accr7azgkkkwumt2@willie-the-truck>
On 14/08/2019 18:20, Will Deacon wrote:
> On Fri, Aug 09, 2019 at 06:07:38PM +0100, Robin Murphy wrote:
>> FIELD_PREP remains a terrible name, but the overall simplification will
>> make further work on this stuff that much more manageable. This also
>> serves as an audit of the header, wherein we can impose a consistent
>> grouping and ordering of the offset and field definitions
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/arm-smmu-regs.h | 126 ++++++++++++++++------------------
>> drivers/iommu/arm-smmu.c | 51 +++++++-------
>> 2 files changed, 84 insertions(+), 93 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-regs.h b/drivers/iommu/arm-smmu-regs.h
>> index 1c278f7ae888..d189f025537a 100644
>> --- a/drivers/iommu/arm-smmu-regs.h
>> +++ b/drivers/iommu/arm-smmu-regs.h
>> @@ -10,111 +10,101 @@
>> #ifndef _ARM_SMMU_REGS_H
>> #define _ARM_SMMU_REGS_H
>>
>> +#include <linux/bits.h>
>> +
>> /* Configuration registers */
>> #define ARM_SMMU_GR0_sCR0 0x0
>> -#define sCR0_CLIENTPD (1 << 0)
>> -#define sCR0_GFRE (1 << 1)
>> -#define sCR0_GFIE (1 << 2)
>> -#define sCR0_EXIDENABLE (1 << 3)
>> -#define sCR0_GCFGFRE (1 << 4)
>> -#define sCR0_GCFGFIE (1 << 5)
>> -#define sCR0_USFCFG (1 << 10)
>> -#define sCR0_VMIDPNE (1 << 11)
>> -#define sCR0_PTM (1 << 12)
>> -#define sCR0_FB (1 << 13)
>> -#define sCR0_VMID16EN (1 << 31)
>> -#define sCR0_BSU_SHIFT 14
>> -#define sCR0_BSU_MASK 0x3
>> +#define sCR0_VMID16EN BIT(31)
>> +#define sCR0_BSU GENMASK(15, 14)
>> +#define sCR0_FB BIT(13)
>> +#define sCR0_PTM BIT(12)
>> +#define sCR0_VMIDPNE BIT(11)
>> +#define sCR0_USFCFG BIT(10)
>> +#define sCR0_GCFGFIE BIT(5)
>> +#define sCR0_GCFGFRE BIT(4)
>> +#define sCR0_EXIDENABLE BIT(3)
>> +#define sCR0_GFIE BIT(2)
>> +#define sCR0_GFRE BIT(1)
>> +#define sCR0_CLIENTPD BIT(0)
>>
>> /* Auxiliary Configuration register */
>> #define ARM_SMMU_GR0_sACR 0x10
>>
>> /* Identification registers */
>> #define ARM_SMMU_GR0_ID0 0x20
>> +#define ID0_S1TS BIT(30)
>> +#define ID0_S2TS BIT(29)
>> +#define ID0_NTS BIT(28)
>> +#define ID0_SMS BIT(27)
>> +#define ID0_ATOSNS BIT(26)
>> +#define ID0_PTFS_NO_AARCH32 BIT(25)
>> +#define ID0_PTFS_NO_AARCH32S BIT(24)
>> +#define ID0_CTTW BIT(14)
>> +#define ID0_NUMIRPT GENMASK(23, 16)
>
> nit: assuming this should be above ID0_CTTW so things are in descending
> bit order?
Bah, indeed it should. Fixed now.
> Other than that, looks good to me.
Thanks!
Robin.
_______________________________________________
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 07/15] drm/mxsfb: Fix the vblank events
From: Daniel Vetter @ 2019-08-14 17:31 UTC (permalink / raw)
To: Robert Chiras
Cc: Marek Vasut, Mark Rutland, Pengutronix Kernel Team, dri-devel,
devicetree, David Airlie, Fabio Estevam, Guido Günther,
linux-kernel, Stefan Agner, Rob Herring, NXP Linux Team,
Daniel Vetter, Shawn Guo, Sascha Hauer, linux-arm-kernel
In-Reply-To: <1565779731-1300-8-git-send-email-robert.chiras@nxp.com>
On Wed, Aug 14, 2019 at 01:48:43PM +0300, Robert Chiras wrote:
> Currently, the vblank support is not correctly implemented in MXSFB_DRM
> driver. The call to drm_vblank_init is made with mode_config.num_crtc
> which at that time is 0. Because of this, vblank is not activated, so
> there won't be any vblank event submitted.
> For example, when running modetest with the '-v' parameter will result
> in an astronomical refresh rate (10000+ Hz), because of that.
Uh, that sounds a bit like a bug somewhere. If vblank doesn't work, we
should give userspace an error back.
Maybe we need more checks in drm_vblank_init()? Can you pls look into
that?
>
> Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 2743975..829abec 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -38,6 +38,9 @@
> #include "mxsfb_drv.h"
> #include "mxsfb_regs.h"
>
> +/* The eLCDIF max possible CRTCs */
> +#define MAX_CRTCS 1
> +
> enum mxsfb_devtype {
> MXSFB_V3,
> MXSFB_V4,
> @@ -138,6 +141,8 @@ static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
> mxsfb->connector = &mxsfb->panel_connector;
> }
>
> + drm_crtc_vblank_on(&pipe->crtc);
> +
> pm_runtime_get_sync(drm->dev);
> drm_panel_prepare(mxsfb->panel);
> mxsfb_crtc_enable(mxsfb);
> @@ -164,6 +169,8 @@ static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
> }
> spin_unlock_irq(&drm->event_lock);
>
> + drm_crtc_vblank_off(&pipe->crtc);
> +
> if (mxsfb->connector != &mxsfb->panel_connector)
> mxsfb->connector = NULL;
> }
> @@ -246,7 +253,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long flags)
>
> pm_runtime_enable(drm->dev);
>
> - ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
> + ret = drm_vblank_init(drm, MAX_CRTCS);
> if (ret < 0) {
> dev_err(drm->dev, "Failed to initialise vblank\n");
> goto err_vblank;
> @@ -269,6 +276,8 @@ static int mxsfb_load(struct drm_device *drm, unsigned long flags)
> goto err_vblank;
> }
>
> + drm_crtc_vblank_off(&mxsfb->pipe.crtc);
Are you sure you need this one here? vblanks should be off after
drm_vblank_init() is called.
Thanks, Daniel
> +
> /*
> * Attach panel only if there is one.
> * If there is no panel attach, it must be a bridge. In this case, we
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
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] drm/aspeed: gfc_crtc: Make structure aspeed_gfx_funcs constant
From: Daniel Vetter @ 2019-08-14 17:27 UTC (permalink / raw)
To: Nishka Dasgupta
Cc: linux-aspeed, airlied, dri-devel, andrew, joel, daniel,
linux-arm-kernel
In-Reply-To: <20190813063355.25549-1-nishkadg.linux@gmail.com>
On Tue, Aug 13, 2019 at 12:03:55PM +0530, Nishka Dasgupta wrote:
> The static structure aspeed_gfx_funcs, of type
> drm_simple_display_pipe_funcs, is used only as an argument to
> drm_simple_display_pipe_init(), which does not modify it. Hence make it
> constant to protect it from unintended modification.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Applied, thanks for your patch.
> ---
> drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> index 15db9e426ec4..2184b8be6fd4 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> @@ -215,7 +215,7 @@ static void aspeed_gfx_disable_vblank(struct drm_simple_display_pipe *pipe)
> writel(reg | CRT_CTRL_VERTICAL_INTR_STS, priv->base + CRT_CTRL1);
> }
>
> -static struct drm_simple_display_pipe_funcs aspeed_gfx_funcs = {
> +static const struct drm_simple_display_pipe_funcs aspeed_gfx_funcs = {
> .enable = aspeed_gfx_pipe_enable,
> .disable = aspeed_gfx_pipe_disable,
> .update = aspeed_gfx_pipe_update,
> --
> 2.19.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Explicitly marking initializer overrides (was "Re: [PATCH] arm64/cache: silence -Woverride-init warnings")
From: Nathan Chancellor @ 2019-08-14 17:26 UTC (permalink / raw)
To: Mark Rutland
Cc: catalin.marinas, linux-kernel, clang-built-linux, Qian Cai, will,
linux-arm-kernel
In-Reply-To: <20190809083251.GA48423@lakrids.cambridge.arm.com>
On Fri, Aug 09, 2019 at 09:32:51AM +0100, Mark Rutland wrote:
> On Thu, Aug 08, 2019 at 10:09:16AM -0700, Nathan Chancellor wrote:
> > On Thu, Aug 08, 2019 at 11:38:08AM +0100, Mark Rutland wrote:
> > > On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
> > > > The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> > > > VIVT I-caches") introduced some compiation warnings from GCC (and
> > > > Clang) with -Winitializer-overrides),
> > > >
> > > > arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> > > > overwritten [-Woverride-init]
> > > > [ICACHE_POLICY_VIPT] = "VIPT",
> > > > ^~~~~~
> > > > arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> > > > 'icache_policy_str[2]')
> > > > arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> > > > overwritten [-Woverride-init]
> > > > [ICACHE_POLICY_PIPT] = "PIPT",
> > > > ^~~~~~
> > > > arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> > > > 'icache_policy_str[3]')
> > > > arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> > > > overwritten [-Woverride-init]
> > > > [ICACHE_POLICY_VPIPT] = "VPIPT",
> > > > ^~~~~~~
> > > > arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> > > > 'icache_policy_str[0]')
> > > >
> > > > because it initializes icache_policy_str[0 ... 3] twice. Since
> > > > arm64 developers are keen to keep the style of initializing a static
> > > > array with a non-zero pattern first, just disable those warnings for
> > > > both GCC and Clang of this file.
> > > >
> > > > Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
> > > > Signed-off-by: Qian Cai <cai@lca.pw>
> > >
> > > This is _not_ a fix, and should not require backporting to stable trees.
> > >
> > > What about all the other instances that we have in mainline?
> > >
> > > I really don't think that we need to go down this road; we're just going
> > > to end up adding this to every file that happens to include a header
> > > using this scheme...
> > >
> > > Please just turn this off by default for clang.
> > >
> > > If we want to enable this, we need a mechanism to permit overridable
> > > assignments as we use range initializers for.
> > >
> > > Thanks,
> > > Mark.
> > >
> >
> > For what it's worth, this is disabled by default for clang in the
> > kernel:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.extrawarn?h=v5.3-rc3#n69
> >
> > It only becomes visible with clang at W=1 because that section doesn't
> > get applied. It becomes visible with GCC at W=1 because of -Wextra.
>
> Thanks for clarifying that!
>
> Do you know if there's any existing mechanism that we can use to silence
> the warning on a per-assignment basis? Either to say that an assignment
> can be overridden, or that the assignment is expected to override an
> existing assignment?
>
I don't think there is, from the brief amount of research I did.
> If not, who would be able to look at adding a mechanism to clang for
> this?
>
I've filed https://github.com/ClangBuiltLinux/linux/issues/639 on our
issue tracker so that I can try to remember to distill all of this
down and file an LLVM bug.
> If we could have some attribute or intrinsic that we could wrap like:
>
> struct foo f = {
> .bar __defaultval = <default>,
> .bar = <newval>, // no warning
> .bar = <anotherval>, // warning
> };
>
> ... or:
>
> struct foo f = {
> .bar = <default>,
> .bar __override = <newval>, // no warning
> .bar = <anotherval>, // warning
> };
>
> ... or:
>
> .bar = OVERRIDE(<newval>), // no warning
>
> ... or:
> OVERRIDE(.bar) = <newval>, // no warning
>
> ... then I think it would be possible to make use of the warning
> effectively, as we could distinguish intentional overrides from
> unintentional ones, and annotating assignments in this way doesn't seem
> onerous to me.
>
> Thanks,
> Mark.
I definitely think it is an interesting idea, hopefully some of our
resident clang experts can weigh in and see how feasible it would be to
implement.
Cheers,
Nathan
_______________________________________________
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] firmware: arm_scmi: updates for v5.4
From: Sudeep Holla @ 2019-08-14 17:24 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML
Cc: Olof Johansson, Kevin Hilman, Arnd Bergmann, Sudeep Holla
Hi ARM SoC Team,
Please pull !
There are minor changes in clock and hwmon subsystems that are Acked-by
Stephen Boyd and Guenter Roeck. It also contains a new reset driver that
is reviewed by Philipp Zabel. Further all these are in -next for a while.
Regards,
Sudeep
-->8
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-updates-5.4
for you to fetch changes up to c8ae9c2da1cc5d18b6d51d10160508a3dc3436bf:
reset: Add support for resets provided by SCMI (2019-08-12 12:23:02 +0100)
----------------------------------------------------------------
ARM SCMI updates/fixes for v5.4
Handful of fixes/updates including:
1. SCMI v2.0(recently released) support for:
- Performance protocol fast channels
- Reset Management Protocol
2. SCMI infrastructure/core support for recieve(Rx) channels,
asynchronous commands and delayed response
3. Usage of asynchronous commands for clock rate setting and sensor
reading based on the attributes read from the firmware
4. Miscellaneous cleanups(typos, naming alignment with specification,
and SPDX License identifier)
5. Couple of fixes: removal of extra check for invalid length and
additional check to ensure platform/firmware has released shared
memory before using it in OSPM
----------------------------------------------------------------
Sudeep Holla (22):
firmware: arm_scmi: Use the correct style for SPDX License Identifier
firmware: arm_scmi: Align few names in sensors protocol with SCMI specification
firmware: arm_scmi: Remove extra check for invalid length message responses
firmware: arm_scmi: Fix few trivial typos in comments
firmware: arm_scmi: Use the term 'message' instead of 'command'
firmware: arm_scmi: Check if platform has released shmem before using
firmware: arm_scmi: Reorder some functions to avoid forward declarations
firmware: arm_scmi: Segregate tx channel handling and prepare to add rx
firmware: arm_scmi: Add receive channel support for notifications
firmware: arm_scmi: Separate out tx buffer handling and prepare to add rx
firmware: arm_scmi: Add mechanism to unpack message headers
firmware: arm_scmi: Add support for asynchronous commands and delayed response
firmware: arm_scmi: Drop async flag in sensor_ops->reading_get
firmware: arm_scmi: Add asynchronous sensor read if it supports
firmware: arm_scmi: Drop config flag in clk_ops->rate_set
firmware: arm_scmi: Use asynchronous CLOCK_RATE_SET when possible
firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessors
firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels
firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol
dt-bindings: arm: Extend SCMI to support new reset protocol
firmware: arm_scmi: Add RESET protocol in SCMI v2.0
reset: Add support for resets provided by SCMI
Documentation/devicetree/bindings/arm/arm,scmi.txt | 17 +
MAINTAINERS | 1 +
drivers/clk/clk-scmi.c | 2 +-
drivers/firmware/arm_scmi/Makefile | 2 +-
drivers/firmware/arm_scmi/base.c | 2 +-
drivers/firmware/arm_scmi/clock.c | 33 +-
drivers/firmware/arm_scmi/common.h | 18 +-
drivers/firmware/arm_scmi/driver.c | 366 +++++++++++++--------
drivers/firmware/arm_scmi/perf.c | 264 ++++++++++++++-
drivers/firmware/arm_scmi/power.c | 6 +-
drivers/firmware/arm_scmi/reset.c | 231 +++++++++++++
drivers/firmware/arm_scmi/sensors.c | 57 ++--
drivers/hwmon/scmi-hwmon.c | 2 +-
drivers/reset/Kconfig | 11 +
drivers/reset/Makefile | 1 +
drivers/reset/reset-scmi.c | 124 +++++++
include/linux/scmi_protocol.h | 46 ++-
17 files changed, 981 insertions(+), 202 deletions(-)
create mode 100644 drivers/firmware/arm_scmi/reset.c
create mode 100644 drivers/reset/reset-scmi.c
_______________________________________________
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] ARM: vexpress: updates for v5.4
From: Sudeep Holla @ 2019-08-14 17:24 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML
Cc: Lorenzo Pieralisi, Arnd Bergmann, Kevin Hilman, Liviu Dudau,
Sudeep Holla, Olof Johansson
Hi ARM SoC Team,
Please pull !
Regards,
Sudeep
-->8
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/vexpress-update-5.4
for you to fetch changes up to ace4682635db252d40071f62af328c90508cafdd:
ARM: vexpress: Cleanup cppcheck shifting warning (2019-07-31 16:36:58 +0100)
----------------------------------------------------------------
ARMv7 Vexpress update for v5.4
Single cleanup patch handling type checks using cppcheck tool
(bitwise shift by more than 31 on a 32 bit type)
----------------------------------------------------------------
Phong Tran (1):
ARM: vexpress: Cleanup cppcheck shifting warning
arch/arm/mach-vexpress/spc.c | 4 ++--
1 file 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] ARM: dts: vexpress: updates for v5.4
From: Sudeep Holla @ 2019-08-14 17:24 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML
Cc: Lorenzo Pieralisi, Arnd Bergmann, Kevin Hilman, Liviu Dudau,
Sudeep Holla, Olof Johansson
Hi ARM SoC Team,
Please pull !
Regards,
Sudeep
-->8
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/vexpress-dt-updates-5.4
for you to fetch changes up to 7ff1154d459d25f8f674765a5ec575207516168c:
ARM: dts: vexpress: Add missing newline at end of file (2019-07-31 16:36:05 +0100)
----------------------------------------------------------------
ARMv7 Vexpress DTS updates for v5.4
Couple of updates adding missing: SPDX GPL-2.0 license identifier
and newline at the end of the file
----------------------------------------------------------------
Geert Uytterhoeven (1):
ARM: dts: vexpress: Add missing newline at end of file
Sudeep Holla (1):
ARM: dts: vexpress: add missing SPDX GPL-2.0 license identifier
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 1 +
arch/arm/boot/dts/vexpress-v2m.dtsi | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
_______________________________________________
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] arm64: dts: juno: updates for v5.4
From: Sudeep Holla @ 2019-08-14 17:24 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML
Cc: Olof Johansson, Kevin Hilman, Liviu Dudau, Arnd Bergmann,
Sudeep Holla
Hi ARM SoC Team,
Please pull !
Regards,
Sudeep
-->8
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-update-5.4
for you to fetch changes up to a24810673638d5da0336ccae5407c3fd59da14ac:
arm64: dts: fast models: Remove clcd's max-memory-bandwidth (2019-08-05 11:44:00 +0100)
----------------------------------------------------------------
ARMv8 Juno/FVP update for v5.4
Single patch removing optional 'max-memory-bandwidth' property for CLCD
that enables to allocate and use 32bpp buffers(used on FVP for Android
development)
----------------------------------------------------------------
Kevin Brodsky (1):
arm64: dts: fast models: Remove clcd's max-memory-bandwidth
arch/arm64/boot/dts/arm/fvp-base-revc.dts | 8 --------
arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 2 --
2 files changed, 10 deletions(-)
_______________________________________________
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/15] iommu/arm-smmu: Convert GR0 registers to bitfields
From: Will Deacon @ 2019-08-14 17:20 UTC (permalink / raw)
To: Robin Murphy
Cc: robdclark, joro, bjorn.andersson, iommu, vivek.gautam,
gregory.clement, linux-arm-kernel
In-Reply-To: <910cad718be01904db20ce73d8d54e7481290136.1565369764.git.robin.murphy@arm.com>
On Fri, Aug 09, 2019 at 06:07:38PM +0100, Robin Murphy wrote:
> FIELD_PREP remains a terrible name, but the overall simplification will
> make further work on this stuff that much more manageable. This also
> serves as an audit of the header, wherein we can impose a consistent
> grouping and ordering of the offset and field definitions
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu-regs.h | 126 ++++++++++++++++------------------
> drivers/iommu/arm-smmu.c | 51 +++++++-------
> 2 files changed, 84 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-regs.h b/drivers/iommu/arm-smmu-regs.h
> index 1c278f7ae888..d189f025537a 100644
> --- a/drivers/iommu/arm-smmu-regs.h
> +++ b/drivers/iommu/arm-smmu-regs.h
> @@ -10,111 +10,101 @@
> #ifndef _ARM_SMMU_REGS_H
> #define _ARM_SMMU_REGS_H
>
> +#include <linux/bits.h>
> +
> /* Configuration registers */
> #define ARM_SMMU_GR0_sCR0 0x0
> -#define sCR0_CLIENTPD (1 << 0)
> -#define sCR0_GFRE (1 << 1)
> -#define sCR0_GFIE (1 << 2)
> -#define sCR0_EXIDENABLE (1 << 3)
> -#define sCR0_GCFGFRE (1 << 4)
> -#define sCR0_GCFGFIE (1 << 5)
> -#define sCR0_USFCFG (1 << 10)
> -#define sCR0_VMIDPNE (1 << 11)
> -#define sCR0_PTM (1 << 12)
> -#define sCR0_FB (1 << 13)
> -#define sCR0_VMID16EN (1 << 31)
> -#define sCR0_BSU_SHIFT 14
> -#define sCR0_BSU_MASK 0x3
> +#define sCR0_VMID16EN BIT(31)
> +#define sCR0_BSU GENMASK(15, 14)
> +#define sCR0_FB BIT(13)
> +#define sCR0_PTM BIT(12)
> +#define sCR0_VMIDPNE BIT(11)
> +#define sCR0_USFCFG BIT(10)
> +#define sCR0_GCFGFIE BIT(5)
> +#define sCR0_GCFGFRE BIT(4)
> +#define sCR0_EXIDENABLE BIT(3)
> +#define sCR0_GFIE BIT(2)
> +#define sCR0_GFRE BIT(1)
> +#define sCR0_CLIENTPD BIT(0)
>
> /* Auxiliary Configuration register */
> #define ARM_SMMU_GR0_sACR 0x10
>
> /* Identification registers */
> #define ARM_SMMU_GR0_ID0 0x20
> +#define ID0_S1TS BIT(30)
> +#define ID0_S2TS BIT(29)
> +#define ID0_NTS BIT(28)
> +#define ID0_SMS BIT(27)
> +#define ID0_ATOSNS BIT(26)
> +#define ID0_PTFS_NO_AARCH32 BIT(25)
> +#define ID0_PTFS_NO_AARCH32S BIT(24)
> +#define ID0_CTTW BIT(14)
> +#define ID0_NUMIRPT GENMASK(23, 16)
nit: assuming this should be above ID0_CTTW so things are in descending
bit order?
Other than that, looks good to me.
Will
_______________________________________________
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 1/6] arm64: unexport set_memory_x and set_memory_nx
From: Will Deacon @ 2019-08-14 16:50 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dave Hansen, Peter Zijlstra, Catalin Marinas, x86, linux-kernel,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <20190813090146.26377-2-hch@lst.de>
On Tue, Aug 13, 2019 at 11:01:41AM +0200, Christoph Hellwig wrote:
> No module currently messed with clearing or setting the execute
> permission of kernel memory, and none really should.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm64/mm/pageattr.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 03c53f16ee77..9ce7bd9d4d9c 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -128,7 +128,6 @@ int set_memory_nx(unsigned long addr, int numpages)
> __pgprot(PTE_PXN),
> __pgprot(0));
> }
> -EXPORT_SYMBOL_GPL(set_memory_nx);
>
> int set_memory_x(unsigned long addr, int numpages)
> {
> @@ -136,7 +135,6 @@ int set_memory_x(unsigned long addr, int numpages)
> __pgprot(0),
> __pgprot(PTE_PXN));
> }
> -EXPORT_SYMBOL_GPL(set_memory_x);
arm64 allmodconfig and defconfig are happy with this, so I'll pick it up
for 5.4 if that's ok with you?
Will
_______________________________________________
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/efi: Move variable assignments after SECTIONS
From: Kees Cook @ 2019-08-14 16:35 UTC (permalink / raw)
To: Will Deacon
Cc: Fangrui Song, Ard Biesheuvel, Catalin Marinas,
Linux Kernel Mailing List, clang-built-linux, Peter Smith,
Nathan Chancellor, linux-arm-kernel
In-Reply-To: <20190814161904.55jgaxnhd4ujyh2h@willie-the-truck>
On Wed, Aug 14, 2019 at 05:19:04PM +0100, Will Deacon wrote:
> On Wed, Aug 14, 2019 at 07:14:42PM +0300, Ard Biesheuvel wrote:
> > On Wed, 14 Aug 2019 at 02:04, Kees Cook <keescook@chromium.org> wrote:
> > >
> > > It seems that LLVM's linker does not correctly handle variable assignments
> > > involving section positions that are updated during the SECTIONS
> > > parsing. Commit aa69fb62bea1 ("arm64/efi: Mark __efistub_stext_offset as
> > > an absolute symbol explicitly") ran into this too, but found a different
> > > workaround.
> > >
> > > However, this was not enough, as other variables were also miscalculated
> > > which manifested as boot failures under UEFI where __efistub__end was
> > > not taking the correct _end value (they should be the same):
> > >
> > > $ ld.lld -EL -maarch64elf --no-undefined -X -shared \
> > > -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> > > -o vmlinux.lld -T poc.lds --whole-archive vmlinux.o && \
> > > readelf -Ws vmlinux.lld | egrep '\b(__efistub_|)_end\b'
> > > 368272: ffff000002218000 0 NOTYPE LOCAL HIDDEN 38 __efistub__end
> > > 368322: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 38 _end
> > >
> > > $ aarch64-linux-gnu-ld.bfd -EL -maarch64elf --no-undefined -X -shared \
> > > -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> > > -o vmlinux.bfd -T poc.lds --whole-archive vmlinux.o && \
> > > readelf -Ws vmlinux.bfd | egrep '\b(__efistub_|)_end\b'
> > > 338124: ffff000012318000 0 NOTYPE LOCAL DEFAULT ABS __efistub__end
> > > 383812: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 15325 _end
> > >
> > > To work around this, all of the __efistub_-prefixed variable assignments
> > > need to be moved after the linker script's SECTIONS entry. As it turns
> > > out, this also solves the problem fixed in commit aa69fb62bea1, so those
> > > changes are reverted here.
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/634
> > > Link: https://bugs.llvm.org/show_bug.cgi?id=42990
> > > Signed-off-by: Kees Cook <keescook@chromium.org>
> >
> > Although it is slightly disappointing that we need to work around this
> > kind of bugs when adding support for a new toolchain, I don't see
> > anything wrong with this patch, so
> >
> > Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Yup, it's gross, but I'll queue it with your ack.
Thanks, and agreed. :)
--
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/efi: Move variable assignments after SECTIONS
From: Will Deacon @ 2019-08-14 16:19 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Kees Cook, Fangrui Song, Catalin Marinas,
Linux Kernel Mailing List, clang-built-linux, Peter Smith,
Nathan Chancellor, linux-arm-kernel
In-Reply-To: <CAKv+Gu9fEAG3CqmORyO2X_Uqse09nnXEQiB1kTL-xBqLWsy8Xg@mail.gmail.com>
On Wed, Aug 14, 2019 at 07:14:42PM +0300, Ard Biesheuvel wrote:
> On Wed, 14 Aug 2019 at 02:04, Kees Cook <keescook@chromium.org> wrote:
> >
> > It seems that LLVM's linker does not correctly handle variable assignments
> > involving section positions that are updated during the SECTIONS
> > parsing. Commit aa69fb62bea1 ("arm64/efi: Mark __efistub_stext_offset as
> > an absolute symbol explicitly") ran into this too, but found a different
> > workaround.
> >
> > However, this was not enough, as other variables were also miscalculated
> > which manifested as boot failures under UEFI where __efistub__end was
> > not taking the correct _end value (they should be the same):
> >
> > $ ld.lld -EL -maarch64elf --no-undefined -X -shared \
> > -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> > -o vmlinux.lld -T poc.lds --whole-archive vmlinux.o && \
> > readelf -Ws vmlinux.lld | egrep '\b(__efistub_|)_end\b'
> > 368272: ffff000002218000 0 NOTYPE LOCAL HIDDEN 38 __efistub__end
> > 368322: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 38 _end
> >
> > $ aarch64-linux-gnu-ld.bfd -EL -maarch64elf --no-undefined -X -shared \
> > -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> > -o vmlinux.bfd -T poc.lds --whole-archive vmlinux.o && \
> > readelf -Ws vmlinux.bfd | egrep '\b(__efistub_|)_end\b'
> > 338124: ffff000012318000 0 NOTYPE LOCAL DEFAULT ABS __efistub__end
> > 383812: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 15325 _end
> >
> > To work around this, all of the __efistub_-prefixed variable assignments
> > need to be moved after the linker script's SECTIONS entry. As it turns
> > out, this also solves the problem fixed in commit aa69fb62bea1, so those
> > changes are reverted here.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/634
> > Link: https://bugs.llvm.org/show_bug.cgi?id=42990
> > Signed-off-by: Kees Cook <keescook@chromium.org>
>
> Although it is slightly disappointing that we need to work around this
> kind of bugs when adding support for a new toolchain, I don't see
> anything wrong with this patch, so
>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Yup, it's gross, but I'll queue it with your ack.
Will
_______________________________________________
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/efi: Move variable assignments after SECTIONS
From: Ard Biesheuvel @ 2019-08-14 16:14 UTC (permalink / raw)
To: Kees Cook
Cc: Fangrui Song, Catalin Marinas, Linux Kernel Mailing List,
clang-built-linux, Peter Smith, Nathan Chancellor, Will Deacon,
linux-arm-kernel
In-Reply-To: <201908131602.6E858DEC@keescook>
On Wed, 14 Aug 2019 at 02:04, Kees Cook <keescook@chromium.org> wrote:
>
> It seems that LLVM's linker does not correctly handle variable assignments
> involving section positions that are updated during the SECTIONS
> parsing. Commit aa69fb62bea1 ("arm64/efi: Mark __efistub_stext_offset as
> an absolute symbol explicitly") ran into this too, but found a different
> workaround.
>
> However, this was not enough, as other variables were also miscalculated
> which manifested as boot failures under UEFI where __efistub__end was
> not taking the correct _end value (they should be the same):
>
> $ ld.lld -EL -maarch64elf --no-undefined -X -shared \
> -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> -o vmlinux.lld -T poc.lds --whole-archive vmlinux.o && \
> readelf -Ws vmlinux.lld | egrep '\b(__efistub_|)_end\b'
> 368272: ffff000002218000 0 NOTYPE LOCAL HIDDEN 38 __efistub__end
> 368322: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 38 _end
>
> $ aarch64-linux-gnu-ld.bfd -EL -maarch64elf --no-undefined -X -shared \
> -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> -o vmlinux.bfd -T poc.lds --whole-archive vmlinux.o && \
> readelf -Ws vmlinux.bfd | egrep '\b(__efistub_|)_end\b'
> 338124: ffff000012318000 0 NOTYPE LOCAL DEFAULT ABS __efistub__end
> 383812: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 15325 _end
>
> To work around this, all of the __efistub_-prefixed variable assignments
> need to be moved after the linker script's SECTIONS entry. As it turns
> out, this also solves the problem fixed in commit aa69fb62bea1, so those
> changes are reverted here.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/634
> Link: https://bugs.llvm.org/show_bug.cgi?id=42990
> Signed-off-by: Kees Cook <keescook@chromium.org>
Although it is slightly disappointing that we need to work around this
kind of bugs when adding support for a new toolchain, I don't see
anything wrong with this patch, so
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/kernel/image-vars.h | 51 +++++++++++++++++++++++++++++++++
> arch/arm64/kernel/image.h | 42 ---------------------------
> arch/arm64/kernel/vmlinux.lds.S | 2 ++
> 3 files changed, 53 insertions(+), 42 deletions(-)
> create mode 100644 arch/arm64/kernel/image-vars.h
>
> diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> new file mode 100644
> index 000000000000..25a2a9b479c2
> --- /dev/null
> +++ b/arch/arm64/kernel/image-vars.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Linker script variables to be set after section resolution, as
> + * ld.lld does not like variables assigned before SECTIONS is processed.
> + */
> +#ifndef __ARM64_KERNEL_IMAGE_VARS_H
> +#define __ARM64_KERNEL_IMAGE_VARS_H
> +
> +#ifndef LINKER_SCRIPT
> +#error This file should only be included in vmlinux.lds.S
> +#endif
> +
> +#ifdef CONFIG_EFI
> +
> +__efistub_stext_offset = stext - _text;
> +
> +/*
> + * The EFI stub has its own symbol namespace prefixed by __efistub_, to
> + * isolate it from the kernel proper. The following symbols are legally
> + * accessed by the stub, so provide some aliases to make them accessible.
> + * Only include data symbols here, or text symbols of functions that are
> + * guaranteed to be safe when executed at another offset than they were
> + * linked at. The routines below are all implemented in assembler in a
> + * position independent manner
> + */
> +__efistub_memcmp = __pi_memcmp;
> +__efistub_memchr = __pi_memchr;
> +__efistub_memcpy = __pi_memcpy;
> +__efistub_memmove = __pi_memmove;
> +__efistub_memset = __pi_memset;
> +__efistub_strlen = __pi_strlen;
> +__efistub_strnlen = __pi_strnlen;
> +__efistub_strcmp = __pi_strcmp;
> +__efistub_strncmp = __pi_strncmp;
> +__efistub_strrchr = __pi_strrchr;
> +__efistub___flush_dcache_area = __pi___flush_dcache_area;
> +
> +#ifdef CONFIG_KASAN
> +__efistub___memcpy = __pi_memcpy;
> +__efistub___memmove = __pi_memmove;
> +__efistub___memset = __pi_memset;
> +#endif
> +
> +__efistub__text = _text;
> +__efistub__end = _end;
> +__efistub__edata = _edata;
> +__efistub_screen_info = screen_info;
> +
> +#endif
> +
> +#endif /* __ARM64_KERNEL_IMAGE_VARS_H */
> diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
> index 2b85c0d6fa3d..c7d38c660372 100644
> --- a/arch/arm64/kernel/image.h
> +++ b/arch/arm64/kernel/image.h
> @@ -65,46 +65,4 @@
> DEFINE_IMAGE_LE64(_kernel_offset_le, TEXT_OFFSET); \
> DEFINE_IMAGE_LE64(_kernel_flags_le, __HEAD_FLAGS);
>
> -#ifdef CONFIG_EFI
> -
> -/*
> - * Use ABSOLUTE() to avoid ld.lld treating this as a relative symbol:
> - * https://github.com/ClangBuiltLinux/linux/issues/561
> - */
> -__efistub_stext_offset = ABSOLUTE(stext - _text);
> -
> -/*
> - * The EFI stub has its own symbol namespace prefixed by __efistub_, to
> - * isolate it from the kernel proper. The following symbols are legally
> - * accessed by the stub, so provide some aliases to make them accessible.
> - * Only include data symbols here, or text symbols of functions that are
> - * guaranteed to be safe when executed at another offset than they were
> - * linked at. The routines below are all implemented in assembler in a
> - * position independent manner
> - */
> -__efistub_memcmp = __pi_memcmp;
> -__efistub_memchr = __pi_memchr;
> -__efistub_memcpy = __pi_memcpy;
> -__efistub_memmove = __pi_memmove;
> -__efistub_memset = __pi_memset;
> -__efistub_strlen = __pi_strlen;
> -__efistub_strnlen = __pi_strnlen;
> -__efistub_strcmp = __pi_strcmp;
> -__efistub_strncmp = __pi_strncmp;
> -__efistub_strrchr = __pi_strrchr;
> -__efistub___flush_dcache_area = __pi___flush_dcache_area;
> -
> -#ifdef CONFIG_KASAN
> -__efistub___memcpy = __pi_memcpy;
> -__efistub___memmove = __pi_memmove;
> -__efistub___memset = __pi_memset;
> -#endif
> -
> -__efistub__text = _text;
> -__efistub__end = _end;
> -__efistub__edata = _edata;
> -__efistub_screen_info = screen_info;
> -
> -#endif
> -
> #endif /* __ARM64_KERNEL_IMAGE_H */
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 7fa008374907..803b24d2464a 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -245,6 +245,8 @@ SECTIONS
> HEAD_SYMBOLS
> }
>
> +#include "image-vars.h"
> +
> /*
> * The HYP init code and ID map text can't be longer than a page each,
> * and should not cross a page boundary.
> --
> 2.17.1
>
>
> --
> 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: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Steve Capper @ 2019-08-14 16:14 UTC (permalink / raw)
To: Mark Rutland
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, Catalin Marinas,
bhsharma@redhat.com, maz@kernel.org, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190814160713.GA1614@capper-ampere.manchester.arm.com>
On Wed, Aug 14, 2019 at 05:07:15PM +0100, Steve Capper wrote:
> On Wed, Aug 14, 2019 at 04:20:18PM +0100, Mark Rutland wrote:
> > Hi Steve,
> >
>
> Hi Mark,
>
> > On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> > > +config KASAN_SHADOW_OFFSET
> > > + hex
> > > + depends on KASAN
> > > + default 0xdfffa00000000000 if (ARM64_VA_BITS_48 || ARM64_USER_VA_BITS_52) && !KASAN_SW_TAGS
> > > + default 0xdfffd00000000000 if ARM64_VA_BITS_47 && !KASAN_SW_TAGS
> > > + default 0xdffffe8000000000 if ARM64_VA_BITS_42 && !KASAN_SW_TAGS
> > > + default 0xdfffffd000000000 if ARM64_VA_BITS_39 && !KASAN_SW_TAGS
> > > + default 0xdffffffa00000000 if ARM64_VA_BITS_36 && !KASAN_SW_TAGS
> > > + default 0xefff900000000000 if (ARM64_VA_BITS_48 || ARM64_USER_VA_BITS_52) && KASAN_SW_TAGS
> > > + default 0xefffc80000000000 if ARM64_VA_BITS_47 && KASAN_SW_TAGS
> > > + default 0xeffffe4000000000 if ARM64_VA_BITS_42 && KASAN_SW_TAGS
> > > + default 0xefffffc800000000 if ARM64_VA_BITS_39 && KASAN_SW_TAGS
> > > + default 0xeffffff900000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS
> > > + default 0xffffffffffffffff
> > > +
> > > source "arch/arm64/Kconfig.platforms"
> > >
> > > menu "Kernel Features"
> > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > > index b2400f9c1213..2b7db0d41498 100644
> > > --- a/arch/arm64/Makefile
> > > +++ b/arch/arm64/Makefile
> > > @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > >
> > > -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> > > -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> > > -# in 32-bit arithmetic
> > > -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> > > - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> > > - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> > > - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> > > -
> > > export TEXT_OFFSET GZFLAGS
> > >
> > > core-y += arch/arm64/kernel/ arch/arm64/mm/
> >
> > I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
> > CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
> > CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
> > CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
> > regardless.
> >
> > I think that's by accident rather than by design, but to
> > minimize/localize the fixup, how about the below? I can send a cleanup
> > patch for scripts/Makefile.kasan later.
> >
> > Build and boot tested with CONFIG_KASAN_{SW_TAGS,GENERIC} and
> > VA_BITS_52 (on a 48-bit VA system).
> >
>
> I've tested this with VA_BITS_52 (booted with 52-bit) with inline
> SW_TAGS and generic KASAN.
>
> FWIW:
> Tested-by: Steve Capper <steve.capper@arm.com>
> Reviewed-by: Steve Capper <steve.capper@arm.com>
>
> Agreed for this small fix now and a bigger fix in Makefile.kasan later.
>
Apologies for the noise, I didn't notice the thread progress as I was
testing. Will test the improved patch :-).
Cheers,
--
Steve
_______________________________________________
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: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Steve Capper @ 2019-08-14 16:07 UTC (permalink / raw)
To: Mark Rutland
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, Catalin Marinas,
bhsharma@redhat.com, maz@kernel.org, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190814152017.GD51963@lakrids.cambridge.arm.com>
On Wed, Aug 14, 2019 at 04:20:18PM +0100, Mark Rutland wrote:
> Hi Steve,
>
Hi Mark,
> On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> > +config KASAN_SHADOW_OFFSET
> > + hex
> > + depends on KASAN
> > + default 0xdfffa00000000000 if (ARM64_VA_BITS_48 || ARM64_USER_VA_BITS_52) && !KASAN_SW_TAGS
> > + default 0xdfffd00000000000 if ARM64_VA_BITS_47 && !KASAN_SW_TAGS
> > + default 0xdffffe8000000000 if ARM64_VA_BITS_42 && !KASAN_SW_TAGS
> > + default 0xdfffffd000000000 if ARM64_VA_BITS_39 && !KASAN_SW_TAGS
> > + default 0xdffffffa00000000 if ARM64_VA_BITS_36 && !KASAN_SW_TAGS
> > + default 0xefff900000000000 if (ARM64_VA_BITS_48 || ARM64_USER_VA_BITS_52) && KASAN_SW_TAGS
> > + default 0xefffc80000000000 if ARM64_VA_BITS_47 && KASAN_SW_TAGS
> > + default 0xeffffe4000000000 if ARM64_VA_BITS_42 && KASAN_SW_TAGS
> > + default 0xefffffc800000000 if ARM64_VA_BITS_39 && KASAN_SW_TAGS
> > + default 0xeffffff900000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS
> > + default 0xffffffffffffffff
> > +
> > source "arch/arm64/Kconfig.platforms"
> >
> > menu "Kernel Features"
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index b2400f9c1213..2b7db0d41498 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> >
> > -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> > -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> > -# in 32-bit arithmetic
> > -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> > - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> > - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> > - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> > -
> > export TEXT_OFFSET GZFLAGS
> >
> > core-y += arch/arm64/kernel/ arch/arm64/mm/
>
> I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
> CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
> CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
> CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
> regardless.
>
> I think that's by accident rather than by design, but to
> minimize/localize the fixup, how about the below? I can send a cleanup
> patch for scripts/Makefile.kasan later.
>
> Build and boot tested with CONFIG_KASAN_{SW_TAGS,GENERIC} and
> VA_BITS_52 (on a 48-bit VA system).
>
I've tested this with VA_BITS_52 (booted with 52-bit) with inline
SW_TAGS and generic KASAN.
FWIW:
Tested-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: Steve Capper <steve.capper@arm.com>
Agreed for this small fix now and a bigger fix in Makefile.kasan later.
Cheers,
--
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] kbuild: rebuild modules when module linker scripts are updated
From: Masahiro Yamada @ 2019-08-14 16:06 UTC (permalink / raw)
To: linux-kbuild
Cc: linux-ia64, linux-doc, Catalin Marinas, Palmer Dabbelt,
James E.J. Bottomley, Masahiro Yamada, Paul Mackerras,
linux-riscv, Will Deacon, Jonathan Corbet, Michael Ellerman,
Helge Deller, Russell King, Geert Uytterhoeven,
Benjamin Herrenschmidt, Fenghua Yu, Albert Ou, linux-m68k,
Michal Marek, Paul Walmsley, linux-arm-kernel, Tony Luck,
linux-parisc, linux-kernel, linuxppc-dev
In-Reply-To: <20190814160623.24802-1-yamada.masahiro@socionext.com>
Currently, the timestamp of module linker scripts are not checked.
Add them to the dependency of modules so they are correctly rebuilt.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Documentation/kbuild/makefiles.rst | 5 +++++
Makefile | 3 ++-
arch/arm/Makefile | 2 +-
arch/arm64/Makefile | 2 +-
arch/ia64/Makefile | 2 +-
arch/m68k/Makefile | 2 +-
arch/parisc/Makefile | 2 +-
arch/powerpc/Makefile | 2 +-
arch/riscv/Makefile | 2 +-
scripts/Makefile.modpost | 5 +++--
10 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst
index d3448d2c8017..36ba92e199d2 100644
--- a/Documentation/kbuild/makefiles.rst
+++ b/Documentation/kbuild/makefiles.rst
@@ -999,6 +999,11 @@ When kbuild executes, the following steps are followed (roughly):
The linker script with full path. Assigned by the top-level Makefile.
+ KBUILD_LDS_MODULE
+
+ The module linker script with full path. Assigned by the top-level
+ Makefile and additionally by the arch Makefile.
+
KBUILD_VMLINUX_OBJS
All object files for vmlinux. They are linked to vmlinux in the same
diff --git a/Makefile b/Makefile
index 164ca615e2f6..af808837a1f2 100644
--- a/Makefile
+++ b/Makefile
@@ -485,7 +485,8 @@ KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_KERNEL :=
KBUILD_AFLAGS_MODULE := -DMODULE
KBUILD_CFLAGS_MODULE := -DMODULE
-KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
+KBUILD_LDFLAGS_MODULE :=
+export KBUILD_LDS_MODULE := $(srctree)/scripts/module-common.lds
KBUILD_LDFLAGS :=
GCC_PLUGINS_CFLAGS :=
CLANG_FLAGS :=
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c3624ca6c0bc..fbe50eec8f34 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -17,7 +17,7 @@ KBUILD_LDFLAGS_MODULE += --be8
endif
ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm/kernel/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/arm/kernel/module.lds
endif
GZFLAGS :=-9
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 61de992bbea3..d4ed1869e536 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -101,7 +101,7 @@ endif
CHECKFLAGS += -D__aarch64__
ifeq ($(CONFIG_ARM64_MODULE_PLTS),y)
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm64/kernel/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/arm64/kernel/module.lds
endif
# Default value
diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
index 171290f9f1de..5c3bcaee5980 100644
--- a/arch/ia64/Makefile
+++ b/arch/ia64/Makefile
@@ -20,7 +20,7 @@ CHECKFLAGS += -D__ia64=1 -D__ia64__=1 -D_LP64 -D__LP64__
OBJCOPYFLAGS := --strip-all
LDFLAGS_vmlinux := -static
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/ia64/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/ia64/module.lds
KBUILD_AFLAGS_KERNEL := -mconstant-gp
EXTRA :=
diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile
index 482513b9af2c..5d9288384096 100644
--- a/arch/m68k/Makefile
+++ b/arch/m68k/Makefile
@@ -73,7 +73,7 @@ KBUILD_AFLAGS += -D__uClinux__
endif
KBUILD_LDFLAGS := -m m68kelf
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/m68k/kernel/module.lds
ifdef CONFIG_SUN3
LDFLAGS_vmlinux = -N
diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index 3b77d729057f..36b834f1c933 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -60,7 +60,7 @@ KBUILD_CFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY=1 \
-DFTRACE_PATCHABLE_FUNCTION_SIZE=$(NOP_COUNT)
CC_FLAGS_FTRACE := -fpatchable-function-entry=$(NOP_COUNT),$(shell echo $$(($(NOP_COUNT)-1)))
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/parisc/kernel/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/parisc/kernel/module.lds
endif
OBJCOPY_FLAGS =-O binary -R .note -R .comment -S
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index c345b79414a9..b2227855de20 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -67,7 +67,7 @@ UTS_MACHINE := $(subst $(space),,$(machine-y))
ifdef CONFIG_PPC32
KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
else
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/powerpc/kernel/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/powerpc/kernel/module.lds
ifeq ($(call ld-ifversion, -ge, 225000000, y),y)
# Have the linker provide sfpr if possible.
# There is a corresponding test in arch/powerpc/lib/Makefile
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 7a117be8297c..426d989125a8 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -52,7 +52,7 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
KBUILD_CFLAGS += -mcmodel=medany
endif
ifeq ($(CONFIG_MODULE_SECTIONS),y)
- KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/riscv/kernel/module.lds
+ KBUILD_LDS_MODULE += $(srctree)/arch/riscv/kernel/module.lds
endif
KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-relax)
diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index bf15818f6947..905db30d6622 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -126,10 +126,11 @@ quiet_cmd_ld_ko_o = LD [M] $@
cmd_ld_ko_o = \
$(LD) -r $(KBUILD_LDFLAGS) \
$(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \
- -o $@ $(real-prereqs) ; \
+ $(addprefix -T , $(KBUILD_LDS_MODULE)) \
+ -o $@ $(filter %.o, $^); \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
-$(modules): %.ko :%.o %.mod.o FORCE
+$(modules): %.ko :%.o %.mod.o $(KBUILD_LDS_MODULE) FORCE
+$(call if_changed,ld_ko_o)
targets += $(modules)
--
2.17.1
_______________________________________________
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] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Mark Rutland @ 2019-08-14 16:03 UTC (permalink / raw)
To: Will Deacon, Andrey Ryabinin
Cc: crecklin, ard.biesheuvel, catalin.marinas, bhsharma, Steve Capper,
maz, linux-arm-kernel
In-Reply-To: <20190814155711.ldwot7ezrrqjlswc@willie-the-truck>
On Wed, Aug 14, 2019 at 04:57:11PM +0100, Will Deacon wrote:
> On Wed, Aug 14, 2019 at 04:20:18PM +0100, Mark Rutland wrote:
> > On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > > index b2400f9c1213..2b7db0d41498 100644
> > > --- a/arch/arm64/Makefile
> > > +++ b/arch/arm64/Makefile
> > > @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > >
> > > -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> > > -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> > > -# in 32-bit arithmetic
> > > -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> > > - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> > > - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> > > - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> > > -
> > > export TEXT_OFFSET GZFLAGS
> > >
> > > core-y += arch/arm64/kernel/ arch/arm64/mm/
> >
> > I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
> > CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
> > CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
> > CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
> > regardless.
> >
> > I think that's by accident rather than by design, but to
> > minimize/localize the fixup, how about the below? I can send a cleanup
> > patch for scripts/Makefile.kasan later.
>
> How much work is that? I've dropped this stuff from -next for now, so we
> have time to fix it properly as long as it's not going to take weeks.
I wrote it first, so no effort; patch below.
Andrey, would you be happy with this?
Thanks,
Mark.
---->8----
From ecdf60051a850f817d98f84ae9011afa2311b8f1 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Wed, 14 Aug 2019 15:31:57 +0100
Subject: [PATCH] kasan/arm64: fix CONFIG_KASAN_SW_TAGS && KASAN_INLINE
The generic Makefile.kasan propagates CONFIG_KASAN_SHADOW_OFFSET into
KASAN_SHADOW_OFFSET, but only does so for CONFIG_KASAN_GENERIC.
Since commit:
6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")
... arm64 defines CONFIG_KASAN_SHADOW_OFFSET in Kconfig rather than
defining KASAN_SHADOW_OFFSET in a Makefile. Thus, if
CONFIG_KASAN_SW_TAGS && KASAN_INLINE are selected, we get build time
splats due to KASAN_SHADOW_OFFSET not being set:
| [mark@lakrids:~/src/linux]% usellvm 8.0.1 usekorg 8.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang
| scripts/kconfig/conf --syncconfig Kconfig
| CC scripts/mod/empty.o
| clang (LLVM option parsing): for the -hwasan-mapping-offset option: '' value invalid for uint argument!
| scripts/Makefile.build:273: recipe for target 'scripts/mod/empty.o' failed
| make[1]: *** [scripts/mod/empty.o] Error 1
| Makefile:1123: recipe for target 'prepare0' failed
| make: *** [prepare0] Error 2
Let's fix this by always propagating CONFIG_KASAN_SHADOW_OFFSET into
KASAN_SHADOW_OFFSET if CONFIG_KASAN is selected, moving the existing
common definition of +CFLAGS_KASAN_NOSANITIZE to the top of
Makefile.kasan.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Will Deacon <will@kernel.org>
---
scripts/Makefile.kasan | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index 6410bd22fe38..03757cc60e06 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -1,4 +1,9 @@
# SPDX-License-Identifier: GPL-2.0
+ifdef CONFIG_KASAN
+CFLAGS_KASAN_NOSANITIZE := -fno-builtin
+KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
+endif
+
ifdef CONFIG_KASAN_GENERIC
ifdef CONFIG_KASAN_INLINE
@@ -7,8 +12,6 @@ else
call_threshold := 0
endif
-KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
-
CFLAGS_KASAN_MINIMAL := -fsanitize=kernel-address
cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
@@ -45,7 +48,3 @@ CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
$(instrumentation_flags)
endif # CONFIG_KASAN_SW_TAGS
-
-ifdef CONFIG_KASAN
-CFLAGS_KASAN_NOSANITIZE := -fno-builtin
-endif
--
2.11.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
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