[Bug 204479] KASAN hit at modprobe zram
https://bugzilla.kernel.org/show_bug.cgi?id=204479 --- Comment #9 from Christophe Leroy (christophe.le...@c-s.fr) --- The module loads seems to be nested. It might then be an SMP issue, kasan_init_region() is most likely not SMP safe. Could you test without CONFIG_SMP or with only one CPU ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 204479] KASAN hit at modprobe zram
https://bugzilla.kernel.org/show_bug.cgi?id=204479 --- Comment #8 from Christophe Leroy (christophe.le...@c-s.fr) --- List of allocated areas with associated kasan shadow area in [ ], together with the addresses when shadow initialisation fails: Aug 08 23:39:58 T600 kernel: ## module_alloc(c78c) = f147 [fe28e000-fe28f8f1] Aug 08 23:39:58 T600 kernel: ## module_alloc(36f8) = f147e000 [fe28fc00-fe2902df] Aug 08 23:39:58 T600 kernel: ## module_alloc(c78c) = f1483000 [fe290600-fe291ef1] Aug 08 23:39:58 T600 kernel: ## module_alloc(c78c) = f1491000 [fe292200-fe293af1] Aug 08 23:39:58 T600 kernel: ## module_alloc(36f8) = f1502000 [fe2a0400-fe2a0adf] Aug 08 23:39:58 T600 kernel: ## module_alloc(1521) = f1013000 [fe202600-fe2028a4] Aug 08 23:39:58 T600 kernel: ## module_alloc(13bc5) = f103d000 [fe207a00-fe20a178] Aug 08 23:39:58 T600 kernel: ## module_alloc(1357) = f1027000 [fe204e00-fe20506a] Aug 08 23:39:58 T600 kernel: ## module_alloc(36f8) = f102a000 [fe205400-fe205adf] Aug 08 23:39:58 T600 kernel: ## module_alloc(4301) = f102f000 [fe205e00-fe206660] Aug 08 23:39:58 T600 kernel: ## module_alloc(4718) = f1065000 [fe20ca00-fe20d2e3] Aug 08 23:39:58 T600 kernel: ## module_alloc(19ac) = f1076000 [fe20ec00-fe20ef35] Aug 08 23:39:58 T600 kernel: ## module_alloc(4718) = f129d000 [fe253a00-fe2542e3] Aug 08 23:39:58 T600 kernel: ## module_alloc(16ca) = f102a000 [fe205400-fe2056d9] Aug 08 23:39:58 T600 kernel: ## module_alloc(1f81) = f1079000 [fe20f200-fe20f5f0] Aug 08 23:39:58 T600 kernel: ## module_alloc(1f81) = f1027000 [fe204e00-fe2051f0] Aug 08 23:39:59 T600 kernel: BUG: Unable to handle kernel data access at 0xfe20d040 Aug 08 23:39:59 T600 kernel: ## module_alloc(185ef) = f12d [fe25a000-fe25d0bd] Aug 08 23:39:59 T600 kernel: ## module_alloc(4035) = f106b000 [fe20d600-fe20de06] Aug 08 23:39:59 T600 kernel: ## module_alloc(6196) = f12b3000 [fe256600-fe257232] Aug 08 23:39:59 T600 kernel: ## module_alloc(1d27) = f1071000 [fe20e200-fe20e5a4] Aug 08 23:39:59 T600 kernel: ## module_alloc(4035) = f102d000 [fe205a00-fe206206] Aug 08 23:39:59 T600 kernel: ## module_alloc(a11b) = f13ad000 [fe275a00-fe276e23] Aug 08 23:39:59 T600 kernel: ## module_alloc(4035) = f12b3000 [fe256600-fe256e06] Aug 08 23:39:59 T600 kernel: ## module_alloc(4035) = f12ea000 [fe25d400-fe25dc06] Aug 08 23:39:59 T600 kernel: ## module_alloc(1d27) = f1033000 [fe206600-fe2069a4] Aug 08 23:39:59 T600 kernel: ## module_alloc(4035) = f1397000 [fe272e00-fe273606] Aug 08 23:39:59 T600 kernel: ## module_alloc(307a) = f12f [fe25e000-fe25e60f] Aug 08 23:39:59 T600 kernel: ## module_alloc(1d27) = f1062000 [fe20c400-fe20c7a4] Aug 08 23:39:59 T600 kernel: ## module_alloc(1d27) = f12f7000 [fe25ee00-fe25f1a4] Aug 08 23:39:59 T600 kernel: ## module_alloc(1d27) = f12fd000 [fe25fa00-fe25fda4] Aug 08 23:39:59 T600 kernel: ## module_alloc(d102) = f1429000 [fe285200-fe286c20] Aug 08 23:39:59 T600 kernel: ## module_alloc(2a37) = f1033000 [fe206600-fe206b46] Aug 08 23:39:59 T600 kernel: ## module_alloc(4718) = f106b000 [fe20d600-fe20dee3] Aug 08 23:39:59 T600 kernel: ## module_alloc(9a3f2) = f1db8000 [fe3b7000-fe3ca47e] Aug 08 23:39:59 T600 kernel: ## module_alloc(18571) = f13cd000 [fe279a00-fe27caae] Aug 08 23:39:59 T600 kernel: ## module_alloc(1f81) = f1071000 [fe20e200-fe20e5f0] Aug 08 23:39:59 T600 kernel: ## module_alloc(1fdb9) = f1438000 [fe287000-fe28afb7] Aug 08 23:39:59 T600 kernel: ## module_alloc(56a49) = f1e54000 [fe3ca800-fe3d5549] Aug 08 23:39:59 T600 kernel: ## module_alloc(56a49) = f1eac000 [fe3d5800-fe3e0549] Aug 08 23:39:59 T600 kernel: ## module_alloc(56a49) = f1f04000 [fe3e0800-fe3eb549] Aug 08 23:39:59 T600 kernel: ## module_alloc(7c61) = f12ea000 [fe25d400-fe25e38c] Aug 08 23:39:59 T600 kernel: ## module_alloc(e011) = f140c000 [fe281800-fe283402] Aug 08 23:39:59 T600 kernel: ## module_alloc(56a49) = f1f5c000 [fe3eb800-fe3f6549] Aug 08 23:39:59 T600 kernel: ## module_alloc(56a49) = f1fb4000 [fe3f6800-fe401549] Aug 08 23:39:59 T600 kernel: ## module_alloc(e011) = f1459000 [fe28b200-fe28ce02] Aug 08 23:39:59 T600 kernel: ## module_alloc(e011) = f147e000 [fe28fc00-fe291802] Aug 08 23:39:59 T600 kernel: ## module_alloc(2561) = f1033000 [fe206600-fe206aac] Aug 08 23:39:59 T600 kernel: ## module_alloc(6ae1) = f12b3000 [fe256600-fe25735c] Aug 08 23:39:59 T600 kernel: ## module_alloc(e011) = f148e000 [fe291c00-fe293802] Aug 08 23:39:59 T600 kernel: ## module_alloc(e011) = f200c000 [fe401800-fe403402] Aug 08 23:40:00 T600 kernel: ## module_alloc(3355) = f1397000 [fe272e00-fe27346a] Aug 08 23:40:00 T600 kernel: ## module_alloc(1c8f) = f12f7000 [fe25ee00-fe25f191] Aug 08 23:40:00 T600 kernel: BUG: Unable to handle kernel data access at 0xfe2731a0 Aug 08 23:40:00 T600 kernel: ## module_alloc(1c078) = f13cd000 [fe279a00-fe27d20f] Aug 08
Re: [PATCH v3 38/41] powerpc: convert put_page() to put_user_page*()
On 8/7/19 10:42 PM, Michael Ellerman wrote:
> Hi John,
>
> john.hubb...@gmail.com writes:
>> diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
>> b/arch/powerpc/mm/book3s64/iommu_api.c
>> index b056cae3388b..e126193ba295 100644
>> --- a/arch/powerpc/mm/book3s64/iommu_api.c
>> +++ b/arch/powerpc/mm/book3s64/iommu_api.c
>> @@ -203,6 +202,7 @@ static void mm_iommu_unpin(struct
>> mm_iommu_table_group_mem_t *mem)
>> {
>> long i;
>> struct page *page = NULL;
>> +bool dirty = false;
>
> I don't think you need that initialisation do you?
>
Nope, it can go. Fixed locally, thanks.
Did you get a chance to look at enough of the other bits to feel comfortable
with the patch, overall?
thanks,
--
John Hubbard
NVIDIA
[PATCH 2/2] powerpc: Convert flush_icache_range to C
From: Alastair D'Silva
Similar to commit 22e9c88d486a
("powerpc/64: reuse PPC32 static inline flush_dcache_range()")
this patch converts flush_icache_range to C.
This was done as we discovered a long-standing bug where the
length of the range was truncated due to using a 32 bit shift
instead of a 64 bit one.
By converting this function to C, it becomes easier to maintain.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/cache.h | 35 +--
arch/powerpc/include/asm/cacheflush.h | 63 +++
arch/powerpc/kernel/misc_64.S | 55 ---
3 files changed, 85 insertions(+), 68 deletions(-)
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index b3388d95f451..d3d7077b75e2 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -55,25 +55,46 @@ struct ppc64_caches {
extern struct ppc64_caches ppc64_caches;
-static inline u32 l1_cache_shift(void)
+static inline u32 l1_dcache_shift(void)
{
return ppc64_caches.l1d.log_block_size;
}
-static inline u32 l1_cache_bytes(void)
+static inline u32 l1_dcache_bytes(void)
{
return ppc64_caches.l1d.block_size;
}
+
+static inline u32 l1_icache_shift(void)
+{
+ return ppc64_caches.l1i.log_block_size;
+}
+
+static inline u32 l1_icache_bytes(void)
+{
+ return ppc64_caches.l1i.block_size;
+}
#else
-static inline u32 l1_cache_shift(void)
+static inline u32 l1_dcache_shift(void)
{
return L1_CACHE_SHIFT;
}
-static inline u32 l1_cache_bytes(void)
+static inline u32 l1_dcache_bytes(void)
{
return L1_CACHE_BYTES;
}
+
+static inline u32 l1_icache_shift(void)
+{
+ return L1_CACHE_SHIFT;
+}
+
+static inline u32 l1_icache_bytes(void)
+{
+ return L1_CACHE_BYTES;
+}
+
#endif
#endif /* ! __ASSEMBLY__ */
@@ -124,6 +145,12 @@ static inline void dcbst(void *addr)
{
__asm__ __volatile__ ("dcbst %y0" : : "Z"(*(u8 *)addr) : "memory");
}
+
+static inline void icbi(void *addr)
+{
+ __asm__ __volatile__ ("icbi %y0" : : "Z"(*(u8 *)addr) : "memory");
+}
+
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_CACHE_H */
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index eef388f2659f..f68e75a6dc4b 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -42,7 +42,6 @@ extern void flush_dcache_page(struct page *page);
#define flush_dcache_mmap_lock(mapping)do { } while (0)
#define flush_dcache_mmap_unlock(mapping) do { } while (0)
-extern void flush_icache_range(unsigned long, unsigned long);
extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr,
int len);
@@ -57,14 +56,17 @@ static inline void __flush_dcache_icache_phys(unsigned long
physaddr)
}
#endif
-/*
- * Write any modified data cache blocks out to memory and invalidate them.
+/**
+ * flush_dcache_range: Write any modified data cache blocks out to memory and
invalidate them.
* Does not invalidate the corresponding instruction cache blocks.
+ *
+ * @start: the start address
+ * @stop: the stop address (exclusive)
*/
static inline void flush_dcache_range(unsigned long start, unsigned long stop)
{
- unsigned long shift = l1_cache_shift();
- unsigned long bytes = l1_cache_bytes();
+ unsigned long shift = l1_dcache_shift();
+ unsigned long bytes = l1_dcache_bytes();
void *addr = (void *)(start & ~(bytes - 1));
unsigned long size = stop - (unsigned long)addr + (bytes - 1);
unsigned long i;
@@ -82,6 +84,49 @@ static inline void flush_dcache_range(unsigned long start,
unsigned long stop)
isync();
}
+/**
+ * flush_icache_range: Write any modified data cache blocks out to memory
+ * and invalidate the corresponding blocks in the instruction cache
+ *
+ * Generic code will call this after writing memory, before executing from it.
+ *
+ * @start: the start address
+ * @stop: the stop address (exclusive)
+ */
+static inline void flush_icache_range(unsigned long start, unsigned long stop)
+{
+ unsigned long shift = l1_dcache_shift();
+ unsigned long bytes = l1_dcache_bytes();
+ void *addr = (void *)(start & ~(bytes - 1));
+ unsigned long size = stop - (unsigned long)addr + (bytes - 1);
+ unsigned long i;
+
+ if (cpu_has_feature(CPU_FTR_COHERENT_ICACHE)) {
+ mb(); /* sync */
+ icbi((void *)start);
+ mb(); /* sync */
+ isync();
+ return;
+ }
+
+ /* Flush the data cache to memory */
+ for (i = 0; i < size >> shift; i++, addr += bytes)
+ dcbst(addr);
+
+ mb(); /* sync */
+
+ shift = l1_icache_shift();
+ bytes = l1_icache_bytes();
+ addr = (void
[PATCH 1/2] powerpc: Allow flush_icache_range to work across ranges >4GB
From: Alastair D'Silva When calling flush_icache_range with a size >4GB, we were masking off the upper 32 bits, so we would incorrectly flush a range smaller than intended. This patch replaces the 32 bit shifts with 64 bit ones, so that the full size is accounted for. Heads-up for backporters: the old version of flush_dcache_range is subject to a similar bug (this has since been replaced with a C implementation). Signed-off-by: Alastair D'Silva --- arch/powerpc/kernel/misc_64.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index b55a7b4cb543..9bc0aa9aeb65 100644 --- a/arch/powerpc/kernel/misc_64.S +++ b/arch/powerpc/kernel/misc_64.S @@ -82,7 +82,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) subfr8,r6,r4/* compute length */ add r8,r8,r5/* ensure we get enough */ lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of cache block size */ - srw.r8,r8,r9/* compute line count */ + srd.r8,r8,r9/* compute line count */ beqlr /* nothing to do? */ mtctr r8 1: dcbst 0,r6 @@ -98,7 +98,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) subfr8,r6,r4/* compute length */ add r8,r8,r5 lwz r9,ICACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of Icache block size */ - srw.r8,r8,r9/* compute line count */ + srd.r8,r8,r9/* compute line count */ beqlr /* nothing to do? */ mtctr r8 2: icbi0,r6 -- 2.21.0
[Bug 204375] kernel 5.2.4 w. KASAN enabled fails to boot on a PowerMac G4 3,6 at very early stage
https://bugzilla.kernel.org/show_bug.cgi?id=204375 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #15 from Erhard F. (erhar...@mailbox.org) --- The fix landed succesfully in 5.2.7 and I can confirm it works on my G4 now. Thanks! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 204479] KASAN hit at modprobe zram
https://bugzilla.kernel.org/show_bug.cgi?id=204479 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #284175|0 |1 is obsolete|| --- Comment #7 from Erhard F. (erhar...@mailbox.org) --- Created attachment 284273 --> https://bugzilla.kernel.org/attachment.cgi?id=284273=edit dmesg (kernel 5.3-rc3 + patch, PowerMac G4 DP) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 204479] KASAN hit at modprobe zram
https://bugzilla.kernel.org/show_bug.cgi?id=204479 --- Comment #6 from Erhard F. (erhar...@mailbox.org) --- (In reply to Christophe Leroy from comment #4) > We need to identify if the allocation of KASAN shadow area at module > allocation fails, or if kasan accesses outside of the allocated area. > > Could you please run again with the below trace: The patch did not apply to the mainstream kernnel with 'patch -p1 < ...' but I inserted the code manually. Please find the new results attached. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 204479] KASAN hit at modprobe zram
https://bugzilla.kernel.org/show_bug.cgi?id=204479 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #284177|0 |1 is obsolete|| --- Comment #5 from Erhard F. (erhar...@mailbox.org) --- Created attachment 284271 --> https://bugzilla.kernel.org/attachment.cgi?id=284271=edit kernel .config (5.3-rc3, PowerMac G4 DP) -- You are receiving this mail because: You are on the CC list for the bug.
[PATCH] soc: fsl: dpio: Add support for QBMan ring bulk enqueue.
The QBMan frame descriptor enqueuing is changed from array
mode (a single frame enqueue at a time) to bulk ring mode.
This new mode allows the enqueuing of multiple frames in one operation.
The original interface is kept but use the bulk enqueue of one frame
Signed-off-by: Youri Querry
---
drivers/soc/fsl/dpio/dpio-service.c | 69 +++-
drivers/soc/fsl/dpio/qbman-portal.c | 772
drivers/soc/fsl/dpio/qbman-portal.h | 175 +++-
3 files changed, 935 insertions(+), 81 deletions(-)
diff --git a/drivers/soc/fsl/dpio/dpio-service.c
b/drivers/soc/fsl/dpio/dpio-service.c
index b9539ef..4eb53ee 100644
--- a/drivers/soc/fsl/dpio/dpio-service.c
+++ b/drivers/soc/fsl/dpio/dpio-service.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
/*
* Copyright 2014-2016 Freescale Semiconductor Inc.
- * Copyright 2016 NXP
+ * Copyright 2016-2019 NXP
*
*/
#include
@@ -435,6 +435,69 @@ int dpaa2_io_service_enqueue_fq(struct dpaa2_io *d,
EXPORT_SYMBOL(dpaa2_io_service_enqueue_fq);
/**
+ * dpaa2_io_service_enqueue_multiple_fq() - Enqueue multiple frames
+ * to a frame queue using one fqid.
+ * @d: the given DPIO service.
+ * @fqid: the given frame queue id.
+ * @fd: the list of frame descriptors enqueued.
+ * @nb: number of frames to be enqueued
+ *
+ * Return the number of enqueued frames (0 if EQCR is busy)
+ * or -ENODEV if there is no dpio service.
+ */
+int dpaa2_io_service_enqueue_multiple_fq(struct dpaa2_io *d,
+ u32 fqid,
+ const struct dpaa2_fd *fd,
+ int nb)
+{
+ struct qbman_eq_desc ed;
+
+ d = service_select(d);
+ if (!d)
+ return -ENODEV;
+
+ qbman_eq_desc_clear();
+ qbman_eq_desc_set_no_orp(, 0);
+ qbman_eq_desc_set_fq(, fqid);
+
+ return qbman_swp_enqueue_multiple(d->swp, , fd, 0, nb);
+}
+EXPORT_SYMBOL(dpaa2_io_service_enqueue_multiple_fq);
+
+/**
+ * dpaa2_io_service_enqueue_multiple_desc_fq() - Enqueue multiple frames
+ * to different frame queue using a list of fqids.
+ * @d: the given DPIO service.
+ * @fqid: the given list of frame queue ids.
+ * @fd: the list of frame descriptors enqueued.
+ * @nb: number of frames to be enqueued
+ *
+ * Return the number of enqueued frames (0 if EQCR is busy)
+ * or -ENODEV if there is no dpio service.
+ */
+int dpaa2_io_service_enqueue_multiple_desc_fq(struct dpaa2_io *d,
+ u32 *fqid,
+ const struct dpaa2_fd *fd,
+ int nb)
+{
+ int i;
+ struct qbman_eq_desc_min ed[32];
+
+ d = service_select(d);
+ if (!d)
+ return -ENODEV;
+
+ for (i = 0; i < nb; i++) {
+ qbman_eq_desc_min_clear([i]);
+ qbman_eq_desc_set_no_orp_min([i], 0);
+ qbman_eq_desc_set_min_fq([i], fqid[i]);
+ }
+
+ return qbman_swp_enqueue_multiple_desc(d->swp, [0], fd, nb);
+}
+EXPORT_SYMBOL(dpaa2_io_service_enqueue_multiple_desc_fq);
+
+/**
* dpaa2_io_service_enqueue_qd() - Enqueue a frame to a QD.
* @d: the given DPIO service.
* @qdid: the given queuing destination id.
@@ -528,7 +591,7 @@ EXPORT_SYMBOL_GPL(dpaa2_io_service_acquire);
/**
* dpaa2_io_store_create() - Create the dma memory storage for dequeue result.
- * @max_frames: the maximum number of dequeued result for frames, must be <=
16.
+ * @max_frames: the maximum number of dequeued result for frames, must be <=
32.
* @dev:the device to allow mapping/unmapping the DMAable region.
*
* The size of the storage is "max_frames*sizeof(struct dpaa2_dq)".
@@ -543,7 +606,7 @@ struct dpaa2_io_store *dpaa2_io_store_create(unsigned int
max_frames,
struct dpaa2_io_store *ret;
size_t size;
- if (!max_frames || (max_frames > 16))
+ if (!max_frames || (max_frames > 32))
return NULL;
ret = kmalloc(sizeof(*ret), GFP_KERNEL);
diff --git a/drivers/soc/fsl/dpio/qbman-portal.c
b/drivers/soc/fsl/dpio/qbman-portal.c
index c66f5b7..c892a86 100644
--- a/drivers/soc/fsl/dpio/qbman-portal.c
+++ b/drivers/soc/fsl/dpio/qbman-portal.c
@@ -1,13 +1,14 @@
// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
/*
* Copyright (C) 2014-2016 Freescale Semiconductor, Inc.
- * Copyright 2016 NXP
+ * Copyright 2016-2019 NXP
*
*/
#include
#include
#include
+#include
#include
#include "qbman-portal.h"
@@ -28,6 +29,7 @@
/* CINH register offsets */
#define QBMAN_CINH_SWP_EQCR_PI 0x800
+#define QBMAN_CINH_SWP_EQCR_CI 0x840
#define QBMAN_CINH_SWP_EQAR0x8c0
#define QBMAN_CINH_SWP_CR_RT0x900
#define QBMAN_CINH_SWP_VDQCR_RT 0x940
@@ -51,6 +53,8 @@
#define QBMAN_CENA_SWP_CR 0x600
#define QBMAN_CENA_SWP_RR(vb) (0x700 + ((u32)(vb) >> 1))
#define QBMAN_CENA_SWP_VDQCR 0x780
+#define QBMAN_CENA_SWP_EQCR_CI 0x840
+#define QBMAN_CENA_SWP_EQCR_CI_MEMBACK
Re: [PATCH] powerpc/64e: drop stale call to smp_processor_id() which hangs SMP startup
Hi Christophe,
On Thu, 2019-08-08 at 12:48 +, Christophe Leroy wrote:
> Santa commit ebb9d30a6a74 ("powerpc/mm: any thread in one core can be
> the first to setup TLB1") removed the need to know the cpu_id in
> early_init_this_mmu(), but the call to smp_processor_id() which was
> marked __maybe_used remained.
>
> Since commit ed1cd6deb013 ("powerpc: Activate
> CONFIG_THREAD_INFO_IN_TASK") thread_info cannot be reached before mmu
> is properly set up.
>
> Drop this stale call to smp_processor_id() which make SMP hang
> when CONFIG_PREEMPT is set.
>
> Reported-by: Chris Packham
> Fixes: ebb9d30a6a74 ("powerpc/mm: any thread in one core can be the
> first to setup TLB1")
> Link: https://github.com/linuxppc/issues/issues/264
> Signed-off-by: Christophe Leroy
> Cc: sta...@vger.kernel.org
Many thanks for your help.
Tested-by: Chris Packham
> ---
> arch/powerpc/mm/nohash/tlb.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/nohash/tlb.c
> b/arch/powerpc/mm/nohash/tlb.c
> index d4acf6fa0596..bf60983a58c7 100644
> --- a/arch/powerpc/mm/nohash/tlb.c
> +++ b/arch/powerpc/mm/nohash/tlb.c
> @@ -630,7 +630,6 @@ static void early_init_this_mmu(void)
> #ifdef CONFIG_PPC_FSL_BOOK3E
> if (mmu_has_feature(MMU_FTR_TYPE_FSL_E)) {
> unsigned int num_cams;
> - int __maybe_unused cpu = smp_processor_id();
> bool map = true;
>
> /* use a quarter of the TLBCAM for bolted linear map
> */
Re: [PATCH] powerpc/kmcent2: update the ethernet devices' phy properties
Le mar. 30 juil. 2019 à 11:44, Madalin-cristian Bucur
a écrit :
>
> > -Original Message-
> >
> > > Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
> > > a écrit :
> > > >
> > > > Change all phy-connection-type properties to phy-mode that are better
> > > > supported by the fman driver.
> > > >
> > > > Use the more readable fixed-link node for the 2 sgmii links.
> > > >
> > > > Change the RGMII link to rgmii-id as the clock delays are added by the
> > > > phy.
> > > >
> > > > Signed-off-by: Valentin Longchamp
> >
> > I don't see any other uses of phy-mode in arch/powerpc/boot/dts/fsl, and I
> > see
> > lots of phy-connection-type with fman. Madalin, does this patch look OK?
> >
> > -Scott
>
> Hi,
>
> we are using "phy-connection-type" not "phy-mode" for the NXP (former
> Freescale)
> DPAA platforms. While the two seem to be interchangeable ("phy-mode" seems to
> be
> more recent, looking at the device tree bindings), the driver code in Linux
> seems
> to use one or the other, not both so one should stick with the variant the
> driver
> is using. To make things more complex, there may be dependencies in
> bootloaders,
> I see code in u-boot using only "phy-connection-type" or only "phy-mode".
>
> I'd leave "phy-connection-type" as is.
So I have finally had time to have a look and now I understand what
happens. You are right, there are bootloader dependencies: u-boot
calls fdt_fixup_phy_connection() that somehow in our case adds (or
changes if already in the device tree) the phy-connection-type
property to a wrong value ! By having a phy-mode in the device tree,
that is not changed by u-boot and by chance picked up by the kernel
fman driver (of_get_phy_mode() ) over phy-connection-mode, the below
patch fixes it for us.
I agree with you, it's not correct to have both phy-connection-type
and phy-mode. Ideally, u-boot on the board should be reworked so that
it does not perform the above wrong fixup. However, in an "unfixed"
.dtb (I have disabled fdt_fixup_phy_connection), the device tree in
the end only has either phy-connection-type or phy-mode, according to
what was chosen in the .dts file. And the fman driver works well with
both (thanks to the call to of_get_phy_mode() ). I would therefore
argue that even if all other DPAA platforms use phy-connection-type,
phy-mode is valid as well. (Furthermore we already have hundreds of
such boards in the field and we don't really support "remote" u-boot
update, so the u-boot fix is going to be difficult for us to pull).
Valentin
>
> Madalin
>
> > > > ---
> > > > arch/powerpc/boot/dts/fsl/kmcent2.dts | 16 +++-
> > > > 1 file changed, 11 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > > b/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > > index 48b7f9797124..c3e0741cafb1 100644
> > > > --- a/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > > +++ b/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > > @@ -210,13 +210,19 @@
> > > >
> > > > fman@40 {
> > > > ethernet@e {
> > > > - fixed-link = <0 1 1000 0 0>;
> > > > - phy-connection-type = "sgmii";
> > > > + phy-mode = "sgmii";
> > > > + fixed-link {
> > > > + speed = <1000>;
> > > > + full-duplex;
> > > > + };
> > > > };
> > > >
> > > > ethernet@e2000 {
> > > > - fixed-link = <1 1 1000 0 0>;
> > > > - phy-connection-type = "sgmii";
> > > > + phy-mode = "sgmii";
> > > > + fixed-link {
> > > > + speed = <1000>;
> > > > + full-duplex;
> > > > + };
> > > > };
> > > >
> > > > ethernet@e4000 {
> > > > @@ -229,7 +235,7 @@
> > > >
> > > > ethernet@e8000 {
> > > > phy-handle = <_phy>;
> > > > - phy-connection-type = "rgmii";
> > > > + phy-mode = "rgmii-id";
> > > > };
> > > >
> > > > mdio0: mdio@fc000 {
> > > > --
> > > > 2.17.1
> > > >
> > >
> > >
>
[PATCH 8/8] dma-mapping: remove CONFIG_ARCH_NO_COHERENT_DMA_MMAP
CONFIG_ARCH_NO_COHERENT_DMA_MMAP is now functionally identical to
!CONFIG_MMU, so remove the separate symbol. The only difference is that
arm did not set it for !CONFIG_MMU, but arm uses a separate dma mapping
implementation including its own mmap method, which is handled by moving
the CONFIG_MMU check in dma_can_mmap so that is only applies to the
dma-direct case, just as the other ifdefs for it.
Signed-off-by: Christoph Hellwig
---
arch/Kconfig| 3 ---
arch/c6x/Kconfig| 1 -
arch/m68k/Kconfig | 1 -
arch/microblaze/Kconfig | 1 -
arch/sh/Kconfig | 1 -
arch/xtensa/Kconfig | 1 -
kernel/dma/mapping.c| 12 +---
7 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index a7b57dd42c26..ec2834206d08 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -790,9 +790,6 @@ config COMPAT_32BIT_TIME
This is relevant on all 32-bit architectures, and 64-bit architectures
as part of compat syscall handling.
-config ARCH_NO_COHERENT_DMA_MMAP
- bool
-
config ARCH_NO_PREEMPT
bool
diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
index b4fb61c83494..e65e8d82442a 100644
--- a/arch/c6x/Kconfig
+++ b/arch/c6x/Kconfig
@@ -20,7 +20,6 @@ config C6X
select OF_EARLY_FLATTREE
select GENERIC_CLOCKEVENTS
select MODULES_USE_ELF_RELA
- select ARCH_NO_COHERENT_DMA_MMAP
select MMU_GATHER_NO_RANGE if MMU
config MMU
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index c518d695c376..614b355ae338 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -8,7 +8,6 @@ config M68K
select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
- select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_NO_PREEMPT if !COLDFIRE
select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index d411de05b628..632c9477a0f6 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -9,7 +9,6 @@ config MICROBLAZE
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_MIGHT_HAVE_PC_PARPORT
- select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT
select TIMER_OF
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 6b1b5941b618..f356ee674d89 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -5,7 +5,6 @@ config SUPERH
select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_MIGHT_HAVE_PC_PARPORT
- select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select HAVE_PATA_PLATFORM
select CLKDEV_LOOKUP
select DMA_DECLARE_COHERENT
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index ebc135bda921..70653aed3005 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -5,7 +5,6 @@ config XTENSA
select ARCH_HAS_BINFMT_FLAT if !MMU
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
- select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
select ARCH_WANT_FRAME_POINTERS
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 64d1de59e133..fc17016b0871 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -186,7 +186,7 @@ int dma_common_mmap(struct device *dev, struct
vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
-#ifndef CONFIG_ARCH_NO_COHERENT_DMA_MMAP
+#ifdef CONFIG_MMU
unsigned long user_count = vma_pages(vma);
unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long off = vma->vm_pgoff;
@@ -217,7 +217,7 @@ int dma_common_mmap(struct device *dev, struct
vm_area_struct *vma,
user_count << PAGE_SHIFT, vma->vm_page_prot);
#else
return -ENXIO;
-#endif /* !CONFIG_ARCH_NO_COHERENT_DMA_MMAP */
+#endif /* CONFIG_MMU */
}
/**
@@ -231,12 +231,10 @@ bool dma_can_mmap(struct device *dev)
{
const struct dma_map_ops *ops = get_dma_ops(dev);
- if (IS_ENABLED(CONFIG_ARCH_NO_COHERENT_DMA_MMAP))
- return false;
-
if (dma_is_direct(ops)) {
- return dev_is_dma_coherent(dev) ||
- IS_ENABLED(CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN);
+ return IS_ENABLED(CONFIG_MMU) &&
+ (dev_is_dma_coherent(dev) ||
+ IS_ENABLED(CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN));
}
return ops->mmap != NULL;
--
2.20.1
[PATCH 7/8] parisc: don't set ARCH_NO_COHERENT_DMA_MMAP
parisc is the only architecture that sets ARCH_NO_COHERENT_DMA_MMAP
when an MMU is enabled. AFAIK this is because parisc CPUs use VIVT
caches, which means exporting normally cachable memory to userspace is
relatively dangrous due to cache aliasing.
But normally cachable memory is only allocated by dma_alloc_coherent
on parisc when using the sba_iommu or ccio_iommu drivers, so just
remove the .mmap implementation for them so that we don't have to set
ARCH_NO_COHERENT_DMA_MMAP, which I plan to get rid of.
Signed-off-by: Christoph Hellwig
---
arch/parisc/Kconfig| 1 -
drivers/parisc/ccio-dma.c | 1 -
drivers/parisc/sba_iommu.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6d732e451071..e9dd88b7f81e 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -52,7 +52,6 @@ config PARISC
select GENERIC_SCHED_CLOCK
select HAVE_UNSTABLE_SCHED_CLOCK if SMP
select GENERIC_CLOCKEVENTS
- select ARCH_NO_COHERENT_DMA_MMAP
select CPU_NO_EFFICIENT_FFS
select NEED_DMA_MAP_STATE
select NEED_SG_DMA_LENGTH
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index 1d7125d29bee..ad290f79983b 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -1024,7 +1024,6 @@ static const struct dma_map_ops ccio_ops = {
.unmap_page = ccio_unmap_page,
.map_sg = ccio_map_sg,
.unmap_sg = ccio_unmap_sg,
- .mmap = dma_common_mmap,
.get_sgtable = dma_common_get_sgtable,
};
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index fa4df65b7e28..ed50502cc65a 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -1084,7 +1084,6 @@ static const struct dma_map_ops sba_ops = {
.unmap_page = sba_unmap_page,
.map_sg = sba_map_sg,
.unmap_sg = sba_unmap_sg,
- .mmap = dma_common_mmap,
.get_sgtable = dma_common_get_sgtable,
};
--
2.20.1
[PATCH 6/8] arm-nommu: call dma_mmap_from_dev_coherent directly
Ther is no need to go through dma_common_mmap for the arm-nommu dma mmap implementation as the only possible memory not handled above could be that from the per-device coherent pool. Signed-off-by: Christoph Hellwig --- arch/arm/mm/dma-mapping-nommu.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c index 52b82559d99b..db9247898300 100644 --- a/arch/arm/mm/dma-mapping-nommu.c +++ b/arch/arm/mm/dma-mapping-nommu.c @@ -68,8 +68,9 @@ static int arm_nommu_dma_mmap(struct device *dev, struct vm_area_struct *vma, if (dma_mmap_from_global_coherent(vma, cpu_addr, size, )) return ret; - - return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size, attrs); + if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, )) + return ret; + return -ENXIO; } -- 2.20.1
[PATCH 5/8] ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*
Replace the local hack with the dma_can_mmap helper to check if
a given device supports mapping DMA allocations to userspace.
Signed-off-by: Christoph Hellwig
Reviewed-by: Takashi Iwai
---
sound/core/pcm_native.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 703857aab00f..9763c18e176a 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -220,13 +220,12 @@ static bool hw_support_mmap(struct snd_pcm_substream
*substream)
{
if (!(substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP))
return false;
- /* architecture supports dma_mmap_coherent()? */
-#if defined(CONFIG_ARCH_NO_COHERENT_DMA_MMAP) || !defined(CONFIG_HAS_DMA)
- if (!substream->ops->mmap &&
- substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
- return false;
-#endif
- return true;
+
+ if (substream->ops->mmap ||
+ substream->dma_buffer.dev.type != SNDRV_DMA_TYPE_DEV)
+ return true;
+
+ return dma_can_mmap(substream->dma_buffer.dev.dev);
}
static int constrain_mask_params(struct snd_pcm_substream *substream,
--
2.20.1
[PATCH 4/8] dma-mapping: add a dma_can_mmap helper
Add a helper to check if DMA allocations for a specific device can be
mapped to userspace using dma_mmap_*.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 5 +
kernel/dma/mapping.c| 23 +++
2 files changed, 28 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f7d1eea32c78..17271857be5d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -462,6 +462,7 @@ int dma_get_sgtable_attrs(struct device *dev, struct
sg_table *sgt,
int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs);
+bool dma_can_mmap(struct device *dev);
int dma_supported(struct device *dev, u64 mask);
int dma_set_mask(struct device *dev, u64 mask);
int dma_set_coherent_mask(struct device *dev, u64 mask);
@@ -552,6 +553,10 @@ static inline int dma_mmap_attrs(struct device *dev,
struct vm_area_struct *vma,
{
return -ENXIO;
}
+static inline bool dma_can_mmap(struct device *dev)
+{
+ return false;
+}
static inline int dma_supported(struct device *dev, u64 mask)
{
return 0;
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 67b900ad0836..64d1de59e133 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -220,6 +220,29 @@ int dma_common_mmap(struct device *dev, struct
vm_area_struct *vma,
#endif /* !CONFIG_ARCH_NO_COHERENT_DMA_MMAP */
}
+/**
+ * dma_can_mmap - check if a given device supports dma_mmap_*
+ * @dev: device to check
+ *
+ * Returns %true if @dev supports dma_mmap_coherent() and dma_mmap_attrs() to
+ * map DMA allocations to userspace.
+ */
+bool dma_can_mmap(struct device *dev)
+{
+ const struct dma_map_ops *ops = get_dma_ops(dev);
+
+ if (IS_ENABLED(CONFIG_ARCH_NO_COHERENT_DMA_MMAP))
+ return false;
+
+ if (dma_is_direct(ops)) {
+ return dev_is_dma_coherent(dev) ||
+ IS_ENABLED(CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN);
+ }
+
+ return ops->mmap != NULL;
+}
+EXPORT_SYMBOL_GPL(dma_can_mmap);
+
/**
* dma_mmap_attrs - map a coherent DMA allocation into user space
* @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
--
2.20.1
[PATCH 3/8] dma-mapping: explicitly wire up ->mmap and ->get_sgtable
While the default ->mmap and ->get_sgtable implementations work for the
majority of our dma_map_ops impementations they are inherently safe
for others that don't use the page allocator or CMA and/or use their
own way of remapping not covered by the common code. So remove the
defaults if these methods are not wired up, but instead wire up the
default implementations for all safe instances.
Fixes: e1c7e324539a ("dma-mapping: always provide the dma_map_ops based
implementation")
Signed-off-by: Christoph Hellwig
---
arch/alpha/kernel/pci_iommu.c | 2 ++
arch/ia64/hp/common/sba_iommu.c | 2 ++
arch/ia64/sn/pci/pci_dma.c | 2 ++
arch/mips/jazz/jazzdma.c| 2 ++
arch/powerpc/kernel/dma-iommu.c | 2 ++
arch/powerpc/platforms/ps3/system-bus.c | 4
arch/powerpc/platforms/pseries/vio.c| 2 ++
arch/s390/pci/pci_dma.c | 2 ++
arch/x86/kernel/amd_gart_64.c | 2 ++
arch/x86/kernel/pci-calgary_64.c| 2 ++
drivers/iommu/amd_iommu.c | 2 ++
drivers/iommu/intel-iommu.c | 2 ++
drivers/parisc/ccio-dma.c | 2 ++
drivers/parisc/sba_iommu.c | 2 ++
kernel/dma/mapping.c| 20
15 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 242108439f42..7f1925a32c99 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -955,5 +955,7 @@ const struct dma_map_ops alpha_pci_ops = {
.map_sg = alpha_pci_map_sg,
.unmap_sg = alpha_pci_unmap_sg,
.dma_supported = alpha_pci_supported,
+ .mmap = dma_common_mmap,
+ .get_sgtable= dma_common_get_sgtable,
};
EXPORT_SYMBOL(alpha_pci_ops);
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index 3d24cc43385b..4c0ea6c2833d 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -2183,6 +2183,8 @@ const struct dma_map_ops sba_dma_ops = {
.map_sg = sba_map_sg_attrs,
.unmap_sg = sba_unmap_sg_attrs,
.dma_supported = sba_dma_supported,
+ .mmap = dma_common_mmap,
+ .get_sgtable= dma_common_get_sgtable,
};
void sba_dma_init(void)
diff --git a/arch/ia64/sn/pci/pci_dma.c b/arch/ia64/sn/pci/pci_dma.c
index b7d42e4edc1f..12ffb9c0d738 100644
--- a/arch/ia64/sn/pci/pci_dma.c
+++ b/arch/ia64/sn/pci/pci_dma.c
@@ -438,6 +438,8 @@ static struct dma_map_ops sn_dma_ops = {
.unmap_sg = sn_dma_unmap_sg,
.dma_supported = sn_dma_supported,
.get_required_mask = sn_dma_get_required_mask,
+ .mmap = dma_common_mmap,
+ .get_sgtable= dma_common_get_sgtable,
};
void sn_dma_init(void)
diff --git a/arch/mips/jazz/jazzdma.c b/arch/mips/jazz/jazzdma.c
index 1804dc9d8136..a01e14955187 100644
--- a/arch/mips/jazz/jazzdma.c
+++ b/arch/mips/jazz/jazzdma.c
@@ -682,5 +682,7 @@ const struct dma_map_ops jazz_dma_ops = {
.sync_sg_for_device = jazz_dma_sync_sg_for_device,
.dma_supported = dma_direct_supported,
.cache_sync = arch_dma_cache_sync,
+ .mmap = dma_common_mmap,
+ .get_sgtable= dma_common_get_sgtable,
};
EXPORT_SYMBOL(jazz_dma_ops);
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index a0879674a9c8..2f5a53874f6d 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -208,4 +208,6 @@ const struct dma_map_ops dma_iommu_ops = {
.sync_single_for_device = dma_iommu_sync_for_device,
.sync_sg_for_cpu= dma_iommu_sync_sg_for_cpu,
.sync_sg_for_device = dma_iommu_sync_sg_for_device,
+ .mmap = dma_common_mmap,
+ .get_sgtable= dma_common_get_sgtable,
};
diff --git a/arch/powerpc/platforms/ps3/system-bus.c
b/arch/powerpc/platforms/ps3/system-bus.c
index 6818317073b9..3542b7bd6a46 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -694,6 +694,8 @@ static const struct dma_map_ops ps3_sb_dma_ops = {
.dma_supported = ps3_dma_supported,
.map_page = ps3_sb_map_page,
.unmap_page = ps3_unmap_page,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
static const struct dma_map_ops ps3_ioc0_dma_ops = {
@@ -704,6 +706,8 @@ static const struct dma_map_ops ps3_ioc0_dma_ops = {
.dma_supported = ps3_dma_supported,
.map_page = ps3_ioc0_map_page,
.unmap_page = ps3_unmap_page,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
/**
diff --git a/arch/powerpc/platforms/pseries/vio.c
[PATCH 2/8] dma-mapping: move the dma_get_sgtable API comments from arm to common code
The comments are spot on and should be near the central API, not just near a single implementation. Signed-off-by: Christoph Hellwig --- arch/arm/mm/dma-mapping.c | 11 --- kernel/dma/mapping.c | 11 +++ 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index ad64d32fb39a..b4d65da76393 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -880,17 +880,6 @@ static void arm_coherent_dma_free(struct device *dev, size_t size, void *cpu_add __arm_dma_free(dev, size, cpu_addr, handle, attrs, true); } -/* - * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems - * that the intention is to allow exporting memory allocated via the - * coherent DMA APIs through the dma_buf API, which only accepts a - * scattertable. This presents a couple of problems: - * 1. Not all memory allocated via the coherent DMA APIs is backed by - *a struct page - * 2. Passing coherent DMA memory into the streaming APIs is not allowed - *as we will try to flush the memory through a different alias to that - *actually being used (and the flushes are redundant.) - */ int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt, void *cpu_addr, dma_addr_t handle, size_t size, unsigned long attrs) diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index 9c0f6a8eb5cb..41590d003465 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -136,6 +136,17 @@ int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt, return ret; } +/* + * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems + * that the intention is to allow exporting memory allocated via the + * coherent DMA APIs through the dma_buf API, which only accepts a + * scattertable. This presents a couple of problems: + * 1. Not all memory allocated via the coherent DMA APIs is backed by + *a struct page + * 2. Passing coherent DMA memory into the streaming APIs is not allowed + *as we will try to flush the memory through a different alias to that + *actually being used (and the flushes are redundant.) + */ int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt, void *cpu_addr, dma_addr_t dma_addr, size_t size, unsigned long attrs) -- 2.20.1
remove default fallbacks in dma_map_ops v3
Hi all, we have a few places where the DMA mapping layer has non-trivial default actions that are questionable and/or dangerous. This series instead wires up the mmap, get_sgtable and get_required_mask methods explicitly and cleans up some surrounding areas. This also means we could get rid of the ARCH_NO_COHERENT_DMA_MMAP kconfig option, as we now require a mmap method wired up, or in case of non-coherent dma-direct the presence of the arch_dma_coherent_to_pfn hook. The only interesting case is that the sound code also checked the ARCH_NO_COHERENT_DMA_MMAP symbol in somewhat odd ways, so I'd like to see a review of the sound situation before going forward with that patch. Changes since v2: - fix use of dma_can_mmap in alsa - improve the CONFIG_* mess a little more Changes since v1: - add a dma_can_mmap helper for alsa
[PATCH 1/8] dma-mapping: provide a better default ->get_required_mask
Most dma_map_ops instances are IOMMUs that work perfectly fine in 32-bits
of IOVA space, and the generic direct mapping code already provides its
own routines that is intelligent based on the amount of memory actually
present. Wire up the dma-direct routine for the ARM direct mapping code
as well, and otherwise default to the constant 32-bit mask. This way
we only need to override it for the occasional odd IOMMU that requires
64-bit IOVA support, or IOMMU drivers that are more efficient if they
can fall back to the direct mapping.
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/dma-mapping.c | 3 +++
arch/powerpc/platforms/ps3/system-bus.c | 7 --
arch/x86/kernel/amd_gart_64.c | 1 +
kernel/dma/mapping.c| 30 +
4 files changed, 14 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 8c0b0baeb398..ad64d32fb39a 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -192,6 +193,7 @@ const struct dma_map_ops arm_dma_ops = {
.sync_sg_for_cpu= arm_dma_sync_sg_for_cpu,
.sync_sg_for_device = arm_dma_sync_sg_for_device,
.dma_supported = arm_dma_supported,
+ .get_required_mask = dma_direct_get_required_mask,
};
EXPORT_SYMBOL(arm_dma_ops);
@@ -212,6 +214,7 @@ const struct dma_map_ops arm_coherent_dma_ops = {
.map_sg = arm_dma_map_sg,
.map_resource = dma_direct_map_resource,
.dma_supported = arm_dma_supported,
+ .get_required_mask = dma_direct_get_required_mask,
};
EXPORT_SYMBOL(arm_coherent_dma_ops);
diff --git a/arch/powerpc/platforms/ps3/system-bus.c
b/arch/powerpc/platforms/ps3/system-bus.c
index 98410119c47b..6818317073b9 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -686,18 +686,12 @@ static int ps3_dma_supported(struct device *_dev, u64
mask)
return mask >= DMA_BIT_MASK(32);
}
-static u64 ps3_dma_get_required_mask(struct device *_dev)
-{
- return DMA_BIT_MASK(32);
-}
-
static const struct dma_map_ops ps3_sb_dma_ops = {
.alloc = ps3_alloc_coherent,
.free = ps3_free_coherent,
.map_sg = ps3_sb_map_sg,
.unmap_sg = ps3_sb_unmap_sg,
.dma_supported = ps3_dma_supported,
- .get_required_mask = ps3_dma_get_required_mask,
.map_page = ps3_sb_map_page,
.unmap_page = ps3_unmap_page,
};
@@ -708,7 +702,6 @@ static const struct dma_map_ops ps3_ioc0_dma_ops = {
.map_sg = ps3_ioc0_map_sg,
.unmap_sg = ps3_ioc0_unmap_sg,
.dma_supported = ps3_dma_supported,
- .get_required_mask = ps3_dma_get_required_mask,
.map_page = ps3_ioc0_map_page,
.unmap_page = ps3_unmap_page,
};
diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index a585ea6f686a..03ed9675f954 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -678,6 +678,7 @@ static const struct dma_map_ops gart_dma_ops = {
.alloc = gart_alloc_coherent,
.free = gart_free_coherent,
.dma_supported = dma_direct_supported,
+ .get_required_mask = dma_direct_get_required_mask,
};
static void gart_iommu_shutdown(void)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index b0038ca3aa92..9c0f6a8eb5cb 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -233,25 +233,6 @@ int dma_mmap_attrs(struct device *dev, struct
vm_area_struct *vma,
}
EXPORT_SYMBOL(dma_mmap_attrs);
-static u64 dma_default_get_required_mask(struct device *dev)
-{
- u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
- u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
- u64 mask;
-
- if (!high_totalram) {
- /* convert to mask just covering totalram */
- low_totalram = (1 << (fls(low_totalram) - 1));
- low_totalram += low_totalram - 1;
- mask = low_totalram;
- } else {
- high_totalram = (1 << (fls(high_totalram) - 1));
- high_totalram += high_totalram - 1;
- mask = (((u64)high_totalram) << 32) + 0x;
- }
- return mask;
-}
-
u64 dma_get_required_mask(struct device *dev)
{
const struct dma_map_ops *ops = get_dma_ops(dev);
@@ -260,7 +241,16 @@ u64 dma_get_required_mask(struct device *dev)
return dma_direct_get_required_mask(dev);
if (ops->get_required_mask)
return ops->get_required_mask(dev);
- return dma_default_get_required_mask(dev);
+
+ /*
+* We require every DMA ops implementation to at least support a 32-bit
+* DMA mask (and use bounce buffering if that
Re: [PATCH 0/2] ftrace: two fixes with func_probes handling
On Thu, 08 Aug 2019 20:45:04 +0530 "Naveen N. Rao" wrote: > Naveen N. Rao wrote: > > Two patches addressing bugs in ftrace function probe handling. The first > > patch addresses a NULL pointer dereference reported by LTP tests, while > > the second one is a trivial patch to address a missing check for return > > value, found by code inspection. > > Steven, > Can you please take a look at these patches? Thanks for the ping. Yes I will. -- Steve
Re: [PATCH 0/2] ftrace: two fixes with func_probes handling
Naveen N. Rao wrote: Two patches addressing bugs in ftrace function probe handling. The first patch addresses a NULL pointer dereference reported by LTP tests, while the second one is a trivial patch to address a missing check for return value, found by code inspection. Steven, Can you please take a look at these patches? Thanks, Naveen
[Bug 204479] KASAN hit at modprobe zram
https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #4 from Christophe Leroy (christophe.le...@c-s.fr) ---
We need to identify if the allocation of KASAN shadow area at module allocation
fails, or if kasan accesses outside of the allocated area.
Could you please run again with the below trace:
diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c
b/arch/powerpc/mm/kasan/kasan_init_32.c
index 74f4555a62ba..2bca2bf691a9 100644
--- a/arch/powerpc/mm/kasan/kasan_init_32.c
+++ b/arch/powerpc/mm/kasan/kasan_init_32.c
@@ -142,6 +142,9 @@ void *module_alloc(unsigned long size)
if (!base)
return NULL;
+ pr_err("## module_alloc(%lx) = %px [%px-%px]\n", size, base,
+ kasan_mem_to_shadow(base), kasan_mem_to_shadow(base + size));
+
if (!kasan_init_region(base, size))
return base;
--
You are receiving this mail because:
You are on the CC list for the bug.
Re: SMP lockup at boot on Freescale/NXP T2080 (powerpc 64)
Le 08/08/2019 à 10:46, Christophe Leroy a écrit : Le 07/08/2019 à 03:24, Chris Packham a écrit : On Wed, 2019-08-07 at 11:13 +1000, Michael Ellerman wrote: Chris Packham writes: On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote: The difference between a working and non working defconfig is CONFIG_PREEMPT specifically CONFIG_PREEMPT=y makes my system hang at boot. Is that now intentionally prohibited on 64-bit powerpc? It's not prohibitied, but it probably should be because no one really tests it properly. I have a handful of IBM machines where I boot a PREEMPT kernel but that's about it. The corenet configs don't have PREEMPT enabled, which suggests it was never really supported on those machines. But maybe someone from NXP can tell me otherwise. I think our workloads need CONFIG_PREEMPT=y because our systems have switch ASIC drivers implemented in userland and we need to be able to react quickly to network events in order to prevent loops. We have seen instances of this not happening simply because some other process is in the middle of a syscall. One thing I am working on here is a setup with a few vendor boards and some of our own kit that we can test the upstream kernels on. Hopefully that'd make these kinds of reports more timely rather than just whenever we decide to move to a new kernel version. The defconfig also sets CONFIG_DEBUG_PREEMPT. Have you tried without CONFIG_DEBUG_PREEMPT ? Reproduced on QEMU. CONFIG_DEBUG_PREEMPT is the trigger. Due to smp_processor_id() being called from early_init_this_mmu(), when CONFIG_DEBUG_PREEMPT is set debug_smp_processor_id() is called instead of raw_smp_processor_id(), but this is too early for debug_smp_processor_id() As this call is useless, just drop it. Can you test patch at https://patchwork.ozlabs.org/patch/1144005/ ? Thanks Christophe
[PATCH] powerpc/64e: drop stale call to smp_processor_id() which hangs SMP startup
Santa commit ebb9d30a6a74 ("powerpc/mm: any thread in one core can be
the first to setup TLB1") removed the need to know the cpu_id in
early_init_this_mmu(), but the call to smp_processor_id() which was
marked __maybe_used remained.
Since commit ed1cd6deb013 ("powerpc: Activate
CONFIG_THREAD_INFO_IN_TASK") thread_info cannot be reached before mmu
is properly set up.
Drop this stale call to smp_processor_id() which make SMP hang
when CONFIG_PREEMPT is set.
Reported-by: Chris Packham
Fixes: ebb9d30a6a74 ("powerpc/mm: any thread in one core can be the first to
setup TLB1")
Link: https://github.com/linuxppc/issues/issues/264
Signed-off-by: Christophe Leroy
Cc: sta...@vger.kernel.org
---
arch/powerpc/mm/nohash/tlb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/mm/nohash/tlb.c b/arch/powerpc/mm/nohash/tlb.c
index d4acf6fa0596..bf60983a58c7 100644
--- a/arch/powerpc/mm/nohash/tlb.c
+++ b/arch/powerpc/mm/nohash/tlb.c
@@ -630,7 +630,6 @@ static void early_init_this_mmu(void)
#ifdef CONFIG_PPC_FSL_BOOK3E
if (mmu_has_feature(MMU_FTR_TYPE_FSL_E)) {
unsigned int num_cams;
- int __maybe_unused cpu = smp_processor_id();
bool map = true;
/* use a quarter of the TLBCAM for bolted linear map */
--
2.13.3
[Bug 204371] BUG kmalloc-4k (Tainted: G W ): Object padding overwritten
https://bugzilla.kernel.org/show_bug.cgi?id=204371 --- Comment #10 from David Sterba (dste...@suse.com) --- In my case it happened on 5.3-rc3, with a strestest. The same machine has been running fstests periodically, with slab debug on, but there are no slab reports like that. [ 8516.870046] BUG kmalloc-4k (Not tainted): Poison overwritten [ 8516.875873] - [ 8516.885864] Disabling lock debugging due to kernel taint [ 8516.891312] INFO: 0x1c70c8c9-0x3cd1e164. First byte 0x16 instead of 0x6b [ 8516.899717] INFO: Allocated in btrfs_read_tree_root+0x46/0x120 [btrfs] age=1769 cpu=7 pid=8717 [ 8516.908544] __slab_alloc.isra.53+0x3e/0x70 [ 8516.912861] kmem_cache_alloc_trace+0x1b0/0x330 [ 8516.917581] btrfs_read_tree_root+0x46/0x120 [btrfs] [ 8516.922737] btrfs_read_fs_root+0xe/0x40 [btrfs] [ 8516.927552] create_reloc_root+0x17f/0x2a0 [btrfs] [ 8516.932536] btrfs_init_reloc_root+0x72/0xe0 [btrfs] [ 8516.937686] record_root_in_trans+0xbb/0xf0 [btrfs] [ 8516.942750] btrfs_record_root_in_trans+0x50/0x70 [btrfs] [ 8516.948340] start_transaction+0xa1/0x550 [btrfs] [ 8516.953237] __btrfs_prealloc_file_range+0xca/0x490 [btrfs] [ 8516.959003] btrfs_prealloc_file_range+0x10/0x20 [btrfs] [ 8516.964509] prealloc_file_extent_cluster+0x13e/0x2b0 [btrfs] [ 8516.970447] relocate_file_extent_cluster+0x8d/0x530 [btrfs] [ 8516.976305] relocate_data_extent+0x80/0x110 [btrfs] [ 8516.981469] relocate_block_group+0x473/0x720 [btrfs] [ 8516.986711] btrfs_relocate_block_group+0x15f/0x2c0 [btrfs] [ 8516.992470] INFO: Freed in btrfs_drop_snapshot+0x832/0xbb0 [btrfs] age=331 cpu=5 pid=8717 [ 8517.000865] kfree+0x29a/0x2d0 [ 8517.004098] btrfs_drop_snapshot+0x832/0xbb0 [btrfs] [ 8517.009279] clean_dirty_subvols+0xf7/0x120 [btrfs] [ 8517.014369] relocate_block_group+0x25a/0x720 [btrfs] [ 8517.019616] btrfs_relocate_block_group+0x15f/0x2c0 [btrfs] [ 8517.025385] btrfs_relocate_chunk+0x49/0x100 [btrfs] [ 8517.030557] __btrfs_balance+0xa00/0xdb0 [btrfs] [ 8517.035365] btrfs_balance+0x3b8/0xbb0 [btrfs] [ 8517.040011] btrfs_ioctl_balance+0x2d5/0x380 [btrfs] [ 8517.045176] btrfs_ioctl+0x16db/0x3460 [btrfs] [ 8517.049772] do_vfs_ioctl+0xa5/0x710 [ 8517.053491] ksys_ioctl+0x70/0x80 [ 8517.056958] __x64_sys_ioctl+0x16/0x20 [ 8517.060845] do_syscall_64+0x5c/0x1d0 [ 8517.064650] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 8518.630509] INFO: 0x088ac804-0x600f3eff. First byte 0x17 instead of 0x6b [ 8518.640015] Object 64763fee: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 8518.650047] INFO: Allocated in btrfs_read_tree_root+0x46/0x120 [btrfs] age=2298 cpu=4 pid=8634 [ 8518.658240] Object 1d16ab39: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 8518.667744] __slab_alloc.isra.53+0x3e/0x70 [ 8518.667751] kmem_cache_alloc_trace+0x1b0/0x330 [ 8518.676569] Object 0f5b2c4b: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 8518.686125] btrfs_read_tree_root+0x46/0x120 [btrfs] [ 8518.686186] btrfs_read_fs_root+0xe/0x40 [btrfs] [ 8518.690444] Object 0e589530: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 8518.695159] create_reloc_root+0x17f/0x2a0 [btrfs] [ 8518.695226] btrfs_init_reloc_root+0x72/0xe0 [btrfs] [ 8518.704680] Object e3821ddd: 6b 6b 6b 6b 6b 6b 6b
Re: [PATCH v2] powerpc/fadump: sysfs for fadump memory reservation
On 08/08/19 3:38 PM, Sourabh Jain wrote: > Add a sys interface to allow querying the memory reserved by > fadump for saving the crash dump. > > Add an ABI doc entry for new sysfs interface. >- /sys/kernel/fadump_mem_reserved > > Signed-off-by: Sourabh Jain > --- > v1 -> v2: > - Added ABI doc for new sysfs interface. > --- > > Documentation/ABI/testing/sysfs-kernel-fadump| 6 ++ > Documentation/powerpc/firmware-assisted-dump.rst | 5 + > arch/powerpc/kernel/fadump.c | 14 ++ > 3 files changed, 25 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-kernel-fadump > > diff --git a/Documentation/ABI/testing/sysfs-kernel-fadump > b/Documentation/ABI/testing/sysfs-kernel-fadump > new file mode 100644 > index ..003e2f025dcb > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-kernel-fadump > @@ -0,0 +1,6 @@ > +What:/sys/kernel/fadump_mem_reserved > +Date:August 2019 > +Contact: linuxppc-dev@lists.ozlabs.org > +Description: read only > + Provide information about the amount of memory > + reserved by fadump to saving the crash dump. s/to saving/to save/ Rest looks good.. Thanks Hari
[Bug 204371] BUG kmalloc-4k (Tainted: G W ): Object padding overwritten
https://bugzilla.kernel.org/show_bug.cgi?id=204371 David Sterba (dste...@suse.com) changed: What|Removed |Added CC||dste...@suse.com --- Comment #9 from David Sterba (dste...@suse.com) --- I've hit the same problem, on x86_64. -- You are receiving this mail because: You are on the CC list for the bug.
[PATCH v2] powerpc/fadump: sysfs for fadump memory reservation
Add a sys interface to allow querying the memory reserved by
fadump for saving the crash dump.
Add an ABI doc entry for new sysfs interface.
- /sys/kernel/fadump_mem_reserved
Signed-off-by: Sourabh Jain
---
v1 -> v2:
- Added ABI doc for new sysfs interface.
---
Documentation/ABI/testing/sysfs-kernel-fadump| 6 ++
Documentation/powerpc/firmware-assisted-dump.rst | 5 +
arch/powerpc/kernel/fadump.c | 14 ++
3 files changed, 25 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-fadump
diff --git a/Documentation/ABI/testing/sysfs-kernel-fadump
b/Documentation/ABI/testing/sysfs-kernel-fadump
new file mode 100644
index ..003e2f025dcb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-fadump
@@ -0,0 +1,6 @@
+What: /sys/kernel/fadump_mem_reserved
+Date: August 2019
+Contact: linuxppc-dev@lists.ozlabs.org
+Description: read only
+ Provide information about the amount of memory
+ reserved by fadump to saving the crash dump.
diff --git a/Documentation/powerpc/firmware-assisted-dump.rst
b/Documentation/powerpc/firmware-assisted-dump.rst
index 9ca12830a48e..a5dfb20d4dc3 100644
--- a/Documentation/powerpc/firmware-assisted-dump.rst
+++ b/Documentation/powerpc/firmware-assisted-dump.rst
@@ -222,6 +222,11 @@ Here is the list of files under kernel sysfs:
be handled and vmcore will not be captured. This interface can be
easily integrated with kdump service start/stop.
+ /sys/kernel/fadump_mem_reserved
+
+ This is used to display the memory reserved by fadump for saving the
+ crash dump.
+
/sys/kernel/fadump_release_mem
This file is available only when fadump is active during
second kernel. This is used to release the reserved memory
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4eab97292cc2..cd373d1d4b82 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1514,6 +1514,13 @@ static ssize_t fadump_enabled_show(struct kobject *kobj,
return sprintf(buf, "%d\n", fw_dump.fadump_enabled);
}
+static ssize_t fadump_mem_reserved_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%ld\n", fw_dump.reserve_dump_area_size);
+}
+
static ssize_t fadump_register_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
@@ -1632,6 +1639,9 @@ static struct kobj_attribute fadump_attr =
__ATTR(fadump_enabled,
static struct kobj_attribute fadump_register_attr = __ATTR(fadump_registered,
0644, fadump_register_show,
fadump_register_store);
+static struct kobj_attribute fadump_mem_reserved_attr =
+ __ATTR(fadump_mem_reserved, 0444,
+ fadump_mem_reserved_show, NULL);
DEFINE_SHOW_ATTRIBUTE(fadump_region);
@@ -1663,6 +1673,10 @@ static void fadump_init_files(void)
printk(KERN_ERR "fadump: unable to create sysfs file"
" fadump_release_mem (%d)\n", rc);
}
+ rc = sysfs_create_file(kernel_kobj, _mem_reserved_attr.attr);
+ if (rc)
+ pr_err("unable to create sysfs file fadump_mem_reserved (%d)\n",
+ rc);
return;
}
--
2.17.2
Re: [PATCH v2 0/3] arm/arm64: Add support for function error injection
On Wed, Aug 07, 2019 at 05:07:03PM +0100, Will Deacon wrote: > On Tue, Aug 06, 2019 at 06:00:12PM +0800, Leo Yan wrote: > > This small patch set is to add support for function error injection; > > this can be used to eanble more advanced debugging feature, e.g. > > CONFIG_BPF_KPROBE_OVERRIDE. > > > > The patch 01/03 is to consolidate the function definition which can be > > suared cross architectures, patches 02,03/03 are used for enabling > > function error injection on arm64 and arm architecture respectively. > > > > I tested on arm64 platform Juno-r2 and one of my laptop with x86 > > architecture with below steps; I don't test for Arm architecture so > > only pass compilation. > > Thanks. I've queued the first two patches up here: > > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/error-injection Thank you, Will. Leo.
Re: [PATCH v4 7/9] powerpc/eeh: Add bdfn field to eeh_dev
On Thu, Aug 8, 2019 at 5:05 PM Jordan Niethe wrote:
>
> On Wed, 2019-08-07 at 13:44 +1000, Sam Bobroff wrote:
> > From: Oliver O'Halloran
> >
> > Preparation for removing pci_dn from the powernv EEH code. The only
> > thing we really use pci_dn for is to get the bdfn of the device for
> > config space accesses, so adding that information to eeh_dev reduces
> > the need to carry around the pci_dn.
> >
> > Signed-off-by: Oliver O'Halloran
> > [SB: Re-wrapped commit message, fixed whitespace damage.]
> > Signed-off-by: Sam Bobroff
> > ---
> > arch/powerpc/include/asm/eeh.h | 2 ++
> > arch/powerpc/include/asm/ppc-pci.h | 2 ++
> > arch/powerpc/kernel/eeh_dev.c | 2 ++
> > 3 files changed, 6 insertions(+)
> >
> > diff --git a/arch/powerpc/include/asm/eeh.h
> > b/arch/powerpc/include/asm/eeh.h
> > index 7f9404a0c3bb..bbe0798f6624 100644
> > --- a/arch/powerpc/include/asm/eeh.h
> > +++ b/arch/powerpc/include/asm/eeh.h
> > @@ -121,6 +121,8 @@ static inline bool eeh_pe_passed(struct eeh_pe
> > *pe)
> > struct eeh_dev {
> > int mode; /* EEH mode */
> > int class_code; /* Class code of the device
> > */
> > + int bdfn; /* bdfn of device (for cfg ops) */
> > + struct pci_controller *controller;
>
> The other members of the structure get a comment, maybe it would be
> more consistant if this one did too?
At some point we need to go through all the EEH documentation /
comments and get rid of everything that is not useful or just straight
up wrong. The comments here are in-offensive, but they mostly just
repeat the information in the variable name so it's hard to see the
value.
Re: SMP lockup at boot on Freescale/NXP T2080 (powerpc 64)
Le 07/08/2019 à 03:24, Chris Packham a écrit : On Wed, 2019-08-07 at 11:13 +1000, Michael Ellerman wrote: Chris Packham writes: On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote: The difference between a working and non working defconfig is CONFIG_PREEMPT specifically CONFIG_PREEMPT=y makes my system hang at boot. Is that now intentionally prohibited on 64-bit powerpc? It's not prohibitied, but it probably should be because no one really tests it properly. I have a handful of IBM machines where I boot a PREEMPT kernel but that's about it. The corenet configs don't have PREEMPT enabled, which suggests it was never really supported on those machines. But maybe someone from NXP can tell me otherwise. I think our workloads need CONFIG_PREEMPT=y because our systems have switch ASIC drivers implemented in userland and we need to be able to react quickly to network events in order to prevent loops. We have seen instances of this not happening simply because some other process is in the middle of a syscall. One thing I am working on here is a setup with a few vendor boards and some of our own kit that we can test the upstream kernels on. Hopefully that'd make these kinds of reports more timely rather than just whenever we decide to move to a new kernel version. The defconfig also sets CONFIG_DEBUG_PREEMPT. Have you tried without CONFIG_DEBUG_PREEMPT ? Christophe
Re: [PATCH v5 10/10] powerpc/fsl_booke/kaslr: dump out kernel offset information on panic
On 2019/8/7 21:03, Michael Ellerman wrote:
Jason Yan writes:
When kaslr is enabled, the kernel offset is different for every boot.
This brings some difficult to debug the kernel. Dump out the kernel
offset when panic so that we can easily debug the kernel.
Some of this is taken from the arm64 version right? Please say so when
you copy other people's code.
No problem. Architectures like x86 or arm64 or s390 both have this
similar code. I guess x86 is the first one.
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index c4ed328a7b96..078fe3d76feb 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -86,6 +86,7 @@ void arch_crash_save_vmcoreinfo(void)
VMCOREINFO_STRUCT_SIZE(mmu_psize_def);
VMCOREINFO_OFFSET(mmu_psize_def, shift);
#endif
+ vmcoreinfo_append_str("KERNELOFFSET=%lx\n", kaslr_offset());
}
There's no mention of that in the commit log.
Please split it into a separate patch and describe what you're doing and
why.
OK
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 1f8db666468d..064075f02837 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -715,12 +715,31 @@ static struct notifier_block ppc_panic_block = {
.priority = INT_MIN /* may not return; must be done last */
};
+/*
+ * Dump out kernel offset information on panic.
+ */
+static int dump_kernel_offset(struct notifier_block *self, unsigned long v,
+ void *p)
+{
+ pr_emerg("Kernel Offset: 0x%lx from 0x%lx\n",
+kaslr_offset(), KERNELBASE);
+
+ return 0;
+}
+
+static struct notifier_block kernel_offset_notifier = {
+ .notifier_call = dump_kernel_offset
+};
+
void __init setup_panic(void)
{
/* PPC64 always does a hard irq disable in its panic handler */
if (!IS_ENABLED(CONFIG_PPC64) && !ppc_md.panic)
return;
atomic_notifier_chain_register(_notifier_list, _panic_block);
+ if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && kaslr_offset() > 0)
+ atomic_notifier_chain_register(_notifier_list,
+ _offset_notifier);
Don't you want to do that before the return above?
Eagle eye. This should not affected by the conditions above.
}
cheers
.
Re: [PATCH v5 09/10] powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter
On 2019/8/7 21:03, Michael Ellerman wrote:
Jason Yan writes:
diff --git a/arch/powerpc/kernel/kaslr_booke.c
b/arch/powerpc/kernel/kaslr_booke.c
index c6b326424b54..436f9a03f385 100644
--- a/arch/powerpc/kernel/kaslr_booke.c
+++ b/arch/powerpc/kernel/kaslr_booke.c
@@ -361,6 +361,18 @@ static unsigned long __init kaslr_choose_location(void
*dt_ptr, phys_addr_t size
return kaslr_offset;
}
+static inline __init bool kaslr_disabled(void)
+{
+ char *str;
+
+ str = strstr(boot_command_line, "nokaslr");
+ if (str == boot_command_line ||
+ (str > boot_command_line && *(str - 1) == ' '))
+ return true;
This extra logic doesn't work for "nokaslrfoo". Is it worth it?
Seems nobody likes this logic. Maybe I can delete this logic for now and
see if anyone has any objections.
cheers
.
[PATCH] powerpc/mm: Use refcount_t for refcount
Reference counters are preferred to use refcount_t instead of
atomic_t.
This is because the implementation of refcount_t can prevent
overflows and detect possible use-after-free.
So convert atomic_t ref counters to refcount_t.
Signed-off-by: Chuhong Yuan
---
arch/powerpc/mm/book3s64/mmu_context.c | 2 +-
arch/powerpc/mm/book3s64/pgtable.c | 7 +++
arch/powerpc/mm/pgtable-frag.c | 9 -
include/linux/mm_types.h | 3 ++-
4 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/mmu_context.c
b/arch/powerpc/mm/book3s64/mmu_context.c
index 2d0cb5ba9a47..f836fd5a6abc 100644
--- a/arch/powerpc/mm/book3s64/mmu_context.c
+++ b/arch/powerpc/mm/book3s64/mmu_context.c
@@ -231,7 +231,7 @@ static void pmd_frag_destroy(void *pmd_frag)
/* drop all the pending references */
count = ((unsigned long)pmd_frag & ~PAGE_MASK) >> PMD_FRAG_SIZE_SHIFT;
/* We allow PTE_FRAG_NR fragments from a PTE page */
- if (atomic_sub_and_test(PMD_FRAG_NR - count, >pt_frag_refcount)) {
+ if (refcount_sub_and_test(PMD_FRAG_NR - count,
>pt_frag_refcount)) {
pgtable_pmd_page_dtor(page);
__free_page(page);
}
diff --git a/arch/powerpc/mm/book3s64/pgtable.c
b/arch/powerpc/mm/book3s64/pgtable.c
index 7d0e0d0d22c4..40056896ce4e 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -277,7 +277,7 @@ static pmd_t *__alloc_for_pmdcache(struct mm_struct *mm)
return NULL;
}
- atomic_set(>pt_frag_refcount, 1);
+ refcount_set(>pt_frag_refcount, 1);
ret = page_address(page);
/*
@@ -294,7 +294,7 @@ static pmd_t *__alloc_for_pmdcache(struct mm_struct *mm)
* count.
*/
if (likely(!mm->context.pmd_frag)) {
- atomic_set(>pt_frag_refcount, PMD_FRAG_NR);
+ refcount_set(>pt_frag_refcount, PMD_FRAG_NR);
mm->context.pmd_frag = ret + PMD_FRAG_SIZE;
}
spin_unlock(>page_table_lock);
@@ -317,8 +317,7 @@ void pmd_fragment_free(unsigned long *pmd)
{
struct page *page = virt_to_page(pmd);
- BUG_ON(atomic_read(>pt_frag_refcount) <= 0);
- if (atomic_dec_and_test(>pt_frag_refcount)) {
+ if (refcount_dec_and_test(>pt_frag_refcount)) {
pgtable_pmd_page_dtor(page);
__free_page(page);
}
diff --git a/arch/powerpc/mm/pgtable-frag.c b/arch/powerpc/mm/pgtable-frag.c
index a7b05214760c..4ef8231b677f 100644
--- a/arch/powerpc/mm/pgtable-frag.c
+++ b/arch/powerpc/mm/pgtable-frag.c
@@ -24,7 +24,7 @@ void pte_frag_destroy(void *pte_frag)
/* drop all the pending references */
count = ((unsigned long)pte_frag & ~PAGE_MASK) >> PTE_FRAG_SIZE_SHIFT;
/* We allow PTE_FRAG_NR fragments from a PTE page */
- if (atomic_sub_and_test(PTE_FRAG_NR - count, >pt_frag_refcount)) {
+ if (refcount_sub_and_test(PTE_FRAG_NR - count,
>pt_frag_refcount)) {
pgtable_page_dtor(page);
__free_page(page);
}
@@ -71,7 +71,7 @@ static pte_t *__alloc_for_ptecache(struct mm_struct *mm, int
kernel)
return NULL;
}
- atomic_set(>pt_frag_refcount, 1);
+ refcount_set(>pt_frag_refcount, 1);
ret = page_address(page);
/*
@@ -87,7 +87,7 @@ static pte_t *__alloc_for_ptecache(struct mm_struct *mm, int
kernel)
* count.
*/
if (likely(!pte_frag_get(>context))) {
- atomic_set(>pt_frag_refcount, PTE_FRAG_NR);
+ refcount_set(>pt_frag_refcount, PTE_FRAG_NR);
pte_frag_set(>context, ret + PTE_FRAG_SIZE);
}
spin_unlock(>page_table_lock);
@@ -110,8 +110,7 @@ void pte_fragment_free(unsigned long *table, int kernel)
{
struct page *page = virt_to_page(table);
- BUG_ON(atomic_read(>pt_frag_refcount) <= 0);
- if (atomic_dec_and_test(>pt_frag_refcount)) {
+ if (refcount_dec_and_test(>pt_frag_refcount)) {
if (!kernel)
pgtable_page_dtor(page);
__free_page(page);
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 3a37a89eb7a7..7fe23a3faf95 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
@@ -147,7 +148,7 @@ struct page {
unsigned long _pt_pad_2;/* mapping */
union {
struct mm_struct *pt_mm; /* x86 pgds only */
- atomic_t pt_frag_refcount; /* powerpc */
+ refcount_t pt_frag_refcount; /* powerpc */
};
#if ALLOC_SPLIT_PTLOCKS
spinlock_t *ptl;
--
2.20.1
Re: [PATCH v5 07/10] powerpc/fsl_booke/32: randomize the kernel image offset
On 2019/8/7 21:03, Michael Ellerman wrote:
Jason Yan writes:
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and boot. This not so much safe so additionally the bootloader may
pass entropy via the /chosen/kaslr-seed node in device tree.
We will use the first 512M of the low memory to randomize the kernel
image. The memory will be split in 64M zones. We will use the lower 8
bit of the entropy to decide the index of the 64M zone. Then we chose a
16K aligned offset inside the 64M zone to put the kernel in.
KERNELBASE
|--> 64M <--|
| |
+---+++---+
| |||kernel|| |
+---+++---+
| |
|-> offset<-|
kimage_vaddr
Can you drop this description / diagram and any other relevant design
details in eg. Documentation/powerpc/kaslr-booke32.rst please?
No problem.
See cpu_families.rst for an example of how to incorporate the ASCII
diagram.
>> diff --git a/arch/powerpc/kernel/kaslr_booke.c
b/arch/powerpc/kernel/kaslr_booke.c
index 30f84c0321b2..52b59b05f906 100644
--- a/arch/powerpc/kernel/kaslr_booke.c
+++ b/arch/powerpc/kernel/kaslr_booke.c
@@ -34,15 +36,329 @@
#include
#include
#include
+#include
#include
+#include
+#include
+
+#ifdef DEBUG
+#define DBG(fmt...) pr_info(fmt)
+#else
+#define DBG(fmt...)
+#endif
Just use pr_debug()?
Sounds better.
+struct regions {
+ unsigned long pa_start;
+ unsigned long pa_end;
+ unsigned long kernel_size;
+ unsigned long dtb_start;
+ unsigned long dtb_end;
+ unsigned long initrd_start;
+ unsigned long initrd_end;
+ unsigned long crash_start;
+ unsigned long crash_end;
+ int reserved_mem;
+ int reserved_mem_addr_cells;
+ int reserved_mem_size_cells;
+};
extern int is_second_reloc;
+/* Simplified build-specific string for starting entropy. */
+static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
+ LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
+
+static __init void kaslr_get_cmdline(void *fdt)
+{
+ int node = fdt_path_offset(fdt, "/chosen");
+
+ early_init_dt_scan_chosen(node, "chosen", 1, boot_command_line);
+}
+
+static unsigned long __init rotate_xor(unsigned long hash, const void *area,
+ size_t size)
+{
+ size_t i;
+ const unsigned long *ptr = area;
+
+ for (i = 0; i < size / sizeof(hash); i++) {
+ /* Rotate by odd number of bits and XOR. */
+ hash = (hash << ((sizeof(hash) * 8) - 7)) | (hash >> 7);
+ hash ^= ptr[i];
+ }
+
+ return hash;
+}
That looks suspiciously like the version Kees wrote in 2013 in
arch/x86/boot/compressed/kaslr.c ?
You should mention that in the change log at least.
Oh yes, I should have do that. Thanks for reminding me.
+
+/* Attempt to create a simple but unpredictable starting entropy. */
It's simple, but I would argue unpredictable is not really true. A local
attacker can probably fingerprint the kernel version, and also has
access to the unflattened device tree, which means they can make
educated guesses about the flattened tree size.
Be careful when copying comments :)
It's true that the comment is not so precise. It's an 'attempt' to
create unpredictable entropy. And apparently the 'attempt' was failed.
I will try to rewrite the comment to reflect the code more precisely.
+static unsigned long __init get_boot_seed(void *fdt)
+{
+ unsigned long hash = 0;
+
+ hash = rotate_xor(hash, build_str, sizeof(build_str));
+ hash = rotate_xor(hash, fdt, fdt_totalsize(fdt));
+
+ return hash;
+}
+
+static __init u64 get_kaslr_seed(void *fdt)
+{
+ int node, len;
+ fdt64_t *prop;
+ u64 ret;
+
+ node = fdt_path_offset(fdt, "/chosen");
+ if (node < 0)
+ return 0;
+
+ prop = fdt_getprop_w(fdt, node, "kaslr-seed", );
+ if (!prop || len != sizeof(u64))
+ return 0;
+
+ ret = fdt64_to_cpu(*prop);
+ *prop = 0;
+ return ret;
+}
+
+static __init bool regions_overlap(u32 s1, u32 e1, u32 s2, u32 e2)
+{
+ return e1 >= s2 && e2 >= s1;
+}
There's a generic helper called memory_intersects(), though it takes
void*. Might not be worth using, not sure.
I will have a try to see if this can save some codes or not.
...
static unsigned long __init kaslr_choose_location(void *dt_ptr, phys_addr_t
size,
unsigned long kernel_sz)
{
- /* return a fixed offset of 64M for now */
- return
Re: [PATCH v4 7/9] powerpc/eeh: Add bdfn field to eeh_dev
On Wed, 2019-08-07 at 13:44 +1000, Sam Bobroff wrote:
> From: Oliver O'Halloran
>
> Preparation for removing pci_dn from the powernv EEH code. The only
> thing we really use pci_dn for is to get the bdfn of the device for
> config space accesses, so adding that information to eeh_dev reduces
> the need to carry around the pci_dn.
>
> Signed-off-by: Oliver O'Halloran
> [SB: Re-wrapped commit message, fixed whitespace damage.]
> Signed-off-by: Sam Bobroff
> ---
> arch/powerpc/include/asm/eeh.h | 2 ++
> arch/powerpc/include/asm/ppc-pci.h | 2 ++
> arch/powerpc/kernel/eeh_dev.c | 2 ++
> 3 files changed, 6 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/eeh.h
> b/arch/powerpc/include/asm/eeh.h
> index 7f9404a0c3bb..bbe0798f6624 100644
> --- a/arch/powerpc/include/asm/eeh.h
> +++ b/arch/powerpc/include/asm/eeh.h
> @@ -121,6 +121,8 @@ static inline bool eeh_pe_passed(struct eeh_pe
> *pe)
> struct eeh_dev {
> int mode; /* EEH mode */
> int class_code; /* Class code of the device
> */
> + int bdfn; /* bdfn of device (for cfg ops) */
> + struct pci_controller *controller;
The other members of the structure get a comment, maybe it would be
more consistant if this one did too?
> int pe_config_addr; /* PE config address
> */
> u32 config_space[16]; /* Saved PCI config space
> */
> int pcix_cap; /* Saved PCIx capability
> */
> diff --git a/arch/powerpc/include/asm/ppc-pci.h
> b/arch/powerpc/include/asm/ppc-pci.h
> index cec2d6409515..72860de205a0 100644
> --- a/arch/powerpc/include/asm/ppc-pci.h
> +++ b/arch/powerpc/include/asm/ppc-pci.h
> @@ -74,6 +74,8 @@ static inline const char *eeh_driver_name(struct
> pci_dev *pdev)
>
> #endif /* CONFIG_EEH */
>
> +#define PCI_BUSNO(bdfn) ((bdfn >> 8) & 0xff)
> +
> #else /* CONFIG_PCI */
> static inline void init_pci_config_tokens(void) { }
> #endif /* !CONFIG_PCI */
> diff --git a/arch/powerpc/kernel/eeh_dev.c
> b/arch/powerpc/kernel/eeh_dev.c
> index c4317c452d98..7370185c7a05 100644
> --- a/arch/powerpc/kernel/eeh_dev.c
> +++ b/arch/powerpc/kernel/eeh_dev.c
> @@ -47,6 +47,8 @@ struct eeh_dev *eeh_dev_init(struct pci_dn *pdn)
> /* Associate EEH device with OF node */
> pdn->edev = edev;
> edev->pdn = pdn;
> + edev->bdfn = (pdn->busno << 8) | pdn->devfn;
> + edev->controller = pdn->phb;
>
> return edev;
> }
powerpc flush_inval_dcache_range() was buggy until v5.3-rc1 (was Re: [PATCH 4/4] powerpc/64: reuse PPC32 static inline flush_dcache_range())
[ deliberately broke threading so this doesn't get buried ]
Christophe Leroy writes:
> diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
> index a4fd536efb44..1b0a42c50ef1 100644
> --- a/arch/powerpc/kernel/misc_64.S
> +++ b/arch/powerpc/kernel/misc_64.S
> @@ -115,35 +115,6 @@ _ASM_NOKPROBE_SYMBOL(flush_icache_range)
> EXPORT_SYMBOL(flush_icache_range)
>
> /*
> - * Like above, but only do the D-cache.
> - *
> - * flush_dcache_range(unsigned long start, unsigned long stop)
> - *
> - *flush all bytes from start to stop-1 inclusive
> - */
> -
> -_GLOBAL_TOC(flush_dcache_range)
> - ld r10,PPC64_CACHES@toc(r2)
> - lwz r7,DCACHEL1BLOCKSIZE(r10) /* Get dcache block size */
> - addir5,r7,-1
> - andcr6,r3,r5/* round low to line bdy */
> - subfr8,r6,r4/* compute length */
> - add r8,r8,r5/* ensure we get enough */
> - lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of dcache block size */
> - srw.r8,r8,r9/* compute line count */
^
> - beqlr /* nothing to do? */
Alastair noticed that this was a 32-bit right shift.
Meaning if you called flush_dcache_range() with a range larger than 4GB,
it did nothing and returned.
That code (which was previously called flush_inval_dcache_range()) was
merged back in 2005:
https://github.com/mpe/linux-fullhistory/commit/faa5ee3743ff9b6df9f9a03600e34fdae596cfb2#diff-67c7ffa8e420c7d4206cae4a9e888e14
Back then it was only used by the smu.c driver, which presumably wasn't
flushing more than 4GB.
Over time it grew more users:
v4.17 (Apr 2018): fb5924fddf9e ("powerpc/mm: Flush cache on memory
hot(un)plug")
v4.15 (Nov 2017): 6c44741d75a2 ("powerpc/lib: Implement UACCESS_FLUSHCACHE
API")
v4.15 (Nov 2017): 32ce3862af3c ("powerpc/lib: Implement PMEM API")
v4.8 (Jul 2016): c40785ad305b ("powerpc/dart: Use a cachable DART")
The DART case doesn't matter, but the others probably could. I assume
the lack of bug reports is due to the fact that pmem stuff is still in
development and the lack of flushing usually doesn't actually matter? Or
are people flushing/hotplugging < 4G at a time?
Anyway we probably want to backport the fix below to various places?
cheers
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index 1ad4089dd110..802f5abbf061 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -148,7 +148,7 @@ _GLOBAL(flush_inval_dcache_range)
subfr8,r6,r4/* compute length */
add r8,r8,r5/* ensure we get enough */
lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of dcache block size */
- srw.r8,r8,r9/* compute line count */
+ srd.r8,r8,r9/* compute line count */
beqlr /* nothing to do? */
sync
isync
Re: [PATCH v5 06/10] powerpc/fsl_booke/32: implement KASLR infrastructure
On 2019/8/7 21:04, Michael Ellerman wrote: Jason Yan writes: This patch add support to boot kernel from places other than KERNELBASE. Since CONFIG_RELOCATABLE has already supported, what we need to do is map or copy kernel to a proper place and relocate. Freescale Book-E parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1 entries are not suitable to map the kernel directly in a randomized region, so we chose to copy the kernel to a proper place and restart to relocate. So to be 100% clear you are randomising the location of the kernel in virtual and physical space, by the same amount, and retaining the 1:1 linear mapping. 100% right :) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 77f6ebf97113..755378887912 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -548,6 +548,17 @@ config RELOCATABLE setting can still be useful to bootwrappers that need to know the load address of the kernel (eg. u-boot/mkimage). +config RANDOMIZE_BASE + bool "Randomize the address of the kernel image" + depends on (FSL_BOOKE && FLATMEM && PPC32) + select RELOCATABLE I think this should depend on RELOCATABLE, rather than selecting it. diff --git a/arch/powerpc/kernel/kaslr_booke.c b/arch/powerpc/kernel/kaslr_booke.c new file mode 100644 index ..30f84c0321b2 --- /dev/null +++ b/arch/powerpc/kernel/kaslr_booke.c @@ -0,0 +1,84 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2019 Jason Yan + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. You don't need that paragraph now that you have the SPDX tag. Rather than using a '//' comment followed by a single line block comment you can format it as: // SPDX-License-Identifier: GPL-2.0-only // // Copyright (C) 2019 Jason Yan > +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include Do you really need all those headers? I will remove useless headers. +extern int is_second_reloc; That should be in a header. Any reason why it isn't a bool? Oh yes, it should be in a header. This variable is already defined before and also used in assembly code. I think it was not defined as a bool just because there is no 'bool' in assembly code. cheers .
