public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Ism Hong" <ism.hong@gmail.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Jeff Xu" <jeffxu@chromium.org>,
	"Christian Göttsche" <cgzones@googlemail.com>,
	"open list:MIPS" <linux-mips@vger.kernel.org>,
	"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mips: fix shmctl/semctl/msgctl syscall for o32
Date: Thu, 30 Jan 2025 09:55:14 +0100	[thread overview]
Message-ID: <Z5s-csyOKMCvH3ct@alpha.franken.de> (raw)
In-Reply-To: <5427df64-658d-4377-89be-963ee7bb68ee@app.fastmail.com>

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 ]

  reply	other threads:[~2025-01-30  8:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-06 11:52 [PATCH] mips: fix shmctl/semctl/msgctl syscall for o32 Ism Hong
2025-01-27 21:20 ` Arnd Bergmann
2025-01-30  8:55   ` Thomas Bogendoerfer [this message]
2025-01-30 14:46   ` Ism Hong
2025-01-30 20:31     ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z5s-csyOKMCvH3ct@alpha.franken.de \
    --to=tsbogend@alpha.franken.de \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=brauner@kernel.org \
    --cc=cgzones@googlemail.com \
    --cc=hca@linux.ibm.com \
    --cc=ism.hong@gmail.com \
    --cc=jeffxu@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox