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), s...@shealevy.com wrote:

Palmer Dabbelt  writes:


On Wed, 14 Mar 2018 05:07:09 PDT (-0700), s...@shealevy.com wrote:

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 14:30:53 PDT (-0700), s...@shealevy.com wrote:

Hi Palmer,

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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

[Palmer Dabbelt]

On Wed, 14 Mar 2018 10:11:49 PDT (-0700), s...@shealevy.com wrote:

Palmer Dabbelt  writes:


On Wed, 14 Mar 2018 05:07:09 PDT (-0700), s...@shealevy.com wrote:

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 14:30:53 PDT (-0700), s...@shealevy.com wrote:

Hi Palmer,

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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]

Palmer Dabbelt  writes:

> On Wed, 14 Mar 2018 05:07:09 PDT (-0700), s...@shealevy.com wrote:
>> Palmer Dabbelt  writes:
>>
>>> On Tue, 13 Mar 2018 14:30:53 PDT (-0700), s...@shealevy.com wrote:
 Hi Palmer,

 Palmer Dabbelt  writes:

> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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?


signature.asc

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

[Shea Levy]

Palmer Dabbelt  writes:

> On Wed, 14 Mar 2018 05:07:09 PDT (-0700), s...@shealevy.com wrote:
>> Palmer Dabbelt  writes:
>>
>>> On Tue, 13 Mar 2018 14:30:53 PDT (-0700), s...@shealevy.com wrote:
 Hi Palmer,

 Palmer Dabbelt  writes:

> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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?


signature.asc
Description: PGP signature

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), s...@shealevy.com wrote:

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zong...@gmail.com wrote:

2018-03-14 5:30 GMT+08:00 Shea Levy :

Hi Palmer,

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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

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), s...@shealevy.com wrote:

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zong...@gmail.com wrote:

2018-03-14 5:30 GMT+08:00 Shea Levy :

Hi Palmer,

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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 

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), s...@shealevy.com wrote:

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 14:30:53 PDT (-0700), s...@shealevy.com wrote:

Hi Palmer,

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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

[Palmer Dabbelt]

On Wed, 14 Mar 2018 05:07:09 PDT (-0700), s...@shealevy.com wrote:

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 14:30:53 PDT (-0700), s...@shealevy.com wrote:

Hi Palmer,

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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

[Zong Li]

2018-03-14 19:56 GMT+08:00 Shea Levy :
> Zong Li  writes:
>
>> 2018-03-14 11:07 GMT+08:00 Palmer Dabbelt :
>>> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zong...@gmail.com wrote:

 2018-03-14 5:30 GMT+08:00 Shea Levy :
>
> Hi Palmer,
>
> Palmer Dabbelt  writes:
>
>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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 

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 :
> Zong Li  writes:
>
>> 2018-03-14 11:07 GMT+08:00 Palmer Dabbelt :
>>> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zong...@gmail.com wrote:

 2018-03-14 5:30 GMT+08:00 Shea Levy :
>
> Hi Palmer,
>
> Palmer Dabbelt  writes:
>
>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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 

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

[Shea Levy]

Palmer Dabbelt  writes:

> On Tue, 13 Mar 2018 14:30:53 PDT (-0700), s...@shealevy.com wrote:
>> Hi Palmer,
>>
>> Palmer Dabbelt  writes:
>>
>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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


signature.asc
Description: PGP signature

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

[Shea Levy]

Palmer Dabbelt  writes:

> On Tue, 13 Mar 2018 14:30:53 PDT (-0700), s...@shealevy.com wrote:
>> Hi Palmer,
>>
>> Palmer Dabbelt  writes:
>>
>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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


signature.asc
Description: PGP signature

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

[Shea Levy]

Zong Li  writes:

> 2018-03-14 11:07 GMT+08:00 Palmer Dabbelt :
>> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zong...@gmail.com wrote:
>>>
>>> 2018-03-14 5:30 GMT+08:00 Shea Levy :

 Hi Palmer,

 Palmer Dabbelt  writes:

> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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 

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

[Shea Levy]

Zong Li  writes:

> 2018-03-14 11:07 GMT+08:00 Palmer Dabbelt :
>> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zong...@gmail.com wrote:
>>>
>>> 2018-03-14 5:30 GMT+08:00 Shea Levy :

 Hi Palmer,

 Palmer Dabbelt  writes:

> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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 

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

[Shea Levy]

Palmer Dabbelt  writes:

> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zong...@gmail.com wrote:
>> 2018-03-14 5:30 GMT+08:00 Shea Levy :
>>> Hi Palmer,
>>>
>>> Palmer Dabbelt  writes:
>>>
 On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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 

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

[Shea Levy]

Palmer Dabbelt  writes:

> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zong...@gmail.com wrote:
>> 2018-03-14 5:30 GMT+08:00 Shea Levy :
>>> Hi Palmer,
>>>
>>> Palmer Dabbelt  writes:
>>>
 On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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 

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 :
> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zong...@gmail.com wrote:
>>
>> 2018-03-14 5:30 GMT+08:00 Shea Levy :
>>>
>>> Hi Palmer,
>>>
>>> Palmer Dabbelt  writes:
>>>
 On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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.

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 :
> On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zong...@gmail.com wrote:
>>
>> 2018-03-14 5:30 GMT+08:00 Shea Levy :
>>>
>>> Hi Palmer,
>>>
>>> Palmer Dabbelt  writes:
>>>
 On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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=151860828416766

so maybe we can use the `medany + fPIC` 

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), s...@shealevy.com wrote:

Hi Palmer,

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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

[Palmer Dabbelt]

On Tue, 13 Mar 2018 14:30:53 PDT (-0700), s...@shealevy.com wrote:

Hi Palmer,

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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

[Palmer Dabbelt]

On Tue, 13 Mar 2018 18:34:19 PDT (-0700), zong...@gmail.com wrote:

2018-03-14 5:30 GMT+08:00 Shea Levy :

Hi Palmer,

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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 

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), zong...@gmail.com wrote:

2018-03-14 5:30 GMT+08:00 Shea Levy :

Hi Palmer,

Palmer Dabbelt  writes:


On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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 

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 :
> Hi Palmer,
>
> Palmer Dabbelt  writes:
>
>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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

[Zong Li]

2018-03-14 5:30 GMT+08:00 Shea Levy :
> Hi Palmer,
>
> Palmer Dabbelt  writes:
>
>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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

[Shea Levy]

Hi Palmer,

Palmer Dabbelt  writes:

> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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.


signature.asc
Description: PGP signature

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

[Shea Levy]

Hi Palmer,

Palmer Dabbelt  writes:

> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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.


signature.asc
Description: PGP signature

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

[Shea Levy]

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/81.html
[2]: http://lists.infradead.org/pipermail/linux-riscv/2018-February/80.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  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-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


signature.asc
Description: PGP signature

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

[Shea Levy]

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/81.html
[2]: http://lists.infradead.org/pipermail/linux-riscv/2018-February/80.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  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-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


signature.asc
Description: PGP signature

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), z...@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/81.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

[Palmer Dabbelt]

On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@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/81.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

[Zong Li]

2018-03-13 16:35 GMT+08:00 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
>

This is the list of testing modules:

# lsmod
btrfs 7876158 0 - Live 0xffd00745d000
ramoops 90806 0 - Live 0xffd0024b8000
lzo 10554 0 - Live 0xffd00205
zstd_decompress 567575 1 btrfs, Live 0xffd00238b000
zstd_compress 1543837 1 btrfs, Live 0xffd002211000
zram 101300 0 - Live 0xffd0021b8000
xxhash 62254 2 zstd_decompress,zstd_compress, Live 0xffd0020cf000
xor 33246 1 btrfs, Live 0xffd002042000
xfs 4395343 0 - Live 0xffd00399e000
tun 252041 0 - Live 0xffd0038e
test_user_copy 5265 0 - Live 0xffd003783000
test_static_keys 19606 0 - Live 0xffd003717000
test_static_key_base 7374 1 test_static_keys, Live 0xffd0036dc000
test_printf 7804 0 [permanent], Live 0xffd00369c000
test_module 1557 0 - Live 0xffd003646000
test_kmod 49100 0 - Live 0xffd0035f2000
test_bpf 1599301 0 - Live 0xffd00300
test_bitmap 4403 0 - Live 0xffd002dd8000
reed_solomon 38866 1 ramoops, Live 0xffd002d86000
raid6_pq 161872 1 btrfs, Live 0xffd002b9e000
netdevsim 65401 0 - Live 0xffd00291
lzo_decompress 9580 2 btrfs,lzo, Live 0xffd002813000
lzo_compress 21527 2 btrfs,lzo, Live 0xffd0027d9000
libcrc32c 2730 1 xfs, Live 0xffd00273c000
fuse 676371 0 - Live 0xffd0024d
exportfs 24850 1 xfs, Live 0xffd0020c7000
echainiv 11953 0 - Live 0xffd00205a000

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 :
>
> 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 0xffd00745d000
ramoops 90806 0 - Live 0xffd0024b8000
lzo 10554 0 - Live 0xffd00205
zstd_decompress 567575 1 btrfs, Live 0xffd00238b000
zstd_compress 1543837 1 btrfs, Live 0xffd002211000
zram 101300 0 - Live 0xffd0021b8000
xxhash 62254 2 zstd_decompress,zstd_compress, Live 0xffd0020cf000
xor 33246 1 btrfs, Live 0xffd002042000
xfs 4395343 0 - Live 0xffd00399e000
tun 252041 0 - Live 0xffd0038e
test_user_copy 5265 0 - Live 0xffd003783000
test_static_keys 19606 0 - Live 0xffd003717000
test_static_key_base 7374 1 test_static_keys, Live 0xffd0036dc000
test_printf 7804 0 [permanent], Live 0xffd00369c000
test_module 1557 0 - Live 0xffd003646000
test_kmod 49100 0 - Live 0xffd0035f2000
test_bpf 1599301 0 - Live 0xffd00300
test_bitmap 4403 0 - Live 0xffd002dd8000
reed_solomon 38866 1 ramoops, Live 0xffd002d86000
raid6_pq 161872 1 btrfs, Live 0xffd002b9e000
netdevsim 65401 0 - Live 0xffd00291
lzo_decompress 9580 2 btrfs,lzo, Live 0xffd002813000
lzo_compress 21527 2 btrfs,lzo, Live 0xffd0027d9000
libcrc32c 2730 1 xfs, Live 0xffd00273c000
fuse 676371 0 - Live 0xffd0024d
exportfs 24850 1 xfs, Live 0xffd0020c7000
echainiv 11953 0 - Live 0xffd00205a000

[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 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