|
Message-ID: <20240910120937.GW10433@brightrain.aerifal.cx> Date: Tue, 10 Sep 2024 08:09:38 -0400 From: Rich Felker <dalias@...c.org> To: Xing Li <lixing@...ngson.cn> Cc: musl@...ts.openwall.com, wanghongliang@...ngson.cn Subject: Re: [PATCH] loongarch64: add fstat and newfstatat syscall support On Tue, Sep 10, 2024 at 05:41:12PM +0800, Xing Li wrote: > linux kernel add fstat and newfstatat to solve the chromium sandbox, the link as follow: > https://lore.kernel.org/loongarch/CAAhV-H7W-Ygn6tXySrip4k3P5xVbVf7GpjOzjXfQvCCbA4r5Wg@mail.gmail.com/T/#t > > So we add fstat and newfstatat as linux kernel. > --- > arch/loongarch64/bits/syscall.h.in | 2 ++ > arch/loongarch64/kstat.h | 21 +++++++++++++++++++++ > 2 files changed, 23 insertions(+) > create mode 100644 arch/loongarch64/kstat.h > > diff --git a/arch/loongarch64/bits/syscall.h.in b/arch/loongarch64/bits/syscall.h.in > index 2afb4ea1..43efb916 100644 > --- a/arch/loongarch64/bits/syscall.h.in > +++ b/arch/loongarch64/bits/syscall.h.in > @@ -76,6 +76,8 @@ > #define __NR_splice 76 > #define __NR_tee 77 > #define __NR_readlinkat 78 > +#define __NR_newfstatat 79 > +#define __NR_fstat 80 > #define __NR_sync 81 > #define __NR_fsync 82 > #define __NR_fdatasync 83 > diff --git a/arch/loongarch64/kstat.h b/arch/loongarch64/kstat.h > new file mode 100644 > index 00000000..92625f36 > --- /dev/null > +++ b/arch/loongarch64/kstat.h > @@ -0,0 +1,21 @@ > +struct kstat { > + dev_t st_dev; > + ino_t st_ino; > + mode_t st_mode; > + nlink_t st_nlink; > + uid_t st_uid; > + gid_t st_gid; > + dev_t st_rdev; > + unsigned long __pad; > + off_t st_size; > + blksize_t st_blksize; > + int __pad2; > + blkcnt_t st_blocks; > + long st_atime_sec; > + long st_atime_nsec; > + long st_mtime_sec; > + long st_mtime_nsec; > + long st_ctime_sec; > + long st_ctime_nsec; > + unsigned __unused[2]; > +}; > -- > 2.27.0 This can't be accepted as-is because it breaks execution of new binaries on old kernels that lack the syscalls. We don't have a fallback order that tries statx is legacy stat fails with ENOSYS. I also don't think this was a good solution to the problem. The same problem exists on riscv32 and any future 32-bit archs where legacy stat syscalls can't be added (because they're time32-only). statx should have just been updated to avoid the need to peek at memory to do effective seccomp with it (e.g. by accepting a null pointer for the empty path part). Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.