On Mon, Jan 27, 2025 at 10:20:49PM +0100, Arnd Bergmann wrote:
> On Mon, Jan 6, 2025, at 12:52, Ism Hong wrote:
> > The commit 275f22148e87 ("ipc: rename old-style shmctl/semctl/msgctl
> > syscalls") switched various architectures to use sys_old_*ctl() with
> > ipc_parse_version, including mips n32/n64. However, for mips o32, commit
> > 0d6040d46817 ("arch: add split IPC system calls where needed") added
> > separate IPC syscalls without properly using the old-style handlers.
> >
> > This causes applications using uClibc-ng to fail with -EINVAL when
> > calling semctl/shmctl/msgctl with IPC_64 flag, as uClibc-ng uses the
> > syscall numbers from kernel headers to determine whether to use the IPC
> > multiplexer or split syscalls. In contrast, glibc is unaffected as it
> > uses a unified feature test macro __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> > (disabled for mips-o32) to make this decision.
> >
> > Fix this by switching the o32 ABI entries for semctl, shmctl and msgctl
> > to use the old-style handlers, matching the behavior of other
> > architectures and fixing compatibility with uClibc-ng.
> >
> > Signed-off-by: Ism Hong <ism.hong@xxxxxxxxx>
>
> I just saw this making it into mainline and had another look, sorry
> I hadn't caught it earlier.
>
> It was an intentional decision to use the new-style IPC_64
> semantics on architectures that didn't already have the
> separate system call.
>
> You may not like that choice, but it's been done this way
> for seven years now, and as far as I can tell, glibc relies
> on this behavior.
>
> I think this commit should be reverted, and uclibc be changed
> to implement the kernel ABI for these syscalls.
I've prepared the revert
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
