Re: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
On 16/4/21 10:26 am, Damien Le Moal wrote:
On 2021/04/16 9:22, Al Viro wrote:
On Thu, Apr 15, 2021 at 07:56:05AM +0200, Christoph Hellwig wrote:
binfmt_flat tends to go through Greg's uclinux tree, adding him and
the list.
FWIW, my involvement with binfmt_flat had been pretty much nil -
the least trivial had been "binfmt_flat: flat_{get,put}_addr_from_rp()
should be able to fail" about 4 years ago and that fell out of hunting
for places where __get_user() had been used without checking error values.
It's in fs/*, but I've no way to test it and I have pretty much
zero familiarity with the guts of that one, so I can't give any useful
feedback on that series. So consider the Christoph's comment seconded -
you want it reviewed by gerg et.al., and it probably ought to go via
gerg/uclinux.git tree.
I'm reasonably familiar with binfmt_{elf,misc,script}; anything
else gets touched as part of larger series and only with sanity checks
from other folks, if the changes are not entirely trivial.
Al,
Thanks for the clarification. Would it make sense to have an entry in
MAINTAINERS file pointing to Greg and the uclinux tree for binfmt_flat.c ?
Greg ?
Yep, looks like it does need that.
Regards
Greg
Re: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
On 2021/04/16 9:22, Al Viro wrote:
> On Thu, Apr 15, 2021 at 07:56:05AM +0200, Christoph Hellwig wrote:
>> binfmt_flat tends to go through Greg's uclinux tree, adding him and
>> the list.
>
> FWIW, my involvement with binfmt_flat had been pretty much nil -
> the least trivial had been "binfmt_flat: flat_{get,put}_addr_from_rp()
> should be able to fail" about 4 years ago and that fell out of hunting
> for places where __get_user() had been used without checking error values.
>
> It's in fs/*, but I've no way to test it and I have pretty much
> zero familiarity with the guts of that one, so I can't give any useful
> feedback on that series. So consider the Christoph's comment seconded -
> you want it reviewed by gerg et.al., and it probably ought to go via
> gerg/uclinux.git tree.
>
> I'm reasonably familiar with binfmt_{elf,misc,script}; anything
> else gets touched as part of larger series and only with sanity checks
> from other folks, if the changes are not entirely trivial.
Al,
Thanks for the clarification. Would it make sense to have an entry in
MAINTAINERS file pointing to Greg and the uclinux tree for binfmt_flat.c ?
Greg ?
--
Damien Le Moal
Western Digital Research
Re: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
On Thu, Apr 15, 2021 at 07:56:05AM +0200, Christoph Hellwig wrote:
> binfmt_flat tends to go through Greg's uclinux tree, adding him and
> the list.
FWIW, my involvement with binfmt_flat had been pretty much nil -
the least trivial had been "binfmt_flat: flat_{get,put}_addr_from_rp()
should be able to fail" about 4 years ago and that fell out of hunting
for places where __get_user() had been used without checking error values.
It's in fs/*, but I've no way to test it and I have pretty much
zero familiarity with the guts of that one, so I can't give any useful
feedback on that series. So consider the Christoph's comment seconded -
you want it reviewed by gerg et.al., and it probably ought to go via
gerg/uclinux.git tree.
I'm reasonably familiar with binfmt_{elf,misc,script}; anything
else gets touched as part of larger series and only with sanity checks
from other folks, if the changes are not entirely trivial.
Re: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
On 2021/04/15 14:56, Christoph Hellwig wrote: > binfmt_flat tends to go through Greg's uclinux tree, adding him and > the list. Thanks Christoph. I resent the series adding Gerg and uclinux-dev. MAINTAINERS file needs an update may be ? > > On Wed, Apr 14, 2021 at 10:46:36PM -0700, Palmer Dabbelt wrote: >> On Wed, 14 Apr 2021 17:32:10 PDT (-0700), Damien Le Moal wrote: On 2021/04/08 0:49, Damien Le Moal wrote: RISC-V NOMMU flat binaries cannot tolerate a gap between the text and data section as the toolchain fully resolves at compile time the PC relative global pointer (__global_pointer$ value loaded in gp register). Without a relocation entry provided, the flat bin loader cannot fix the value if a gap is introduced and executables fail to run. This series fixes this problem by allowing an architecture to request the flat loader to suppress the gap between the text and data sections. The first patch fixes binfmt_flat flat_load_file() using the new configuration option CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP. The second patch enables this option for RISCV NOMMU builds. These patches do not change the binfmt_flat loader behavior for other architectures. Changes from v1: * Replace FLAT_TEXT_DATA_NO_GAP macro with CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP config option (patch 1). * Remove the addition of riscv/include/asm/flat.h and set CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP for RISCV and !MMU Damien Le Moal (2): binfmt_flat: allow not offsetting data start riscv: Disable text-data gap in flat binaries arch/riscv/Kconfig | 1 + fs/Kconfig.binfmt | 3 +++ fs/binfmt_flat.c | 21 +++-- 3 files changed, 19 insertions(+), 6 deletions(-) >>> >>> Ping ? >>> >>> Any comment on these patches ? >>> >>> Without them, RISC-V NOMMU user space does not run... I would really like >>> to get >>> these in this cycle if possible. >> >> This LGTM, but it's pretty far out of my area of expertise. I'm happy to >> take them via my tree, but I'd prefer to get an Ack from someone. >> >> Al, get_maintainer suggests you? >> >> Acked-by: Palmer Dabbelt > ---end quoted text--- > -- Damien Le Moal Western Digital Research
Re: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
binfmt_flat tends to go through Greg's uclinux tree, adding him and the list. On Wed, Apr 14, 2021 at 10:46:36PM -0700, Palmer Dabbelt wrote: > On Wed, 14 Apr 2021 17:32:10 PDT (-0700), Damien Le Moal wrote: >>> On 2021/04/08 0:49, Damien Le Moal wrote: >>> RISC-V NOMMU flat binaries cannot tolerate a gap between the text and >>> data section as the toolchain fully resolves at compile time the PC >>> relative global pointer (__global_pointer$ value loaded in gp register). >>> Without a relocation entry provided, the flat bin loader cannot fix the >>> value if a gap is introduced and executables fail to run. >>> >>> This series fixes this problem by allowing an architecture to request >>> the flat loader to suppress the gap between the text and data sections. >>> The first patch fixes binfmt_flat flat_load_file() using the new >>> configuration option CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP. The second >>> patch enables this option for RISCV NOMMU builds. >>> >>> These patches do not change the binfmt_flat loader behavior for other >>> architectures. >>> >>> Changes from v1: >>> * Replace FLAT_TEXT_DATA_NO_GAP macro with >>> CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP config option (patch 1). >>> * Remove the addition of riscv/include/asm/flat.h and set >>> CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP for RISCV and !MMU >>> >>> Damien Le Moal (2): >>> binfmt_flat: allow not offsetting data start >>> riscv: Disable text-data gap in flat binaries >>> >>> arch/riscv/Kconfig | 1 + >>> fs/Kconfig.binfmt | 3 +++ >>> fs/binfmt_flat.c | 21 +++-- >>> 3 files changed, 19 insertions(+), 6 deletions(-) >>> >> >> Ping ? >> >> Any comment on these patches ? >> >> Without them, RISC-V NOMMU user space does not run... I would really like to >> get >> these in this cycle if possible. > > This LGTM, but it's pretty far out of my area of expertise. I'm happy to > take them via my tree, but I'd prefer to get an Ack from someone. > > Al, get_maintainer suggests you? > > Acked-by: Palmer Dabbelt ---end quoted text---
Re: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
On Wed, 14 Apr 2021 17:32:10 PDT (-0700), Damien Le Moal wrote: On 2021/04/08 0:49, Damien Le Moal wrote: RISC-V NOMMU flat binaries cannot tolerate a gap between the text and data section as the toolchain fully resolves at compile time the PC relative global pointer (__global_pointer$ value loaded in gp register). Without a relocation entry provided, the flat bin loader cannot fix the value if a gap is introduced and executables fail to run. This series fixes this problem by allowing an architecture to request the flat loader to suppress the gap between the text and data sections. The first patch fixes binfmt_flat flat_load_file() using the new configuration option CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP. The second patch enables this option for RISCV NOMMU builds. These patches do not change the binfmt_flat loader behavior for other architectures. Changes from v1: * Replace FLAT_TEXT_DATA_NO_GAP macro with CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP config option (patch 1). * Remove the addition of riscv/include/asm/flat.h and set CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP for RISCV and !MMU Damien Le Moal (2): binfmt_flat: allow not offsetting data start riscv: Disable text-data gap in flat binaries arch/riscv/Kconfig | 1 + fs/Kconfig.binfmt | 3 +++ fs/binfmt_flat.c | 21 +++-- 3 files changed, 19 insertions(+), 6 deletions(-) Ping ? Any comment on these patches ? Without them, RISC-V NOMMU user space does not run... I would really like to get these in this cycle if possible. This LGTM, but it's pretty far out of my area of expertise. I'm happy to take them via my tree, but I'd prefer to get an Ack from someone. Al, get_maintainer suggests you? Acked-by: Palmer Dabbelt
Re: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
On 2021/04/08 0:49, Damien Le Moal wrote: > RISC-V NOMMU flat binaries cannot tolerate a gap between the text and > data section as the toolchain fully resolves at compile time the PC > relative global pointer (__global_pointer$ value loaded in gp register). > Without a relocation entry provided, the flat bin loader cannot fix the > value if a gap is introduced and executables fail to run. > > This series fixes this problem by allowing an architecture to request > the flat loader to suppress the gap between the text and data sections. > The first patch fixes binfmt_flat flat_load_file() using the new > configuration option CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP. The second > patch enables this option for RISCV NOMMU builds. > > These patches do not change the binfmt_flat loader behavior for other > architectures. > > Changes from v1: > * Replace FLAT_TEXT_DATA_NO_GAP macro with > CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP config option (patch 1). > * Remove the addition of riscv/include/asm/flat.h and set > CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP for RISCV and !MMU > > Damien Le Moal (2): > binfmt_flat: allow not offsetting data start > riscv: Disable text-data gap in flat binaries > > arch/riscv/Kconfig | 1 + > fs/Kconfig.binfmt | 3 +++ > fs/binfmt_flat.c | 21 +++-- > 3 files changed, 19 insertions(+), 6 deletions(-) > Ping ? Any comment on these patches ? Without them, RISC-V NOMMU user space does not run... I would really like to get these in this cycle if possible. -- Damien Le Moal Western Digital Research
[PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
RISC-V NOMMU flat binaries cannot tolerate a gap between the text and data section as the toolchain fully resolves at compile time the PC relative global pointer (__global_pointer$ value loaded in gp register). Without a relocation entry provided, the flat bin loader cannot fix the value if a gap is introduced and executables fail to run. This series fixes this problem by allowing an architecture to request the flat loader to suppress the gap between the text and data sections. The first patch fixes binfmt_flat flat_load_file() using the new configuration option CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP. The second patch enables this option for RISCV NOMMU builds. These patches do not change the binfmt_flat loader behavior for other architectures. Changes from v1: * Replace FLAT_TEXT_DATA_NO_GAP macro with CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP config option (patch 1). * Remove the addition of riscv/include/asm/flat.h and set CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP for RISCV and !MMU Damien Le Moal (2): binfmt_flat: allow not offsetting data start riscv: Disable text-data gap in flat binaries arch/riscv/Kconfig | 1 + fs/Kconfig.binfmt | 3 +++ fs/binfmt_flat.c | 21 +++-- 3 files changed, 19 insertions(+), 6 deletions(-) -- 2.30.2
