From: "Arnd Bergmann" <arnd@arndb.de>
To: "Huacai Chen" <chenhuacai@loongson.cn>,
"Huacai Chen" <chenhuacai@kernel.org>
Cc: loongarch@lists.linux.dev,
Linux-Arch <linux-arch@vger.kernel.org>,
"Xuefeng Li" <lixuefeng@loongson.cn>, guoren <guoren@kernel.org>,
"WANG Xuerui" <kernel@xen0n.name>,
"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
linux-kernel@vger.kernel.org, loongson-kernel@lists.loongnix.cn,
stable@vger.kernel.org
Subject: Re: [PATCH] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h
Date: Sat, 11 May 2024 14:17:08 +0200 [thread overview]
Message-ID: <f92e23be-3f3f-4bc6-8711-3bcf6beb7fa2@app.fastmail.com> (raw)
In-Reply-To: <20240511100157.2334539-1-chenhuacai@loongson.cn>
On Sat, May 11, 2024, at 12:01, Huacai Chen wrote:
> Chromium sandbox apparently wants to deny statx [1] so it could properly
> inspect arguments after the sandboxed process later falls back to fstat.
> Because there's currently not a "fd-only" version of statx, so that the
> sandbox has no way to ensure the path argument is empty without being
> able to peek into the sandboxed process's memory. For architectures able
> to do newfstatat though, glibc falls back to newfstatat after getting
> -ENOSYS for statx, then the respective SIGSYS handler [2] takes care of
> inspecting the path argument, transforming allowed newfstatat's into
> fstat instead which is allowed and has the same type of return value.
>
> But, as LoongArch is the first architecture to not have fstat nor
> newfstatat, the LoongArch glibc does not attempt falling back at all
> when it gets -ENOSYS for statx -- and you see the problem there!
My main objection here is that this is inconsistent with 32-bit
architectures: we normally have newfstatat() on 64-bit
architectures but fstatat64() on 32-bit ones. While loongarch64
is the first 64-bit one that is missing newfstatat(), we have
riscv32 already without fstatat64().
Importantly, we can't just add fstatat64() on riscv32 because
there is no time64 version for it other than statx(), and I don't
want the architectures to diverge more than necessary.
I would not mind adding a variant of statx() that works for
both riscv32 and loongarch64 though, if it gets added to all
architectures.
Arnd
next prev parent reply other threads:[~2024-05-11 12:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-11 10:01 [PATCH] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h Huacai Chen
2024-05-11 12:17 ` Arnd Bergmann [this message]
2024-05-11 14:28 ` Huacai Chen
2024-05-11 15:38 ` Arnd Bergmann
2024-05-12 3:11 ` Huacai Chen
2024-05-12 7:52 ` Arnd Bergmann
2024-05-15 9:30 ` maobibo
2024-05-15 14:25 ` Arnd Bergmann
2024-05-16 2:52 ` maobibo
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=f92e23be-3f3f-4bc6-8711-3bcf6beb7fa2@app.fastmail.com \
--to=arnd@arndb.de \
--cc=chenhuacai@kernel.org \
--cc=chenhuacai@loongson.cn \
--cc=guoren@kernel.org \
--cc=jiaxun.yang@flygoat.com \
--cc=kernel@xen0n.name \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lixuefeng@loongson.cn \
--cc=loongarch@lists.linux.dev \
--cc=loongson-kernel@lists.loongnix.cn \
--cc=stable@vger.kernel.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).