[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BL0PR04MB65143E710571C8CE7E7F0FB0E74C9@BL0PR04MB6514.namprd04.prod.outlook.com>
Date: Fri, 16 Apr 2021 00:26:27 +0000
From: Damien Le Moal <Damien.LeMoal@....com>
To: Al Viro <viro@...iv.linux.org.uk>, Christoph Hellwig <hch@....de>
CC: Palmer Dabbelt <palmer@...belt.com>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"jcmvbkbc@...il.com" <jcmvbkbc@...il.com>,
"gerg@...ux-m68k.org" <gerg@...ux-m68k.org>,
Anup Patel <Anup.Patel@....com>,
"uclinux-dev@...inux.org" <uclinux-dev@...inux.org>
Subject: 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
Powered by blists - more mailing lists