[PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Zong Li]

These patches resolve the some issues of loadable module.
  - symbol out of ranges
  - unknown relocation types

The reference of external variable and function symbols
cannot exceed 32-bit offset ranges in kernel module.
The module only can work on the 32-bit OS or the 64-bit
OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and
.plt sections during loading module, let it can refer
to the symbol which locate more than 32-bit offset.
These sections depend on the relocation types:
 - R_RISCV_GOT_HI20
 - R_RISCV_CALL_PLT

These patches also support more relocation types
 - R_RISCV_CALL
 - R_RISCV_HI20
 - R_RISCV_LO12_I
 - R_RISCV_LO12_S
 - R_RISCV_RVC_BRANCH
 - R_RISCV_RVC_JUMP
 - R_RISCV_ALIGN
 - R_RISCV_ADD32
 - R_RISCV_SUB32

Zong Li (11):
  RISC-V: Add sections of PLT and GOT for kernel module
  RISC-V: Add section of GOT.PLT for kernel module
  RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
  RISC-V: Support CALL relocation type in kernel module
  RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
  RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
  RISC-V: Support ALIGN relocation type in kernel module
  RISC-V: Support ADD32 relocation type in kernel module
  RISC-V: Support SUB32 relocation type in kernel module
  RISC-V: Enable module support in defconfig
  RISC-V: Add definition of relocation types

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

-- 
2.16.1

[PATCH 01/11] RISC-V: Add sections of PLT and GOT for kernel module

[Zong Li]

The address of external symbols will locate more than 32-bit offset
in 64-bit kernel with sv39 or sv48 virtual addressing.

Module loader emits the GOT and PLT entries for data symbols and
function symbols respectively.

The PLT entry is a trampoline code for jumping to the 64-bit
real address. The GOT entry is just the data symbol address.

Signed-off-by: Zong Li <zong@andestech.com>
---
 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/include/asm/module.h     | 102 ++++++++++++++++++++++++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 139 ++++++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.lds        |   7 ++
 6 files changed, 257 insertions(+)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 310b9a5d6737..e2ff7c23dfe0 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -135,6 +135,9 @@ choice
 		bool "medium any code model"
 endchoice
 
+config MODULE_SECTIONS
+	bool "Support GOT and PLT sections"
+
 choice
 	prompt "Maximum Physical Memory"
 	default MAXPHYSMEM_2GB if 32BIT
@@ -145,6 +148,8 @@ choice
 		bool "2GiB"
 	config MAXPHYSMEM_128GB
 		depends on 64BIT && CMODEL_MEDANY
+		select MODULE_SECTIONS if MODULES
+		select HAVE_MOD_ARCH_SPECIFIC
 		bool "128GiB"
 endchoice
 
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 26892daefa05..d8b4e5c9277f 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -56,6 +56,9 @@ endif
 ifeq ($(CONFIG_CMODEL_MEDANY),y)
 	KBUILD_CFLAGS += -mcmodel=medany
 endif
+ifeq ($(CONFIG_MODULE_SECTIONS),y)
+	KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/riscv/kernel/module.lds
+endif
 
 # GCC versions that support the "-mstrict-align" option default to allowing
 # unaligned accesses.  While unaligned accesses are explicitly allowed in the
diff --git a/arch/riscv/include/asm/module.h b/arch/riscv/include/asm/module.h
new file mode 100644
index 000000000000..bcc48d113deb
--- /dev/null
+++ b/arch/riscv/include/asm/module.h
@@ -0,0 +1,102 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2017 Andes Technology Corporation */
+
+#ifndef _ASM_RISCV_MODULE_H
+#define _ASM_RISCV_MODULE_H
+
+#include <asm-generic/module.h>
+
+#define MODULE_ARCH_VERMAGIC    "riscv"
+
+#ifdef CONFIG_MODULE_SECTIONS
+struct mod_section {
+	struct elf64_shdr *shdr;
+	int num_entries;
+	int max_entries;
+};
+
+struct mod_arch_specific {
+	struct mod_section got;
+	struct mod_section plt;
+};
+#endif
+
+u64 module_emit_got_entry(struct module *mod, u64 val);
+u64 module_emit_plt_entry(struct module *mod, u64 val);
+
+struct got_entry {
+	u64 symbol_addr;	/* the real variable address */
+};
+
+static inline struct got_entry emit_got_entry(u64 val)
+{
+	return (struct got_entry) {val};
+}
+
+static inline struct got_entry *get_got_entry(u64 val,
+					      const struct mod_section *sec)
+{
+	struct got_entry *got = (struct got_entry *)sec->shdr->sh_addr;
+	int i;
+	for (i = 0; i < sec->num_entries; i++) {
+		if (got[i].symbol_addr == val)
+			return &got[i];
+	}
+	return NULL;
+}
+
+struct plt_entry {
+	/*
+	 * Trampoline code to real target address. The return address
+	 * should be the original (pc+4) before entring plt entry.
+	 * For 8 byte alignment of symbol_addr,
+	 * don't pack structure to remove the padding.
+	 */
+	u32 insn_auipc;		/* auipc t0, 0x0                       */
+	u32 insn_ld;		/* ld    t1, 0x10(t0)                  */
+	u32 insn_jr;		/* jr    t1                            */
+	u64 symbol_addr;	/* the real jump target address        */
+};
+
+#define OPC_AUIPC  0x0017
+#define OPC_LD     0x3003
+#define OPC_JALR   0x0067
+#define REG_T0     0x5
+#define REG_T1     0x6
+#define IMM_OFFSET 0x10
+
+static inline struct plt_entry emit_plt_entry(u64 val)
+{
+	/*
+	 * U-Type encoding:
+	 * +------------+----------+----------+
+	 * | imm[31:12] | rd[11:7] | opc[6:0] |
+	 * +------------+----------+----------+
+	 *
+	 * I-Type encoding:
+	 * +------------+------------+--------+----------+----------+
+	 * | imm[31:20] | rs1[19:15] | funct3 | rd[11:7] | opc[6:0] |
+	 * +------------+------------+--------+----------+----------+
+	 *
+	 */
+	return (struct plt_entry) {
+		OPC_AUIPC | (REG_T0 << 7),
+		OPC_LD | (IMM_OFFSET << 20) | (REG_T0 << 15) | (REG_T1 << 7),
+		OPC_JALR | (REG_T1 << 15),
+		val
+	};
+}
+
+static inline struct plt_entry *get_plt_entry(u64 val,
+					      const struct mod_section *sec)
+{
+	struct plt_entry *plt = (struct plt_entry *)sec->shdr->sh_addr;
+	int i;
+	for (i = 0; i < sec->num_entries; i++) {
+		if (plt[i].symbol_addr == val)
+			return &plt[i];
+	}
+	return NULL;
+}
+
+#endif /* _ASM_RISCV_MODULE_H */
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index 196f62ffc428..d355e3c18278 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -34,6 +34,7 @@ CFLAGS_setup.o := -mcmodel=medany
 obj-$(CONFIG_SMP)		+= smpboot.o
 obj-$(CONFIG_SMP)		+= smp.o
 obj-$(CONFIG_MODULES)		+= module.o
+obj-$(CONFIG_MODULE_SECTIONS)	+= module-sections.o
 obj-$(CONFIG_FUNCTION_TRACER)	+= mcount.o
 obj-$(CONFIG_FUNCTION_GRAPH_TRACER)	+= ftrace.o
 
diff --git a/arch/riscv/kernel/module-sections.c b/arch/riscv/kernel/module-sections.c
new file mode 100644
index 000000000000..94ba1551eac3
--- /dev/null
+++ b/arch/riscv/kernel/module-sections.c
@@ -0,0 +1,139 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (C) 2014-2017 Linaro Ltd. <ard.biesheuvel@linaro.org>
+ *
+ * Copyright (C) 2018 Andes Technology Corporation <zong@andestech.com>
+ */
+
+#include <linux/elf.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+u64 module_emit_got_entry(struct module *mod, u64 val)
+{
+	struct mod_section *got_sec = &mod->arch.got;
+	int i = got_sec->num_entries;
+	struct got_entry *got = get_got_entry(val, got_sec);
+
+	if (got)
+		return (u64)got;
+
+	/* There is no duplicate entry, create a new one */
+	got = (struct got_entry *)got_sec->shdr->sh_addr;
+	got[i] = emit_got_entry(val);
+
+	got_sec->num_entries++;
+	BUG_ON(got_sec->num_entries > got_sec->max_entries);
+
+	return (u64)&got[i];
+}
+
+u64 module_emit_plt_entry(struct module *mod, u64 val)
+{
+	struct mod_section *plt_sec = &mod->arch.plt;
+	struct plt_entry *plt = get_plt_entry(val, plt_sec);
+	int i = plt_sec->num_entries;
+
+	if (plt)
+		return (u64)plt;
+
+	/* There is no duplicate entry, create a new one */
+	plt = (struct plt_entry *)plt_sec->shdr->sh_addr;
+	plt[i] = emit_plt_entry(val);
+
+	plt_sec->num_entries++;
+	BUG_ON(plt_sec->num_entries > plt_sec->max_entries);
+
+	return (u64)&plt[i];
+}
+
+static int is_rela_equal(const Elf64_Rela *x, const Elf64_Rela *y)
+{
+	return x->r_info == y->r_info && x->r_addend == y->r_addend;
+}
+
+static bool duplicate_rela(const Elf64_Rela *rela, int idx)
+{
+	int i;
+	for (i = 0; i < idx; i++) {
+		if (is_rela_equal(&rela[i], &rela[idx]))
+			return true;
+	}
+	return false;
+}
+
+static void count_max_entries(Elf64_Rela *relas, int num,
+			      unsigned int *plts, unsigned int *gots)
+{
+	unsigned int type, i;
+
+	for (i = 0; i < num; i++) {
+		type = ELF64_R_TYPE(relas[i].r_info);
+		if (type == R_RISCV_CALL_PLT) {
+			if (!duplicate_rela(relas, i))
+				(*plts)++;
+		} else if (type == R_RISCV_GOT_HI20) {
+			if (!duplicate_rela(relas, i))
+				(*gots)++;
+		}
+	}
+}
+
+int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
+			      char *secstrings, struct module *mod)
+{
+	unsigned int num_plts = 0;
+	unsigned int num_gots = 0;
+	int i;
+
+	/*
+	 * Find the empty .got and .plt sections.
+	 */
+	for (i = 0; i < ehdr->e_shnum; i++) {
+		if (!strcmp(secstrings + sechdrs[i].sh_name, ".plt"))
+			mod->arch.plt.shdr = sechdrs + i;
+		else if (!strcmp(secstrings + sechdrs[i].sh_name, ".got"))
+			mod->arch.got.shdr = sechdrs + i;
+	}
+
+	if (!mod->arch.plt.shdr) {
+		pr_err("%s: module PLT section(s) missing\n", mod->name);
+		return -ENOEXEC;
+	}
+	if (!mod->arch.got.shdr) {
+		pr_err("%s: module GOT section(s) missing\n", mod->name);
+		return -ENOEXEC;
+	}
+
+	/* Calculate the maxinum number of entries */
+	for (i = 0; i < ehdr->e_shnum; i++) {
+		Elf64_Rela *relas = (void *)ehdr + sechdrs[i].sh_offset;
+		int num_rela = sechdrs[i].sh_size / sizeof(Elf64_Rela);
+		Elf64_Shdr *dst_sec = sechdrs + sechdrs[i].sh_info;
+
+		if (sechdrs[i].sh_type != SHT_RELA)
+			continue;
+
+		/* ignore relocations that operate on non-exec sections */
+		if (!(dst_sec->sh_flags & SHF_EXECINSTR))
+			continue;
+
+		count_max_entries(relas, num_rela, &num_plts, &num_gots);
+	}
+
+	mod->arch.plt.shdr->sh_type = SHT_NOBITS;
+	mod->arch.plt.shdr->sh_flags = SHF_EXECINSTR | SHF_ALLOC;
+	mod->arch.plt.shdr->sh_addralign = L1_CACHE_BYTES;
+	mod->arch.plt.shdr->sh_size = (num_plts + 1) * sizeof(struct plt_entry);
+	mod->arch.plt.num_entries = 0;
+	mod->arch.plt.max_entries = num_plts;
+
+	mod->arch.got.shdr->sh_type = SHT_NOBITS;
+	mod->arch.got.shdr->sh_flags = SHF_ALLOC;
+	mod->arch.got.shdr->sh_addralign = L1_CACHE_BYTES;
+	mod->arch.got.shdr->sh_size = (num_gots + 1) * sizeof(struct got_entry);
+	mod->arch.got.num_entries = 0;
+	mod->arch.got.max_entries = num_gots;
+
+	return 0;
+}
diff --git a/arch/riscv/kernel/module.lds b/arch/riscv/kernel/module.lds
new file mode 100644
index 000000000000..7ef580e62883
--- /dev/null
+++ b/arch/riscv/kernel/module.lds
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2017 Andes Technology Corporation */
+
+SECTIONS {
+	.plt (NOLOAD) : { BYTE(0) }
+	.got (NOLOAD) : { BYTE(0) }
+}
-- 
2.16.1

Re: [PATCH 01/11] RISC-V: Add sections of PLT and GOT for kernel module

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 2601 bytes --]

Hi Zong,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5 next-20180314]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Zong-Li/RISC-V-Resolve-the-issue-of-loadable-module-on-64-bit/20180314-203750
config: riscv-defconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=riscv 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/module.h:25:0,
                    from fs/notify/fsnotify.c:23:
>> arch/riscv/include/asm/module.h:37:25: warning: 'struct mod_section' declared inside parameter list will not be visible outside of this definition or declaration
               const struct mod_section *sec)
                            ^~~~~~~~~~~
   arch/riscv/include/asm/module.h: In function 'get_got_entry':
>> arch/riscv/include/asm/module.h:39:49: error: dereferencing pointer to incomplete type 'const struct mod_section'
     struct got_entry *got = (struct got_entry *)sec->shdr->sh_addr;
                                                    ^~
   arch/riscv/include/asm/module.h: At top level:
   arch/riscv/include/asm/module.h:91:25: warning: 'struct mod_section' declared inside parameter list will not be visible outside of this definition or declaration
               const struct mod_section *sec)
                            ^~~~~~~~~~~
   arch/riscv/include/asm/module.h: In function 'get_plt_entry':
   arch/riscv/include/asm/module.h:93:49: error: dereferencing pointer to incomplete type 'const struct mod_section'
     struct plt_entry *plt = (struct plt_entry *)sec->shdr->sh_addr;
                                                    ^~

vim +39 arch/riscv/include/asm/module.h

    35	
    36	static inline struct got_entry *get_got_entry(u64 val,
  > 37						      const struct mod_section *sec)
    38	{
  > 39		struct got_entry *got = (struct got_entry *)sec->shdr->sh_addr;
    40		int i;
    41		for (i = 0; i < sec->num_entries; i++) {
    42			if (got[i].symbol_addr == val)
    43				return &got[i];
    44		}
    45		return NULL;
    46	}
    47	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 16430 bytes --]

[PATCH 02/11] RISC-V: Add section of GOT.PLT for kernel module

[Zong Li]

Separate the function symbol address from .plt to .got.plt section.

The original plt entry has trampoline code with symbol address,
there is a 32-bit padding bwtween jar instruction and symbol address.

Extract the symbol address to .got.plt to reduce the module size.

Signed-off-by: Zong Li <zong@andestech.com>
---
 arch/riscv/include/asm/module.h     | 40 +++++++++++++++++++++++--------------
 arch/riscv/kernel/module-sections.c | 21 +++++++++++++++++--
 arch/riscv/kernel/module.lds        |  1 +
 3 files changed, 45 insertions(+), 17 deletions(-)

diff --git a/arch/riscv/include/asm/module.h b/arch/riscv/include/asm/module.h
index bcc48d113deb..016e6a618e83 100644
--- a/arch/riscv/include/asm/module.h
+++ b/arch/riscv/include/asm/module.h
@@ -18,6 +18,7 @@ struct mod_section {
 struct mod_arch_specific {
 	struct mod_section got;
 	struct mod_section plt;
+	struct mod_section got_plt;
 };
 #endif
 
@@ -49,13 +50,10 @@ struct plt_entry {
 	/*
 	 * Trampoline code to real target address. The return address
 	 * should be the original (pc+4) before entring plt entry.
-	 * For 8 byte alignment of symbol_addr,
-	 * don't pack structure to remove the padding.
 	 */
 	u32 insn_auipc;		/* auipc t0, 0x0                       */
 	u32 insn_ld;		/* ld    t1, 0x10(t0)                  */
 	u32 insn_jr;		/* jr    t1                            */
-	u64 symbol_addr;	/* the real jump target address        */
 };
 
 #define OPC_AUIPC  0x0017
@@ -63,9 +61,8 @@ struct plt_entry {
 #define OPC_JALR   0x0067
 #define REG_T0     0x5
 #define REG_T1     0x6
-#define IMM_OFFSET 0x10
 
-static inline struct plt_entry emit_plt_entry(u64 val)
+static inline struct plt_entry emit_plt_entry(u64 val, u64 plt, u64 got_plt)
 {
 	/*
 	 * U-Type encoding:
@@ -79,24 +76,37 @@ static inline struct plt_entry emit_plt_entry(u64 val)
 	 * +------------+------------+--------+----------+----------+
 	 *
 	 */
+	u64 offset = got_plt - plt;
+	u32 hi20 = (offset + 0x800) & 0xfffff000;
+	u32 lo12 = (offset - hi20);
 	return (struct plt_entry) {
-		OPC_AUIPC | (REG_T0 << 7),
-		OPC_LD | (IMM_OFFSET << 20) | (REG_T0 << 15) | (REG_T1 << 7),
-		OPC_JALR | (REG_T1 << 15),
-		val
+		OPC_AUIPC | (REG_T0 << 7) | hi20,
+		OPC_LD | (lo12 << 20) | (REG_T0 << 15) | (REG_T1 << 7),
+		OPC_JALR | (REG_T1 << 15)
 	};
 }
 
-static inline struct plt_entry *get_plt_entry(u64 val,
-					      const struct mod_section *sec)
+static inline int get_got_plt_idx(u64 val, const struct mod_section *sec)
 {
-	struct plt_entry *plt = (struct plt_entry *)sec->shdr->sh_addr;
+	struct got_entry *got_plt = (struct got_entry *)sec->shdr->sh_addr;
 	int i;
 	for (i = 0; i < sec->num_entries; i++) {
-		if (plt[i].symbol_addr == val)
-			return &plt[i];
+		if (got_plt[i].symbol_addr == val)
+			return i;
 	}
-	return NULL;
+	return -1;
+}
+
+static inline struct plt_entry *get_plt_entry(u64 val,
+				      const struct mod_section *sec_plt,
+				      const struct mod_section *sec_got_plt)
+{
+	struct plt_entry *plt = (struct plt_entry *)sec_plt->shdr->sh_addr;
+	int got_plt_idx = get_got_plt_idx(val, sec_got_plt);
+	if (got_plt_idx >= 0)
+		return plt + got_plt_idx;
+	else
+		return NULL;
 }
 
 #endif /* _ASM_RISCV_MODULE_H */
diff --git a/arch/riscv/kernel/module-sections.c b/arch/riscv/kernel/module-sections.c
index 94ba1551eac3..bbbd26e19bfd 100644
--- a/arch/riscv/kernel/module-sections.c
+++ b/arch/riscv/kernel/module-sections.c
@@ -30,18 +30,23 @@ u64 module_emit_got_entry(struct module *mod, u64 val)
 
 u64 module_emit_plt_entry(struct module *mod, u64 val)
 {
+	struct mod_section *got_plt_sec = &mod->arch.got_plt;
+	struct got_entry *got_plt;
 	struct mod_section *plt_sec = &mod->arch.plt;
-	struct plt_entry *plt = get_plt_entry(val, plt_sec);
+	struct plt_entry *plt = get_plt_entry(val, plt_sec, got_plt_sec);
 	int i = plt_sec->num_entries;
 
 	if (plt)
 		return (u64)plt;
 
 	/* There is no duplicate entry, create a new one */
+	got_plt = (struct got_entry *)got_plt_sec->shdr->sh_addr;
+	got_plt[i] = emit_got_entry(val);
 	plt = (struct plt_entry *)plt_sec->shdr->sh_addr;
-	plt[i] = emit_plt_entry(val);
+	plt[i] = emit_plt_entry(val, (u64)&plt[i], (u64)&got_plt[i]);
 
 	plt_sec->num_entries++;
+	got_plt_sec->num_entries++;
 	BUG_ON(plt_sec->num_entries > plt_sec->max_entries);
 
 	return (u64)&plt[i];
@@ -94,6 +99,8 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
 			mod->arch.plt.shdr = sechdrs + i;
 		else if (!strcmp(secstrings + sechdrs[i].sh_name, ".got"))
 			mod->arch.got.shdr = sechdrs + i;
+		else if (!strcmp(secstrings + sechdrs[i].sh_name, ".got.plt"))
+			mod->arch.got_plt.shdr = sechdrs + i;
 	}
 
 	if (!mod->arch.plt.shdr) {
@@ -104,6 +111,10 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
 		pr_err("%s: module GOT section(s) missing\n", mod->name);
 		return -ENOEXEC;
 	}
+	if (!mod->arch.got_plt.shdr) {
+		pr_err("%s: module GOT.PLT section(s) missing\n", mod->name);
+		return -ENOEXEC;
+	}
 
 	/* Calculate the maxinum number of entries */
 	for (i = 0; i < ehdr->e_shnum; i++) {
@@ -135,5 +146,11 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
 	mod->arch.got.num_entries = 0;
 	mod->arch.got.max_entries = num_gots;
 
+	mod->arch.got_plt.shdr->sh_type = SHT_NOBITS;
+	mod->arch.got_plt.shdr->sh_flags = SHF_ALLOC;
+	mod->arch.got_plt.shdr->sh_addralign = L1_CACHE_BYTES;
+	mod->arch.got_plt.shdr->sh_size = (num_plts + 1) * sizeof(struct got_entry);
+	mod->arch.got_plt.num_entries = 0;
+	mod->arch.got_plt.max_entries = num_plts;
 	return 0;
 }
diff --git a/arch/riscv/kernel/module.lds b/arch/riscv/kernel/module.lds
index 7ef580e62883..295ecfb341a2 100644
--- a/arch/riscv/kernel/module.lds
+++ b/arch/riscv/kernel/module.lds
@@ -4,4 +4,5 @@
 SECTIONS {
 	.plt (NOLOAD) : { BYTE(0) }
 	.got (NOLOAD) : { BYTE(0) }
+	.got.plt (NOLOAD) : { BYTE(0) }
 }
-- 
2.16.1

Re: [PATCH 02/11] RISC-V: Add section of GOT.PLT for kernel module

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 3941 bytes --]

Hi Zong,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5 next-20180314]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Zong-Li/RISC-V-Resolve-the-issue-of-loadable-module-on-64-bit/20180314-203750
config: riscv-defconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=riscv 

All errors (new ones prefixed by >>):

   In file included from include/linux/module.h:25:0,
                    from fs/notify/fsnotify.c:23:
   arch/riscv/include/asm/module.h:38:25: warning: 'struct mod_section' declared inside parameter list will not be visible outside of this definition or declaration
               const struct mod_section *sec)
                            ^~~~~~~~~~~
   arch/riscv/include/asm/module.h: In function 'get_got_entry':
   arch/riscv/include/asm/module.h:40:49: error: dereferencing pointer to incomplete type 'const struct mod_section'
     struct got_entry *got = (struct got_entry *)sec->shdr->sh_addr;
                                                    ^~
   arch/riscv/include/asm/module.h: At top level:
   arch/riscv/include/asm/module.h:89:57: warning: 'struct mod_section' declared inside parameter list will not be visible outside of this definition or declaration
    static inline int get_got_plt_idx(u64 val, const struct mod_section *sec)
                                                            ^~~~~~~~~~~
   arch/riscv/include/asm/module.h: In function 'get_got_plt_idx':
   arch/riscv/include/asm/module.h:91:53: error: dereferencing pointer to incomplete type 'const struct mod_section'
     struct got_entry *got_plt = (struct got_entry *)sec->shdr->sh_addr;
                                                        ^~
   arch/riscv/include/asm/module.h: At top level:
   arch/riscv/include/asm/module.h:101:24: warning: 'struct mod_section' declared inside parameter list will not be visible outside of this definition or declaration
              const struct mod_section *sec_plt,
                           ^~~~~~~~~~~
   arch/riscv/include/asm/module.h: In function 'get_plt_entry':
   arch/riscv/include/asm/module.h:104:53: error: dereferencing pointer to incomplete type 'const struct mod_section'
     struct plt_entry *plt = (struct plt_entry *)sec_plt->shdr->sh_addr;
                                                        ^~
>> arch/riscv/include/asm/module.h:105:41: error: passing argument 2 of 'get_got_plt_idx' from incompatible pointer type [-Werror=incompatible-pointer-types]
     int got_plt_idx = get_got_plt_idx(val, sec_got_plt);
                                            ^~~~~~~~~~~
   arch/riscv/include/asm/module.h:89:19: note: expected 'const struct mod_section *' but argument is of type 'const struct mod_section *'
    static inline int get_got_plt_idx(u64 val, const struct mod_section *sec)
                      ^~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors

vim +/get_got_plt_idx +105 arch/riscv/include/asm/module.h

    99	
   100	static inline struct plt_entry *get_plt_entry(u64 val,
 > 101					      const struct mod_section *sec_plt,
   102					      const struct mod_section *sec_got_plt)
   103	{
   104		struct plt_entry *plt = (struct plt_entry *)sec_plt->shdr->sh_addr;
 > 105		int got_plt_idx = get_got_plt_idx(val, sec_got_plt);
   106		if (got_plt_idx >= 0)
   107			return plt + got_plt_idx;
   108		else
   109			return NULL;
   110	}
   111	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 16430 bytes --]

Re: [PATCH 02/11] RISC-V: Add section of GOT.PLT for kernel module

[Zong Li]

2018-03-15 1:34 GMT+08:00 kbuild test robot <lkp@intel.com>:
> Hi Zong,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.16-rc5 next-20180314]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url:    https://github.com/0day-ci/linux/commits/Zong-Li/RISC-V-Resolve-the-issue-of-loadable-module-on-64-bit/20180314-203750
> config: riscv-defconfig (attached as .config)
> compiler: riscv64-linux-gcc (GCC) 7.2.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         make.cross ARCH=riscv
>
> All errors (new ones prefixed by >>):
>
>    In file included from include/linux/module.h:25:0,
>                     from fs/notify/fsnotify.c:23:
>    arch/riscv/include/asm/module.h:38:25: warning: 'struct mod_section' declared inside parameter list will not be visible outside of this definition or declaration
>                const struct mod_section *sec)
>                             ^~~~~~~~~~~
>    arch/riscv/include/asm/module.h: In function 'get_got_entry':
>    arch/riscv/include/asm/module.h:40:49: error: dereferencing pointer to incomplete type 'const struct mod_section'
>      struct got_entry *got = (struct got_entry *)sec->shdr->sh_addr;
>                                                     ^~
>    arch/riscv/include/asm/module.h: At top level:
>    arch/riscv/include/asm/module.h:89:57: warning: 'struct mod_section' declared inside parameter list will not be visible outside of this definition or declaration
>     static inline int get_got_plt_idx(u64 val, const struct mod_section *sec)
>                                                             ^~~~~~~~~~~
>    arch/riscv/include/asm/module.h: In function 'get_got_plt_idx':
>    arch/riscv/include/asm/module.h:91:53: error: dereferencing pointer to incomplete type 'const struct mod_section'
>      struct got_entry *got_plt = (struct got_entry *)sec->shdr->sh_addr;
>                                                         ^~
>    arch/riscv/include/asm/module.h: At top level:
>    arch/riscv/include/asm/module.h:101:24: warning: 'struct mod_section' declared inside parameter list will not be visible outside of this definition or declaration
>               const struct mod_section *sec_plt,
>                            ^~~~~~~~~~~
>    arch/riscv/include/asm/module.h: In function 'get_plt_entry':
>    arch/riscv/include/asm/module.h:104:53: error: dereferencing pointer to incomplete type 'const struct mod_section'
>      struct plt_entry *plt = (struct plt_entry *)sec_plt->shdr->sh_addr;
>                                                         ^~
>>> arch/riscv/include/asm/module.h:105:41: error: passing argument 2 of 'get_got_plt_idx' from incompatible pointer type [-Werror=incompatible-pointer-types]
>      int got_plt_idx = get_got_plt_idx(val, sec_got_plt);
>                                             ^~~~~~~~~~~
>    arch/riscv/include/asm/module.h:89:19: note: expected 'const struct mod_section *' but argument is of type 'const struct mod_section *'
>     static inline int get_got_plt_idx(u64 val, const struct mod_section *sec)
>                       ^~~~~~~~~~~~~~~
>    cc1: some warnings being treated as errors
>
> vim +/get_got_plt_idx +105 arch/riscv/include/asm/module.h
>
>     99
>    100  static inline struct plt_entry *get_plt_entry(u64 val,
>  > 101                                        const struct mod_section *sec_plt,
>    102                                        const struct mod_section *sec_got_plt)
>    103  {
>    104          struct plt_entry *plt = (struct plt_entry *)sec_plt->shdr->sh_addr;
>  > 105          int got_plt_idx = get_got_plt_idx(val, sec_got_plt);
>    106          if (got_plt_idx >= 0)
>    107                  return plt + got_plt_idx;
>    108          else
>    109                  return NULL;
>    110  }
>    111
>
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

The config default is enable the MODULES, but also need to consider
the MODULES disable situation.
Modify the include/asm/module.h in PATCH v2

+u64 module_emit_got_entry(struct module *mod, u64 val);
+u64 module_emit_plt_entry(struct module *mod, u64 val);

 #ifdef CONFIG_MODULE_SECTIONS
 struct mod_section {
@@ -23,6 +21,10 @@ struct mod_arch_specific {
        struct mod_section plt;
        struct mod_section got_plt;
 };
-#endif

-u64 module_emit_got_entry(struct module *mod, u64 val);
-u64 module_emit_plt_entry(struct module *mod, u64 val);

 struct got_entry {
         u64 symbol_addr;        /* the real variable address */
@@ -108,6 +109,5 @@ static inline struct plt_entry *get_plt_entry(u64 val,
                 return NULL;
 }

+#endif /* CONFIG_MODULE_SECTIONS */

 #endif /* _ASM_RISCV_MODULE_H */

[PATCH 03/11] RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module

[Zong Li]

For CALL_PLT, emit the plt entry only when offset is more than 32-bit.

For PCREL_LO12, it uses the location of corresponding HI20 to
get the address of external symbol. It should check the HI20 type
is the PCREL_HI20 or GOT_HI20, because sometime the location will
have two or more relocation types.
For example:
0:   00000797                auipc   a5,0x0
                     0: R_RISCV_ALIGN        *ABS*
                     0: R_RISCV_GOT_HI20     SYMBOL
4:   0007b783                ld      a5,0(a5) # 0 <SYMBOL>
                     4: R_RISCV_PCREL_LO12_I .L0
                     4: R_RISCV_RELAX        *ABS*

Signed-off-by: Zong Li <zong@andestech.com>
---
 arch/riscv/kernel/module.c | 61 ++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 51 insertions(+), 10 deletions(-)

diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index e0f05034fc21..242d3a14c210 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -92,6 +92,28 @@ static int apply_r_riscv_pcrel_lo12_s_rela(struct module *me, u32 *location,
 	return 0;
 }
 
+static int apply_r_riscv_got_hi20_rela(struct module *me, u32 *location,
+				       Elf_Addr v)
+{
+	s64 offset = (void *)v - (void *)location;
+	s32 hi20;
+
+	/* Always emit the got entry */
+	if (IS_ENABLED(CONFIG_MODULE_SECTIONS)) {
+		offset = module_emit_got_entry(me, v);
+		offset = (void *)offset - (void *)location;
+	} else {
+		pr_err(
+		  "%s: can not generate the GOT entry for symbol = %016llx from PC = %p\n",
+		  me->name, v, location);
+		return -EINVAL;
+	}
+
+	hi20 = (offset + 0x800) & 0xfffff000;
+	*location = (*location & 0xfff) | hi20;
+	return 0;
+}
+
 static int apply_r_riscv_call_plt_rela(struct module *me, u32 *location,
 				       Elf_Addr v)
 {
@@ -100,10 +122,16 @@ static int apply_r_riscv_call_plt_rela(struct module *me, u32 *location,
 	u32 hi20, lo12;
 
 	if (offset != fill_v) {
-		pr_err(
-		  "%s: target %016llx can not be addressed by the 32-bit offset from PC = %p\n",
-		  me->name, v, location);
-		return -EINVAL;
+		/* Only emit the plt entry if offset over 32-bit range */
+		if (IS_ENABLED(CONFIG_MODULE_SECTIONS)) {
+			offset = module_emit_plt_entry(me, v);
+			offset = (void *)offset - (void *)location;
+		} else {
+			pr_err(
+			  "%s: target %016llx can not be addressed by the 32-bit offset from PC = %p\n",
+			  me->name, v, location);
+			return -EINVAL;
+		}
 	}
 
 	hi20 = (offset + 0x800) & 0xfffff000;
@@ -127,6 +155,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
 	[R_RISCV_PCREL_HI20]		= apply_r_riscv_pcrel_hi20_rela,
 	[R_RISCV_PCREL_LO12_I]		= apply_r_riscv_pcrel_lo12_i_rela,
 	[R_RISCV_PCREL_LO12_S]		= apply_r_riscv_pcrel_lo12_s_rela,
+	[R_RISCV_GOT_HI20]		= apply_r_riscv_got_hi20_rela,
 	[R_RISCV_CALL_PLT]		= apply_r_riscv_call_plt_rela,
 	[R_RISCV_RELAX]			= apply_r_riscv_relax_rela,
 };
@@ -184,25 +213,37 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
 				u64 hi20_loc =
 					sechdrs[sechdrs[relsec].sh_info].sh_addr
 					+ rel[j].r_offset;
-				/* Find the corresponding HI20 PC-relative relocation entry */
-				if (hi20_loc == sym->st_value) {
+				u32 hi20_type = ELF_RISCV_R_TYPE(rel[j].r_info);
+
+				/* Find the corresponding HI20 relocation entry */
+				if (hi20_loc == sym->st_value
+				    && (hi20_type == R_RISCV_PCREL_HI20
+					|| hi20_type == R_RISCV_GOT_HI20)) {
+					s32 hi20, lo12;
 					Elf_Sym *hi20_sym =
 						(Elf_Sym *)sechdrs[symindex].sh_addr
 						+ ELF_RISCV_R_SYM(rel[j].r_info);
 					u64 hi20_sym_val =
 						hi20_sym->st_value
 						+ rel[j].r_addend;
+
 					/* Calculate lo12 */
-					s64 offset = hi20_sym_val - hi20_loc;
-					s32 hi20 = (offset + 0x800) & 0xfffff000;
-					s32 lo12 = offset - hi20;
+					u64 offset = hi20_sym_val - hi20_loc;
+					if (hi20_type == R_RISCV_GOT_HI20) {
+						offset = module_emit_got_entry(
+							 me, hi20_sym_val);
+						offset = offset - hi20_loc;
+					}
+					hi20 = (offset + 0x800) & 0xfffff000;
+					lo12 = offset - hi20;
 					v = lo12;
+
 					break;
 				}
 			}
 			if (j == sechdrs[relsec].sh_size / sizeof(*rel)) {
 				pr_err(
-				  "%s: Can not find HI20 PC-relative relocation information\n",
+				  "%s: Can not find HI20 relocation information\n",
 				  me->name);
 				return -EINVAL;
 			}
-- 
2.16.1

[PATCH 04/11] RISC-V: Support CALL relocation type in kernel module

[Zong Li]

Signed-off-by: Zong Li <zong@andestech.com>
---
 arch/riscv/kernel/module.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 242d3a14c210..7e85e5840b4d 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -141,6 +141,27 @@ static int apply_r_riscv_call_plt_rela(struct module *me, u32 *location,
 	return 0;
 }
 
+static int apply_r_riscv_call_rela(struct module *me, u32 *location,
+				   Elf_Addr v)
+{
+	s64 offset = (void *)v - (void *)location;
+	s32 fill_v = offset;
+	u32 hi20, lo12;
+
+	if (offset != fill_v) {
+		pr_err(
+		  "%s: target %016llx can not be addressed by the 32-bit offset from PC = %p\n",
+		  me->name, v, location);
+		return -EINVAL;
+	}
+
+	hi20 = (offset + 0x800) & 0xfffff000;
+	lo12 = (offset - hi20) & 0xfff;
+	*location = (*location & 0xfff) | hi20;
+	*(location + 1) = (*(location + 1) & 0xfffff) | (lo12 << 20);
+	return 0;
+}
+
 static int apply_r_riscv_relax_rela(struct module *me, u32 *location,
 				    Elf_Addr v)
 {
@@ -157,6 +178,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
 	[R_RISCV_PCREL_LO12_S]		= apply_r_riscv_pcrel_lo12_s_rela,
 	[R_RISCV_GOT_HI20]		= apply_r_riscv_got_hi20_rela,
 	[R_RISCV_CALL_PLT]		= apply_r_riscv_call_plt_rela,
+	[R_RISCV_CALL]			= apply_r_riscv_call_rela,
 	[R_RISCV_RELAX]			= apply_r_riscv_relax_rela,
 };
 
-- 
2.16.1

[PATCH 05/11] RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module

[Zong Li]

HI20 and LO12_I/LO12_S relocate the absolute address, the range of
offset must in 32-bit.

Signed-off-by: Zong Li <zong@andestech.com>
---
 arch/riscv/kernel/module.c | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 7e85e5840b4d..654fe7dcd38d 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -92,6 +92,45 @@ static int apply_r_riscv_pcrel_lo12_s_rela(struct module *me, u32 *location,
 	return 0;
 }
 
+static int apply_r_riscv_hi20_rela(struct module *me, u32 *location,
+				   Elf_Addr v)
+{
+	s32 hi20;
+
+	if (IS_ENABLED(CMODEL_MEDLOW)) {
+		pr_err(
+		  "%s: target %016llx can not be addressed by the 32-bit offset from PC = %p\n",
+		  me->name, v, location);
+		return -EINVAL;
+	}
+
+	hi20 = ((s32)v + 0x800) & 0xfffff000;
+	*location = (*location & 0xfff) | hi20;
+	return 0;
+}
+
+static int apply_r_riscv_lo12_i_rela(struct module *me, u32 *location,
+				     Elf_Addr v)
+{
+	/* Skip medlow checking because of filtering by HI20 already */
+	s32 hi20 = ((s32)v + 0x800) & 0xfffff000;
+	s32 lo12 = ((s32)v - hi20);
+	*location = (*location & 0xfffff) | ((lo12 & 0xfff) << 20);
+	return 0;
+}
+
+static int apply_r_riscv_lo12_s_rela(struct module *me, u32 *location,
+				     Elf_Addr v)
+{
+	/* Skip medlow checking because of filtering by HI20 already */
+	s32 hi20 = ((s32)v + 0x800) & 0xfffff000;
+	s32 lo12 = ((s32)v - hi20);
+	u32 imm11_5 = (lo12 & 0xfe0) << (31 - 11);
+	u32 imm4_0 = (lo12 & 0x1f) << (11 - 4);
+	*location = (*location & 0x1fff07f) | imm11_5 | imm4_0;
+	return 0;
+}
+
 static int apply_r_riscv_got_hi20_rela(struct module *me, u32 *location,
 				       Elf_Addr v)
 {
@@ -176,6 +215,9 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
 	[R_RISCV_PCREL_HI20]		= apply_r_riscv_pcrel_hi20_rela,
 	[R_RISCV_PCREL_LO12_I]		= apply_r_riscv_pcrel_lo12_i_rela,
 	[R_RISCV_PCREL_LO12_S]		= apply_r_riscv_pcrel_lo12_s_rela,
+	[R_RISCV_HI20]			= apply_r_riscv_hi20_rela,
+	[R_RISCV_LO12_I]		= apply_r_riscv_lo12_i_rela,
+	[R_RISCV_LO12_S]		= apply_r_riscv_lo12_s_rela,
 	[R_RISCV_GOT_HI20]		= apply_r_riscv_got_hi20_rela,
 	[R_RISCV_CALL_PLT]		= apply_r_riscv_call_plt_rela,
 	[R_RISCV_CALL]			= apply_r_riscv_call_rela,
-- 
2.16.1

[PATCH 06/11] RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq

[Zong Li]

Signed-off-by: Zong Li <zong@andestech.com>
---
 arch/riscv/kernel/module.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 654fe7dcd38d..e23c051dfc62 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -49,6 +49,39 @@ static int apply_r_riscv_jal_rela(struct module *me, u32 *location,
 	return 0;
 }
 
+static int apply_r_riscv_rcv_branch_rela(struct module *me, u32 *location,
+					 Elf_Addr v)
+{
+	s64 offset = (void *)v - (void *)location;
+	u16 imm8 = (offset & 0x100) << (12 - 8);
+	u16 imm7_6 = (offset & 0xc0) >> (6 - 5);
+	u16 imm5 = (offset & 0x20) >> (5 - 2);
+	u16 imm4_3 = (offset & 0x18) << (12 - 5);
+	u16 imm2_1 = (offset & 0x6) << (12 - 10);
+
+	*(u16 *)location = (*(u16 *)location & 0xe383) |
+		    imm8 | imm7_6 | imm5 | imm4_3 | imm2_1;
+	return 0;
+}
+
+static int apply_r_riscv_rvc_jump_rela(struct module *me, u32 *location,
+				       Elf_Addr v)
+{
+	s64 offset = (void *)v - (void *)location;
+	u16 imm11 = (offset & 0x800) << (12 - 11);
+	u16 imm10 = (offset & 0x400) >> (10 - 8);
+	u16 imm9_8 = (offset & 0x300) << (12 - 11);
+	u16 imm7 = (offset & 0x80) >> (7 - 6);
+	u16 imm6 = (offset & 0x40) << (12 - 11);
+	u16 imm5 = (offset & 0x20) >> (5 - 2);
+	u16 imm4 = (offset & 0x10) << (12 - 5);
+	u16 imm3_1 = (offset & 0xe) << (12 - 10);
+
+	*(u16 *)location = (*(u16 *)location & 0xe003) |
+		    imm11 | imm10 | imm9_8 | imm7 | imm6 | imm5 | imm4 | imm3_1;
+	return 0;
+}
+
 static int apply_r_riscv_pcrel_hi20_rela(struct module *me, u32 *location,
 					 Elf_Addr v)
 {
@@ -212,6 +245,8 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
 	[R_RISCV_64]			= apply_r_riscv_64_rela,
 	[R_RISCV_BRANCH]		= apply_r_riscv_branch_rela,
 	[R_RISCV_JAL]			= apply_r_riscv_jal_rela,
+	[R_RISCV_RVC_BRANCH]		= apply_r_riscv_rcv_branch_rela,
+	[R_RISCV_RVC_JUMP]		= apply_r_riscv_rvc_jump_rela,
 	[R_RISCV_PCREL_HI20]		= apply_r_riscv_pcrel_hi20_rela,
 	[R_RISCV_PCREL_LO12_I]		= apply_r_riscv_pcrel_lo12_i_rela,
 	[R_RISCV_PCREL_LO12_S]		= apply_r_riscv_pcrel_lo12_s_rela,
-- 
2.16.1

[PATCH 07/11] RISC-V: Support ALIGN relocation type in kernel module

[Zong Li]

Just ignore align type. The nop instructions cannot be removed in
kernel module. Kernel modules is not doing relax.

Signed-off-by: Zong Li <zong@andestech.com>
---
 arch/riscv/kernel/module.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index e23c051dfc62..351bf2a518ee 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -240,6 +240,12 @@ static int apply_r_riscv_relax_rela(struct module *me, u32 *location,
 	return 0;
 }
 
+static int apply_r_riscv_align_rela(struct module *me, u32 *location,
+				    Elf_Addr v)
+{
+	return 0;
+}
+
 static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
 				Elf_Addr v) = {
 	[R_RISCV_64]			= apply_r_riscv_64_rela,
@@ -257,6 +263,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
 	[R_RISCV_CALL_PLT]		= apply_r_riscv_call_plt_rela,
 	[R_RISCV_CALL]			= apply_r_riscv_call_rela,
 	[R_RISCV_RELAX]			= apply_r_riscv_relax_rela,
+	[R_RISCV_ALIGN]			= apply_r_riscv_align_rela,
 };
 
 int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
-- 
2.16.1

[PATCH 08/11] RISC-V: Support ADD32 relocation type in kernel module

[Zong Li]

Signed-off-by: Zong Li <zong@andestech.com>
---
 arch/riscv/kernel/module.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 351bf2a518ee..2d14dff22861 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -246,6 +246,13 @@ static int apply_r_riscv_align_rela(struct module *me, u32 *location,
 	return 0;
 }
 
+static int apply_r_riscv_add32_rela(struct module *me, u32 *location,
+				    Elf_Addr v)
+{
+	*(u32 *)location += (*(u32 *)v);
+	return 0;
+}
+
 static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
 				Elf_Addr v) = {
 	[R_RISCV_64]			= apply_r_riscv_64_rela,
@@ -264,6 +271,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
 	[R_RISCV_CALL]			= apply_r_riscv_call_rela,
 	[R_RISCV_RELAX]			= apply_r_riscv_relax_rela,
 	[R_RISCV_ALIGN]			= apply_r_riscv_align_rela,
+	[R_RISCV_ADD32]			= apply_r_riscv_add32_rela,
 };
 
 int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
-- 
2.16.1

[PATCH 09/11] RISC-V: Support SUB32 relocation type in kernel module

[Zong Li]

Signed-off-by: Zong Li <zong@andestech.com>
---
 arch/riscv/kernel/module.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 2d14dff22861..4228270efe93 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -253,6 +253,13 @@ static int apply_r_riscv_add32_rela(struct module *me, u32 *location,
 	return 0;
 }
 
+static int apply_r_riscv_sub32_rela(struct module *me, u32 *location,
+				    Elf_Addr v)
+{
+	*(u32 *)location -= (*(u32 *)v);
+	return 0;
+}
+
 static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
 				Elf_Addr v) = {
 	[R_RISCV_64]			= apply_r_riscv_64_rela,
@@ -272,6 +279,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
 	[R_RISCV_RELAX]			= apply_r_riscv_relax_rela,
 	[R_RISCV_ALIGN]			= apply_r_riscv_align_rela,
 	[R_RISCV_ADD32]			= apply_r_riscv_add32_rela,
+	[R_RISCV_SUB32]			= apply_r_riscv_sub32_rela,
 };
 
 int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
-- 
2.16.1

[PATCH 10/11] RISC-V: Enable module support in defconfig

[Zong Li]

Signed-off-by: Zong Li <zong@andestech.com>
---
 arch/riscv/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 92ff23586c11..07326466871b 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -74,3 +74,5 @@ CONFIG_NFS_V4_2=y
 CONFIG_ROOT_NFS=y
 # CONFIG_RCU_TRACE is not set
 CONFIG_CRYPTO_USER_API_HASH=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
-- 
2.16.1

[PATCH 11/11] RISC-V: Add definition of relocation types

[Zong Li]

Signed-off-by: Zong Li <zong@andestech.com>
---
 arch/riscv/include/uapi/asm/elf.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/riscv/include/uapi/asm/elf.h b/arch/riscv/include/uapi/asm/elf.h
index a510edfa8226..5111c7c35e8b 100644
--- a/arch/riscv/include/uapi/asm/elf.h
+++ b/arch/riscv/include/uapi/asm/elf.h
@@ -79,5 +79,29 @@ typedef union __riscv_fp_state elf_fpregset_t;
 #define R_RISCV_TPREL_I		49
 #define R_RISCV_TPREL_S		50
 #define R_RISCV_RELAX		51
+#define R_RISCV_SUB6		52
+#define R_RISCV_SET6		53
+#define R_RISCV_SET8		54
+#define R_RISCV_SET16		55
+#define R_RISCV_SET32		56
+#define R_RISCV_32_PCREL	57
+
+/* NDS V5*/
+#define R_RISCV_ALIGN_BTB		240
+#define R_RISCV_10_PCREL		241
+#define R_RISCV_DATA			242
+#define R_RISCV_LALO_HI20		243
+#define R_RISCV_LALO_LO12_I		244
+#define R_RISCV_RELAX_ENTRY		245
+#define R_RISCV_LGP18S0			246
+#define R_RISCV_LGP17S1			247
+#define R_RISCV_LGP17S2			248
+#define R_RISCV_LGP17S3			249
+#define R_RISCV_SGP18S0			250
+#define R_RISCV_SGP17S1			251
+#define R_RISCV_SGP17S2			252
+#define R_RISCV_SGP17S3			253
+#define R_RISCV_RELAX_REGION_BEGIN	254
+#define R_RISCV_RELAX_REGION_END	255
 
 #endif /* _UAPI_ASM_ELF_H */
-- 
2.16.1

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Zong Li]

2018-03-13 16:35 GMT+08:00 Zong Li <zong@andestech.com>:
>
> These patches resolve the some issues of loadable module.
>   - symbol out of ranges
>   - unknown relocation types
>
> The reference of external variable and function symbols
> cannot exceed 32-bit offset ranges in kernel module.
> The module only can work on the 32-bit OS or the 64-bit
> OS with sv32 virtual addressing.
>
> These patches will generate the .got, .got.plt and
> .plt sections during loading module, let it can refer
> to the symbol which locate more than 32-bit offset.
> These sections depend on the relocation types:
>  - R_RISCV_GOT_HI20
>  - R_RISCV_CALL_PLT
>
> These patches also support more relocation types
>  - R_RISCV_CALL
>  - R_RISCV_HI20
>  - R_RISCV_LO12_I
>  - R_RISCV_LO12_S
>  - R_RISCV_RVC_BRANCH
>  - R_RISCV_RVC_JUMP
>  - R_RISCV_ALIGN
>  - R_RISCV_ADD32
>  - R_RISCV_SUB32
>
> Zong Li (11):
>   RISC-V: Add sections of PLT and GOT for kernel module
>   RISC-V: Add section of GOT.PLT for kernel module
>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>   RISC-V: Support CALL relocation type in kernel module
>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>   RISC-V: Support ALIGN relocation type in kernel module
>   RISC-V: Support ADD32 relocation type in kernel module
>   RISC-V: Support SUB32 relocation type in kernel module
>   RISC-V: Enable module support in defconfig
>   RISC-V: Add definition of relocation types
>
>  arch/riscv/Kconfig                  |   5 ++
>  arch/riscv/Makefile                 |   3 +
>  arch/riscv/configs/defconfig        |   2 +
>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>  arch/riscv/kernel/Makefile          |   1 +
>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>  arch/riscv/kernel/module.lds        |   8 ++
>  9 files changed, 480 insertions(+), 6 deletions(-)
>  create mode 100644 arch/riscv/include/asm/module.h
>  create mode 100644 arch/riscv/kernel/module-sections.c
>  create mode 100644 arch/riscv/kernel/module.lds
>
> --
> 2.16.1
>

This is the list of testing modules:

# lsmod
btrfs 7876158 0 - Live 0xffffffd00745d000
ramoops 90806 0 - Live 0xffffffd0024b8000
lzo 10554 0 - Live 0xffffffd002050000
zstd_decompress 567575 1 btrfs, Live 0xffffffd00238b000
zstd_compress 1543837 1 btrfs, Live 0xffffffd002211000
zram 101300 0 - Live 0xffffffd0021b8000
xxhash 62254 2 zstd_decompress,zstd_compress, Live 0xffffffd0020cf000
xor 33246 1 btrfs, Live 0xffffffd002042000
xfs 4395343 0 - Live 0xffffffd00399e000
tun 252041 0 - Live 0xffffffd0038e0000
test_user_copy 5265 0 - Live 0xffffffd003783000
test_static_keys 19606 0 - Live 0xffffffd003717000
test_static_key_base 7374 1 test_static_keys, Live 0xffffffd0036dc000
test_printf 7804 0 [permanent], Live 0xffffffd00369c000
test_module 1557 0 - Live 0xffffffd003646000
test_kmod 49100 0 - Live 0xffffffd0035f2000
test_bpf 1599301 0 - Live 0xffffffd003000000
test_bitmap 4403 0 - Live 0xffffffd002dd8000
reed_solomon 38866 1 ramoops, Live 0xffffffd002d86000
raid6_pq 161872 1 btrfs, Live 0xffffffd002b9e000
netdevsim 65401 0 - Live 0xffffffd002910000
lzo_decompress 9580 2 btrfs,lzo, Live 0xffffffd002813000
lzo_compress 21527 2 btrfs,lzo, Live 0xffffffd0027d9000
libcrc32c 2730 1 xfs, Live 0xffffffd00273c000
fuse 676371 0 - Live 0xffffffd0024d0000
exportfs 24850 1 xfs, Live 0xffffffd0020c7000
echainiv 11953 0 - Live 0xffffffd00205a000

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Palmer Dabbelt]

On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
> These patches resolve the some issues of loadable module.
>   - symbol out of ranges
>   - unknown relocation types
>
> The reference of external variable and function symbols
> cannot exceed 32-bit offset ranges in kernel module.
> The module only can work on the 32-bit OS or the 64-bit
> OS with sv32 virtual addressing.
>
> These patches will generate the .got, .got.plt and
> .plt sections during loading module, let it can refer
> to the symbol which locate more than 32-bit offset.
> These sections depend on the relocation types:
>  - R_RISCV_GOT_HI20
>  - R_RISCV_CALL_PLT
>
> These patches also support more relocation types
>  - R_RISCV_CALL
>  - R_RISCV_HI20
>  - R_RISCV_LO12_I
>  - R_RISCV_LO12_S
>  - R_RISCV_RVC_BRANCH
>  - R_RISCV_RVC_JUMP
>  - R_RISCV_ALIGN
>  - R_RISCV_ADD32
>  - R_RISCV_SUB32
>
> Zong Li (11):
>   RISC-V: Add sections of PLT and GOT for kernel module
>   RISC-V: Add section of GOT.PLT for kernel module
>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>   RISC-V: Support CALL relocation type in kernel module
>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>   RISC-V: Support ALIGN relocation type in kernel module
>   RISC-V: Support ADD32 relocation type in kernel module
>   RISC-V: Support SUB32 relocation type in kernel module
>   RISC-V: Enable module support in defconfig
>   RISC-V: Add definition of relocation types
>
>  arch/riscv/Kconfig                  |   5 ++
>  arch/riscv/Makefile                 |   3 +
>  arch/riscv/configs/defconfig        |   2 +
>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>  arch/riscv/kernel/Makefile          |   1 +
>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>  arch/riscv/kernel/module.lds        |   8 ++
>  9 files changed, 480 insertions(+), 6 deletions(-)
>  create mode 100644 arch/riscv/include/asm/module.h
>  create mode 100644 arch/riscv/kernel/module-sections.c
>  create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same
R_RISCV_ALIGN problem as the other one

    http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

It looks like this one uses shared libraries for modules instead of static
objects.  I think using shared objects is the right thing to do, as it'll allow
us to place modules anywhere in the address space by having multiple GOTs and
PLTs.  That's kind of complicated, though, so we can start with something
simpler like this.

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Shea Levy]

[-- Attachment #1: Type: text/plain, Size: 3150 bytes --]

Hi Palmer,

Palmer Dabbelt <palmer@sifive.com> writes:

> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>> These patches resolve the some issues of loadable module.
>>   - symbol out of ranges
>>   - unknown relocation types
>>
>> The reference of external variable and function symbols
>> cannot exceed 32-bit offset ranges in kernel module.
>> The module only can work on the 32-bit OS or the 64-bit
>> OS with sv32 virtual addressing.
>>
>> These patches will generate the .got, .got.plt and
>> .plt sections during loading module, let it can refer
>> to the symbol which locate more than 32-bit offset.
>> These sections depend on the relocation types:
>>  - R_RISCV_GOT_HI20
>>  - R_RISCV_CALL_PLT
>>
>> These patches also support more relocation types
>>  - R_RISCV_CALL
>>  - R_RISCV_HI20
>>  - R_RISCV_LO12_I
>>  - R_RISCV_LO12_S
>>  - R_RISCV_RVC_BRANCH
>>  - R_RISCV_RVC_JUMP
>>  - R_RISCV_ALIGN
>>  - R_RISCV_ADD32
>>  - R_RISCV_SUB32
>>
>> Zong Li (11):
>>   RISC-V: Add sections of PLT and GOT for kernel module
>>   RISC-V: Add section of GOT.PLT for kernel module
>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>   RISC-V: Support CALL relocation type in kernel module
>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>   RISC-V: Support ALIGN relocation type in kernel module
>>   RISC-V: Support ADD32 relocation type in kernel module
>>   RISC-V: Support SUB32 relocation type in kernel module
>>   RISC-V: Enable module support in defconfig
>>   RISC-V: Add definition of relocation types
>>
>>  arch/riscv/Kconfig                  |   5 ++
>>  arch/riscv/Makefile                 |   3 +
>>  arch/riscv/configs/defconfig        |   2 +
>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>  arch/riscv/kernel/Makefile          |   1 +
>>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>>  arch/riscv/kernel/module.lds        |   8 ++
>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>  create mode 100644 arch/riscv/include/asm/module.h
>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>  create mode 100644 arch/riscv/kernel/module.lds
>
> This is the second set of patches that turn on modules, and it has the same
> R_RISCV_ALIGN problem as the other one
>
>     http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>
> It looks like this one uses shared libraries for modules instead of static
> objects.  I think using shared objects is the right thing to do, as it'll allow
> us to place modules anywhere in the address space by having multiple GOTs and
> PLTs.

Can you expand on this? It was my understanding that outside of the
context of multiple address spaces sharing code the GOT and PLT were
simply unnecessary overhead, what benefit would they bring here?

> That's kind of complicated, though, so we can start with something
> simpler like this.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Zong Li]

2018-03-14 5:30 GMT+08:00 Shea Levy <shea@shealevy.com>:
> Hi Palmer,
>
> Palmer Dabbelt <palmer@sifive.com> writes:
>
>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>> These patches resolve the some issues of loadable module.
>>>   - symbol out of ranges
>>>   - unknown relocation types
>>>
>>> The reference of external variable and function symbols
>>> cannot exceed 32-bit offset ranges in kernel module.
>>> The module only can work on the 32-bit OS or the 64-bit
>>> OS with sv32 virtual addressing.
>>>
>>> These patches will generate the .got, .got.plt and
>>> .plt sections during loading module, let it can refer
>>> to the symbol which locate more than 32-bit offset.
>>> These sections depend on the relocation types:
>>>  - R_RISCV_GOT_HI20
>>>  - R_RISCV_CALL_PLT
>>>
>>> These patches also support more relocation types
>>>  - R_RISCV_CALL
>>>  - R_RISCV_HI20
>>>  - R_RISCV_LO12_I
>>>  - R_RISCV_LO12_S
>>>  - R_RISCV_RVC_BRANCH
>>>  - R_RISCV_RVC_JUMP
>>>  - R_RISCV_ALIGN
>>>  - R_RISCV_ADD32
>>>  - R_RISCV_SUB32
>>>
>>> Zong Li (11):
>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>   RISC-V: Support CALL relocation type in kernel module
>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>   RISC-V: Enable module support in defconfig
>>>   RISC-V: Add definition of relocation types
>>>
>>>  arch/riscv/Kconfig                  |   5 ++
>>>  arch/riscv/Makefile                 |   3 +
>>>  arch/riscv/configs/defconfig        |   2 +
>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>  arch/riscv/kernel/Makefile          |   1 +
>>>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>>>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>  create mode 100644 arch/riscv/kernel/module.lds
>>
>> This is the second set of patches that turn on modules, and it has the same
>> R_RISCV_ALIGN problem as the other one
>>
>>     http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>
>> It looks like this one uses shared libraries for modules instead of static
>> objects.  I think using shared objects is the right thing to do, as it'll allow
>> us to place modules anywhere in the address space by having multiple GOTs and
>> PLTs.
>
> Can you expand on this? It was my understanding that outside of the
> context of multiple address spaces sharing code the GOT and PLT were
> simply unnecessary overhead, what benefit would they bring here?
>
>> That's kind of complicated, though, so we can start with something
>> simpler like this.

Hi,

The kernel module is a object file, it is not be linked by linker, the
GOT and PLT
sections will not be generated through -fPIC option, but it will
generate the relative
relocation type. As Palmer mention before, If we have GOT and PLT sections,
we can put the module anywhere, even we support the KASLR in the kernel.

For the ALIGN problem, the kernel module loader is difficult to remove
or migrate
the module's code like relax doing, so the remnant nop instructions harm the
performance,  I agree the point that adding the mno-relax option and checking
the alignment in ALIGN type in module loader.

>> That's kind of complicated, though, so we can start with something
>> simpler like this.

So what is the suggestion for that.

Thanks a lot.

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Palmer Dabbelt]

On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zongbox@gmail.com wrote:
> 2018-03-14 5:30 GMT+08:00 Shea Levy <shea@shealevy.com>:
>> Hi Palmer,
>>
>> Palmer Dabbelt <palmer@sifive.com> writes:
>>
>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>>> These patches resolve the some issues of loadable module.
>>>>   - symbol out of ranges
>>>>   - unknown relocation types
>>>>
>>>> The reference of external variable and function symbols
>>>> cannot exceed 32-bit offset ranges in kernel module.
>>>> The module only can work on the 32-bit OS or the 64-bit
>>>> OS with sv32 virtual addressing.
>>>>
>>>> These patches will generate the .got, .got.plt and
>>>> .plt sections during loading module, let it can refer
>>>> to the symbol which locate more than 32-bit offset.
>>>> These sections depend on the relocation types:
>>>>  - R_RISCV_GOT_HI20
>>>>  - R_RISCV_CALL_PLT
>>>>
>>>> These patches also support more relocation types
>>>>  - R_RISCV_CALL
>>>>  - R_RISCV_HI20
>>>>  - R_RISCV_LO12_I
>>>>  - R_RISCV_LO12_S
>>>>  - R_RISCV_RVC_BRANCH
>>>>  - R_RISCV_RVC_JUMP
>>>>  - R_RISCV_ALIGN
>>>>  - R_RISCV_ADD32
>>>>  - R_RISCV_SUB32
>>>>
>>>> Zong Li (11):
>>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>>   RISC-V: Support CALL relocation type in kernel module
>>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>>   RISC-V: Enable module support in defconfig
>>>>   RISC-V: Add definition of relocation types
>>>>
>>>>  arch/riscv/Kconfig                  |   5 ++
>>>>  arch/riscv/Makefile                 |   3 +
>>>>  arch/riscv/configs/defconfig        |   2 +
>>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>>  arch/riscv/kernel/Makefile          |   1 +
>>>>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>>>>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>>  create mode 100644 arch/riscv/kernel/module.lds
>>>
>>> This is the second set of patches that turn on modules, and it has the same
>>> R_RISCV_ALIGN problem as the other one
>>>
>>>     http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>>
>>> It looks like this one uses shared libraries for modules instead of static
>>> objects.  I think using shared objects is the right thing to do, as it'll allow
>>> us to place modules anywhere in the address space by having multiple GOTs and
>>> PLTs.
>>
>> Can you expand on this? It was my understanding that outside of the
>> context of multiple address spaces sharing code the GOT and PLT were
>> simply unnecessary overhead, what benefit would they bring here?
>>
>>> That's kind of complicated, though, so we can start with something
>>> simpler like this.
>
> Hi,
>
> The kernel module is a object file, it is not be linked by linker, the
> GOT and PLT
> sections will not be generated through -fPIC option, but it will
> generate the relative
> relocation type. As Palmer mention before, If we have GOT and PLT sections,
> we can put the module anywhere, even we support the KASLR in the kernel.

Sorry, I guess I meant PIC objects not shared objects (I keep forgetting about
PIE).  We'll probably eventually add large code model targets, but they might
end up just being functionally equilivant to PIE with multi-GOT and multi-PLT
so it might not matter.

Either way, this is the sanest way to do it for now.

> For the ALIGN problem, the kernel module loader is difficult to remove
> or migrate
> the module's code like relax doing, so the remnant nop instructions harm the
> performance,  I agree the point that adding the mno-relax option and checking
> the alignment in ALIGN type in module loader.

Sounds good.  I just merged the mno-relax stuff, it'll show up when I get
around to generating a 7.3.0 backport branch.  For now I think you should just
fail on R_RISCV_ALIGN and attempt to pass -mno-relax to the compiler (via
something like "$(call cc-option,-mno-relax)", like we do for
"-mstrict-align").  I don't think it's worth handling R_RISCV_ALIGN in the
kernel, as that's essentially the same as full relaxation support.

>>> That's kind of complicated, though, so we can start with something
>>> simpler like this.
>
> So what is the suggestion for that.

Well, I'm not really sure -- essentially the idea of proper multi-GOT and
multi-PLT support would be to merge the GOTs and PLTs of modules together when
they're within range of each other.  We haven't even figured this out in
userspace yet, so it's probably not worth attempting for kernel modules for a
bit.

If I understand your code correctly, you're currently generating one GOT and
one PLT per loaded module.  If that's the case, then this is correct, it's just
possible to save some memory by merging these tables.  It's probably not worth
the complexity for kernel modules for a while.

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Zong Li]

2018-03-14 11:07 GMT+08:00 Palmer Dabbelt <palmer@sifive.com>:
> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zongbox@gmail.com wrote:
>>
>> 2018-03-14 5:30 GMT+08:00 Shea Levy <shea@shealevy.com>:
>>>
>>> Hi Palmer,
>>>
>>> Palmer Dabbelt <palmer@sifive.com> writes:
>>>
>>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>>>>
>>>>> These patches resolve the some issues of loadable module.
>>>>>   - symbol out of ranges
>>>>>   - unknown relocation types
>>>>>
>>>>> The reference of external variable and function symbols
>>>>> cannot exceed 32-bit offset ranges in kernel module.
>>>>> The module only can work on the 32-bit OS or the 64-bit
>>>>> OS with sv32 virtual addressing.
>>>>>
>>>>> These patches will generate the .got, .got.plt and
>>>>> .plt sections during loading module, let it can refer
>>>>> to the symbol which locate more than 32-bit offset.
>>>>> These sections depend on the relocation types:
>>>>>  - R_RISCV_GOT_HI20
>>>>>  - R_RISCV_CALL_PLT
>>>>>
>>>>> These patches also support more relocation types
>>>>>  - R_RISCV_CALL
>>>>>  - R_RISCV_HI20
>>>>>  - R_RISCV_LO12_I
>>>>>  - R_RISCV_LO12_S
>>>>>  - R_RISCV_RVC_BRANCH
>>>>>  - R_RISCV_RVC_JUMP
>>>>>  - R_RISCV_ALIGN
>>>>>  - R_RISCV_ADD32
>>>>>  - R_RISCV_SUB32
>>>>>
>>>>> Zong Li (11):
>>>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>>>   RISC-V: Support CALL relocation type in kernel module
>>>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>>>   RISC-V: Enable module support in defconfig
>>>>>   RISC-V: Add definition of relocation types
>>>>>
>>>>>  arch/riscv/Kconfig                  |   5 ++
>>>>>  arch/riscv/Makefile                 |   3 +
>>>>>  arch/riscv/configs/defconfig        |   2 +
>>>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>>>  arch/riscv/kernel/Makefile          |   1 +
>>>>>  arch/riscv/kernel/module-sections.c | 156
>>>>> ++++++++++++++++++++++++++++++++
>>>>>  arch/riscv/kernel/module.c          | 175
>>>>> ++++++++++++++++++++++++++++++++++--
>>>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>>>  create mode 100644 arch/riscv/kernel/module.lds
>>>>
>>>>
>>>> This is the second set of patches that turn on modules, and it has the
>>>> same
>>>> R_RISCV_ALIGN problem as the other one
>>>>
>>>>
>>>> http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>>>
>>>> It looks like this one uses shared libraries for modules instead of
>>>> static
>>>> objects.  I think using shared objects is the right thing to do, as
>>>> it'll allow
>>>> us to place modules anywhere in the address space by having multiple
>>>> GOTs and
>>>> PLTs.
>>>
>>>
>>> Can you expand on this? It was my understanding that outside of the
>>> context of multiple address spaces sharing code the GOT and PLT were
>>> simply unnecessary overhead, what benefit would they bring here?
>>>
>>>> That's kind of complicated, though, so we can start with something
>>>> simpler like this.
>>
>>
>> Hi,
>>
>> The kernel module is a object file, it is not be linked by linker, the
>> GOT and PLT
>> sections will not be generated through -fPIC option, but it will
>> generate the relative
>> relocation type. As Palmer mention before, If we have GOT and PLT
>> sections,
>> we can put the module anywhere, even we support the KASLR in the kernel.
>
>
> Sorry, I guess I meant PIC objects not shared objects (I keep forgetting
> about
> PIE).  We'll probably eventually add large code model targets, but they
> might
> end up just being functionally equilivant to PIE with multi-GOT and
> multi-PLT
> so it might not matter.
>
> Either way, this is the sanest way to do it for now.

Actually, I try to use the large code model and without PIC before.
(The compiler with mcmodel=large obtain from my colleague development)
On this compiler version, the `-mcmodel=large` uses the constant pool
mechanism to
puts the addresses of data symbols at the function tail. It can resolve
the reference about out of range of data symbol, but this code generation not
apply to function call. For the compiler code generation and no linker to do
relax reason, kernel module still needs the PLT section to jump to far target.
On the other hand, the ARM64 mailing list has the patches to remove
the large code model for cache performance.

https://marc.info/?l=linux-arm-kernel&m=151860828416766

so maybe we can use the `medany + fPIC` for now.

>> For the ALIGN problem, the kernel module loader is difficult to remove
>> or migrate
>> the module's code like relax doing, so the remnant nop instructions harm
>> the
>> performance,  I agree the point that adding the mno-relax option and
>> checking
>> the alignment in ALIGN type in module loader.
>
>
> Sounds good.  I just merged the mno-relax stuff, it'll show up when I get
> around to generating a 7.3.0 backport branch.  For now I think you should
> just
> fail on R_RISCV_ALIGN and attempt to pass -mno-relax to the compiler (via
> something like "$(call cc-option,-mno-relax)", like we do for
> "-mstrict-align").  I don't think it's worth handling R_RISCV_ALIGN in the
> kernel, as that's essentially the same as full relaxation support.

OK. I will send the v2 patches with the modification as you mention about
R_RISCV_ALIGN type?

> If I understand your code correctly, you're currently generating one GOT and
> one PLT per loaded module.  If that's the case, then this is correct, it's
> just
> possible to save some memory by merging these tables.  It's probably not
> worth
> the complexity for kernel modules for a while.

Yes, there are one GOT and one PLT per loaded module.
In the [PATCH 02/11], I generate the third section .got.plt for saving
more memory of
each PLT entry.

Thanks a lot.

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Shea Levy]

[-- Attachment #1: Type: text/plain, Size: 6846 bytes --]

Zong Li <zongbox@gmail.com> writes:

> 2018-03-14 11:07 GMT+08:00 Palmer Dabbelt <palmer@sifive.com>:
>> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zongbox@gmail.com wrote:
>>>
>>> 2018-03-14 5:30 GMT+08:00 Shea Levy <shea@shealevy.com>:
>>>>
>>>> Hi Palmer,
>>>>
>>>> Palmer Dabbelt <palmer@sifive.com> writes:
>>>>
>>>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>>>>>
>>>>>> These patches resolve the some issues of loadable module.
>>>>>>   - symbol out of ranges
>>>>>>   - unknown relocation types
>>>>>>
>>>>>> The reference of external variable and function symbols
>>>>>> cannot exceed 32-bit offset ranges in kernel module.
>>>>>> The module only can work on the 32-bit OS or the 64-bit
>>>>>> OS with sv32 virtual addressing.
>>>>>>
>>>>>> These patches will generate the .got, .got.plt and
>>>>>> .plt sections during loading module, let it can refer
>>>>>> to the symbol which locate more than 32-bit offset.
>>>>>> These sections depend on the relocation types:
>>>>>>  - R_RISCV_GOT_HI20
>>>>>>  - R_RISCV_CALL_PLT
>>>>>>
>>>>>> These patches also support more relocation types
>>>>>>  - R_RISCV_CALL
>>>>>>  - R_RISCV_HI20
>>>>>>  - R_RISCV_LO12_I
>>>>>>  - R_RISCV_LO12_S
>>>>>>  - R_RISCV_RVC_BRANCH
>>>>>>  - R_RISCV_RVC_JUMP
>>>>>>  - R_RISCV_ALIGN
>>>>>>  - R_RISCV_ADD32
>>>>>>  - R_RISCV_SUB32
>>>>>>
>>>>>> Zong Li (11):
>>>>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>>>>   RISC-V: Support CALL relocation type in kernel module
>>>>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>>>>   RISC-V: Enable module support in defconfig
>>>>>>   RISC-V: Add definition of relocation types
>>>>>>
>>>>>>  arch/riscv/Kconfig                  |   5 ++
>>>>>>  arch/riscv/Makefile                 |   3 +
>>>>>>  arch/riscv/configs/defconfig        |   2 +
>>>>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>>>>  arch/riscv/kernel/Makefile          |   1 +
>>>>>>  arch/riscv/kernel/module-sections.c | 156
>>>>>> ++++++++++++++++++++++++++++++++
>>>>>>  arch/riscv/kernel/module.c          | 175
>>>>>> ++++++++++++++++++++++++++++++++++--
>>>>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>>>>  create mode 100644 arch/riscv/kernel/module.lds
>>>>>
>>>>>
>>>>> This is the second set of patches that turn on modules, and it has the
>>>>> same
>>>>> R_RISCV_ALIGN problem as the other one
>>>>>
>>>>>
>>>>> http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>>>>
>>>>> It looks like this one uses shared libraries for modules instead of
>>>>> static
>>>>> objects.  I think using shared objects is the right thing to do, as
>>>>> it'll allow
>>>>> us to place modules anywhere in the address space by having multiple
>>>>> GOTs and
>>>>> PLTs.
>>>>
>>>>
>>>> Can you expand on this? It was my understanding that outside of the
>>>> context of multiple address spaces sharing code the GOT and PLT were
>>>> simply unnecessary overhead, what benefit would they bring here?
>>>>
>>>>> That's kind of complicated, though, so we can start with something
>>>>> simpler like this.
>>>
>>>
>>> Hi,
>>>
>>> The kernel module is a object file, it is not be linked by linker, the
>>> GOT and PLT
>>> sections will not be generated through -fPIC option, but it will
>>> generate the relative
>>> relocation type. As Palmer mention before, If we have GOT and PLT
>>> sections,
>>> we can put the module anywhere, even we support the KASLR in the kernel.
>>
>>
>> Sorry, I guess I meant PIC objects not shared objects (I keep forgetting
>> about
>> PIE).  We'll probably eventually add large code model targets, but they
>> might
>> end up just being functionally equilivant to PIE with multi-GOT and
>> multi-PLT
>> so it might not matter.
>>
>> Either way, this is the sanest way to do it for now.
>
> Actually, I try to use the large code model and without PIC before.
> (The compiler with mcmodel=large obtain from my colleague development)
> On this compiler version, the `-mcmodel=large` uses the constant pool
> mechanism to
> puts the addresses of data symbols at the function tail. It can resolve
> the reference about out of range of data symbol, but this code generation not
> apply to function call. For the compiler code generation and no linker to do
> relax reason, kernel module still needs the PLT section to jump to far target.
> On the other hand, the ARM64 mailing list has the patches to remove
> the large code model for cache performance.
>
> https://marc.info/?l=linux-arm-kernel&m=151860828416766
>
> so maybe we can use the `medany + fPIC` for now.
>
>>> For the ALIGN problem, the kernel module loader is difficult to remove
>>> or migrate
>>> the module's code like relax doing, so the remnant nop instructions harm
>>> the
>>> performance,  I agree the point that adding the mno-relax option and
>>> checking
>>> the alignment in ALIGN type in module loader.
>>
>>
>> Sounds good.  I just merged the mno-relax stuff, it'll show up when I get
>> around to generating a 7.3.0 backport branch.  For now I think you should
>> just
>> fail on R_RISCV_ALIGN and attempt to pass -mno-relax to the compiler (via
>> something like "$(call cc-option,-mno-relax)", like we do for
>> "-mstrict-align").  I don't think it's worth handling R_RISCV_ALIGN in the
>> kernel, as that's essentially the same as full relaxation support.
>
> OK. I will send the v2 patches with the modification as you mention about
> R_RISCV_ALIGN type?

Just to avoid work duplication, do you think you'll get to this before
this weekend? I was planning on bringing my patches up-to-date then, but
since we're going the PIC route I can base my no-relax/ALIGN support on
top of your series instead.

>
>> If I understand your code correctly, you're currently generating one GOT and
>> one PLT per loaded module.  If that's the case, then this is correct, it's
>> just
>> possible to save some memory by merging these tables.  It's probably not
>> worth
>> the complexity for kernel modules for a while.
>
> Yes, there are one GOT and one PLT per loaded module.
> In the [PATCH 02/11], I generate the third section .got.plt for saving
> more memory of
> each PLT entry.
>
> Thanks a lot.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Zong Li]

2018-03-14 19:56 GMT+08:00 Shea Levy <shea@shealevy.com>:
> Zong Li <zongbox@gmail.com> writes:
>
>> 2018-03-14 11:07 GMT+08:00 Palmer Dabbelt <palmer@sifive.com>:
>>> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zongbox@gmail.com wrote:
>>>>
>>>> 2018-03-14 5:30 GMT+08:00 Shea Levy <shea@shealevy.com>:
>>>>>
>>>>> Hi Palmer,
>>>>>
>>>>> Palmer Dabbelt <palmer@sifive.com> writes:
>>>>>
>>>>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>>>>>>
>>>>>>> These patches resolve the some issues of loadable module.
>>>>>>>   - symbol out of ranges
>>>>>>>   - unknown relocation types
>>>>>>>
>>>>>>> The reference of external variable and function symbols
>>>>>>> cannot exceed 32-bit offset ranges in kernel module.
>>>>>>> The module only can work on the 32-bit OS or the 64-bit
>>>>>>> OS with sv32 virtual addressing.
>>>>>>>
>>>>>>> These patches will generate the .got, .got.plt and
>>>>>>> .plt sections during loading module, let it can refer
>>>>>>> to the symbol which locate more than 32-bit offset.
>>>>>>> These sections depend on the relocation types:
>>>>>>>  - R_RISCV_GOT_HI20
>>>>>>>  - R_RISCV_CALL_PLT
>>>>>>>
>>>>>>> These patches also support more relocation types
>>>>>>>  - R_RISCV_CALL
>>>>>>>  - R_RISCV_HI20
>>>>>>>  - R_RISCV_LO12_I
>>>>>>>  - R_RISCV_LO12_S
>>>>>>>  - R_RISCV_RVC_BRANCH
>>>>>>>  - R_RISCV_RVC_JUMP
>>>>>>>  - R_RISCV_ALIGN
>>>>>>>  - R_RISCV_ADD32
>>>>>>>  - R_RISCV_SUB32
>>>>>>>
>>>>>>> Zong Li (11):
>>>>>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>>>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>>>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>>>>>   RISC-V: Support CALL relocation type in kernel module
>>>>>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>>>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>>>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>>>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>>>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>>>>>   RISC-V: Enable module support in defconfig
>>>>>>>   RISC-V: Add definition of relocation types
>>>>>>>
>>>>>>>  arch/riscv/Kconfig                  |   5 ++
>>>>>>>  arch/riscv/Makefile                 |   3 +
>>>>>>>  arch/riscv/configs/defconfig        |   2 +
>>>>>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>>>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>>>>>  arch/riscv/kernel/Makefile          |   1 +
>>>>>>>  arch/riscv/kernel/module-sections.c | 156
>>>>>>> ++++++++++++++++++++++++++++++++
>>>>>>>  arch/riscv/kernel/module.c          | 175
>>>>>>> ++++++++++++++++++++++++++++++++++--
>>>>>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>>>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>>>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>>>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>>>>>  create mode 100644 arch/riscv/kernel/module.lds
>>>>>>
>>>>>>
>>>>>> This is the second set of patches that turn on modules, and it has the
>>>>>> same
>>>>>> R_RISCV_ALIGN problem as the other one
>>>>>>
>>>>>>
>>>>>> http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>>>>>
>>>>>> It looks like this one uses shared libraries for modules instead of
>>>>>> static
>>>>>> objects.  I think using shared objects is the right thing to do, as
>>>>>> it'll allow
>>>>>> us to place modules anywhere in the address space by having multiple
>>>>>> GOTs and
>>>>>> PLTs.
>>>>>
>>>>>
>>>>> Can you expand on this? It was my understanding that outside of the
>>>>> context of multiple address spaces sharing code the GOT and PLT were
>>>>> simply unnecessary overhead, what benefit would they bring here?
>>>>>
>>>>>> That's kind of complicated, though, so we can start with something
>>>>>> simpler like this.
>>>>
>>>>
>>>> Hi,
>>>>
>>>> The kernel module is a object file, it is not be linked by linker, the
>>>> GOT and PLT
>>>> sections will not be generated through -fPIC option, but it will
>>>> generate the relative
>>>> relocation type. As Palmer mention before, If we have GOT and PLT
>>>> sections,
>>>> we can put the module anywhere, even we support the KASLR in the kernel.
>>>
>>>
>>> Sorry, I guess I meant PIC objects not shared objects (I keep forgetting
>>> about
>>> PIE).  We'll probably eventually add large code model targets, but they
>>> might
>>> end up just being functionally equilivant to PIE with multi-GOT and
>>> multi-PLT
>>> so it might not matter.
>>>
>>> Either way, this is the sanest way to do it for now.
>>
>> Actually, I try to use the large code model and without PIC before.
>> (The compiler with mcmodel=large obtain from my colleague development)
>> On this compiler version, the `-mcmodel=large` uses the constant pool
>> mechanism to
>> puts the addresses of data symbols at the function tail. It can resolve
>> the reference about out of range of data symbol, but this code generation not
>> apply to function call. For the compiler code generation and no linker to do
>> relax reason, kernel module still needs the PLT section to jump to far target.
>> On the other hand, the ARM64 mailing list has the patches to remove
>> the large code model for cache performance.
>>
>> https://marc.info/?l=linux-arm-kernel&m=151860828416766
>>
>> so maybe we can use the `medany + fPIC` for now.
>>
>>>> For the ALIGN problem, the kernel module loader is difficult to remove
>>>> or migrate
>>>> the module's code like relax doing, so the remnant nop instructions harm
>>>> the
>>>> performance,  I agree the point that adding the mno-relax option and
>>>> checking
>>>> the alignment in ALIGN type in module loader.
>>>
>>>
>>> Sounds good.  I just merged the mno-relax stuff, it'll show up when I get
>>> around to generating a 7.3.0 backport branch.  For now I think you should
>>> just
>>> fail on R_RISCV_ALIGN and attempt to pass -mno-relax to the compiler (via
>>> something like "$(call cc-option,-mno-relax)", like we do for
>>> "-mstrict-align").  I don't think it's worth handling R_RISCV_ALIGN in the
>>> kernel, as that's essentially the same as full relaxation support.
>>
>> OK. I will send the v2 patches with the modification as you mention about
>> R_RISCV_ALIGN type?
>
> Just to avoid work duplication, do you think you'll get to this before
> this weekend? I was planning on bringing my patches up-to-date then, but
> since we're going the PIC route I can base my no-relax/ALIGN support on
> top of your series instead.
>

Hi Shea,

I'm not sure whether there are any problems before finishing discussion.
If only the alignment problem, I think that it is quick modification.

Thanks a lot.

>>
>>> If I understand your code correctly, you're currently generating one GOT and
>>> one PLT per loaded module.  If that's the case, then this is correct, it's
>>> just
>>> possible to save some memory by merging these tables.  It's probably not
>>> worth
>>> the complexity for kernel modules for a while.
>>
>> Yes, there are one GOT and one PLT per loaded module.
>> In the [PATCH 02/11], I generate the third section .got.plt for saving
>> more memory of
>> each PLT entry.
>>
>> Thanks a lot.

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Shea Levy]

[-- Attachment #1: Type: text/plain, Size: 5823 bytes --]

Palmer Dabbelt <palmer@sifive.com> writes:

> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zongbox@gmail.com wrote:
>> 2018-03-14 5:30 GMT+08:00 Shea Levy <shea@shealevy.com>:
>>> Hi Palmer,
>>>
>>> Palmer Dabbelt <palmer@sifive.com> writes:
>>>
>>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>>>> These patches resolve the some issues of loadable module.
>>>>>   - symbol out of ranges
>>>>>   - unknown relocation types
>>>>>
>>>>> The reference of external variable and function symbols
>>>>> cannot exceed 32-bit offset ranges in kernel module.
>>>>> The module only can work on the 32-bit OS or the 64-bit
>>>>> OS with sv32 virtual addressing.
>>>>>
>>>>> These patches will generate the .got, .got.plt and
>>>>> .plt sections during loading module, let it can refer
>>>>> to the symbol which locate more than 32-bit offset.
>>>>> These sections depend on the relocation types:
>>>>>  - R_RISCV_GOT_HI20
>>>>>  - R_RISCV_CALL_PLT
>>>>>
>>>>> These patches also support more relocation types
>>>>>  - R_RISCV_CALL
>>>>>  - R_RISCV_HI20
>>>>>  - R_RISCV_LO12_I
>>>>>  - R_RISCV_LO12_S
>>>>>  - R_RISCV_RVC_BRANCH
>>>>>  - R_RISCV_RVC_JUMP
>>>>>  - R_RISCV_ALIGN
>>>>>  - R_RISCV_ADD32
>>>>>  - R_RISCV_SUB32
>>>>>
>>>>> Zong Li (11):
>>>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>>>   RISC-V: Support CALL relocation type in kernel module
>>>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>>>   RISC-V: Enable module support in defconfig
>>>>>   RISC-V: Add definition of relocation types
>>>>>
>>>>>  arch/riscv/Kconfig                  |   5 ++
>>>>>  arch/riscv/Makefile                 |   3 +
>>>>>  arch/riscv/configs/defconfig        |   2 +
>>>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>>>  arch/riscv/kernel/Makefile          |   1 +
>>>>>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>>>>>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>>>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>>>  create mode 100644 arch/riscv/kernel/module.lds
>>>>
>>>> This is the second set of patches that turn on modules, and it has the same
>>>> R_RISCV_ALIGN problem as the other one
>>>>
>>>>     http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>>>
>>>> It looks like this one uses shared libraries for modules instead of static
>>>> objects.  I think using shared objects is the right thing to do, as it'll allow
>>>> us to place modules anywhere in the address space by having multiple GOTs and
>>>> PLTs.
>>>
>>> Can you expand on this? It was my understanding that outside of the
>>> context of multiple address spaces sharing code the GOT and PLT were
>>> simply unnecessary overhead, what benefit would they bring here?
>>>
>>>> That's kind of complicated, though, so we can start with something
>>>> simpler like this.
>>
>> Hi,
>>
>> The kernel module is a object file, it is not be linked by linker, the
>> GOT and PLT
>> sections will not be generated through -fPIC option, but it will
>> generate the relative
>> relocation type. As Palmer mention before, If we have GOT and PLT sections,
>> we can put the module anywhere, even we support the KASLR in the kernel.
>
> Sorry, I guess I meant PIC objects not shared objects (I keep forgetting about
> PIE).  We'll probably eventually add large code model targets, but they might
> end up just being functionally equilivant to PIE with multi-GOT and multi-PLT
> so it might not matter.
>
> Either way, this is the sanest way to do it for now.
>
>> For the ALIGN problem, the kernel module loader is difficult to remove
>> or migrate
>> the module's code like relax doing, so the remnant nop instructions harm the
>> performance,  I agree the point that adding the mno-relax option and checking
>> the alignment in ALIGN type in module loader.
>
> Sounds good.  I just merged the mno-relax stuff, it'll show up when I get
> around to generating a 7.3.0 backport branch.  For now I think you should just
> fail on R_RISCV_ALIGN and attempt to pass -mno-relax to the compiler (via
> something like "$(call cc-option,-mno-relax)", like we do for
> "-mstrict-align").  I don't think it's worth handling R_RISCV_ALIGN in the
> kernel, as that's essentially the same as full relaxation support.
>

Should we unconditionally fail on R_RISCV_ALIGN or only if the code
isn't already aligned?

>
>>>> That's kind of complicated, though, so we can start with something
>>>> simpler like this.
>>
>> So what is the suggestion for that.
>
> Well, I'm not really sure -- essentially the idea of proper multi-GOT and
> multi-PLT support would be to merge the GOTs and PLTs of modules together when
> they're within range of each other.  We haven't even figured this out in
> userspace yet, so it's probably not worth attempting for kernel modules for a
> bit.
>
> If I understand your code correctly, you're currently generating one GOT and
> one PLT per loaded module.  If that's the case, then this is correct, it's just
> possible to save some memory by merging these tables.  It's probably not worth
> the complexity for kernel modules for a while.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Palmer Dabbelt]

On Wed, 14 Mar 2018 04:54:14 PDT (-0700), shea@shealevy.com wrote:
> Palmer Dabbelt <palmer@sifive.com> writes:
>
>> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zongbox@gmail.com wrote:
>>> 2018-03-14 5:30 GMT+08:00 Shea Levy <shea@shealevy.com>:
>>>> Hi Palmer,
>>>>
>>>> Palmer Dabbelt <palmer@sifive.com> writes:
>>>>
>>>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>>>>> These patches resolve the some issues of loadable module.
>>>>>>   - symbol out of ranges
>>>>>>   - unknown relocation types
>>>>>>
>>>>>> The reference of external variable and function symbols
>>>>>> cannot exceed 32-bit offset ranges in kernel module.
>>>>>> The module only can work on the 32-bit OS or the 64-bit
>>>>>> OS with sv32 virtual addressing.
>>>>>>
>>>>>> These patches will generate the .got, .got.plt and
>>>>>> .plt sections during loading module, let it can refer
>>>>>> to the symbol which locate more than 32-bit offset.
>>>>>> These sections depend on the relocation types:
>>>>>>  - R_RISCV_GOT_HI20
>>>>>>  - R_RISCV_CALL_PLT
>>>>>>
>>>>>> These patches also support more relocation types
>>>>>>  - R_RISCV_CALL
>>>>>>  - R_RISCV_HI20
>>>>>>  - R_RISCV_LO12_I
>>>>>>  - R_RISCV_LO12_S
>>>>>>  - R_RISCV_RVC_BRANCH
>>>>>>  - R_RISCV_RVC_JUMP
>>>>>>  - R_RISCV_ALIGN
>>>>>>  - R_RISCV_ADD32
>>>>>>  - R_RISCV_SUB32
>>>>>>
>>>>>> Zong Li (11):
>>>>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>>>>   RISC-V: Support CALL relocation type in kernel module
>>>>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>>>>   RISC-V: Enable module support in defconfig
>>>>>>   RISC-V: Add definition of relocation types
>>>>>>
>>>>>>  arch/riscv/Kconfig                  |   5 ++
>>>>>>  arch/riscv/Makefile                 |   3 +
>>>>>>  arch/riscv/configs/defconfig        |   2 +
>>>>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>>>>  arch/riscv/kernel/Makefile          |   1 +
>>>>>>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>>>>>>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>>>>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>>>>  create mode 100644 arch/riscv/kernel/module.lds
>>>>>
>>>>> This is the second set of patches that turn on modules, and it has the same
>>>>> R_RISCV_ALIGN problem as the other one
>>>>>
>>>>>     http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>>>>
>>>>> It looks like this one uses shared libraries for modules instead of static
>>>>> objects.  I think using shared objects is the right thing to do, as it'll allow
>>>>> us to place modules anywhere in the address space by having multiple GOTs and
>>>>> PLTs.
>>>>
>>>> Can you expand on this? It was my understanding that outside of the
>>>> context of multiple address spaces sharing code the GOT and PLT were
>>>> simply unnecessary overhead, what benefit would they bring here?
>>>>
>>>>> That's kind of complicated, though, so we can start with something
>>>>> simpler like this.
>>>
>>> Hi,
>>>
>>> The kernel module is a object file, it is not be linked by linker, the
>>> GOT and PLT
>>> sections will not be generated through -fPIC option, but it will
>>> generate the relative
>>> relocation type. As Palmer mention before, If we have GOT and PLT sections,
>>> we can put the module anywhere, even we support the KASLR in the kernel.
>>
>> Sorry, I guess I meant PIC objects not shared objects (I keep forgetting about
>> PIE).  We'll probably eventually add large code model targets, but they might
>> end up just being functionally equilivant to PIE with multi-GOT and multi-PLT
>> so it might not matter.
>>
>> Either way, this is the sanest way to do it for now.
>>
>>> For the ALIGN problem, the kernel module loader is difficult to remove
>>> or migrate
>>> the module's code like relax doing, so the remnant nop instructions harm the
>>> performance,  I agree the point that adding the mno-relax option and checking
>>> the alignment in ALIGN type in module loader.
>>
>> Sounds good.  I just merged the mno-relax stuff, it'll show up when I get
>> around to generating a 7.3.0 backport branch.  For now I think you should just
>> fail on R_RISCV_ALIGN and attempt to pass -mno-relax to the compiler (via
>> something like "$(call cc-option,-mno-relax)", like we do for
>> "-mstrict-align").  I don't think it's worth handling R_RISCV_ALIGN in the
>> kernel, as that's essentially the same as full relaxation support.
>>
>
> Should we unconditionally fail on R_RISCV_ALIGN or only if the code
> isn't already aligned?

Either way is OK for me.  With '-mno-relax' there shouldn't be any
R_RISCV_ALIGN relocations, so it shouldn't matter.

>>
>>>>> That's kind of complicated, though, so we can start with something
>>>>> simpler like this.
>>>
>>> So what is the suggestion for that.
>>
>> Well, I'm not really sure -- essentially the idea of proper multi-GOT and
>> multi-PLT support would be to merge the GOTs and PLTs of modules together when
>> they're within range of each other.  We haven't even figured this out in
>> userspace yet, so it's probably not worth attempting for kernel modules for a
>> bit.
>>
>> If I understand your code correctly, you're currently generating one GOT and
>> one PLT per loaded module.  If that's the case, then this is correct, it's just
>> possible to save some memory by merging these tables.  It's probably not worth
>> the complexity for kernel modules for a while.

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Palmer Dabbelt]

On Tue, 13 Mar 2018 14:30:53 PDT (-0700), shea@shealevy.com wrote:
> Hi Palmer,
>
> Palmer Dabbelt <palmer@sifive.com> writes:
>
>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>> These patches resolve the some issues of loadable module.
>>>   - symbol out of ranges
>>>   - unknown relocation types
>>>
>>> The reference of external variable and function symbols
>>> cannot exceed 32-bit offset ranges in kernel module.
>>> The module only can work on the 32-bit OS or the 64-bit
>>> OS with sv32 virtual addressing.
>>>
>>> These patches will generate the .got, .got.plt and
>>> .plt sections during loading module, let it can refer
>>> to the symbol which locate more than 32-bit offset.
>>> These sections depend on the relocation types:
>>>  - R_RISCV_GOT_HI20
>>>  - R_RISCV_CALL_PLT
>>>
>>> These patches also support more relocation types
>>>  - R_RISCV_CALL
>>>  - R_RISCV_HI20
>>>  - R_RISCV_LO12_I
>>>  - R_RISCV_LO12_S
>>>  - R_RISCV_RVC_BRANCH
>>>  - R_RISCV_RVC_JUMP
>>>  - R_RISCV_ALIGN
>>>  - R_RISCV_ADD32
>>>  - R_RISCV_SUB32
>>>
>>> Zong Li (11):
>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>   RISC-V: Support CALL relocation type in kernel module
>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>   RISC-V: Enable module support in defconfig
>>>   RISC-V: Add definition of relocation types
>>>
>>>  arch/riscv/Kconfig                  |   5 ++
>>>  arch/riscv/Makefile                 |   3 +
>>>  arch/riscv/configs/defconfig        |   2 +
>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>  arch/riscv/kernel/Makefile          |   1 +
>>>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>>>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>  create mode 100644 arch/riscv/kernel/module.lds
>>
>> This is the second set of patches that turn on modules, and it has the same
>> R_RISCV_ALIGN problem as the other one
>>
>>     http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>
>> It looks like this one uses shared libraries for modules instead of static
>> objects.  I think using shared objects is the right thing to do, as it'll allow
>> us to place modules anywhere in the address space by having multiple GOTs and
>> PLTs.
>
> Can you expand on this? It was my understanding that outside of the
> context of multiple address spaces sharing code the GOT and PLT were
> simply unnecessary overhead, what benefit would they bring here?

We don't currently have any position-dependent RISC-V code models larger than
"medany", in which all code and data must live within a single 32-bit
addressable range.  The PLT and GOT sort of provide an out here, so the code
only needs to get to the table (which can then get anywhere via an indirection
layer).

This is relevant for Linux modules because it lets us load modules anywhere in
the address space.  It's also a bit of a headache, as it either requires a
GOT+PLT per module (which is big) or merging tables (which is hard).

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Shea Levy]

[-- Attachment #1: Type: text/plain, Size: 4249 bytes --]

Palmer Dabbelt <palmer@sifive.com> writes:

> On Tue, 13 Mar 2018 14:30:53 PDT (-0700), shea@shealevy.com wrote:
>> Hi Palmer,
>>
>> Palmer Dabbelt <palmer@sifive.com> writes:
>>
>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>>> These patches resolve the some issues of loadable module.
>>>>   - symbol out of ranges
>>>>   - unknown relocation types
>>>>
>>>> The reference of external variable and function symbols
>>>> cannot exceed 32-bit offset ranges in kernel module.
>>>> The module only can work on the 32-bit OS or the 64-bit
>>>> OS with sv32 virtual addressing.
>>>>
>>>> These patches will generate the .got, .got.plt and
>>>> .plt sections during loading module, let it can refer
>>>> to the symbol which locate more than 32-bit offset.
>>>> These sections depend on the relocation types:
>>>>  - R_RISCV_GOT_HI20
>>>>  - R_RISCV_CALL_PLT
>>>>
>>>> These patches also support more relocation types
>>>>  - R_RISCV_CALL
>>>>  - R_RISCV_HI20
>>>>  - R_RISCV_LO12_I
>>>>  - R_RISCV_LO12_S
>>>>  - R_RISCV_RVC_BRANCH
>>>>  - R_RISCV_RVC_JUMP
>>>>  - R_RISCV_ALIGN
>>>>  - R_RISCV_ADD32
>>>>  - R_RISCV_SUB32
>>>>
>>>> Zong Li (11):
>>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>>   RISC-V: Support CALL relocation type in kernel module
>>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>>   RISC-V: Enable module support in defconfig
>>>>   RISC-V: Add definition of relocation types
>>>>
>>>>  arch/riscv/Kconfig                  |   5 ++
>>>>  arch/riscv/Makefile                 |   3 +
>>>>  arch/riscv/configs/defconfig        |   2 +
>>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>>  arch/riscv/kernel/Makefile          |   1 +
>>>>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>>>>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>>  create mode 100644 arch/riscv/kernel/module.lds
>>>
>>> This is the second set of patches that turn on modules, and it has the same
>>> R_RISCV_ALIGN problem as the other one
>>>
>>>     http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>>
>>> It looks like this one uses shared libraries for modules instead of static
>>> objects.  I think using shared objects is the right thing to do, as it'll allow
>>> us to place modules anywhere in the address space by having multiple GOTs and
>>> PLTs.
>>
>> Can you expand on this? It was my understanding that outside of the
>> context of multiple address spaces sharing code the GOT and PLT were
>> simply unnecessary overhead, what benefit would they bring here?
>
> We don't currently have any position-dependent RISC-V code models larger than
> "medany", in which all code and data must live within a single 32-bit
> addressable range.  The PLT and GOT sort of provide an out here, so the code
> only needs to get to the table (which can then get anywhere via an indirection
> layer).
>
> This is relevant for Linux modules because it lets us load modules anywhere in
> the address space.  It's also a bit of a headache, as it either requires a
> GOT+PLT per module (which is big) or merging tables (which is hard).

I see, thanks! We only get this benefit if we actually do the relevanat
indirection in the table, right? And if we merge tables we still have to
have all modules within 32 bits of the common table? Is this how some
future "medlarge" code model will work, or is it more of a convenient
way to reuse existing techniques until other code models are worked out?

Thanks,
Shea

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Palmer Dabbelt]

On Wed, 14 Mar 2018 05:07:09 PDT (-0700), shea@shealevy.com wrote:
> Palmer Dabbelt <palmer@sifive.com> writes:
>
>> On Tue, 13 Mar 2018 14:30:53 PDT (-0700), shea@shealevy.com wrote:
>>> Hi Palmer,
>>>
>>> Palmer Dabbelt <palmer@sifive.com> writes:
>>>
>>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>>>> These patches resolve the some issues of loadable module.
>>>>>   - symbol out of ranges
>>>>>   - unknown relocation types
>>>>>
>>>>> The reference of external variable and function symbols
>>>>> cannot exceed 32-bit offset ranges in kernel module.
>>>>> The module only can work on the 32-bit OS or the 64-bit
>>>>> OS with sv32 virtual addressing.
>>>>>
>>>>> These patches will generate the .got, .got.plt and
>>>>> .plt sections during loading module, let it can refer
>>>>> to the symbol which locate more than 32-bit offset.
>>>>> These sections depend on the relocation types:
>>>>>  - R_RISCV_GOT_HI20
>>>>>  - R_RISCV_CALL_PLT
>>>>>
>>>>> These patches also support more relocation types
>>>>>  - R_RISCV_CALL
>>>>>  - R_RISCV_HI20
>>>>>  - R_RISCV_LO12_I
>>>>>  - R_RISCV_LO12_S
>>>>>  - R_RISCV_RVC_BRANCH
>>>>>  - R_RISCV_RVC_JUMP
>>>>>  - R_RISCV_ALIGN
>>>>>  - R_RISCV_ADD32
>>>>>  - R_RISCV_SUB32
>>>>>
>>>>> Zong Li (11):
>>>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>>>   RISC-V: Support CALL relocation type in kernel module
>>>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>>>   RISC-V: Enable module support in defconfig
>>>>>   RISC-V: Add definition of relocation types
>>>>>
>>>>>  arch/riscv/Kconfig                  |   5 ++
>>>>>  arch/riscv/Makefile                 |   3 +
>>>>>  arch/riscv/configs/defconfig        |   2 +
>>>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>>>  arch/riscv/kernel/Makefile          |   1 +
>>>>>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>>>>>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>>>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>>>  create mode 100644 arch/riscv/kernel/module.lds
>>>>
>>>> This is the second set of patches that turn on modules, and it has the same
>>>> R_RISCV_ALIGN problem as the other one
>>>>
>>>>     http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>>>
>>>> It looks like this one uses shared libraries for modules instead of static
>>>> objects.  I think using shared objects is the right thing to do, as it'll allow
>>>> us to place modules anywhere in the address space by having multiple GOTs and
>>>> PLTs.
>>>
>>> Can you expand on this? It was my understanding that outside of the
>>> context of multiple address spaces sharing code the GOT and PLT were
>>> simply unnecessary overhead, what benefit would they bring here?
>>
>> We don't currently have any position-dependent RISC-V code models larger than
>> "medany", in which all code and data must live within a single 32-bit
>> addressable range.  The PLT and GOT sort of provide an out here, so the code
>> only needs to get to the table (which can then get anywhere via an indirection
>> layer).
>>
>> This is relevant for Linux modules because it lets us load modules anywhere in
>> the address space.  It's also a bit of a headache, as it either requires a
>> GOT+PLT per module (which is big) or merging tables (which is hard).
>
> I see, thanks! We only get this benefit if we actually do the relevanat
> indirection in the table, right? And if we merge tables we still have to
> have all modules within 32 bits of the common table? Is this how some
> future "medlarge" code model will work, or is it more of a convenient
> way to reuse existing techniques until other code models are worked out?

The idea is that you'd merge the tables only when it's possible to do that
correctly, which is the tricky part.

It'd be called "largeany", the "med" part is what limits the code model to 32
bit offsets.  We might just call it "large", as the "any" is kind of redundant.

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Shea Levy]

[-- Attachment #1: Type: text/plain, Size: 4916 bytes --]

Palmer Dabbelt <palmer@sifive.com> writes:

> On Wed, 14 Mar 2018 05:07:09 PDT (-0700), shea@shealevy.com wrote:
>> Palmer Dabbelt <palmer@sifive.com> writes:
>>
>>> On Tue, 13 Mar 2018 14:30:53 PDT (-0700), shea@shealevy.com wrote:
>>>> Hi Palmer,
>>>>
>>>> Palmer Dabbelt <palmer@sifive.com> writes:
>>>>
>>>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>>>>> These patches resolve the some issues of loadable module.
>>>>>>   - symbol out of ranges
>>>>>>   - unknown relocation types
>>>>>>
>>>>>> The reference of external variable and function symbols
>>>>>> cannot exceed 32-bit offset ranges in kernel module.
>>>>>> The module only can work on the 32-bit OS or the 64-bit
>>>>>> OS with sv32 virtual addressing.
>>>>>>
>>>>>> These patches will generate the .got, .got.plt and
>>>>>> .plt sections during loading module, let it can refer
>>>>>> to the symbol which locate more than 32-bit offset.
>>>>>> These sections depend on the relocation types:
>>>>>>  - R_RISCV_GOT_HI20
>>>>>>  - R_RISCV_CALL_PLT
>>>>>>
>>>>>> These patches also support more relocation types
>>>>>>  - R_RISCV_CALL
>>>>>>  - R_RISCV_HI20
>>>>>>  - R_RISCV_LO12_I
>>>>>>  - R_RISCV_LO12_S
>>>>>>  - R_RISCV_RVC_BRANCH
>>>>>>  - R_RISCV_RVC_JUMP
>>>>>>  - R_RISCV_ALIGN
>>>>>>  - R_RISCV_ADD32
>>>>>>  - R_RISCV_SUB32
>>>>>>
>>>>>> Zong Li (11):
>>>>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>>>>   RISC-V: Support CALL relocation type in kernel module
>>>>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>>>>   RISC-V: Enable module support in defconfig
>>>>>>   RISC-V: Add definition of relocation types
>>>>>>
>>>>>>  arch/riscv/Kconfig                  |   5 ++
>>>>>>  arch/riscv/Makefile                 |   3 +
>>>>>>  arch/riscv/configs/defconfig        |   2 +
>>>>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>>>>  arch/riscv/kernel/Makefile          |   1 +
>>>>>>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>>>>>>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>>>>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>>>>  create mode 100644 arch/riscv/kernel/module.lds
>>>>>
>>>>> This is the second set of patches that turn on modules, and it has the same
>>>>> R_RISCV_ALIGN problem as the other one
>>>>>
>>>>>     http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>>>>
>>>>> It looks like this one uses shared libraries for modules instead of static
>>>>> objects.  I think using shared objects is the right thing to do, as it'll allow
>>>>> us to place modules anywhere in the address space by having multiple GOTs and
>>>>> PLTs.
>>>>
>>>> Can you expand on this? It was my understanding that outside of the
>>>> context of multiple address spaces sharing code the GOT and PLT were
>>>> simply unnecessary overhead, what benefit would they bring here?
>>>
>>> We don't currently have any position-dependent RISC-V code models larger than
>>> "medany", in which all code and data must live within a single 32-bit
>>> addressable range.  The PLT and GOT sort of provide an out here, so the code
>>> only needs to get to the table (which can then get anywhere via an indirection
>>> layer).
>>>
>>> This is relevant for Linux modules because it lets us load modules anywhere in
>>> the address space.  It's also a bit of a headache, as it either requires a
>>> GOT+PLT per module (which is big) or merging tables (which is hard).
>>
>> I see, thanks! We only get this benefit if we actually do the relevanat
>> indirection in the table, right? And if we merge tables we still have to
>> have all modules within 32 bits of the common table? Is this how some
>> future "medlarge" code model will work, or is it more of a convenient
>> way to reuse existing techniques until other code models are worked out?
>
> The idea is that you'd merge the tables only when it's possible to do that
> correctly, which is the tricky part.
>
> It'd be called "largeany", the "med" part is what limits the code model to 32
> bit offsets.  We might just call it "large", as the "any" is kind of redundant.

Ah, right, that makes more sense :D. So would "mcmodel=large" also use
PLTs/GOTs for long jumps?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Palmer Dabbelt]

On Wed, 14 Mar 2018 10:11:49 PDT (-0700), shea@shealevy.com wrote:
> Palmer Dabbelt <palmer@sifive.com> writes:
>
>> On Wed, 14 Mar 2018 05:07:09 PDT (-0700), shea@shealevy.com wrote:
>>> Palmer Dabbelt <palmer@sifive.com> writes:
>>>
>>>> On Tue, 13 Mar 2018 14:30:53 PDT (-0700), shea@shealevy.com wrote:
>>>>> Hi Palmer,
>>>>>
>>>>> Palmer Dabbelt <palmer@sifive.com> writes:
>>>>>
>>>>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote:
>>>>>>> These patches resolve the some issues of loadable module.
>>>>>>>   - symbol out of ranges
>>>>>>>   - unknown relocation types
>>>>>>>
>>>>>>> The reference of external variable and function symbols
>>>>>>> cannot exceed 32-bit offset ranges in kernel module.
>>>>>>> The module only can work on the 32-bit OS or the 64-bit
>>>>>>> OS with sv32 virtual addressing.
>>>>>>>
>>>>>>> These patches will generate the .got, .got.plt and
>>>>>>> .plt sections during loading module, let it can refer
>>>>>>> to the symbol which locate more than 32-bit offset.
>>>>>>> These sections depend on the relocation types:
>>>>>>>  - R_RISCV_GOT_HI20
>>>>>>>  - R_RISCV_CALL_PLT
>>>>>>>
>>>>>>> These patches also support more relocation types
>>>>>>>  - R_RISCV_CALL
>>>>>>>  - R_RISCV_HI20
>>>>>>>  - R_RISCV_LO12_I
>>>>>>>  - R_RISCV_LO12_S
>>>>>>>  - R_RISCV_RVC_BRANCH
>>>>>>>  - R_RISCV_RVC_JUMP
>>>>>>>  - R_RISCV_ALIGN
>>>>>>>  - R_RISCV_ADD32
>>>>>>>  - R_RISCV_SUB32
>>>>>>>
>>>>>>> Zong Li (11):
>>>>>>>   RISC-V: Add sections of PLT and GOT for kernel module
>>>>>>>   RISC-V: Add section of GOT.PLT for kernel module
>>>>>>>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>>>>>>>   RISC-V: Support CALL relocation type in kernel module
>>>>>>>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>>>>>>>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>>>>>>>   RISC-V: Support ALIGN relocation type in kernel module
>>>>>>>   RISC-V: Support ADD32 relocation type in kernel module
>>>>>>>   RISC-V: Support SUB32 relocation type in kernel module
>>>>>>>   RISC-V: Enable module support in defconfig
>>>>>>>   RISC-V: Add definition of relocation types
>>>>>>>
>>>>>>>  arch/riscv/Kconfig                  |   5 ++
>>>>>>>  arch/riscv/Makefile                 |   3 +
>>>>>>>  arch/riscv/configs/defconfig        |   2 +
>>>>>>>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>>>>>>>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>>>>>>>  arch/riscv/kernel/Makefile          |   1 +
>>>>>>>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>>>>>>>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>>>>>>>  arch/riscv/kernel/module.lds        |   8 ++
>>>>>>>  9 files changed, 480 insertions(+), 6 deletions(-)
>>>>>>>  create mode 100644 arch/riscv/include/asm/module.h
>>>>>>>  create mode 100644 arch/riscv/kernel/module-sections.c
>>>>>>>  create mode 100644 arch/riscv/kernel/module.lds
>>>>>>
>>>>>> This is the second set of patches that turn on modules, and it has the same
>>>>>> R_RISCV_ALIGN problem as the other one
>>>>>>
>>>>>>     http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
>>>>>>
>>>>>> It looks like this one uses shared libraries for modules instead of static
>>>>>> objects.  I think using shared objects is the right thing to do, as it'll allow
>>>>>> us to place modules anywhere in the address space by having multiple GOTs and
>>>>>> PLTs.
>>>>>
>>>>> Can you expand on this? It was my understanding that outside of the
>>>>> context of multiple address spaces sharing code the GOT and PLT were
>>>>> simply unnecessary overhead, what benefit would they bring here?
>>>>
>>>> We don't currently have any position-dependent RISC-V code models larger than
>>>> "medany", in which all code and data must live within a single 32-bit
>>>> addressable range.  The PLT and GOT sort of provide an out here, so the code
>>>> only needs to get to the table (which can then get anywhere via an indirection
>>>> layer).
>>>>
>>>> This is relevant for Linux modules because it lets us load modules anywhere in
>>>> the address space.  It's also a bit of a headache, as it either requires a
>>>> GOT+PLT per module (which is big) or merging tables (which is hard).
>>>
>>> I see, thanks! We only get this benefit if we actually do the relevanat
>>> indirection in the table, right? And if we merge tables we still have to
>>> have all modules within 32 bits of the common table? Is this how some
>>> future "medlarge" code model will work, or is it more of a convenient
>>> way to reuse existing techniques until other code models are worked out?
>>
>> The idea is that you'd merge the tables only when it's possible to do that
>> correctly, which is the tricky part.
>>
>> It'd be called "largeany", the "med" part is what limits the code model to 32
>> bit offsets.  We might just call it "large", as the "any" is kind of redundant.
>
> Ah, right, that makes more sense :D. So would "mcmodel=large" also use
> PLTs/GOTs for long jumps?

We'd probably still restrict the size of single object files to 32-bit offsets,
but jumps outside of an object file would use an offset table.  Of course, none
of this is set in stone yet because we haven't fully figured out how to make
this all work.

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

[Shea Levy]

[-- Attachment #1: Type: text/plain, Size: 3527 bytes --]

Hello!

You may be interested in my recent patchset [1], which has known issues
but addresses the same problems yours does. It differs in the approach
taken here in that, rather than supporting GOT/PLT handling which we
can't really take advantage of anyway, we simply build non-PIC modules
instead [2]. Additionally, I see your patchset has the same concern mine
does, which is that ignoring ALIGN relaxations is not actually an option
[3]. The approach I plan to take is outlined by Palmer at [4].

As of now I hope to get back to my patchset this weekend, but if you're
close to a complete implementation by then maybe I can avoid duplicating
the work ;)

Thanks,
Shea

[1]: http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html
[2]: http://lists.infradead.org/pipermail/linux-riscv/2018-February/000080.html
[3]: http://lists.infradead.org/pipermail/linux-riscv/2018-February/000105.html
[4]: http://lists.infradead.org/pipermail/linux-riscv/2018-March/000147.html
Zong Li <zong@andestech.com> writes:

> These patches resolve the some issues of loadable module.
>   - symbol out of ranges
>   - unknown relocation types
>
> The reference of external variable and function symbols
> cannot exceed 32-bit offset ranges in kernel module.
> The module only can work on the 32-bit OS or the 64-bit
> OS with sv32 virtual addressing.
>
> These patches will generate the .got, .got.plt and
> .plt sections during loading module, let it can refer
> to the symbol which locate more than 32-bit offset.
> These sections depend on the relocation types:
>  - R_RISCV_GOT_HI20
>  - R_RISCV_CALL_PLT
>
> These patches also support more relocation types
>  - R_RISCV_CALL
>  - R_RISCV_HI20
>  - R_RISCV_LO12_I
>  - R_RISCV_LO12_S
>  - R_RISCV_RVC_BRANCH
>  - R_RISCV_RVC_JUMP
>  - R_RISCV_ALIGN
>  - R_RISCV_ADD32
>  - R_RISCV_SUB32
>
> Zong Li (11):
>   RISC-V: Add sections of PLT and GOT for kernel module
>   RISC-V: Add section of GOT.PLT for kernel module
>   RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
>   RISC-V: Support CALL relocation type in kernel module
>   RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
>   RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
>   RISC-V: Support ALIGN relocation type in kernel module
>   RISC-V: Support ADD32 relocation type in kernel module
>   RISC-V: Support SUB32 relocation type in kernel module
>   RISC-V: Enable module support in defconfig
>   RISC-V: Add definition of relocation types
>
>  arch/riscv/Kconfig                  |   5 ++
>  arch/riscv/Makefile                 |   3 +
>  arch/riscv/configs/defconfig        |   2 +
>  arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
>  arch/riscv/include/uapi/asm/elf.h   |  24 +++++
>  arch/riscv/kernel/Makefile          |   1 +
>  arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
>  arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
>  arch/riscv/kernel/module.lds        |   8 ++
>  9 files changed, 480 insertions(+), 6 deletions(-)
>  create mode 100644 arch/riscv/include/asm/module.h
>  create mode 100644 arch/riscv/kernel/module-sections.c
>  create mode 100644 arch/riscv/kernel/module.lds
>
> -- 
> 2.16.1
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]