Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp881906pxf; Wed, 7 Apr 2021 14:03:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzDV+KBRHizaJDyzNe4+0jSSlu6Mhmnl8cEDeC9qZz5Wy8wixuidMn2SUwaBNfS3OUHhDtZ X-Received: by 2002:a17:906:4347:: with SMTP id z7mr4622531ejm.246.1617829421346; Wed, 07 Apr 2021 14:03:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617829421; cv=none; d=google.com; s=arc-20160816; b=pAkvYjx/51GXkLAqkYNaYyDENqT600L8OP3bpZ4u5JUHPf3WO+jhV69wjPnZ/C4fJc oOGaRjOpgaCk7fw19qakRl94bulwe0f2hmtkKtAqK/1hjHcA/7PAH3fvJ01XkYxL3XAb fBKbvE6oEAcAp4OIiGNHaxRbVQSwyGwYdcNQKZ0Gc5vmnrb0TiWpsvcE1S2PrGpuBqVP ginSmkssmF71DZ9xpTdDGtEBxtiT5K/xpLGcFrRgBvH+IVZnrmiF7x9VAgpvg1mFKSTD ohLhYh6fj4zBVol54pbO6xLGYNGmyLEBHKD9SJQKmKkVk3lj474tdDliNkQpxOrPCgKS M61A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=0nDJOtzdVtaN8ORmzKafZoh53B1CYisRHfet8EWrH6Q=; b=bMJC4os9VN7qlMagJ4AmzmfpUeDToXEjA7aRcJFN8rBKQaAJYgCPvEg45P5YjI5xNI NS3kzDoC8z5f5TKZRvpmFhX5/a2j6LlntoXMtFVrrEpNigvk0WYiQ/+b1uWVjiuqh71k OqAOlv+2tevtBCq0aqSYXdGsyhy4b+T0x5jjbzmJhaXtLkif5KfzkzLkfExsU3Asrjp9 MrewCqNxrRyQvMmuea29VMwO0laAHAFlWUcq3LjRKbYsR6iMEpuDHfpdi5hgRTUQwAzr WeC3RQQs2I7O65jDtu48JWVhm0KZZ3TOaY3MT0/EXE00hu2xjKI8EBRDzhhdBBTORwiU xv5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u18si19766006ejk.68.2021.04.07.14.03.18; Wed, 07 Apr 2021 14:03:41 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344124AbhDGOON (ORCPT + 99 others); Wed, 7 Apr 2021 10:14:13 -0400 Received: from verein.lst.de ([213.95.11.211]:59521 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243083AbhDGOOM (ORCPT ); Wed, 7 Apr 2021 10:14:12 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 3A0CA68C4E; Wed, 7 Apr 2021 16:14:00 +0200 (CEST) Date: Wed, 7 Apr 2021 16:13:59 +0200 From: Christoph Hellwig To: Damien Le Moal Cc: Palmer Dabbelt , linux-riscv@lists.infradead.org, Alexander Viro , linux-kernel@vger.kernel.org, Max Filippov , Greg Ungerer , Anup Patel , Christoph Hellwig Subject: Re: [PATCH 1/2] binfmt_flat: allow not offsetting data start Message-ID: <20210407141359.GA19843@lst.de> References: <20210407115638.1055824-1-damien.lemoal@wdc.com> <20210407115638.1055824-2-damien.lemoal@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210407115638.1055824-2-damien.lemoal@wdc.com> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 07, 2021 at 08:56:37PM +0900, Damien Le Moal wrote: > Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset > the data start"") restored offsetting the start of the data section by > a number of words defined by MAX_SHARED_LIBS. As a result, since > MAX_SHARED_LIBS is never 0, a gap between the text and data sections > always exist. For architecture which cannot support a such gap between > the text and data sections (e.g. riscv nommu), flat binary programs > cannot be executed. > > To allow an architecture to request contiguous text and data sections, > introduce the macro FLAT_TEXT_DATA_NO_GAP which can be defined by the > architecture in its asm/flat.h file. With this change, the macro > DATA_GAP_WORDS is conditionally defined in binfmt_flat.c to > MAX_SHARED_LIBS for architectures tolerating the gap > (FLAT_TEXT_DATA_NO_GAP undefined case) and to 0 when > FLAT_TEXT_DATA_NO_GAP is defined. DATA_GAP_WORDS is used in > load_flat_file() to calculate the data section length and start > position. > > The definition of FLAT_TEXT_DATA_NO_GAP by an architecture also > prevents the use of the separate text/data load case (when > FLAT_FLAG_RAM and FLAT_FLAG_GZIP are not set with NOMMU kernels). Please make this a CONFIG_* option selected by the architecture, which also allows to use IS_ENABLED() to error out early for your check.