mips: fix shmctl/semctl/msgctl syscall for o32

[PATCH] mips: fix shmctl/semctl/msgctl syscall for o32

Posted by Ism Hong 1 year, 1 month ago

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@gmail.com>
---
 arch/mips/kernel/syscalls/syscall_o32.tbl | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/kernel/syscalls/syscall_o32.tbl b/arch/mips/kernel/syscalls/syscall_o32.tbl
index 349b8aad1159..e8a57c206758 100644
--- a/arch/mips/kernel/syscalls/syscall_o32.tbl
+++ b/arch/mips/kernel/syscalls/syscall_o32.tbl
@@ -382,15 +382,15 @@
 368	o32	io_pgetevents			sys_io_pgetevents_time32	compat_sys_io_pgetevents
 # room for arch specific calls
 393	o32	semget				sys_semget
-394	o32	semctl				sys_semctl			compat_sys_semctl
+394	o32	semctl				sys_old_semctl		compat_sys_old_semctl
 395	o32	shmget				sys_shmget
-396	o32	shmctl				sys_shmctl			compat_sys_shmctl
+396	o32	shmctl				sys_old_shmctl		compat_sys_old_shmctl
 397	o32	shmat				sys_shmat			compat_sys_shmat
 398	o32	shmdt				sys_shmdt
 399	o32	msgget				sys_msgget
 400	o32	msgsnd				sys_msgsnd			compat_sys_msgsnd
 401	o32	msgrcv				sys_msgrcv			compat_sys_msgrcv
-402	o32	msgctl				sys_msgctl			compat_sys_msgctl
+402	o32	msgctl				sys_old_msgctl		compat_sys_old_msgctl
 403	o32	clock_gettime64			sys_clock_gettime		sys_clock_gettime
 404	o32	clock_settime64			sys_clock_settime		sys_clock_settime
 405	o32	clock_adjtime64			sys_clock_adjtime		sys_clock_adjtime
-- 
2.37.2

Re: [PATCH] mips: fix shmctl/semctl/msgctl syscall for o32

Posted by Arnd Bergmann 1 year ago

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@gmail.com>

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

Re: [PATCH] mips: fix shmctl/semctl/msgctl syscall for o32

Posted by Ism Hong 1 year ago

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@gmail.com>
> 
> 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

Re: [PATCH] mips: fix shmctl/semctl/msgctl syscall for o32

Posted by Arnd Bergmann 1 year ago

On Thu, Jan 30, 2025, at 15:46, Ism Hong wrote:
> Arnd Bergmann 於 2025/1/28 清晨5:20 寫道:
>
> 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.

Yes, that is correct. I think musl doesn't call the separate
syscalls if the architecture provides the old-style socket() syscall,
so it's not affected either way, but glibc needs the revert.

     Arnd

Re: [PATCH] mips: fix shmctl/semctl/msgctl syscall for o32

Posted by Thomas Bogendoerfer 1 year ago

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@gmail.com>
> 
> 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 ]