Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: qQV5h89YymbQglQRl7vDunP8HRCeLZQNwWNwZwKnUzjcKUgfFzJzJMR+bKSJeHU/gWBm35e5HB
 C2ciMe0Mrg6GZ3hKWYTv7zdOnNN2TGnUcP2zO/UmB26V6pIG/gV/w7i+5pM+U/+ZO/ylv0n3sW
 RwIio1ClAzaEUP/RXtHmt9vezLO1aBLkPCRanIbUGu3oakHMZAe54qsll0JMFkFh0FXRMaxBGp
 OojrlKhfE8Xnj8U9B/A6OHBcP3XEszjTlFaMFOMbVpFf5YDI/2EdQrK0gRGpyDgPgdPcScyiG5
 3ZE=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     Al Viro <viro@zeniv.linux.org.uk>, Christoph Hellwig <hch@lst.de>
CC:     Palmer Dabbelt <palmer@dabbelt.com>,
        "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "jcmvbkbc@gmail.com" <jcmvbkbc@gmail.com>,
        "gerg@linux-m68k.org" <gerg@linux-m68k.org>,
        Anup Patel <Anup.Patel@wdc.com>,
        "uclinux-dev@uclinux.org" <uclinux-dev@uclinux.org>
Subject: Re: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
Thread-Topic: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V
Thread-Index: AQHXK8WacfnVzM4zUUS2ex+k23Zi9Q==
Date:   Fri, 16 Apr 2021 00:26:27 +0000
Message-ID: <BL0PR04MB65143E710571C8CE7E7F0FB0E74C9@BL0PR04MB6514.namprd04.prod.outlook.com>
References: <BL0PR04MB65148D80C819A7E3B8365242E74D9@BL0PR04MB6514.namprd04.prod.outlook.com>
 <mhng-61cff5f4-32a0-417d-9a2f-eb6d052cf802@palmerdabbelt-glaptop>
 <20210415055605.GB8947@lst.de> <YHjYoDA2JPxSYVu0@zeniv-ca.linux.org.uk>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c8512ce1-44b9-40f1-1346-08d9006e462b
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2021 00:26:27.0986
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZHT04CDAsT9wWBAHUclBG/pknEDwrZVeAiKM6kHo7Zhp0bLs7fgadX7CehUOqhufCGp+fsNnz0gD6EjhdRA5mg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR04MB7072
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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=