linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Yury Norov <yury.norov@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	"linux-audit/audit-kernel" 
	<reply+ADSN7RXLQ62LNLD2MK5HFHF65GIU3EVBNHHDPMBXHU@reply.github.com>,
	"linux-audit/audit-kernel" <audit-kernel@noreply.github.com>,
	Mention <mention@noreply.github.com>,
	Xiongfeng Wang <wangxiongfeng2@huawei.com>,
	Wang ShaoBo <bobo.shaobowang@huawei.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	Adam Borowski <kilobyte@angband.pl>,
	Alexander Graf <agraf@suse.de>,
	Alexey Klimov <klimov.linux@gmail.com>,
	Andreas Schwab <schwab@suse.de>,
	Andrew Pinski <pinskia@gmail.com>,
	Bamvor Zhangjian <bamv2005@gmail.com>,
	Chris Metcalf <cmetcalf@mellanox.com>,
	Christoph Muellner <christoph.muellner@theobroma-systems.com>,
	Dave Martin <Dave.Martin@arm.com>,
	"David S . Miller" <davem@davemloft.net>,
	Florian Weimer <fweimer@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	James Hogan <james.hogan@imgtec.com>,
	James Morse <james.morse@arm.com>,
	Joseph Myers <joseph@codesourcery.com>,
	Lin Yongting <linyongting@huawei.com>,
	Manuel Montezelo <manuel.montezelo@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
	Nathan_Lynch <Nathan_Lynch@mentor.com>,
	Philipp Tomsich <philipp.tomsich@theobroma-systems.com>,
	Prasun Kapoor <Prasun.Kapoor@caviumnetworks.com>,
	Ramana Radhakrishnan <ramana.gcc@googlemail.com>,
	Steve Ellcey <sellcey@caviumnetworks.com>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>
Subject: Re: [linux-audit/audit-kernel] BUG: audit_classify_syscall() fails to properly handle 64-bit syscalls when executing as 32-bit application on ARM (#131)
Date: Mon, 5 Jul 2021 15:40:17 +0200	[thread overview]
Message-ID: <CAK8P3a0L4YU2q6WCZviNJGzAuQniwrZDKc7w1nHMB276hZzG6Q@mail.gmail.com> (raw)
In-Reply-To: <YN9V/qM0mxIYXt3h@yury-ThinkPad>

On Fri, Jul 2, 2021 at 8:07 PM Yury Norov <yury.norov@gmail.com> wrote:
> On Thu, Jul 01, 2021 at 05:08:45AM -0700, Paul Moore wrote:
>
> To Catalin, Arnd:
>
> At least Marvell, Samsung, Huawei, Cisco and Weiyuchen's employer
> actively use and develop arm64/ilp32. I receive feedback / bugrepotrs
> on ilp32 every 4-6 month. Is that enough for you to reconsider
> including the project into the mainline?
>
> For me, having different versions of ILP32 is more dangerous in this
> situation, than upstreaming the project and fixing 2-3 bugs a year.

I think the overall tradeoff is not that different from what it was in the
past. Keeping it out of the tree clearly creates extra work both for you
and the users, but reduces the overhead for everyone else, who
can ignore that corner case. We have tried removing both x86-x32
support and arm64 big-endian support from the kernel not that long
ago. Both have considerably more impact on kernel maintenance than
your aarch64-ilp32 work, and they probably even have fewer users,
but we always ended up keeping the status quo.

However, there are clearly some changes that happened over the
past few years that may be relevant here:

- The expectation in the past was that ilp32 support would eventually
   go away as users move on to full 64-bit support. It has survived a
   lot longer than I would have guessed, but I still find it hard to tell
   whether this would continue. What's more important than the current
   number of users is how many of those you expect to run linux-6.x
   or linux-7.x with aarch64-ilp32 in the future.

- Another thing that has changed is that we now have a rough timeline
  for aarch32 support to be removed from future Arm processors. If
  no Armv9 processors after 2022 support Aarch32 mode, we may see
  interest in ilp32 mode go up between 2025 and 2030 when those
  processors make it into more markets.

- On the other hand, interest in not just 32-bit hardware running Linux
  but also in 32-bit user space is already declining overall. We'll
  probably still see some 10 to 20 years of 32-bit user space
  deployments on (mostly) memory constrained systems, but this
  is getting increasingly obscure as more applications run into
  virtual memory space restrictions (3GB or 4GB typically) before
  they exceed the available RAM. On RV64 and ARCv3, there is
  already a conclusion that they will not support 32-bit user space,
  neither ilp32 style on 64-bit instructions nor with hardware support
  for RV32/ARC32 binaries. I expect the same for Loongarch.

          Arnd

      parent reply	other threads:[~2021-07-05 13:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <linux-audit/audit-kernel/issues/131@github.com>
     [not found] ` <linux-audit/audit-kernel/issues/131/872191450@github.com>
2021-07-02 18:07   ` [linux-audit/audit-kernel] BUG: audit_classify_syscall() fails to properly handle 64-bit syscalls when executing as 32-bit application on ARM (#131) Yury Norov
2021-07-02 18:19     ` Florian Weimer
2021-07-05  9:36       ` Szabolcs Nagy
2021-07-05 11:55         ` Arnd Bergmann
2021-07-05 12:09           ` Szabolcs Nagy
2021-07-05 10:48     ` Andreas Schwab
2021-07-07 18:44       ` Yury Norov
2021-07-07 18:54         ` Paul Moore
2021-07-05 13:40     ` Arnd Bergmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK8P3a0L4YU2q6WCZviNJGzAuQniwrZDKc7w1nHMB276hZzG6Q@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=Dave.Martin@arm.com \
    --cc=Nathan_Lynch@mentor.com \
    --cc=Prasun.Kapoor@caviumnetworks.com \
    --cc=agraf@suse.de \
    --cc=audit-kernel@noreply.github.com \
    --cc=bamv2005@gmail.com \
    --cc=bobo.shaobowang@huawei.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoph.muellner@theobroma-systems.com \
    --cc=cmetcalf@mellanox.com \
    --cc=davem@davemloft.net \
    --cc=fweimer@redhat.com \
    --cc=geert@linux-m68k.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=james.hogan@imgtec.com \
    --cc=james.morse@arm.com \
    --cc=joseph@codesourcery.com \
    --cc=kilobyte@angband.pl \
    --cc=klimov.linux@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linyongting@huawei.com \
    --cc=manuel.montezelo@gmail.com \
    --cc=maxim.kuvyrkov@linaro.org \
    --cc=mention@noreply.github.com \
    --cc=philipp.tomsich@theobroma-systems.com \
    --cc=pinskia@gmail.com \
    --cc=ramana.gcc@googlemail.com \
    --cc=reply+ADSN7RXLQ62LNLD2MK5HFHF65GIU3EVBNHHDPMBXHU@reply.github.com \
    --cc=schwab@suse.de \
    --cc=schwidefsky@de.ibm.com \
    --cc=sellcey@caviumnetworks.com \
    --cc=szabolcs.nagy@arm.com \
    --cc=wangxiongfeng2@huawei.com \
    --cc=yury.norov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).