Re: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
Damien Le Moal <[email protected]> Fri, 16 Apr 2021 00:26:27 +0000
| Newsgroups | gmane.linux.kernel,gmane.linux.ports.riscv,gmane.linux.uclinux.devel |
|---|---|
| Message-ID | <BL0PR04MB65143E710571C8CE7E7F0FB0E74C9@BL0PR04MB6514.namprd04.prod.outlook.com> |
On 2021/04/16 9:22, Al Viro wrote:=0A=
> On Thu, Apr 15, 2021 at 07:56:05AM +0200, Christoph Hellwig wrote:=0A=
>> binfmt_flat tends to go through Greg's uclinux tree, adding him and=0A=
>> the list.=0A=
> =0A=
> FWIW, my involvement with binfmt_flat had been pretty much nil -=0A=
> the least trivial had been "binfmt_flat: flat_{get,put}_addr_from_rp()=0A=
> should be able to fail" about 4 years ago and that fell out of hunting=0A=
> for places where __get_user() had been used without checking error values=
.=0A=
> =0A=
> It's in fs/*, but I've no way to test it and I have pretty much=0A=
> zero familiarity with the guts of that one, so I can't give any useful=0A=
> feedback on that series. So consider the Christoph's comment seconded -=
=0A=
> you want it reviewed by gerg et.al., and it probably ought to go via=0A=
> gerg/uclinux.git tree.=0A=
> =0A=
> I'm reasonably familiar with binfmt_{elf,misc,script}; anything=0A=
> else gets touched as part of larger series and only with sanity checks=0A=
> from other folks, if the changes are not entirely trivial.=0A=
=0A=
Al,=0A=
=0A=
Thanks for the clarification. Would it make sense to have an entry in=0A=
MAINTAINERS file pointing to Greg and the uclinux tree for binfmt_flat.c ?=
=0A=
Greg ?=0A=
=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=