linux-kernel - Drop IPC_OLD for direct ipc syscalls? (was: Re: [PATCH v2 3/4] m68k: Wire up direct ipc calls)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdW-w6yMDcgK-T38n45c1rURPHsVw+SwULjbgoG7d1HOOA@mail.gmail.com>
Date:	Sun, 20 Sep 2015 11:07:28 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Andreas Schwab <schwab@...ux-m68k.org>
Cc:	Greg Ungerer <gerg@...inux.org>,
	"Linux/m68k" <linux-m68k@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>,
	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Drop IPC_OLD for direct ipc syscalls? (was: Re: [PATCH v2 3/4] m68k:
 Wire up direct ipc calls)

Hi Andreas,

On Thu, Sep 17, 2015 at 5:39 PM, Andreas Schwab <schwab@...ux-m68k.org> wrote:
> Geert Uytterhoeven <geert@...ux-m68k.org> writes:
> > > > > It would be nice if the direct syscalls would drop the use of
> > > > > ipc_parse_version.  Currently, apart from going through the ipc
> > > > > multiplexer, the semctl, shmctl and msgctl wrappers in libc need to add
> > > > > the IPC_64 bit to the cmd operand.  If that would be implied then no
> > > > > special wrappers would be needed any more for direct syscalls.
> > > >
> > > > You mean that we should drop "select ARCH_WANT_IPC_PARSE_VERSION",
> > > > but we can't do that because an indirect call through sys_ipc() would
> > > > still need it when dispatching to sys_{sem,shm,msg}ctl()?
> > >
> > > Yes.  But all architectures that currently use both sys_ipc and
> > > ARCH_WANT_IPC_PARSE_VERSION would benefit from decoupling it when they
> > > add the direct syscalls.
> >
> > Do we currently have architectures that use both sys_ipc and the direct
> > syscalls, where keeping ipc_parse_version() in the direct syscalls is
> > required?
>
> IMHO it doesn't make sense to suport IPC_OLD via the direct syscalls,
> even for those architectures that started with them in the first place.
> There are quite a few architectures that define
> ARCH_WANT_IPC_PARSE_VERSION even though they started life after IPC_64
> was added.  They probably just forgot to adjust ipc/util.h back then.

Thanks!

I had a quick look at the code, but I'm not feeling sufficiently familiar with
the (g)libc interaction to cook up a patch dropping ipc_parse_version() from
direct ipc calls.

Should I postpone wiring up the direct ipc syscalls on m68k (and thus renumber
__NR_membarrier) until the above is resolved, or can they go in in v4.3?

I guess the same is true for x86-32.

Thanks again!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/