Re: [RESEND PATCH v3 04/11] s390/cpacf: mark scpacf_query() as __always_inline
On 4/22/19 8:49 PM, Masahiro Yamada wrote:
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for s390, the following error is reported:
In file included from arch/s390/crypto/des_s390.c:19:
./arch/s390/include/asm/cpacf.h: In function 'cpacf_query':
./arch/s390/include/asm/cpacf.h:170:2: warning: asm operand 3 probably doesn't
match constraints
asm volatile(
^~~
./arch/s390/include/asm/cpacf.h:170:2: error: impossible constraint in 'asm'
This also seems to still be broken, again with gcc 9.1.1
BUILDSTDERR: In file included from arch/s390/crypto/prng.c:29:
BUILDSTDERR: ./arch/s390/include/asm/cpacf.h: In function 'cpacf_query_func':
BUILDSTDERR: ./arch/s390/include/asm/cpacf.h:170:2: warning: asm operand 3
probably doesn't match constraints
BUILDSTDERR: 170 | asm volatile(
BUILDSTDERR: | ^~~
BUILDSTDERR: ./arch/s390/include/asm/cpacf.h:170:2: error: impossible
constraint in 'asm'
I realized we're still carrying a patch to add -fno-section-anchors
but it's a similar failure to powerpc.
Thanks,
Laura
(config attached, full build log at
https://kojipkgs.fedoraproject.org//work/tasks/6330/34886330/build.log)
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2:
- split into a separate patch
arch/s390/include/asm/cpacf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/include/asm/cpacf.h b/arch/s390/include/asm/cpacf.h
index 3cc52e37b4b2..f316de40e51b 100644
--- a/arch/s390/include/asm/cpacf.h
+++ b/arch/s390/include/asm/cpacf.h
@@ -202,7 +202,7 @@ static inline int __cpacf_check_opcode(unsigned int opcode)
}
}
-static inline int cpacf_query(unsigned int opcode, cpacf_mask_t *mask)
+static __always_inline int cpacf_query(unsigned int opcode, cpacf_mask_t *mask)
{
if (__cpacf_check_opcode(opcode)) {
__cpacf_query(opcode, mask);
# s390
#
# Automatically generated file; DO NOT EDIT.
# Linux/s390 5.1.0 Kernel Configuration
#
#
# Compiler: gcc (GCC) 9.0.1 20190312 (Red Hat 9.0.1-0.10)
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=90001
CONFIG_CLANG_VERSION=0
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_HAVE_KERNEL_UNCOMPRESSED=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
# CONFIG_KERNEL_UNCOMPRESSED is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_PSI=y
# CONFIG_PSI_DEFAULT_DISABLED is not set
# CONFIG_CPU_ISOLATION is not set
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_BUILD_BIN2C=y
# CONFIG_IKCONFIG is not set
CONFIG_IKHEADERS_PROC=m
CONFIG_LOG_BUF_SHIFT=16
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING=y
# CONFIG_NUMA_BALANCING_DEFAULT_ENABLED is not set
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_MEMCG_KMEM=y
CONFIG_BLK_CGROUP=y
CONFIG_DEBUG_BLK_CGROUP=y
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_CGROUP_PIDS=y
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_BPF=y
# CONFIG_CGROUP_DEBUG is
Re: [PATCH 1/2] mm/cma: remove unsupported gfp_mask parameter from cma_alloc()
On 07/09/2018 05:19 AM, Marek Szyprowski wrote:
cma_alloc() function doesn't really support gfp flags other than
__GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.
This will help to avoid giving false feeling that this function supports
standard gfp flags and callers can pass __GFP_ZERO to get zeroed buffer,
what has already been an issue: see commit dd65a941f6ba ("arm64:
dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag").
For Ion,
Acked-by: Laura Abbott
Signed-off-by: Marek Szyprowski
---
arch/powerpc/kvm/book3s_hv_builtin.c | 2 +-
drivers/s390/char/vmcp.c | 2 +-
drivers/staging/android/ion/ion_cma_heap.c | 2 +-
include/linux/cma.h| 2 +-
kernel/dma/contiguous.c| 3 ++-
mm/cma.c | 8
mm/cma_debug.c | 2 +-
7 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index d4a3f4da409b..fc6bb9630a9c 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -77,7 +77,7 @@ struct page *kvm_alloc_hpt_cma(unsigned long nr_pages)
VM_BUG_ON(order_base_2(nr_pages) < KVM_CMA_CHUNK_ORDER - PAGE_SHIFT);
return cma_alloc(kvm_cma, nr_pages, order_base_2(HPT_ALIGN_PAGES),
-GFP_KERNEL);
+false);
}
EXPORT_SYMBOL_GPL(kvm_alloc_hpt_cma);
diff --git a/drivers/s390/char/vmcp.c b/drivers/s390/char/vmcp.c
index 948ce82a7725..0fa1b6b1491a 100644
--- a/drivers/s390/char/vmcp.c
+++ b/drivers/s390/char/vmcp.c
@@ -68,7 +68,7 @@ static void vmcp_response_alloc(struct vmcp_session *session)
* anymore the system won't work anyway.
*/
if (order > 2)
- page = cma_alloc(vmcp_cma, nr_pages, 0, GFP_KERNEL);
+ page = cma_alloc(vmcp_cma, nr_pages, 0, false);
if (page) {
session->response = (char *)page_to_phys(page);
session->cma_alloc = 1;
diff --git a/drivers/staging/android/ion/ion_cma_heap.c
b/drivers/staging/android/ion/ion_cma_heap.c
index 49718c96bf9e..3fafd013d80a 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -39,7 +39,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct
ion_buffer *buffer,
if (align > CONFIG_CMA_ALIGNMENT)
align = CONFIG_CMA_ALIGNMENT;
- pages = cma_alloc(cma_heap->cma, nr_pages, align, GFP_KERNEL);
+ pages = cma_alloc(cma_heap->cma, nr_pages, align, false);
if (!pages)
return -ENOMEM;
diff --git a/include/linux/cma.h b/include/linux/cma.h
index bf90f0bb42bd..190184b5ff32 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -33,7 +33,7 @@ extern int cma_init_reserved_mem(phys_addr_t base,
phys_addr_t size,
const char *name,
struct cma **res_cma);
extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int
align,
- gfp_t gfp_mask);
+ bool no_warn);
extern bool cma_release(struct cma *cma, const struct page *pages, unsigned
int count);
extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data);
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index d987dcd1bd56..19ea5d70150c 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -191,7 +191,8 @@ struct page *dma_alloc_from_contiguous(struct device *dev,
size_t count,
if (align > CONFIG_CMA_ALIGNMENT)
align = CONFIG_CMA_ALIGNMENT;
- return cma_alloc(dev_get_cma_area(dev), count, align, gfp_mask);
+ return cma_alloc(dev_get_cma_area(dev), count, align,
+gfp_mask & __GFP_NOWARN);
}
/**
diff --git a/mm/cma.c b/mm/cma.c
index 5809bbe360d7..4cb76121a3ab 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -395,13 +395,13 @@ static inline void cma_debug_show_areas(struct cma *cma)
{ }
* @cma: Contiguous memory region for which the allocation is performed.
* @count: Requested number of pages.
* @align: Requested alignment of pages (in PAGE_SIZE order).
- * @gfp_mask: GFP mask to use during compaction
+ * @no_warn: Avoid printing message about failed allocation
*
* This function allocates part of contiguous memory on specific
* contiguous memory area.
*/
struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
- gfp_t gfp_mask)
+ bool no_warn)
{
unsigned long mask, offset;
unsigned long pfn = -1;
@@ -447,7 +447,7 @@ struct page *cma_alloc(struct cma *cma, size_t count,
unsigned int align,
pfn = cma->base_pfn + (bitmap_no
[PATCHv6 4/4] arm64: Add build salt to the vDSO
The vDSO needs to have a unique build id in a similar manner to the kernel and modules. Use the build salt macro. Acked-by: Will Deacon Signed-off-by: Laura Abbott --- v6: Remove the semi-colon, Ack from Will --- arch/arm64/kernel/vdso/note.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/kernel/vdso/note.S b/arch/arm64/kernel/vdso/note.S index b82c85e5d972..e20483b104d9 100644 --- a/arch/arm64/kernel/vdso/note.S +++ b/arch/arm64/kernel/vdso/note.S @@ -22,7 +22,10 @@ #include #include #include +#include ELFNOTE_START(Linux, 0, "a") .long LINUX_VERSION_CODE ELFNOTE_END + +BUILD_SALT -- 2.17.1
[PATCHv6 3/4] powerpc: Add build salt to the vDSO
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Signed-off-by: Laura Abbott
---
v6: Remove semi-colon
---
arch/powerpc/kernel/vdso32/note.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/vdso32/note.S
b/arch/powerpc/kernel/vdso32/note.S
index d4b5be4f3d5f..227a7327399e 100644
--- a/arch/powerpc/kernel/vdso32/note.S
+++ b/arch/powerpc/kernel/vdso32/note.S
@@ -5,6 +5,7 @@
#include
#include
+#include
#define ASM_ELF_NOTE_BEGIN(name, flags, vendor, type)\
.section name, flags; \
@@ -23,3 +24,5 @@
ASM_ELF_NOTE_BEGIN(".note.kernel-version", "a", UTS_SYSNAME, 0)
.long LINUX_VERSION_CODE
ASM_ELF_NOTE_END
+
+BUILD_SALT
--
2.17.1
[PATCHv6 2/4] x86: Add build salt to the vDSO
The vDSO needs to have a unique build id in a similar manner to the kernel and modules. Use the build salt macro. Acked-by: Andy Lutomirski Signed-off-by: Laura Abbott --- v6: Ack from Andy --- arch/x86/entry/vdso/vdso-note.S | 3 +++ arch/x86/entry/vdso/vdso32/note.S | 3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/x86/entry/vdso/vdso-note.S b/arch/x86/entry/vdso/vdso-note.S index 79a071e4357e..79423170118f 100644 --- a/arch/x86/entry/vdso/vdso-note.S +++ b/arch/x86/entry/vdso/vdso-note.S @@ -3,6 +3,7 @@ * Here we can supply some information useful to userland. */ +#include #include #include #include @@ -10,3 +11,5 @@ ELFNOTE_START(Linux, 0, "a") .long LINUX_VERSION_CODE ELFNOTE_END + +BUILD_SALT diff --git a/arch/x86/entry/vdso/vdso32/note.S b/arch/x86/entry/vdso/vdso32/note.S index 9fd51f206314..e78047d119f6 100644 --- a/arch/x86/entry/vdso/vdso32/note.S +++ b/arch/x86/entry/vdso/vdso32/note.S @@ -4,6 +4,7 @@ * Here we can supply some information useful to userland. */ +#include #include #include @@ -14,6 +15,8 @@ ELFNOTE_START(Linux, 0, "a") .long LINUX_VERSION_CODE ELFNOTE_END +BUILD_SALT + #ifdef CONFIG_XEN /* * Add a special note telling glibc's dynamic linker a fake hardware -- 2.17.1
[PATCHv6 1/4] kbuild: Add build salt to the kernel and modules
In Fedora, the debug information is packaged separately (foo-debuginfo) and
can be installed separately. There's been a long standing issue where only
one version of a debuginfo info package can be installed at a time. There's
been an effort for Fedora for parallel debuginfo to rectify this problem.
Part of the requirement to allow parallel debuginfo to work is that build ids
are unique between builds. The existing upstream rpm implementation ensures
this by re-calculating the build-id using the version and release as a
seed. This doesn't work 100% for the kernel because of the vDSO which is
its own binary and doesn't get updated when embedded.
Fix this by adding some data in an ELF note for both the kernel and modules.
The data is controlled via a Kconfig option so distributions can set it
to an appropriate value to ensure uniqueness between builds.
Suggested-by: Masahiro Yamada
Signed-off-by: Laura Abbott
---
v6: Added more detail to the commit text about why exactly this feature
is useful. Default string now ""
---
include/linux/build-salt.h | 20
init/Kconfig | 9 +
init/version.c | 3 +++
scripts/mod/modpost.c | 3 +++
4 files changed, 35 insertions(+)
create mode 100644 include/linux/build-salt.h
diff --git a/include/linux/build-salt.h b/include/linux/build-salt.h
new file mode 100644
index ..bb007bd05e7a
--- /dev/null
+++ b/include/linux/build-salt.h
@@ -0,0 +1,20 @@
+#ifndef __BUILD_SALT_H
+#define __BUILD_SALT_H
+
+#include
+
+#define LINUX_ELFNOTE_BUILD_SALT 0x100
+
+#ifdef __ASSEMBLER__
+
+#define BUILD_SALT \
+ ELFNOTE(Linux, LINUX_ELFNOTE_BUILD_SALT, .asciz CONFIG_BUILD_SALT)
+
+#else
+
+#define BUILD_SALT \
+ ELFNOTE32("Linux", LINUX_ELFNOTE_BUILD_SALT, CONFIG_BUILD_SALT)
+
+#endif
+
+#endif /* __BUILD_SALT_H */
diff --git a/init/Kconfig b/init/Kconfig
index 041f3a022122..d39b31484c52 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -107,6 +107,15 @@ config LOCALVERSION_AUTO
which is done within the script "scripts/setlocalversion".)
+config BUILD_SALT
+ string "Build ID Salt"
+ default ""
+ help
+ The build ID is used to link binaries and their debug info. Setting
+ this option will use the value in the calculation of the build id.
+ This is mostly useful for distributions which want to ensure the
+ build is unique between builds. It's safe to leave the default.
+
config HAVE_KERNEL_GZIP
bool
diff --git a/init/version.c b/init/version.c
index bfb4e3f4955e..ef4012ec4375 100644
--- a/init/version.c
+++ b/init/version.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -49,3 +50,5 @@ const char linux_proc_banner[] =
"%s version %s"
" (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
" (" LINUX_COMPILER ") %s\n";
+
+BUILD_SALT;
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 1663fb19343a..dc6d714e4dcb 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -2125,10 +2125,13 @@ static int check_modname_len(struct module *mod)
**/
static void add_header(struct buffer *b, struct module *mod)
{
+ buf_printf(b, "#include \n");
buf_printf(b, "#include \n");
buf_printf(b, "#include \n");
buf_printf(b, "#include \n");
buf_printf(b, "\n");
+ buf_printf(b, "BUILD_SALT;\n");
+ buf_printf(b, "\n");
buf_printf(b, "MODULE_INFO(vermagic, VERMAGIC_STRING);\n");
buf_printf(b, "MODULE_INFO(name, KBUILD_MODNAME);\n");
buf_printf(b, "\n");
--
2.17.1
[PATCHv6 0/4] Salted build ids via ELF notes
Hi, This is v6 of the series to allow unique build ids. v6 is mostly minor fixups and Acks for this to go through the kbuild tree. Thanks, Laura Laura Abbott (4): kbuild: Add build salt to the kernel and modules x86: Add build salt to the vDSO powerpc: Add build salt to the vDSO arm64: Add build salt to the vDSO arch/arm64/kernel/vdso/note.S | 3 +++ arch/powerpc/kernel/vdso32/note.S | 3 +++ arch/x86/entry/vdso/vdso-note.S | 3 +++ arch/x86/entry/vdso/vdso32/note.S | 3 +++ include/linux/build-salt.h| 20 init/Kconfig | 9 + init/version.c| 3 +++ scripts/mod/modpost.c | 3 +++ 8 files changed, 47 insertions(+) create mode 100644 include/linux/build-salt.h -- 2.17.1
Re: [PATCHv5 1/4] kbuild: Add build salt to the kernel and modules
On 07/03/2018 08:59 PM, Masahiro Yamada wrote: Hi. Thanks for the update. 2018-07-04 8:34 GMT+09:00 Laura Abbott : The build id generated from --build-id can be generated in several different ways, with the default being the sha1 on the output of the linked file. For distributions, it can be useful to make sure this ID is unique, even if the actual file contents don't change. The easiest way to do this is to insert a section with some data. Add an ELF note to both the kernel and module which contains some data based off of a config option. Signed-off-by: Masahiro Yamada Signed-off-by: Laura Abbott --- v5: I used S-o-b here since the majority of the code was written already. I think Suggested-by is good enough. S-o-b is appended as a patch is passed from people to people. Anyway, this looks good except one bike-shed. Please feel free to change the tag if you think it's not appropriate. I also tweaked this to take an ascii string instead of just a hex value since this makes things much easier on the distribution side. --- diff --git a/init/Kconfig b/init/Kconfig index 041f3a022122..8de789f40db9 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -107,6 +107,15 @@ config LOCALVERSION_AUTO which is done within the script "scripts/setlocalversion".) +config BUILD_SALT + string "Build ID Salt" + default "Linux" How about empty string "" for default? Sure, seems to work fine. Thanks, Laura
Re: [PATCHv5 2/4] x86: Add build salt to the vDSO
On 07/05/2018 08:58 AM, Andy Lutomirski wrote: On Tue, Jul 3, 2018 at 4:34 PM, Laura Abbott wrote: The vDSO needs to have a unique build id in a similar manner to the kernel and modules. Use the build salt macro. Looks good to me. I have no idea whose tree these would go through. I was intending this to go through kbuild tree. Can I take this as an Ack? Signed-off-by: Laura Abbott --- v5: Switched to using the single line BUILD_SALT macro --- arch/x86/entry/vdso/vdso-note.S | 3 +++ arch/x86/entry/vdso/vdso32/note.S | 3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/x86/entry/vdso/vdso-note.S b/arch/x86/entry/vdso/vdso-note.S index 79a071e4357e..79423170118f 100644 --- a/arch/x86/entry/vdso/vdso-note.S +++ b/arch/x86/entry/vdso/vdso-note.S @@ -3,6 +3,7 @@ * Here we can supply some information useful to userland. */ +#include #include #include #include @@ -10,3 +11,5 @@ ELFNOTE_START(Linux, 0, "a") .long LINUX_VERSION_CODE ELFNOTE_END + +BUILD_SALT diff --git a/arch/x86/entry/vdso/vdso32/note.S b/arch/x86/entry/vdso/vdso32/note.S index 9fd51f206314..e78047d119f6 100644 --- a/arch/x86/entry/vdso/vdso32/note.S +++ b/arch/x86/entry/vdso/vdso32/note.S @@ -4,6 +4,7 @@ * Here we can supply some information useful to userland. */ +#include #include #include @@ -14,6 +15,8 @@ ELFNOTE_START(Linux, 0, "a") .long LINUX_VERSION_CODE ELFNOTE_END +BUILD_SALT + #ifdef CONFIG_XEN /* * Add a special note telling glibc's dynamic linker a fake hardware -- 2.17.1
Re: [PATCHv5 4/4] arm64: Add build salt to the vDSO
On 07/03/2018 08:55 PM, Masahiro Yamada wrote: Hi. 2018-07-04 8:34 GMT+09:00 Laura Abbott : The vDSO needs to have a unique build id in a similar manner to the kernel and modules. Use the build salt macro. Signed-off-by: Laura Abbott --- v5: I was previously focused on x86 only but since powerpc gave a patch, I figured I would do arm64 since the changes were also fairly simple. --- arch/arm64/kernel/vdso/note.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/kernel/vdso/note.S b/arch/arm64/kernel/vdso/note.S index b82c85e5d972..2c429dfd3f45 100644 --- a/arch/arm64/kernel/vdso/note.S +++ b/arch/arm64/kernel/vdso/note.S @@ -22,7 +22,10 @@ #include #include #include +#include ELFNOTE_START(Linux, 0, "a") .long LINUX_VERSION_CODE ELFNOTE_END + +BUILD_SALT; I think this works, but I prefer no-semicolon in assembly files. For coding consistency, I want ';' as statement delimiter in .c files. But, only new line after each statement in .S files. For example, in arch/x86/xen/xen-head.S I see no semicolon after ELFNOTE(). I found this: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473k/dom1359731141352.html It says ';' starts a comment line although it is not the case of GAS. Same for 3/4. Yes, that was a typo out of habit. Will fix.
[PATCHv5 4/4] arm64: Add build salt to the vDSO
The vDSO needs to have a unique build id in a similar manner to the kernel and modules. Use the build salt macro. Signed-off-by: Laura Abbott --- v5: I was previously focused on x86 only but since powerpc gave a patch, I figured I would do arm64 since the changes were also fairly simple. --- arch/arm64/kernel/vdso/note.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/kernel/vdso/note.S b/arch/arm64/kernel/vdso/note.S index b82c85e5d972..2c429dfd3f45 100644 --- a/arch/arm64/kernel/vdso/note.S +++ b/arch/arm64/kernel/vdso/note.S @@ -22,7 +22,10 @@ #include #include #include +#include ELFNOTE_START(Linux, 0, "a") .long LINUX_VERSION_CODE ELFNOTE_END + +BUILD_SALT; -- 2.17.1
[PATCHv5 3/4] powerpc: Add build salt to the vDSO
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Signed-off-by: Laura Abbott
---
v5: New approach with the BUILD_SALT macro
---
arch/powerpc/kernel/vdso32/note.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/vdso32/note.S
b/arch/powerpc/kernel/vdso32/note.S
index d4b5be4f3d5f..ec1d05265c75 100644
--- a/arch/powerpc/kernel/vdso32/note.S
+++ b/arch/powerpc/kernel/vdso32/note.S
@@ -5,6 +5,7 @@
#include
#include
+#include
#define ASM_ELF_NOTE_BEGIN(name, flags, vendor, type)\
.section name, flags; \
@@ -23,3 +24,5 @@
ASM_ELF_NOTE_BEGIN(".note.kernel-version", "a", UTS_SYSNAME, 0)
.long LINUX_VERSION_CODE
ASM_ELF_NOTE_END
+
+BUILD_SALT;
--
2.17.1
[PATCHv5 2/4] x86: Add build salt to the vDSO
The vDSO needs to have a unique build id in a similar manner to the kernel and modules. Use the build salt macro. Signed-off-by: Laura Abbott --- v5: Switched to using the single line BUILD_SALT macro --- arch/x86/entry/vdso/vdso-note.S | 3 +++ arch/x86/entry/vdso/vdso32/note.S | 3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/x86/entry/vdso/vdso-note.S b/arch/x86/entry/vdso/vdso-note.S index 79a071e4357e..79423170118f 100644 --- a/arch/x86/entry/vdso/vdso-note.S +++ b/arch/x86/entry/vdso/vdso-note.S @@ -3,6 +3,7 @@ * Here we can supply some information useful to userland. */ +#include #include #include #include @@ -10,3 +11,5 @@ ELFNOTE_START(Linux, 0, "a") .long LINUX_VERSION_CODE ELFNOTE_END + +BUILD_SALT diff --git a/arch/x86/entry/vdso/vdso32/note.S b/arch/x86/entry/vdso/vdso32/note.S index 9fd51f206314..e78047d119f6 100644 --- a/arch/x86/entry/vdso/vdso32/note.S +++ b/arch/x86/entry/vdso/vdso32/note.S @@ -4,6 +4,7 @@ * Here we can supply some information useful to userland. */ +#include #include #include @@ -14,6 +15,8 @@ ELFNOTE_START(Linux, 0, "a") .long LINUX_VERSION_CODE ELFNOTE_END +BUILD_SALT + #ifdef CONFIG_XEN /* * Add a special note telling glibc's dynamic linker a fake hardware -- 2.17.1
[PATCHv5 1/4] kbuild: Add build salt to the kernel and modules
The build id generated from --build-id can be generated in several different
ways, with the default being the sha1 on the output of the linked file. For
distributions, it can be useful to make sure this ID is unique, even if the
actual file contents don't change. The easiest way to do this is to insert
a section with some data.
Add an ELF note to both the kernel and module which contains some data based
off of a config option.
Signed-off-by: Masahiro Yamada
Signed-off-by: Laura Abbott
---
v5: I used S-o-b here since the majority of the code was written
already. Please feel free to change the tag if you think it's not
appropriate. I also tweaked this to take an ascii string instead of just
a hex value since this makes things much easier on the distribution
side.
---
include/linux/build-salt.h | 20
init/Kconfig | 9 +
init/version.c | 3 +++
scripts/mod/modpost.c | 3 +++
4 files changed, 35 insertions(+)
create mode 100644 include/linux/build-salt.h
diff --git a/include/linux/build-salt.h b/include/linux/build-salt.h
new file mode 100644
index ..bb007bd05e7a
--- /dev/null
+++ b/include/linux/build-salt.h
@@ -0,0 +1,20 @@
+#ifndef __BUILD_SALT_H
+#define __BUILD_SALT_H
+
+#include
+
+#define LINUX_ELFNOTE_BUILD_SALT 0x100
+
+#ifdef __ASSEMBLER__
+
+#define BUILD_SALT \
+ ELFNOTE(Linux, LINUX_ELFNOTE_BUILD_SALT, .asciz CONFIG_BUILD_SALT)
+
+#else
+
+#define BUILD_SALT \
+ ELFNOTE32("Linux", LINUX_ELFNOTE_BUILD_SALT, CONFIG_BUILD_SALT)
+
+#endif
+
+#endif /* __BUILD_SALT_H */
diff --git a/init/Kconfig b/init/Kconfig
index 041f3a022122..8de789f40db9 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -107,6 +107,15 @@ config LOCALVERSION_AUTO
which is done within the script "scripts/setlocalversion".)
+config BUILD_SALT
+ string "Build ID Salt"
+ default "Linux"
+ help
+ The build ID is used to link binaries and their debug info. Setting
+ this option will use the value in the calculation of the build id.
+ This is mostly useful for distributions which want to ensure the
+ build is unique between builds. It's safe to leave the default.
+
config HAVE_KERNEL_GZIP
bool
diff --git a/init/version.c b/init/version.c
index bfb4e3f4955e..ef4012ec4375 100644
--- a/init/version.c
+++ b/init/version.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -49,3 +50,5 @@ const char linux_proc_banner[] =
"%s version %s"
" (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
" (" LINUX_COMPILER ") %s\n";
+
+BUILD_SALT;
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 1663fb19343a..dc6d714e4dcb 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -2125,10 +2125,13 @@ static int check_modname_len(struct module *mod)
**/
static void add_header(struct buffer *b, struct module *mod)
{
+ buf_printf(b, "#include \n");
buf_printf(b, "#include \n");
buf_printf(b, "#include \n");
buf_printf(b, "#include \n");
buf_printf(b, "\n");
+ buf_printf(b, "BUILD_SALT;\n");
+ buf_printf(b, "\n");
buf_printf(b, "MODULE_INFO(vermagic, VERMAGIC_STRING);\n");
buf_printf(b, "MODULE_INFO(name, KBUILD_MODNAME);\n");
buf_printf(b, "\n");
--
2.17.1
[PATCHv5 0/4] Salted build ids via ELF notes
Hi, This is v5 of the series to allow unique build ids in the kernel. As a reminder of the context: "" In Fedora, the debug information is packaged separately (foo-debuginfo) and can be installed separately. There's been a long standing issue where only one version of a debuginfo info package can be installed at a time. Mark Wielaard made an effort for Fedora 27 to allow parallel installation of debuginfo (see https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo for more details) Part of the requirement to allow this to work is that build ids are unique between builds. The existing upstream rpm implementation ensures this by re-calculating the build-id using the version and release as a seed. This doesn't work 100% for the kernel because of the vDSO which is its own binary and doesn't get updated. After poking holes in a few of my ideas, there was a discussion with some people from the binutils team about adding --build-id-salt to let ld do the calculation debugedit is doing. There was a counter proposal made to add in the salt while building. The easiest proposal was to add an item in the linker script vs. linking in an object since we need the salt to go in every module as well as the kernel and vmlinux. "" v5 uses the approach suggested by Masahiro Yamada which uses the existing ELF note macro to more easily add the salt (vs previous approaches which tried to adjust via linker section). If arch maintainers are okay, I'd like acks for this so this can go through the kbuild tree. Thanks, Laura Laura Abbott (4): kbuild: Add build salt to the kernel and modules x86: Add build salt to the vDSO powerpc: Add build salt to the vDSO arm64: Add build salt to the vDSO arch/arm64/kernel/vdso/note.S | 3 +++ arch/powerpc/kernel/vdso32/note.S | 3 +++ arch/x86/entry/vdso/vdso-note.S | 3 +++ arch/x86/entry/vdso/vdso32/note.S | 3 +++ include/linux/build-salt.h| 20 init/Kconfig | 9 + init/version.c| 3 +++ scripts/mod/modpost.c | 3 +++ 8 files changed, 47 insertions(+) create mode 100644 include/linux/build-salt.h -- 2.17.1
[PATCHv5 0/4] Salted build ids via ELF notes
Hi, This is v5 of the series to allow unique build ids in the kernel. As a reminder of the context: "" In Fedora, the debug information is packaged separately (foo-debuginfo) and can be installed separately. There's been a long standing issue where only one version of a debuginfo info package can be installed at a time. Mark Wielaard made an effort for Fedora 27 to allow parallel installation of debuginfo (see https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo for more details) Part of the requirement to allow this to work is that build ids are unique between builds. The existing upstream rpm implementation ensures this by re-calculating the build-id using the version and release as a seed. This doesn't work 100% for the kernel because of the vDSO which is its own binary and doesn't get updated. After poking holes in a few of my ideas, there was a discussion with some people from the binutils team about adding --build-id-salt to let ld do the calculation debugedit is doing. There was a counter proposal made to add in the salt while building. The easiest proposal was to add an item in the linker script vs. linking in an object since we need the salt to go in every module as well as the kernel and vmlinux. "" v5 uses the approach suggested by Masahiro Yamada which uses the existing ELF note macro to more easily add the salt (vs previous approaches which tried to adjust via linker section). If arch maintainers are okay, I'd like acks for this so this can go through the kbuild tree. Thanks, Laura Laura Abbott (4): kbuild: Add build salt to the kernel and modules x86: Add build salt to the vDSO powerpc: Add build salt to the vDSO arm64: Add build salt to the vDSO arch/arm64/kernel/vdso/note.S | 3 +++ arch/powerpc/kernel/vdso32/note.S | 3 +++ arch/x86/entry/vdso/vdso-note.S | 3 +++ arch/x86/entry/vdso/vdso32/note.S | 3 +++ include/linux/build-salt.h| 20 init/Kconfig | 9 + init/version.c| 3 +++ scripts/mod/modpost.c | 3 +++ 8 files changed, 47 insertions(+) create mode 100644 include/linux/build-salt.h -- 2.17.1
Re: kernel BUG at mm/usercopy.c:72!
On 05/16/2017 07:32 AM, Kees Cook wrote:
> On Tue, May 16, 2017 at 4:09 AM, Michael Ellerman wrote:
>> [Cc'ing the relevant folks]
>>
>> Breno Leitao writes:
>>> Hello,
>>>
>>> Kernel 4.12-rc1 is showing a bug when I try it on a POWER8 virtual
>>> machine. Justing SSHing into the machine causes this issue.
>>>
>>> [23.138124] usercopy: kernel memory overwrite attempt detected to
>>> d3d80030 (mm_struct) (560 bytes)
>>> [23.138195] [ cut here ]
>>> [23.138229] kernel BUG at mm/usercopy.c:72!
>>> [23.138252] Oops: Exception in kernel mode, sig: 5 [#3]
>>> [23.138280] SMP NR_CPUS=2048
>>> [23.138280] NUMA
>>> [23.138302] pSeries
>>> [23.138330] Modules linked in:
>>> [23.138354] CPU: 4 PID: 2215 Comm: sshd Tainted: G D
>>> 4.12.0-rc1+ #9
>>> [23.138395] task: c001e272dc00 task.stack: c001e27b
>>> [23.138430] NIP: c0342358 LR: c0342354 CTR:
>>> c06eb060
>>> [23.138472] REGS: c001e27b3a00 TRAP: 0700 Tainted: G D
>>> (4.12.0-rc1+)
>>> [23.138513] MSR: 80029033
>>> [23.138517] CR: 28004222 XER: 2000
>>> [23.138565] CFAR: c0b34500 SOFTE: 1
>>> [23.138565] GPR00: c0342354 c001e27b3c80 c142a000
>>> 005e
>>> [23.138565] GPR04: c001ffe0ade8 c001ffe21bf8 2920283536302062
>>> 79746573290d0a74
>>> [23.138565] GPR08: 0007 c0f61864 0001feeb
>>> 3064206f74206465
>>> [23.138565] GPR12: 4400 cfb42600 0015
>>> 545bdc40
>>> [23.138565] GPR16: 545c49c8 01000b4b8890 778c26f0
>>> 545cf000
>>> [23.138565] GPR20: 546109c8 c7e8 54610010
>>> 778c22e8
>>> [23.138565] GPR24: 545c8c40 c000ff6bcef0 c01e5220
>>> 0230
>>> [23.138565] GPR28: d3d80260 0230
>>> d3d80030
>>> [23.138920] NIP [c0342358] __check_object_size+0x88/0x2d0
>>> [23.138956] LR [c0342354] __check_object_size+0x84/0x2d0
>>> [23.138990] Call Trace:
>>> [23.139006] [c001e27b3c80] [c0342354]
>>> __check_object_size+0x84/0x2d0 (unreliable)
>>> [23.139056] [c001e27b3d00] [c09f5ba8]
>>> bpf_prog_create_from_user+0xa8/0x1a0
>>> [23.139099] [c001e27b3d60] [c01e5d30]
>>> do_seccomp+0x120/0x720
>>> [23.139136] [c001e27b3dd0] [c00fd53c]
>>> SyS_prctl+0x2ac/0x6b0
>>> [23.139172] [c001e27b3e30] [c000af84]
>>> system_call+0x38/0xe0
>>> [23.139218] Instruction dump:
>>> [23.139240] 6000 6042 3c82ff94 3ca2ff9d 38841788 38a5e868
>>> 3c62ff95 7fc8f378
>>> [23.139283] 7fe6fb78 386310c0 487f2169 6000 <0fe0> 6042
>>> 2ba30010 409d018c
>>> [23.139328] ---[ end trace 1a1dc952a4b7c4af ]---
>>>
>>> I found that kernel 4.11 does not have this issue. I also found that, if
>>> I revert 517e1fbeb65f5eade8d14f46ac365db6c75aea9b, I do not see the
>>> problem.
>>>
>>> On the other side, if I cherry-pick commit
>>> 517e1fbeb65f5eade8d14f46ac365db6c75aea9b into 4.11, I start seeing the
>>> same issue also on 4.11.
>>
>> Yeah it looks like powerpc also suffers from the same bug that arm64
>> used to, ie. virt_addr_valid() will return true for some vmalloc
>> addresses.
>>
>> virt_addr_valid() is used pretty widely, I'm not sure if we can just fix
>> it without other fallout. I'll dig a bit more tomorrow if no one beats
>> me to it.
>>
>> Kees, depending on how that turns out we may ask you to revert
>> 517e1fbeb65f ("mm/usercopy: Drop extra is_vmalloc_or_module() check").
>
> That's fine by me. Let me know what you think would be best.
>
> Laura, I don't see much harm in putting this back in place. It seems
> like it's just a matter of efficiency to have it removed?
>
> -Kees
>
Yes, there shouldn't be any harm if we need to bring it back.
Perhaps I should submit a follow on patch to rename virt_addr_valid to
virt_addr_valid_except_where_it_isnt.
Thanks,
Laura
Re: [PATCH v4 12/12] mm: SLUB hardened usercopy support
On 07/25/2016 01:45 PM, Kees Cook wrote:
On Mon, Jul 25, 2016 at 12:16 PM, Laura Abbott wrote:
On 07/20/2016 01:27 PM, Kees Cook wrote:
Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the
SLUB allocator to catch any copies that may span objects. Includes a
redzone handling fix discovered by Michael Ellerman.
Based on code from PaX and grsecurity.
Signed-off-by: Kees Cook
Tested-by: Michael Ellerman
---
init/Kconfig | 1 +
mm/slub.c| 36
2 files changed, 37 insertions(+)
diff --git a/init/Kconfig b/init/Kconfig
index 798c2020ee7c..1c4711819dfd 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1765,6 +1765,7 @@ config SLAB
config SLUB
bool "SLUB (Unqueued Allocator)"
+ select HAVE_HARDENED_USERCOPY_ALLOCATOR
help
SLUB is a slab allocator that minimizes cache line usage
instead of managing queues of cached objects (SLAB approach).
diff --git a/mm/slub.c b/mm/slub.c
index 825ff4505336..7dee3d9a5843 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3614,6 +3614,42 @@ void *__kmalloc_node(size_t size, gfp_t flags, int
node)
EXPORT_SYMBOL(__kmalloc_node);
#endif
+#ifdef CONFIG_HARDENED_USERCOPY
+/*
+ * Rejects objects that are incorrectly sized.
+ *
+ * Returns NULL if check passes, otherwise const char * to name of cache
+ * to indicate an error.
+ */
+const char *__check_heap_object(const void *ptr, unsigned long n,
+ struct page *page)
+{
+ struct kmem_cache *s;
+ unsigned long offset;
+ size_t object_size;
+
+ /* Find object and usable object size. */
+ s = page->slab_cache;
+ object_size = slab_ksize(s);
+
+ /* Find offset within object. */
+ offset = (ptr - page_address(page)) % s->size;
+
+ /* Adjust for redzone and reject if within the redzone. */
+ if (kmem_cache_debug(s) && s->flags & SLAB_RED_ZONE) {
+ if (offset < s->red_left_pad)
+ return s->name;
+ offset -= s->red_left_pad;
+ }
+
+ /* Allow address range falling entirely within object size. */
+ if (offset <= object_size && n <= object_size - offset)
+ return NULL;
+
+ return s->name;
+}
+#endif /* CONFIG_HARDENED_USERCOPY */
+
I compared this against what check_valid_pointer does for SLUB_DEBUG
checking. I was hoping we could utilize that function to avoid
duplication but a) __check_heap_object needs to allow accesses anywhere
in the object, not just the beginning b) accessing page->objects
is racy without the addition of locking in SLUB_DEBUG.
Still, the ptr < page_address(page) check from __check_heap_object would
be good to add to avoid generating garbage large offsets and trying to
infer C math.
diff --git a/mm/slub.c b/mm/slub.c
index 7dee3d9..5370e4f 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3632,6 +3632,9 @@ const char *__check_heap_object(const void *ptr,
unsigned long n,
s = page->slab_cache;
object_size = slab_ksize(s);
+ if (ptr < page_address(page))
+ return s->name;
+
/* Find offset within object. */
offset = (ptr - page_address(page)) % s->size;
With that, you can add
Reviwed-by: Laura Abbott
Cool, I'll add that.
Should I add your reviewed-by for this patch only or for the whole series?
Thanks!
-Kees
Just this patch for now, I'm working through a couple of others
static size_t __ksize(const void *object)
{
struct page *page;
Thanks,
Laura
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 12/12] mm: SLUB hardened usercopy support
On 07/25/2016 02:42 PM, Rik van Riel wrote:
On Mon, 2016-07-25 at 12:16 -0700, Laura Abbott wrote:
On 07/20/2016 01:27 PM, Kees Cook wrote:
Under CONFIG_HARDENED_USERCOPY, this adds object size checking to
the
SLUB allocator to catch any copies that may span objects. Includes
a
redzone handling fix discovered by Michael Ellerman.
Based on code from PaX and grsecurity.
Signed-off-by: Kees Cook
Tested-by: Michael Ellerman
---
init/Kconfig | 1 +
mm/slub.c| 36
2 files changed, 37 insertions(+)
diff --git a/init/Kconfig b/init/Kconfig
index 798c2020ee7c..1c4711819dfd 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1765,6 +1765,7 @@ config SLAB
config SLUB
bool "SLUB (Unqueued Allocator)"
+ select HAVE_HARDENED_USERCOPY_ALLOCATOR
help
SLUB is a slab allocator that minimizes cache line
usage
instead of managing queues of cached objects (SLAB
approach).
diff --git a/mm/slub.c b/mm/slub.c
index 825ff4505336..7dee3d9a5843 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3614,6 +3614,42 @@ void *__kmalloc_node(size_t size, gfp_t
flags, int node)
EXPORT_SYMBOL(__kmalloc_node);
#endif
+#ifdef CONFIG_HARDENED_USERCOPY
+/*
+ * Rejects objects that are incorrectly sized.
+ *
+ * Returns NULL if check passes, otherwise const char * to name of
cache
+ * to indicate an error.
+ */
+const char *__check_heap_object(const void *ptr, unsigned long n,
+ struct page *page)
+{
+ struct kmem_cache *s;
+ unsigned long offset;
+ size_t object_size;
+
+ /* Find object and usable object size. */
+ s = page->slab_cache;
+ object_size = slab_ksize(s);
+
+ /* Find offset within object. */
+ offset = (ptr - page_address(page)) % s->size;
+
+ /* Adjust for redzone and reject if within the redzone. */
+ if (kmem_cache_debug(s) && s->flags & SLAB_RED_ZONE) {
+ if (offset < s->red_left_pad)
+ return s->name;
+ offset -= s->red_left_pad;
+ }
+
+ /* Allow address range falling entirely within object
size. */
+ if (offset <= object_size && n <= object_size - offset)
+ return NULL;
+
+ return s->name;
+}
+#endif /* CONFIG_HARDENED_USERCOPY */
+
I compared this against what check_valid_pointer does for SLUB_DEBUG
checking. I was hoping we could utilize that function to avoid
duplication but a) __check_heap_object needs to allow accesses
anywhere
in the object, not just the beginning b) accessing page->objects
is racy without the addition of locking in SLUB_DEBUG.
Still, the ptr < page_address(page) check from __check_heap_object
would
be good to add to avoid generating garbage large offsets and trying
to
infer C math.
diff --git a/mm/slub.c b/mm/slub.c
index 7dee3d9..5370e4f 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3632,6 +3632,9 @@ const char *__check_heap_object(const void
*ptr, unsigned long n,
s = page->slab_cache;
object_size = slab_ksize(s);
+ if (ptr < page_address(page))
+ return s->name;
+
/* Find offset within object. */
offset = (ptr - page_address(page)) % s->size;
I don't get it, isn't that already guaranteed because we
look for the page that ptr is in, before __check_heap_object
is called?
Specifically, in patch 3/12:
+ page = virt_to_head_page(ptr);
+
+ /* Check slab allocator for flags and size. */
+ if (PageSlab(page))
+ return __check_heap_object(ptr, n, page);
How can that generate a ptr that is not inside the page?
What am I overlooking? And, should it be in the changelog or
a comment? :)
I ran into the subtraction issue when the vmalloc detection wasn't
working on ARM64, somehow virt_to_head_page turned into a page
that happened to have PageSlab set. I agree if everything is working
properly this is redundant but given the type of feature this is, a
little bit of redundancy against a system running off into the weeds
or bad patches might be warranted.
I'm not super attached to the check if other maintainers think it
is redundant. Updating the __check_heap_object header comment
with a note of what we are assuming could work
Thanks,
Laura
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 12/12] mm: SLUB hardened usercopy support
On 07/20/2016 01:27 PM, Kees Cook wrote:
Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the
SLUB allocator to catch any copies that may span objects. Includes a
redzone handling fix discovered by Michael Ellerman.
Based on code from PaX and grsecurity.
Signed-off-by: Kees Cook
Tested-by: Michael Ellerman
---
init/Kconfig | 1 +
mm/slub.c| 36
2 files changed, 37 insertions(+)
diff --git a/init/Kconfig b/init/Kconfig
index 798c2020ee7c..1c4711819dfd 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1765,6 +1765,7 @@ config SLAB
config SLUB
bool "SLUB (Unqueued Allocator)"
+ select HAVE_HARDENED_USERCOPY_ALLOCATOR
help
SLUB is a slab allocator that minimizes cache line usage
instead of managing queues of cached objects (SLAB approach).
diff --git a/mm/slub.c b/mm/slub.c
index 825ff4505336..7dee3d9a5843 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3614,6 +3614,42 @@ void *__kmalloc_node(size_t size, gfp_t flags, int node)
EXPORT_SYMBOL(__kmalloc_node);
#endif
+#ifdef CONFIG_HARDENED_USERCOPY
+/*
+ * Rejects objects that are incorrectly sized.
+ *
+ * Returns NULL if check passes, otherwise const char * to name of cache
+ * to indicate an error.
+ */
+const char *__check_heap_object(const void *ptr, unsigned long n,
+ struct page *page)
+{
+ struct kmem_cache *s;
+ unsigned long offset;
+ size_t object_size;
+
+ /* Find object and usable object size. */
+ s = page->slab_cache;
+ object_size = slab_ksize(s);
+
+ /* Find offset within object. */
+ offset = (ptr - page_address(page)) % s->size;
+
+ /* Adjust for redzone and reject if within the redzone. */
+ if (kmem_cache_debug(s) && s->flags & SLAB_RED_ZONE) {
+ if (offset < s->red_left_pad)
+ return s->name;
+ offset -= s->red_left_pad;
+ }
+
+ /* Allow address range falling entirely within object size. */
+ if (offset <= object_size && n <= object_size - offset)
+ return NULL;
+
+ return s->name;
+}
+#endif /* CONFIG_HARDENED_USERCOPY */
+
I compared this against what check_valid_pointer does for SLUB_DEBUG
checking. I was hoping we could utilize that function to avoid
duplication but a) __check_heap_object needs to allow accesses anywhere
in the object, not just the beginning b) accessing page->objects
is racy without the addition of locking in SLUB_DEBUG.
Still, the ptr < page_address(page) check from __check_heap_object would
be good to add to avoid generating garbage large offsets and trying to
infer C math.
diff --git a/mm/slub.c b/mm/slub.c
index 7dee3d9..5370e4f 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3632,6 +3632,9 @@ const char *__check_heap_object(const void *ptr, unsigned
long n,
s = page->slab_cache;
object_size = slab_ksize(s);
+ if (ptr < page_address(page))
+ return s->name;
+
/* Find offset within object. */
offset = (ptr - page_address(page)) % s->size;
With that, you can add
Reviwed-by: Laura Abbott
static size_t __ksize(const void *object)
{
struct page *page;
Thanks,
Laura
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 00/12] mm: Hardened usercopy
On 07/20/2016 01:26 PM, Kees Cook wrote: Hi, [This is now in my kspp -next tree, though I'd really love to add some additional explicit Tested-bys, Reviewed-bys, or Acked-bys. If you've looked through any part of this or have done any testing, please consider sending an email with your "*-by:" line. :)] This is a start of the mainline port of PAX_USERCOPY[1]. After writing tests (now in lkdtm in -next) for Casey's earlier port[2], I kept tweaking things further and further until I ended up with a whole new patch series. To that end, I took Rik, Laura, and other people's feedback along with additional changes and clean-ups. Based on my understanding, PAX_USERCOPY was designed to catch a few classes of flaws (mainly bad bounds checking) around the use of copy_to_user()/copy_from_user(). These changes don't touch get_user() and put_user(), since these operate on constant sized lengths, and tend to be much less vulnerable. There are effectively three distinct protections in the whole series, each of which I've given a separate CONFIG, though this patch set is only the first of the three intended protections. (Generally speaking, PAX_USERCOPY covers what I'm calling CONFIG_HARDENED_USERCOPY (this) and CONFIG_HARDENED_USERCOPY_WHITELIST (future), and PAX_USERCOPY_SLABS covers CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC (future).) This series, which adds CONFIG_HARDENED_USERCOPY, checks that objects being copied to/from userspace meet certain criteria: - if address is a heap object, the size must not exceed the object's allocated size. (This will catch all kinds of heap overflow flaws.) - if address range is in the current process stack, it must be within the a valid stack frame (if such checking is possible) or at least entirely within the current process's stack. (This could catch large lengths that would have extended beyond the current process stack, or overflows if their length extends back into the original stack.) - if the address range is part of kernel data, rodata, or bss, allow it. - if address range is page-allocated, that it doesn't span multiple allocations (excepting Reserved and CMA pages). - if address is within the kernel text, reject it. - everything else is accepted The patches in the series are: - Support for examination of CMA page types: 1- mm: Add is_migrate_cma_page - Support for arch-specific stack frame checking (which will likely be replaced in the future by Josh's more comprehensive unwinder): 2- mm: Implement stack frame object validation - The core copy_to/from_user() checks, without the slab object checks: 3- mm: Hardened usercopy - Per-arch enablement of the protection: 4- x86/uaccess: Enable hardened usercopy 5- ARM: uaccess: Enable hardened usercopy 6- arm64/uaccess: Enable hardened usercopy 7- ia64/uaccess: Enable hardened usercopy 8- powerpc/uaccess: Enable hardened usercopy 9- sparc/uaccess: Enable hardened usercopy 10- s390/uaccess: Enable hardened usercopy - The heap allocator implementation of object size checking: 11- mm: SLAB hardened usercopy support 12- mm: SLUB hardened usercopy support Some notes: - This is expected to apply on top of -next which contains fixes for the position of _etext on both arm and arm64, though it has some conflicts with KASAN that should be trivial to fix up. Also in -next are the tests for this protection (in lkdtm), prefixed with USERCOPY_. - I couldn't detect a measurable performance change with these features enabled. Kernel build times were unchanged, hackbench was unchanged, etc. I think we could flip this to "on by default" at some point, but for now, I'm leaving it off until I can get some more definitive measurements. I would love if someone with greater familiarity with perf could give this a spin and report results. - The SLOB support extracted from grsecurity seems entirely broken. I have no idea what's going on there, I spent my time testing SLAB and SLUB. Having someone else look at SLOB would be nice, but this series doesn't depend on it. Additional features that would be nice, but aren't blocking this series: - Needs more architecture support for stack frame checking (only x86 now, but it seems Josh will have a good solution for this soon). Thanks! -Kees [1] https://grsecurity.net/download.php "grsecurity - test kernel patch" [2] http://www.openwall.com/lists/kernel-hardening/2016/05/19/5 v4: - handle CMA pages, labbott - update stack checker comments, labbott - check for vmalloc addresses, labbott - deal with KASAN in -next changing arm64 copy*user calls - check for linear mappings at runtime instead of via CONFIG v3: - switch to using BUG for better Oops integration - when checking page allocations, check each for Reserved - use enums for the stack check return for readability v2: - added s390 support - handle slub red zone - disallow writes to rodata area - stack frame walker now C
Re: [PATCH v3 02/11] mm: Hardened usercopy
On 07/20/2016 03:24 AM, Balbir Singh wrote:
On Tue, 2016-07-19 at 11:48 -0700, Kees Cook wrote:
On Mon, Jul 18, 2016 at 6:06 PM, Laura Abbott wrote:
On 07/15/2016 02:44 PM, Kees Cook wrote:
This doesn't work when copying CMA allocated memory since CMA purposely
allocates larger than a page block size without setting head pages.
Given CMA may be used with drivers doing zero copy buffers, I think it
should be permitted.
Something like the following lets it pass (I can clean up and submit
the is_migrate_cma_page APIs as a separate patch for review)
Yeah, this would be great. I'd rather use an accessor to check this
than a direct check for MIGRATE_CMA.
*/
for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr))
{
- if (!PageReserved(page))
+ if (!PageReserved(page) && !is_migrate_cma_page(page))
return "";
}
Yeah, I'll modify this a bit so that which type it starts as is
maintained for all pages (rather than allowing to flip back and forth
-- even though that is likely impossible).
Sorry, I completely missed the MIGRATE_CMA bits. Could you clarify if you
caught this in testing/review?
Balbir Singh.
I caught it while looking at the code and then wrote a test case to confirm
I was correct because I wasn't sure how to easily find an in tree user.
Thanks,
Laura
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mm: Add is_migrate_cma_page
Code such as hardened user copy[1] needs a way to tell if a page is CMA or not. Add is_migrate_cma_page in a similar way to is_migrate_isolate_page. [1]http://article.gmane.org/gmane.linux.kernel.mm/155238 Signed-off-by: Laura Abbott --- Here's an explicit patch, slightly different than what I posted before. It can be kept separate or folded in as needed. --- include/linux/mmzone.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index 02069c2..c8478b2 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -68,8 +68,10 @@ extern char * const migratetype_names[MIGRATE_TYPES]; #ifdef CONFIG_CMA # define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA) +# define is_migrate_cma_page(_page) (get_pageblock_migratetype(_page) == MIGRATE_CMA) #else # define is_migrate_cma(migratetype) false +# define is_migrate_cma_page(_page) false #endif #define for_each_migratetype_order(order, type) \ -- 2.7.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 02/11] mm: Hardened usercopy
On 07/15/2016 02:44 PM, Kees Cook wrote:
This is the start of porting PAX_USERCOPY into the mainline kernel. This
is the first set of features, controlled by CONFIG_HARDENED_USERCOPY. The
work is based on code by PaX Team and Brad Spengler, and an earlier port
from Casey Schaufler. Additional non-slab page tests are from Rik van Riel.
This patch contains the logic for validating several conditions when
performing copy_to_user() and copy_from_user() on the kernel object
being copied to/from:
- address range doesn't wrap around
- address range isn't NULL or zero-allocated (with a non-zero copy size)
- if on the slab allocator:
- object size must be less than or equal to copy size (when check is
implemented in the allocator, which appear in subsequent patches)
- otherwise, object must not span page allocations
- if on the stack
- object must not extend before/after the current process task
- object must be contained by the current stack frame (when there is
arch/build support for identifying stack frames)
- object must not overlap with kernel text
Signed-off-by: Kees Cook
Tested-By: Valdis Kletnieks
Tested-by: Michael Ellerman
---
arch/Kconfig| 7 ++
include/linux/slab.h| 12 +++
include/linux/thread_info.h | 15 +++
mm/Makefile | 4 +
mm/usercopy.c | 234
security/Kconfig| 28 ++
6 files changed, 300 insertions(+)
create mode 100644 mm/usercopy.c
diff --git a/arch/Kconfig b/arch/Kconfig
index 5e2776562035..195ee4cc939a 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -433,6 +433,13 @@ config HAVE_ARCH_WITHIN_STACK_FRAMES
and similar) by implementing an inline arch_within_stack_frames(),
which is used by CONFIG_HARDENED_USERCOPY.
+config HAVE_ARCH_LINEAR_KERNEL_MAPPING
+ bool
+ help
+ An architecture should select this if it has a secondary linear
+ mapping of the kernel text. This is used to verify that kernel
+ text exposures are not visible under CONFIG_HARDENED_USERCOPY.
+
config HAVE_CONTEXT_TRACKING
bool
help
diff --git a/include/linux/slab.h b/include/linux/slab.h
index aeb3e6d00a66..96a16a3fb7cb 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -155,6 +155,18 @@ void kfree(const void *);
void kzfree(const void *);
size_t ksize(const void *);
+#ifdef CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR
+const char *__check_heap_object(const void *ptr, unsigned long n,
+ struct page *page);
+#else
+static inline const char *__check_heap_object(const void *ptr,
+ unsigned long n,
+ struct page *page)
+{
+ return NULL;
+}
+#endif
+
/*
* Some archs want to perform DMA into kmalloc caches and need a guaranteed
* alignment larger than the alignment of a 64-bit integer.
diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
index 3d5c80b4391d..f24b99eac969 100644
--- a/include/linux/thread_info.h
+++ b/include/linux/thread_info.h
@@ -155,6 +155,21 @@ static inline int arch_within_stack_frames(const void *
const stack,
}
#endif
+#ifdef CONFIG_HARDENED_USERCOPY
+extern void __check_object_size(const void *ptr, unsigned long n,
+ bool to_user);
+
+static inline void check_object_size(const void *ptr, unsigned long n,
+bool to_user)
+{
+ __check_object_size(ptr, n, to_user);
+}
+#else
+static inline void check_object_size(const void *ptr, unsigned long n,
+bool to_user)
+{ }
+#endif /* CONFIG_HARDENED_USERCOPY */
+
#endif /* __KERNEL__ */
#endif /* _LINUX_THREAD_INFO_H */
diff --git a/mm/Makefile b/mm/Makefile
index 78c6f7dedb83..32d37247c7e5 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -21,6 +21,9 @@ KCOV_INSTRUMENT_memcontrol.o := n
KCOV_INSTRUMENT_mmzone.o := n
KCOV_INSTRUMENT_vmstat.o := n
+# Since __builtin_frame_address does work as used, disable the warning.
+CFLAGS_usercopy.o += $(call cc-disable-warning, frame-address)
+
mmu-y := nommu.o
mmu-$(CONFIG_MMU) := gup.o highmem.o memory.o mincore.o \
mlock.o mmap.o mprotect.o mremap.o msync.o rmap.o \
@@ -99,3 +102,4 @@ obj-$(CONFIG_USERFAULTFD) += userfaultfd.o
obj-$(CONFIG_IDLE_PAGE_TRACKING) += page_idle.o
obj-$(CONFIG_FRAME_VECTOR) += frame_vector.o
obj-$(CONFIG_DEBUG_PAGE_REF) += debug_page_ref.o
+obj-$(CONFIG_HARDENED_USERCOPY) += usercopy.o
diff --git a/mm/usercopy.c b/mm/usercopy.c
new file mode 100644
index ..e4bf4e7ccdf6
--- /dev/null
+++ b/mm/usercopy.c
@@ -0,0 +1,234 @@
+/*
+ * This implements the various checks for CONFIG_HARDENED_USERCOPY*,
+ * which are designed to protect kernel memory from needless exposure
+ * and overwrite under many unintended conditions. This code is based
+ * on PAX_USERC
Re: [PATCH v3 02/11] mm: Hardened usercopy
On 07/15/2016 02:44 PM, Kees Cook wrote:
This is the start of porting PAX_USERCOPY into the mainline kernel. This
is the first set of features, controlled by CONFIG_HARDENED_USERCOPY. The
work is based on code by PaX Team and Brad Spengler, and an earlier port
from Casey Schaufler. Additional non-slab page tests are from Rik van Riel.
This patch contains the logic for validating several conditions when
performing copy_to_user() and copy_from_user() on the kernel object
being copied to/from:
- address range doesn't wrap around
- address range isn't NULL or zero-allocated (with a non-zero copy size)
- if on the slab allocator:
- object size must be less than or equal to copy size (when check is
implemented in the allocator, which appear in subsequent patches)
- otherwise, object must not span page allocations
- if on the stack
- object must not extend before/after the current process task
- object must be contained by the current stack frame (when there is
arch/build support for identifying stack frames)
- object must not overlap with kernel text
Signed-off-by: Kees Cook
Tested-By: Valdis Kletnieks
Tested-by: Michael Ellerman
---
arch/Kconfig| 7 ++
include/linux/slab.h| 12 +++
include/linux/thread_info.h | 15 +++
mm/Makefile | 4 +
mm/usercopy.c | 234
security/Kconfig| 28 ++
6 files changed, 300 insertions(+)
create mode 100644 mm/usercopy.c
diff --git a/arch/Kconfig b/arch/Kconfig
index 5e2776562035..195ee4cc939a 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -433,6 +433,13 @@ config HAVE_ARCH_WITHIN_STACK_FRAMES
and similar) by implementing an inline arch_within_stack_frames(),
which is used by CONFIG_HARDENED_USERCOPY.
+config HAVE_ARCH_LINEAR_KERNEL_MAPPING
+ bool
+ help
+ An architecture should select this if it has a secondary linear
+ mapping of the kernel text. This is used to verify that kernel
+ text exposures are not visible under CONFIG_HARDENED_USERCOPY.
+
config HAVE_CONTEXT_TRACKING
bool
help
diff --git a/include/linux/slab.h b/include/linux/slab.h
index aeb3e6d00a66..96a16a3fb7cb 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -155,6 +155,18 @@ void kfree(const void *);
void kzfree(const void *);
size_t ksize(const void *);
+#ifdef CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR
+const char *__check_heap_object(const void *ptr, unsigned long n,
+ struct page *page);
+#else
+static inline const char *__check_heap_object(const void *ptr,
+ unsigned long n,
+ struct page *page)
+{
+ return NULL;
+}
+#endif
+
/*
* Some archs want to perform DMA into kmalloc caches and need a guaranteed
* alignment larger than the alignment of a 64-bit integer.
diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
index 3d5c80b4391d..f24b99eac969 100644
--- a/include/linux/thread_info.h
+++ b/include/linux/thread_info.h
@@ -155,6 +155,21 @@ static inline int arch_within_stack_frames(const void *
const stack,
}
#endif
+#ifdef CONFIG_HARDENED_USERCOPY
+extern void __check_object_size(const void *ptr, unsigned long n,
+ bool to_user);
+
+static inline void check_object_size(const void *ptr, unsigned long n,
+bool to_user)
+{
+ __check_object_size(ptr, n, to_user);
+}
+#else
+static inline void check_object_size(const void *ptr, unsigned long n,
+bool to_user)
+{ }
+#endif /* CONFIG_HARDENED_USERCOPY */
+
#endif /* __KERNEL__ */
#endif /* _LINUX_THREAD_INFO_H */
diff --git a/mm/Makefile b/mm/Makefile
index 78c6f7dedb83..32d37247c7e5 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -21,6 +21,9 @@ KCOV_INSTRUMENT_memcontrol.o := n
KCOV_INSTRUMENT_mmzone.o := n
KCOV_INSTRUMENT_vmstat.o := n
+# Since __builtin_frame_address does work as used, disable the warning.
+CFLAGS_usercopy.o += $(call cc-disable-warning, frame-address)
+
mmu-y := nommu.o
mmu-$(CONFIG_MMU) := gup.o highmem.o memory.o mincore.o \
mlock.o mmap.o mprotect.o mremap.o msync.o rmap.o \
@@ -99,3 +102,4 @@ obj-$(CONFIG_USERFAULTFD) += userfaultfd.o
obj-$(CONFIG_IDLE_PAGE_TRACKING) += page_idle.o
obj-$(CONFIG_FRAME_VECTOR) += frame_vector.o
obj-$(CONFIG_DEBUG_PAGE_REF) += debug_page_ref.o
+obj-$(CONFIG_HARDENED_USERCOPY) += usercopy.o
diff --git a/mm/usercopy.c b/mm/usercopy.c
new file mode 100644
index ..e4bf4e7ccdf6
--- /dev/null
+++ b/mm/usercopy.c
@@ -0,0 +1,234 @@
+/*
+ * This implements the various checks for CONFIG_HARDENED_USERCOPY*,
+ * which are designed to protect kernel memory from needless exposure
+ * and overwrite under many unintended conditions. This code is based
+ * on PAX_USERC
Re: [PATCH 0/9] mm: Hardened usercopy
On Sat, Jul 9, 2016 at 1:25 AM, Ard Biesheuvel wrote: > On 9 July 2016 at 04:22, Laura Abbott wrote: > > On 07/06/2016 03:25 PM, Kees Cook wrote: > >> > >> Hi, > >> > >> This is a start of the mainline port of PAX_USERCOPY[1]. After I started > >> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I > >> kept tweaking things further and further until I ended up with a whole > >> new patch series. To that end, I took Rik's feedback and made a number > >> of other changes and clean-ups as well. > >> > >> Based on my understanding, PAX_USERCOPY was designed to catch a few > >> classes of flaws around the use of copy_to_user()/copy_from_user(). > These > >> changes don't touch get_user() and put_user(), since these operate on > >> constant sized lengths, and tend to be much less vulnerable. There > >> are effectively three distinct protections in the whole series, > >> each of which I've given a separate CONFIG, though this patch set is > >> only the first of the three intended protections. (Generally speaking, > >> PAX_USERCOPY covers what I'm calling CONFIG_HARDENED_USERCOPY (this) and > >> CONFIG_HARDENED_USERCOPY_WHITELIST (future), and PAX_USERCOPY_SLABS > covers > >> CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC (future).) > >> > >> This series, which adds CONFIG_HARDENED_USERCOPY, checks that objects > >> being copied to/from userspace meet certain criteria: > >> - if address is a heap object, the size must not exceed the object's > >> allocated size. (This will catch all kinds of heap overflow flaws.) > >> - if address range is in the current process stack, it must be within > the > >> current stack frame (if such checking is possible) or at least > entirely > >> within the current process's stack. (This could catch large lengths > that > >> would have extended beyond the current process stack, or overflows if > >> their length extends back into the original stack.) > >> - if the address range is part of kernel data, rodata, or bss, allow it. > >> - if address range is page-allocated, that it doesn't span multiple > >> allocations. > >> - if address is within the kernel text, reject it. > >> - everything else is accepted > >> > >> The patches in the series are: > >> - The core copy_to/from_user() checks, without the slab object checks: > >> 1- mm: Hardened usercopy > >> - Per-arch enablement of the protection: > >> 2- x86/uaccess: Enable hardened usercopy > >> 3- ARM: uaccess: Enable hardened usercopy > >> 4- arm64/uaccess: Enable hardened usercopy > >> 5- ia64/uaccess: Enable hardened usercopy > >> 6- powerpc/uaccess: Enable hardened usercopy > >> 7- sparc/uaccess: Enable hardened usercopy > >> - The heap allocator implementation of object size checking: > >> 8- mm: SLAB hardened usercopy support > >> 9- mm: SLUB hardened usercopy support > >> > >> Some notes: > >> > >> - This is expected to apply on top of -next which contains fixes for the > >> position of _etext on both arm and arm64. > >> > >> - I couldn't detect a measurable performance change with these features > >> enabled. Kernel build times were unchanged, hackbench was unchanged, > >> etc. I think we could flip this to "on by default" at some point. > >> > >> - The SLOB support extracted from grsecurity seems entirely broken. I > >> have no idea what's going on there, I spent my time testing SLAB and > >> SLUB. Having someone else look at SLOB would be nice, but this series > >> doesn't depend on it. > >> > >> Additional features that would be nice, but aren't blocking this series: > >> > >> - Needs more architecture support for stack frame checking (only x86 > now). > >> > >> > > > > Even with the SLUB fixup I'm still seeing this blow up on my arm64 > system. > > This is a > > Fedora rawhide kernel + the patches > > > > [ 0.666700] usercopy: kernel memory exposure attempt detected from > > fc0008b4dd58 () (8 bytes) > > [ 0.666720] CPU: 2 PID: 79 Comm: modprobe Tainted: GW > > 4.7.0-0.rc6.git1.1.hardenedusercopy.fc25.aarch64 #1 > > [ 0.666733] Hardware name: AppliedMicro Mustang/Mustang, BIOS 1.1.0 Nov > 24 > > 2015 > > [ 0.666744] Call trace:
Re: Missing operand for tlbie instruction on Power7
On 10/05/2015 08:35 PM, Michael Ellerman wrote: On Fri, 2015-10-02 at 08:43 -0700, Laura Abbott wrote: Hi, We received a report (https://bugzilla.redhat.com/show_bug.cgi?id=1267395) of bad assembly when compiling on powerpc with little endian ... After some discussion with the binutils folks, it turns out that the tlbie instruction actually requires another operand and binutils was updated to check for this https://sourceware.org/ml/binutils/2015-05/msg00133.html . The code sequence in arch/powerpc/include/asm/ppc_asm.h now needs to be updated: #if !defined(CONFIG_4xx) && !defined(CONFIG_8xx) #define tlbia \ li r4,1024;\ mtctr r4; \ lis r4,KERNELBASE@h;\ 0: tlbie r4; \ addir4,r4,0x1000; \ bdnz0b #endif I don't know enough ppc assembly to properly fix this but I can test. How are you testing? This code is fairly old and I'm dubious if it still works. These days we have a ppc_md hook for flushing the TLB, ppc_md.flush_tlb(). Ideally the swsusp code would use that. cheers Testing would probably just be compile and maybe boot. I don't have regular access to the hardware. This problem just showed up for me when someone tried to compile Fedora rawhide with the latest binutils. From what I can tell, it looks like the .flush_tlb of the cpu_spec is only defined for power7 and power8 and I don't see a ppc_md.flush_tlb on the master branch. It's not clear what to do for the case where there is no flush_tlb function. Would filling in a .flush_tlb for all the PPC_BOOK3S_64 with the existing tlbia sequence work? It's also worth noting that the __flush_power7 uses tlbiel instead of tlbie. Thanks, Laura ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing operand for tlbie instruction on Power7
On 10/03/2015 05:00 PM, Segher Boessenkool wrote: On Fri, Oct 02, 2015 at 09:24:46PM -0500, Peter Bergner wrote: Ok, than we can just zero out r5 for example and use it in tlbie as RS, right? That won't assemble _unless_ your assembler is in POWER7 mode. It also won't do the right thing at run time on older machines. Correct, getting this to work on both pre-power7 and power7 and later is tricky. One really horrible hack would be to do: li r0,0 tlbie r4,0 On pre-power7, the "0" will be taken as a zero L operand and on power7 and later, it'll be r0, but with a zero value we loaded in the insn before. I know, really ugly. :-) Hide the "li 0,0" somewhere earlier, and write it as "tlbie 4,0", and don't write a comment -- we *like* tricky! It should really be a separate macro define for power7 and 4xx etc.; and the macro should not be called "tlbia", but something that makes it obvious at the usage sites that it is in fact a macro; and why a macro anyway, a function call might be better here? Segher I can't speculate on why it is a macro but would something such as the following work? Alternatively, we could move the assembly into swusp_asm64.S which appears to be the only 64-bit caller of tlbia diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h index dd0fc18..53e5f59 100644 --- a/arch/powerpc/include/asm/ppc_asm.h +++ b/arch/powerpc/include/asm/ppc_asm.h @@ -434,14 +434,30 @@ END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,945) #endif /* - * This instruction is not implemented on the PPC 603 or 601; however, on + * tlbia is not implemented on the PPC 603 or 601; however, on * the 403GCX and 405GP tlbia IS defined and tlbie is not. * All of these instructions exist in the 8xx, they have magical powers, * and they must be used. + * + * The ISA 2.06 update for POWER7 changed the number of arguments to tlbie + * so it gets its own special case as well as any config that may set + * mtune=power7 such as CONFIG_PPC_BOOK3S_64 */ -#if !defined(CONFIG_4xx) && !defined(CONFIG_8xx) -#define tlbia \ +#if defined(CONFIG_4xx) || defined(CONFIG_8xx) +#define TLBIA_ACTION tlbia +#elif defined(CONFIG_POWER7_CPU) || defined(CONFIG_PPC_BOOK3S_64) +#define TLBIA_ACTION \ + li r4,1024;\ + mtctr r4; \ + lis r4,KERNELBASE@h;\ + li r0,0; \ +0: tlbie r4,r0; \ + addir4,r4,0x1000; \ + bdnz0b + +#else +#define TLBIA_ACTION \ li r4,1024;\ mtctr r4; \ lis r4,KERNELBASE@h;\ diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S index dc0488b..40c3b33 100644 --- a/arch/powerpc/kernel/head_32.S +++ b/arch/powerpc/kernel/head_32.S @@ -901,7 +901,7 @@ _ENTRY(__restore_cpu_setup) load_up_mmu: sync/* Force all PTE updates to finish */ isync - tlbia /* Clear all TLB entries */ + TLBIA_ACTION/* Clear all TLB entries */ sync/* wait for tlbia/tlbie to finish */ TLBSYNC /* ... on all CPUs */ /* Load the SDR1 register (hash table base & size) */ diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S index 7d7d863..6a83ec2 100644 --- a/arch/powerpc/kernel/head_40x.S +++ b/arch/powerpc/kernel/head_40x.S @@ -869,7 +869,7 @@ start_here: /* Load up the kernel context */ 2: sync/* Flush to memory before changing TLB */ - tlbia + TLBIA_ACTION isync /* Flush shadow TLBs */ /* set up the PTE pointers for the Abatron bdiGDB. @@ -897,7 +897,7 @@ start_here: * virtual to physical and more importantly sets the cache mode. */ initial_mmu: - tlbia /* Invalidate all TLB entries */ + TLBIA_ACTION/* Invalidate all TLB entries */ isync /* We should still be executing code at physical address 0x diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 78c1eba..533d736 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -711,7 +711,7 @@ start_here: /* Load up the kernel context */ 2: SYNC/* Force all PTE updates to finish */ - tlbia /* Clear all TLB entries */ + TLBIA_ACTION/* Clear all TLB entries */ sync/* wait for tlbia/tlbie to finish */ TLBSYNC /* ... on all CPUs */ @@ -741,7 +741,7 @@ start_here: * these mappings is mapped by page tables. */ initial_mmu: - tlbia /* Inval
Re: Missing operand for tlbie instruction on Power7
On 10/02/2015 03:00 PM, Segher Boessenkool wrote: On Sat, Oct 03, 2015 at 12:37:35AM +0300, Denis Kirjanov wrote: -0: tlbie r4; \ +0: tlbie r4, 0; \ This isn't correct. With POWER7 and later (which this compile is, since it's on LE), the tlbie instruction takes two register operands: tlbie RB, RS The tlbie instruction on pre POWER7 cpus had one required register operand (RB) and an optional second L operand, where if you omitted it, it was the same as using "0": tlbie RB, L This is a POWER7 and later build, so your change which adds the "0" above is really adding r0 for RS. The new tlbie instruction doesn't treat r0 specially, so you'll be using whatever random bits which happen to be in r0 which I don't think that is what you want. Ok, than we can just zero out r5 for example and use it in tlbie as RS, right? That won't assemble _unless_ your assembler is in POWER7 mode. It also won't do the right thing at run time on older machines. Where is this tlbia macro used at all, for 64-bit machines? [labbott@labbott-redhat-machine linux_upstream]$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h CALLarch/powerpc/kernel/systbl_chk.sh AS arch/powerpc/kernel/swsusp_asm64.o arch/powerpc/kernel/swsusp_asm64.S: Assembler messages: arch/powerpc/kernel/swsusp_asm64.S:188: Error: missing operand scripts/Makefile.build:294: recipe for target 'arch/powerpc/kernel/swsusp_asm64.o' failed make[1]: *** [arch/powerpc/kernel/swsusp_asm64.o] Error 1 Makefile:941: recipe for target 'arch/powerpc/kernel' failed make: *** [arch/powerpc/kernel] Error 2 This is piece of code protected by CONFIG_PPC_BOOK3S_64. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Missing operand for tlbie instruction on Power7
Hi, We received a report (https://bugzilla.redhat.com/show_bug.cgi?id=1267395) of bad assembly when compiling on powerpc with little endian [labbott@labbott-redhat-machine linux_upstream]$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h CALLarch/powerpc/kernel/systbl_chk.sh AS arch/powerpc/kernel/swsusp_asm64.o arch/powerpc/kernel/swsusp_asm64.S: Assembler messages: arch/powerpc/kernel/swsusp_asm64.S:188: Error: missing operand scripts/Makefile.build:294: recipe for target 'arch/powerpc/kernel/swsusp_asm64.o' failed make[1]: *** [arch/powerpc/kernel/swsusp_asm64.o] Error 1 Makefile:941: recipe for target 'arch/powerpc/kernel' failed make: *** [arch/powerpc/kernel] Error 2 This problem started happening after a binutils update: [labbott@labbott-redhat-machine linux_upstream]$ powerpc64-linux-gnu-as --version GNU assembler version 2.25.1-1.fc22 Copyright (C) 2014 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `powerpc64-linux-gnu'. [labbott@labbott-redhat-machine linux_upstream]$ After some discussion with the binutils folks, it turns out that the tlbie instruction actually requires another operand and binutils was updated to check for this https://sourceware.org/ml/binutils/2015-05/msg00133.html . The code sequence in arch/powerpc/include/asm/ppc_asm.h now needs to be updated: #if !defined(CONFIG_4xx) && !defined(CONFIG_8xx) #define tlbia \ li r4,1024;\ mtctr r4; \ lis r4,KERNELBASE@h;\ 0: tlbie r4; \ addir4,r4,0x1000; \ bdnz0b #endif I don't know enough ppc assembly to properly fix this but I can test. Thanks, Laura ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 2/6] genalloc:support allocating specific region
On 09/28/2015 07:09 PM, Zhao Qiang wrote: Add new algo for genalloc, it reserve a specific region of memory matching the size requirement (no alignment constraint) Signed-off-by: Zhao Qiang Reviewed-by: Laura Abbott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 1/6] genalloc:support memory-allocation with bytes-alignment to genalloc
On 09/28/2015 07:09 PM, Zhao Qiang wrote: Bytes alignment is required to manage some special RAM, so add gen_pool_first_fit_align to genalloc, meanwhile add gen_pool_alloc_data to pass data to gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper) Signed-off-by: Zhao Qiang Reviewed-by: Laura Abbott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram
On 08/24/2015 08:03 PM, Zhao Qiang wrote:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Tuesday, August 25, 2015 7:32 AM
To: Zhao Qiang-B45475; Wood Scott-B07421
Cc: linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
Yang-Leo-R58472; pau...@samba.org
Subject: Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage
muram
On 08/24/2015 02:31 AM, Zhao Qiang wrote:
+out:
+ of_node_put(np);
+ return ret;
+}
+
+/**
+ * qe_muram_alloc - allocate the requested size worth of multi-user
+ram
+ * @size: number of bytes to allocate
+ * @align: requested alignment, in bytes
+ *
+ * This function returns an offset into the muram area.
+ * Use qe_dpram_addr() to get the virtual address of the area.
+ * Use qe_muram_free() to free the allocation.
+ */
+unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
+{
+ unsigned long start;
+ unsigned long flags;
+ struct muram_block *entry;
+
+ spin_lock_irqsave(&qe_muram_lock, flags);
+ muram_pool_data.align = align;
+ start = gen_pool_alloc(muram_pool, size);
The advantage of creating gen_pool_alloc_data was so that you could pass
in the align automatically without having to modify the structure.
Is there a reason you aren't using that?
+ memset(qe_muram_addr(start), 0, size);
There doesn't seem to be a check for allocation failure from the
gen_alloc.
gen_pool_alloc will return 0 if there is error, but if the address returned is
just 0x0, it can't distinguish it is address or error.
Yes, that's a bad limitation of gen_pool. Maybe one day that will get fixed.
In a previous out of tree driver, I worked around this by offsetting the
gen_pool_add by a constant so any return value was non-zero and out of memory
was zero and then subtracting the constant off of the return value. Not sure
if that's better or worse than just fixing gen_alloc.
+ entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry)
+ goto out;
+ entry->start = start;
+ entry->size = size;
+ list_add(&entry->head, &muram_block_list);
What's the point of keeping the block list anyway? It's used only in this
file and it only seems to duplicate what gen_alloc is doing internally.
Is there some lookup functionality you still need? Could you use a
gen_alloc API to do so?
I need to record the size when allocation, so when free the block, I can get
The right size for the block, and pass the right size to
gen_pool_free(struct gen_pool *pool, unsigned long addr, size_t size).
Yes, I see now what you are doing.
Thanks,
Laura
Thanks
Zhao
Thanks,
Laura
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On 08/24/2015 07:40 PM, Zhao Qiang wrote:
On 08/25/2015 07:11 AM, Laura Abbott wrote:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Tuesday, August 25, 2015 7:11 AM
To: Zhao Qiang-B45475; Wood Scott-B07421
Cc: linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
Yang-Leo-R58472; pau...@samba.org
Subject: Re: [PATCH v6 1/3] genalloc:support memory-allocation with
bytes-alignment to genalloc
On 08/24/2015 02:31 AM, Zhao Qiang wrote:
Bytes alignment is required to manage some special RAM, so add
gen_pool_first_fit_align to genalloc, meanwhile add
gen_pool_alloc_data to pass data to gen_pool_first_fit_align(modify
gen_pool_alloc as a wrapper)
Signed-off-by: Zhao Qiang
---
Changes for v6:
- patches set v6 include a new patch because of using
- genalloc to manage QE MURAM, patch 0001 is the new
- patch, adding bytes alignment for allocation for use.
include/linux/genalloc.h | 23 +++
lib/genalloc.c | 58
+++-
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h index
1ccaab4..55da07e 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -34,6 +34,7 @@
struct device;
struct device_node;
+struct gen_pool;
/**
* Allocation callback function type definition @@ -47,7 +48,7 @@
typedef unsigned long (*genpool_algo_t)(unsigned long *map,
unsigned long size,
unsigned long start,
unsigned int nr,
- void *data);
+ void *data, struct gen_pool *pool);
/*
* General purpose special memory pool descriptor.
@@ -73,6 +74,13 @@ struct gen_pool_chunk {
unsigned long bits[0]; /* bitmap for allocating memory chunk
*/
};
+/*
+ * gen_pool data descriptor for gen_pool_first_fit_align.
+ */
+struct genpool_data_align {
+ int align; /* alignment by bytes for starting address */
+};
+
(sorry for chiming in late, I've been traveling)
Is there an advantage here to wrapping this in a structure instead of
just passing a pointer to an align integer?
Please look at the commit message for
ca279cf1065fb689abea1dc7d8c11787729bb185 which adds "data":
"As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm."
Right, I understand what the purpose is but I'm not sure what you're getting
from the structure vs passing a pointer, e.g.
int align;
align = 4;
gen_pool_alloc_data(&pool, size, &align);
it just seems to obfuscate what's going on by wrapping a single integer in
a structure that's narrowly defined in a generic function right now. I guess
it could change later which would necessitate having the structure but again
it's so generic I'm not sure what else you would pass that would be applicable
to all clients.
Thanks,
Laura
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram
On 08/24/2015 02:31 AM, Zhao Qiang wrote:
diff --git a/drivers/soc/fsl/qe/qe_common.c b/drivers/soc/fsl/qe/qe_common.c
new file mode 100644
index 000..7f1762c
--- /dev/null
+++ b/drivers/soc/fsl/qe/qe_common.c
@@ -0,0 +1,193 @@
+/*
+ * common qe code
+ *
+ * author: scott wood
+ *
+ * copyright 2007-2008,2010 freescale Semiconductor, Inc.
+ *
+ * some parts derived from commproc.c/qe2_common.c, which is:
+ * copyright (c) 1997 dan error_act (dma...@jlc.net)
+ * copyright (c) 1999-2001 dan Malek
+ * copyright (c) 2000 montavista Software, Inc (sou...@mvista.com)
+ * 2006 (c) montavista software, Inc.
+ * vitaly bordug
+ *
+ * this program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the free software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static struct gen_pool *muram_pool;
+static struct genpool_data_align muram_pool_data;
+static spinlock_t qe_muram_lock;
+static u8 __iomem *muram_vbase;
+static phys_addr_t muram_pbase;
+
+struct muram_block {
+ struct list_head head;
+ unsigned long start;
+ int size;
+};
+
+static LIST_HEAD(muram_block_list);
+
+/* max address size we deal with */
+#define OF_MAX_ADDR_CELLS 4
+
+int qe_muram_init(void)
+{
+ struct device_node *np;
+ struct resource r;
+ u32 zero[OF_MAX_ADDR_CELLS] = {};
+ resource_size_t max = 0;
+ int i = 0;
+ int ret = 0;
+
+ if (muram_pbase)
+ return 0;
+
+ muram_pool = gen_pool_create(1, -1);
+ gen_pool_set_algo(muram_pool, gen_pool_first_fit_align,
+ &muram_pool_data);
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,qe-muram-data");
+ if (!np) {
+ /* try legacy bindings */
+ np = of_find_node_by_name(NULL, "data-only");
+ if (!np) {
+ pr_err("Cannot find CPM muram data node");
+ ret = -ENODEV;
+ goto out;
+ }
+ }
+
+ muram_pbase = of_translate_address(np, zero);
+ if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
+ pr_err("Cannot translate zero through CPM muram node");
+ ret = -ENODEV;
+ goto out;
+ }
+
+ while (of_address_to_resource(np, i++, &r) == 0) {
+ if (r.end > max)
+ max = r.end;
+ ret = gen_pool_add(muram_pool, r.start - muram_pbase,
+ resource_size(&r), -1);
+ if (ret) {
+ pr_err("QE MURAM: could not add muram ");
+ pr_err("remainder to pool!\n");
Don't split the error string over two lines
+ return ret;
returning here misses the error path
+ }
+
+ }
+
+ muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
+ if (!muram_vbase) {
+ pr_err("Cannot map CPM muram");
+ ret = -ENOMEM;
+ }
+
gen_pool_destroy on the error path
+out:
+ of_node_put(np);
+ return ret;
+}
+
+/**
+ * qe_muram_alloc - allocate the requested size worth of multi-user ram
+ * @size: number of bytes to allocate
+ * @align: requested alignment, in bytes
+ *
+ * This function returns an offset into the muram area.
+ * Use qe_dpram_addr() to get the virtual address of the area.
+ * Use qe_muram_free() to free the allocation.
+ */
+unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
+{
+ unsigned long start;
+ unsigned long flags;
+ struct muram_block *entry;
+
+ spin_lock_irqsave(&qe_muram_lock, flags);
+ muram_pool_data.align = align;
+ start = gen_pool_alloc(muram_pool, size);
The advantage of creating gen_pool_alloc_data was so that you could
pass in the align automatically without having to modify the structure.
Is there a reason you aren't using that?
+ memset(qe_muram_addr(start), 0, size);
There doesn't seem to be a check for allocation failure from the
gen_alloc.
+ entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry)
+ goto out;
+ entry->start = start;
+ entry->size = size;
+ list_add(&entry->head, &muram_block_list);
What's the point of keeping the block list anyway? It's used only in
this file and it only seems to duplicate what gen_alloc is doing internally.
Is there some lookup functionality you still need? Could you use a gen_alloc
API to do so?
+ spin_unlock_irqrestore(&qe_muram_lock, flags);
+
+ return start;
+out:
+ gen_pool_free(muram_pool, start, size);
+ return (unsigned long) -ENOMEM;
+}
+EXPORT_SYMBOL(qe_muram_alloc);
+
+/**
+ * qe_muram_free - free a chunk of multi-user ram
+ * @offset: The beginni
Re: [PATCH v6 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On 08/24/2015 02:31 AM, Zhao Qiang wrote:
Bytes alignment is required to manage some special RAM,
so add gen_pool_first_fit_align to genalloc,
meanwhile add gen_pool_alloc_data to pass data to
gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper)
Signed-off-by: Zhao Qiang
---
Changes for v6:
- patches set v6 include a new patch because of using
- genalloc to manage QE MURAM, patch 0001 is the new
- patch, adding bytes alignment for allocation for use.
include/linux/genalloc.h | 23 +++
lib/genalloc.c | 58 +++-
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 1ccaab4..55da07e 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -34,6 +34,7 @@
struct device;
struct device_node;
+struct gen_pool;
/**
* Allocation callback function type definition
@@ -47,7 +48,7 @@ typedef unsigned long (*genpool_algo_t)(unsigned long *map,
unsigned long size,
unsigned long start,
unsigned int nr,
- void *data);
+ void *data, struct gen_pool *pool);
/*
* General purpose special memory pool descriptor.
@@ -73,6 +74,13 @@ struct gen_pool_chunk {
unsigned long bits[0]; /* bitmap for allocating memory chunk */
};
+/*
+ * gen_pool data descriptor for gen_pool_first_fit_align.
+ */
+struct genpool_data_align {
+ int align; /* alignment by bytes for starting address */
+};
+
(sorry for chiming in late, I've been traveling)
Is there an advantage here to wrapping this in a structure instead of just
passing a pointer to an align integer?
Thanks,
Laura
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] genalloc:add an gen_pool_alloc_align func to genalloc
On 07/12/2015 07:22 PM, Zhao Qiang wrote:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Friday, July 10, 2015 5:51 AM
To: Zhao Qiang-B45475; lau...@codeaurora.org
Cc: linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
a...@linux-foundation.org; o...@lixom.net; catalin.mari...@arm.com; Wood
Scott-B07421; Xie Xiaobo-R63061
Subject: Re: [RFC] genalloc:add an gen_pool_alloc_align func to genalloc
On 07/09/2015 12:47 AM, Zhao Qiang wrote:
Bytes alignment is required to manage some special ram, so add
gen_pool_alloc_align func to genalloc.
rename gen_pool_alloc to gen_pool_alloc_align with a align parameter,
then provide gen_pool_alloc to call gen_pool_alloc_align with align =
1 Byte.
Signed-off-by: Zhao Qiang
---
FSL's IP block QE require this function to manage muram.
QE supported only PowerPC, and its code was put under arch/powerpc
directory, using arch/powerpc/lib/rheap.c to manage muram.
Now it support both arm(ls1021,ls1043,ls2085 and such on) and powerpc,
the code need to move from arch/powerpc to public direcory, Scott wood
hopes to use genalloc to manage the muram, after discussing with
scott, we decide to add gen_pool_alloc_align to meet the requirement
for bytes-alignment.
gen_pool supports custom allocation algorithms. I thought this was
discussed previously and the conclusion was that if you wanted alignment
you should use custom allocation algorithms. I'm failing at finding any
thread discussing it though.
Perhaps another option would be to add another runtime argument to
gen_pool where you could pass the alignment to your custom allocation
function. This way alignment isn't inherently coded into any of the
algorithms.
include/linux/genalloc.h | 10 +++---
lib/genalloc.c | 38 ++
2 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h index
1ccaab4..65fdf14 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -96,6 +96,8 @@ static inline int gen_pool_add(struct gen_pool *pool,
unsigned long addr,
}
extern void gen_pool_destroy(struct gen_pool *);
extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
+extern unsigned long gen_pool_alloc_align(struct gen_pool *, size_t,
+ unsigned long align);
extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
dma_addr_t *dma);
extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
@@ -108,14 +110,16 @@ extern void gen_pool_set_algo(struct gen_pool
*pool, genpool_algo_t algo,
void *data);
extern unsigned long gen_pool_first_fit(unsigned long *map, unsigned
long size,
- unsigned long start, unsigned int nr, void *data);
+ unsigned long start, unsigned int nr, void *data,
+ unsigned long align_mask);
extern unsigned long gen_pool_first_fit_order_align(unsigned long
*map,
unsigned long size, unsigned long start, unsigned int nr,
- void *data);
+ void *data, unsigned long align_mask);
extern unsigned long gen_pool_best_fit(unsigned long *map, unsigned
long size,
- unsigned long start, unsigned int nr, void *data);
+ unsigned long start, unsigned int nr, void *data,
+ unsigned long align_mask);
extern struct gen_pool *devm_gen_pool_create(struct device *dev,
int min_alloc_order, int nid);
diff --git a/lib/genalloc.c b/lib/genalloc.c index d214866..dd63448
100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -258,19 +258,22 @@ void gen_pool_destroy(struct gen_pool *pool)
EXPORT_SYMBOL(gen_pool_destroy);
/**
- * gen_pool_alloc - allocate special memory from the pool
+ * gen_pool_alloc_align - allocate special memory from the pool
* @pool: pool to allocate from
* @size: number of bytes to allocate from the pool
+ * @align: number of bytes to align
*
* Allocate the requested number of bytes from the specified pool.
* Uses the pool allocation function (with first-fit algorithm by
default).
* Can not be used in NMI handler on architectures without
* NMI-safe cmpxchg implementation.
*/
-unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size)
+unsigned long gen_pool_alloc_align(struct gen_pool *pool, size_t size,
+ unsigned long align)
{
struct gen_pool_chunk *chunk;
unsigned long addr = 0;
+ unsigned long align_mask;
int order = pool->min_alloc_order;
int nbits, start_bit = 0, end_bit, remain;
@@ -281,6 +284,7 @@ unsigned long gen_pool_alloc(struct gen_pool *pool,
size_t size)
if (size == 0)
return 0;
+ align_mask = ((align + (1UL << order) - 1) >> order) - 1;
nbits = (size + (1UL << order) - 1) >> order;
rcu_read_lock();
Re: [RFC] genalloc:add an gen_pool_alloc_align func to genalloc
On 07/09/2015 03:17 PM, Scott Wood wrote: On Thu, 2015-07-09 at 14:51 -0700, Laura Abbott wrote: On 07/09/2015 12:47 AM, Zhao Qiang wrote: Bytes alignment is required to manage some special ram, so add gen_pool_alloc_align func to genalloc. rename gen_pool_alloc to gen_pool_alloc_align with a align parameter, then provide gen_pool_alloc to call gen_pool_alloc_align with align = 1 Byte. Signed-off-by: Zhao Qiang --- FSL's IP block QE require this function to manage muram. QE supported only PowerPC, and its code was put under arch/powerpc directory, using arch/powerpc/lib/rheap.c to manage muram. Now it support both arm(ls1021,ls1043,ls2085 and such on) and powerpc, the code need to move from arch/powerpc to public direcory, Scott wood hopes to use genalloc to manage the muram, after discussing with scott, we decide to add gen_pool_alloc_align to meet the requirement for bytes-alignment. gen_pool supports custom allocation algorithms. I thought this was discussed previously and the conclusion was that if you wanted alignment you should use custom allocation algorithms. I'm failing at finding any thread discussing it though. I hope that by "custom algorithm" you don't mean something implemented outside lib/genalloc.c, as this does not seem like such a specialized requirement that everyone must reimplement it separately. If the functions are generic enough (which I think they are) they could stay in genalloc.c as another option for people to use. Perhaps another option would be to add another runtime argument to gen_pool where you could pass the alignment to your custom allocation function. This way alignment isn't inherently coded into any of the algorithms. That wouldn't let the alignment change for each allocation (and could already be done with pool->data). I suppose one could call get_pool_set_algo() with different data (or modify the memory that pool->data is already pointing to) before each allocation, but that's a bit clunky... If making alignment part of the mainstream flow is undesired for some reason, how about a gen_pool_alloc_data() that lets it be passed in per-allocation (with gen_pool_alloc() being a wrapper that passes in pool->data)? Yes, that's what I was thinking. I dropped the alloc from my 'runtime argument to gen_pool_alloc' so it wasn't clear I was talking about allocation time and not pool creation time. Yes, I know, we could do it in a wrapper (like cpm_muram_alloc() unnecessarily does), but why not make the interface better match the way it's used? Agreed. -Scott Thanks, Laura ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] genalloc:add an gen_pool_alloc_align func to genalloc
On 07/09/2015 12:47 AM, Zhao Qiang wrote:
Bytes alignment is required to manage some special ram,
so add gen_pool_alloc_align func to genalloc.
rename gen_pool_alloc to gen_pool_alloc_align with a align parameter,
then provide gen_pool_alloc to call gen_pool_alloc_align with
align = 1 Byte.
Signed-off-by: Zhao Qiang
---
FSL's IP block QE require this function to manage muram.
QE supported only PowerPC, and its code was put under arch/powerpc directory,
using arch/powerpc/lib/rheap.c to manage muram.
Now it support both arm(ls1021,ls1043,ls2085 and such on) and powerpc,
the code need to move from arch/powerpc to public direcory,
Scott wood hopes to use genalloc to manage the muram, after discussing
with scott, we decide to add gen_pool_alloc_align to meet the requirement
for bytes-alignment.
gen_pool supports custom allocation algorithms. I thought this was discussed
previously and the conclusion was that if you wanted alignment you should
use custom allocation algorithms. I'm failing at finding any thread discussing
it though.
Perhaps another option would be to add another runtime argument to gen_pool
where you could pass the alignment to your custom allocation function. This
way alignment isn't inherently coded into any of the algorithms.
include/linux/genalloc.h | 10 +++---
lib/genalloc.c | 38 ++
2 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 1ccaab4..65fdf14 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -96,6 +96,8 @@ static inline int gen_pool_add(struct gen_pool *pool,
unsigned long addr,
}
extern void gen_pool_destroy(struct gen_pool *);
extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
+extern unsigned long gen_pool_alloc_align(struct gen_pool *, size_t,
+ unsigned long align);
extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
dma_addr_t *dma);
extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
@@ -108,14 +110,16 @@ extern void gen_pool_set_algo(struct gen_pool *pool,
genpool_algo_t algo,
void *data);
extern unsigned long gen_pool_first_fit(unsigned long *map, unsigned long
size,
- unsigned long start, unsigned int nr, void *data);
+ unsigned long start, unsigned int nr, void *data,
+ unsigned long align_mask);
extern unsigned long gen_pool_first_fit_order_align(unsigned long *map,
unsigned long size, unsigned long start, unsigned int nr,
- void *data);
+ void *data, unsigned long align_mask);
extern unsigned long gen_pool_best_fit(unsigned long *map, unsigned long size,
- unsigned long start, unsigned int nr, void *data);
+ unsigned long start, unsigned int nr, void *data,
+ unsigned long align_mask);
extern struct gen_pool *devm_gen_pool_create(struct device *dev,
int min_alloc_order, int nid);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index d214866..dd63448 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -258,19 +258,22 @@ void gen_pool_destroy(struct gen_pool *pool)
EXPORT_SYMBOL(gen_pool_destroy);
/**
- * gen_pool_alloc - allocate special memory from the pool
+ * gen_pool_alloc_align - allocate special memory from the pool
* @pool: pool to allocate from
* @size: number of bytes to allocate from the pool
+ * @align: number of bytes to align
*
* Allocate the requested number of bytes from the specified pool.
* Uses the pool allocation function (with first-fit algorithm by default).
* Can not be used in NMI handler on architectures without
* NMI-safe cmpxchg implementation.
*/
-unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size)
+unsigned long gen_pool_alloc_align(struct gen_pool *pool, size_t size,
+ unsigned long align)
{
struct gen_pool_chunk *chunk;
unsigned long addr = 0;
+ unsigned long align_mask;
int order = pool->min_alloc_order;
int nbits, start_bit = 0, end_bit, remain;
@@ -281,6 +284,7 @@ unsigned long gen_pool_alloc(struct gen_pool *pool, size_t
size)
if (size == 0)
return 0;
+ align_mask = ((align + (1UL << order) - 1) >> order) - 1;
nbits = (size + (1UL << order) - 1) >> order;
rcu_read_lock();
list_for_each_entry_rcu(chunk, &pool->chunks, next_chunk) {
@@ -290,7 +294,7 @@ unsigned long gen_pool_alloc(struct gen_pool *pool, size_t
size)
end_bit = chunk_size(chunk) >> order;
retry:
start_bit = pool->algo(chunk->bits, end_bit, start_bit, nbits,
- pool->data);
+ pool->data, align_mask);
if (start_bit >= end_bit)
continue;
remain = bitmap_set_ll(chunk->bits
[RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig
Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture specific scatterlist.h, make it a proper Kconfig option and use that instead. At same time, remove the header files are are now mostly useless and just include asm-generic/scatterlist.h. Cc: Russell King Cc: Tony Luck Cc: Fenghua Yu Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: "James E.J. Bottomley" Cc: Fenghua Yu Cc: Tony Luck Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Andrew Morton Signed-off-by: Laura Abbott --- arch/arm/Kconfig | 1 + arch/arm/include/asm/Kbuild| 1 + arch/arm/include/asm/scatterlist.h | 12 arch/arm64/Kconfig | 1 + arch/ia64/Kconfig | 1 + arch/ia64/include/asm/Kbuild | 1 + arch/ia64/include/asm/scatterlist.h| 7 --- arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/Kbuild| 1 + arch/powerpc/include/asm/scatterlist.h | 17 - arch/s390/Kconfig | 1 + arch/s390/include/asm/Kbuild | 1 + arch/s390/include/asm/scatterlist.h| 3 --- arch/sparc/Kconfig | 1 + arch/sparc/include/asm/Kbuild | 1 + arch/sparc/include/asm/scatterlist.h | 8 arch/x86/Kconfig | 1 + arch/x86/include/asm/Kbuild| 1 + arch/x86/include/asm/scatterlist.h | 8 include/linux/scatterlist.h| 2 +- include/scsi/scsi.h| 2 +- lib/Kconfig| 7 +++ lib/scatterlist.c | 4 ++-- 23 files changed, 24 insertions(+), 59 deletions(-) delete mode 100644 arch/arm/include/asm/scatterlist.h delete mode 100644 arch/ia64/include/asm/scatterlist.h delete mode 100644 arch/powerpc/include/asm/scatterlist.h delete mode 100644 arch/s390/include/asm/scatterlist.h delete mode 100644 arch/sparc/include/asm/scatterlist.h delete mode 100644 arch/x86/include/asm/scatterlist.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 1594945..8122294 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -82,6 +82,7 @@ config ARM <http://www.arm.linux.org.uk/>. config ARM_HAS_SG_CHAIN + select ARCH_HAS_SG_CHAIN bool config NEED_SG_DMA_LENGTH diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild index 3278afe..2357ed6 100644 --- a/arch/arm/include/asm/Kbuild +++ b/arch/arm/include/asm/Kbuild @@ -18,6 +18,7 @@ generic-y += param.h generic-y += parport.h generic-y += poll.h generic-y += resource.h +generic-y += scatterlist.h generic-y += sections.h generic-y += segment.h generic-y += sembuf.h diff --git a/arch/arm/include/asm/scatterlist.h b/arch/arm/include/asm/scatterlist.h deleted file mode 100644 index cefdb8f..000 --- a/arch/arm/include/asm/scatterlist.h +++ /dev/null @@ -1,12 +0,0 @@ -#ifndef _ASMARM_SCATTERLIST_H -#define _ASMARM_SCATTERLIST_H - -#ifdef CONFIG_ARM_HAS_SG_CHAIN -#define ARCH_HAS_SG_CHAIN -#endif - -#include -#include -#include - -#endif /* _ASMARM_SCATTERLIST_H */ diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 27bbcfc..f2f95f4 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -2,6 +2,7 @@ config ARM64 def_bool y select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select ARCH_USE_CMPXCHG_LOCKREF + select ARCH_HAS_SG_CHAIN select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_WANT_OPTIONAL_GPIOLIB select ARCH_WANT_COMPAT_IPC_PARSE_VERSION diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 0c8e553..13e2e8b 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -44,6 +44,7 @@ config IA64 select HAVE_MOD_ARCH_SPECIFIC select MODULES_USE_ELF_RELA select ARCH_USE_CMPXCHG_LOCKREF + select ARCH_HAS_SG_CHAIN default y help The Itanium Processor Family is Intel's 64-bit successor to diff --git a/arch/ia64/include/asm/Kbuild b/arch/ia64/include/asm/Kbuild index 283a831..3906865 100644 --- a/arch/ia64/include/asm/Kbuild +++ b/arch/ia64/include/asm/Kbuild @@ -2,6 +2,7 @@ generic-y += clkdev.h generic-y += exec.h generic-y += kvm_para.h +generic-y += scatterlist.h generic-y += trace_clock.h generic-y += preempt.h generic-y += vtime.h diff --git a/arch/ia64/include/asm/scatterlist.h b/arch/ia64/include/asm/scatterlist.h deleted file mode 100644 index 08fd93b..000 --- a/arch/ia64/include/asm/scatterlist.h +++ /dev/null @@ -1,7 +0,0 @@ -#ifndef _ASM_IA64_SCATTERLIST_H -#define _ASM_IA64_SCATTERLIST_H - -#include -#define ARCH_HAS_SG_CHAIN - -#endif /* _ASM_IA64_SCATTERLIST_H */ diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 957bf34..659aee2 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -141,6 +141
[RESEND][PATCH 0/2] Cleanup asm/scatterlist.h
I haven't gotten many responses so I'm going to try sending again (this time with a cover letter which I probably should have done in the first place...) ARCH_HAS_SG_CHAIN is currently defined as needed in asm/scatterlist.h. It was suggested[1] that this should probably be a proper Kconfig. At the same time, we can clean up most of the asm/scatterlist.h files to reduce redundancy. This makes parisc the only architecture that still has an asm/scatterlist.h file due to the #define sg_virt_addr (which could probably be cleaned up further still) Andrew, once we get a few more Acked-bys can we take this through your tree as suggested by Will? Thanks, Laura [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/240435.html Laura Abbott (2): lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig Cleanup useless architecture versions of scatterlist.h arch/alpha/include/asm/Kbuild | 1 + arch/alpha/include/asm/scatterlist.h | 6 -- arch/arm/Kconfig | 1 + arch/arm/include/asm/Kbuild | 1 + arch/arm/include/asm/scatterlist.h| 12 arch/arm64/Kconfig| 1 + arch/cris/include/asm/Kbuild | 1 + arch/cris/include/asm/scatterlist.h | 6 -- arch/frv/include/asm/Kbuild | 1 + arch/frv/include/asm/scatterlist.h| 6 -- arch/ia64/Kconfig | 1 + arch/ia64/include/asm/Kbuild | 1 + arch/ia64/include/asm/scatterlist.h | 7 --- arch/m32r/include/asm/Kbuild | 1 + arch/m32r/include/asm/scatterlist.h | 6 -- arch/microblaze/include/asm/Kbuild| 1 + arch/microblaze/include/asm/scatterlist.h | 1 - arch/mn10300/include/asm/Kbuild | 1 + arch/mn10300/include/asm/scatterlist.h| 16 arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/Kbuild | 1 + arch/powerpc/include/asm/scatterlist.h| 17 - arch/s390/Kconfig | 1 + arch/s390/include/asm/Kbuild | 1 + arch/s390/include/asm/scatterlist.h | 3 --- arch/score/include/asm/Kbuild | 2 +- arch/score/include/asm/scatterlist.h | 6 -- arch/sparc/Kconfig| 1 + arch/sparc/include/asm/Kbuild | 1 + arch/sparc/include/asm/scatterlist.h | 8 arch/x86/Kconfig | 1 + arch/x86/include/asm/Kbuild | 1 + arch/x86/include/asm/scatterlist.h| 8 include/linux/scatterlist.h | 2 +- include/scsi/scsi.h | 2 +- lib/Kconfig | 7 +++ lib/scatterlist.c | 4 ++-- 37 files changed, 31 insertions(+), 107 deletions(-) delete mode 100644 arch/alpha/include/asm/scatterlist.h delete mode 100644 arch/arm/include/asm/scatterlist.h delete mode 100644 arch/cris/include/asm/scatterlist.h delete mode 100644 arch/frv/include/asm/scatterlist.h delete mode 100644 arch/ia64/include/asm/scatterlist.h delete mode 100644 arch/m32r/include/asm/scatterlist.h delete mode 100644 arch/microblaze/include/asm/scatterlist.h delete mode 100644 arch/mn10300/include/asm/scatterlist.h delete mode 100644 arch/powerpc/include/asm/scatterlist.h delete mode 100644 arch/s390/include/asm/scatterlist.h delete mode 100644 arch/score/include/asm/scatterlist.h delete mode 100644 arch/sparc/include/asm/scatterlist.h delete mode 100644 arch/x86/include/asm/scatterlist.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig
Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture specific scatterlist.h, make it a proper Kconfig option and use that instead. At same time, remove the header files are are now mostly useless and just include asm-generic/scatterlist.h. Cc: Russell King Cc: Tony Luck Cc: Fenghua Yu Benjamin Herrenschmidt Paul Mackerras Signed-off-by: Laura Abbott --- arch/arm/Kconfig | 1 + arch/arm/include/asm/Kbuild| 1 + arch/arm/include/asm/scatterlist.h | 12 arch/arm64/Kconfig | 1 + arch/ia64/Kconfig | 1 + arch/ia64/include/asm/Kbuild | 1 + arch/ia64/include/asm/scatterlist.h| 7 --- arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/Kbuild| 1 + arch/powerpc/include/asm/scatterlist.h | 17 - arch/s390/Kconfig | 1 + arch/s390/include/asm/Kbuild | 1 + arch/s390/include/asm/scatterlist.h| 3 --- arch/sparc/Kconfig | 1 + arch/sparc/include/asm/Kbuild | 1 + arch/sparc/include/asm/scatterlist.h | 8 arch/x86/Kconfig | 1 + arch/x86/include/asm/Kbuild| 1 + arch/x86/include/asm/scatterlist.h | 8 include/linux/scatterlist.h| 2 +- include/scsi/scsi.h| 2 +- lib/Kconfig| 7 +++ lib/scatterlist.c | 4 ++-- 23 files changed, 24 insertions(+), 59 deletions(-) delete mode 100644 arch/arm/include/asm/scatterlist.h delete mode 100644 arch/ia64/include/asm/scatterlist.h delete mode 100644 arch/powerpc/include/asm/scatterlist.h delete mode 100644 arch/s390/include/asm/scatterlist.h delete mode 100644 arch/sparc/include/asm/scatterlist.h delete mode 100644 arch/x86/include/asm/scatterlist.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 1594945..8122294 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -82,6 +82,7 @@ config ARM <http://www.arm.linux.org.uk/>. config ARM_HAS_SG_CHAIN + select ARCH_HAS_SG_CHAIN bool config NEED_SG_DMA_LENGTH diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild index 3278afe..2357ed6 100644 --- a/arch/arm/include/asm/Kbuild +++ b/arch/arm/include/asm/Kbuild @@ -18,6 +18,7 @@ generic-y += param.h generic-y += parport.h generic-y += poll.h generic-y += resource.h +generic-y += scatterlist.h generic-y += sections.h generic-y += segment.h generic-y += sembuf.h diff --git a/arch/arm/include/asm/scatterlist.h b/arch/arm/include/asm/scatterlist.h deleted file mode 100644 index cefdb8f..000 --- a/arch/arm/include/asm/scatterlist.h +++ /dev/null @@ -1,12 +0,0 @@ -#ifndef _ASMARM_SCATTERLIST_H -#define _ASMARM_SCATTERLIST_H - -#ifdef CONFIG_ARM_HAS_SG_CHAIN -#define ARCH_HAS_SG_CHAIN -#endif - -#include -#include -#include - -#endif /* _ASMARM_SCATTERLIST_H */ diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 27bbcfc..f2f95f4 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -2,6 +2,7 @@ config ARM64 def_bool y select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select ARCH_USE_CMPXCHG_LOCKREF + select ARCH_HAS_SG_CHAIN select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_WANT_OPTIONAL_GPIOLIB select ARCH_WANT_COMPAT_IPC_PARSE_VERSION diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 0c8e553..13e2e8b 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -44,6 +44,7 @@ config IA64 select HAVE_MOD_ARCH_SPECIFIC select MODULES_USE_ELF_RELA select ARCH_USE_CMPXCHG_LOCKREF + select ARCH_HAS_SG_CHAIN default y help The Itanium Processor Family is Intel's 64-bit successor to diff --git a/arch/ia64/include/asm/Kbuild b/arch/ia64/include/asm/Kbuild index 283a831..3906865 100644 --- a/arch/ia64/include/asm/Kbuild +++ b/arch/ia64/include/asm/Kbuild @@ -2,6 +2,7 @@ generic-y += clkdev.h generic-y += exec.h generic-y += kvm_para.h +generic-y += scatterlist.h generic-y += trace_clock.h generic-y += preempt.h generic-y += vtime.h diff --git a/arch/ia64/include/asm/scatterlist.h b/arch/ia64/include/asm/scatterlist.h deleted file mode 100644 index 08fd93b..000 --- a/arch/ia64/include/asm/scatterlist.h +++ /dev/null @@ -1,7 +0,0 @@ -#ifndef _ASM_IA64_SCATTERLIST_H -#define _ASM_IA64_SCATTERLIST_H - -#include -#define ARCH_HAS_SG_CHAIN - -#endif /* _ASM_IA64_SCATTERLIST_H */ diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 957bf34..659aee2 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -141,6 +141,7 @@ config PPC select HAVE_DEBUG_STACKOVERFLOW select HAVE_IRQ_EXIT_ON_IRQ_STACK select ARCH_USE_CMPXCHG_LOCKREF if PPC64 + select ARCH_HAS_SG_CHAIN config GENERIC_CSUM def_bool CPU_LITTLE_ENDIAN
