Arnd Bergmann 於 2025/1/28 清晨5:20 寫道:
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.
Arnd
Hi Arnd,
Thank you for your explanation, and sorry for the late reply due to the
Chinese New Year.
From your response, I understand that the preferred solution would be
to modify uClibc to align the behavior of semctl/shmctl/msgctl with
glibc and musl by adopting a unified feature test macro. If that is the
case, I will work on preparing a patch for uClibc accordingly.
Please let me know if you have any suggestions or if I have
misunderstood anything.
Thanks,
Ism
