On Monday 2021-03-22 22:55, Frank Scheiner wrote: >>> Riccardo Mottola first recognized a problem with 5.10.x kernels on his >>> Sun T2000 with UltraSPARC T1 (details in [this thread]). I could verify >>> the problem also on my Sun T1000 and it looks like this specific issue >>> breaks the mounting of the root FS or maybe mounting file systems at >>> all. This affects both booting from disk and from network. >>> (...) >>> ...as first bad commit. >>> >>> ``` >>> commit 028abd9222df0cf5855dab5014a5ebaf06f90565 >>> Author: Christoph Hellwig <hch@xxxxxx> >>> fs: remove compat_sys_mount Some participants in the discussion over at the debian-sparc list mentioned "NFS" and "Invalid argument", which is something I know just too well from iptables. NFS is a filesystem that uses an extra data blob (5th argument to the mount syscall). Such blobs have historically not always been designed to bear the same layout between ILP32 and LP64 modes, and nfs's structs fell prey to this as well. My hypothesis now is that fs/nfs/fs_context.c line 1160: if (in_compat_syscall()) nfs4_compat_mount_data_conv(data); and ones similar to it (I didn't look too close where nfs3 gets to do its conversion), no longer trigger as a result of compat_sys_mount being wiped from the syscall table: +++ arch/sparc/kernel/syscalls/syscall.tbl @@ -201,7 +201,7 @@ 164 64 utrap_install sys_utrap_install 165 common quotactl sys_quotactl 166 common set_tid_address sys_set_tid_address -167 common mount sys_mount compat_sys_mount +167 common mount sys_mount I didn't extract from the debian-sparc discussion whether people were running the all-LP64 userspace, or had some older Debian with a ILP32-on-64bitkernel setup. [But that's just a theory - a kernel theory!]
