linux-kernel - RE: [PATCH v3 0/7] ia64: system call table generation support

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3908561D78D1C84285E8C5FCA982C28F7D410C05@ORSMSX107.amr.corp.intel.com>
Date:   Fri, 12 Oct 2018 16:11:56 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Firoz Khan <firoz.khan@...aro.org>
CC:     "linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
        "Yu, Fenghua" <fenghua.yu@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        "y2038 Mailman List" <y2038@...ts.linaro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-Arch <linux-arch@...r.kernel.org>,
        "Arnd Bergmann" <arnd@...db.de>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        "Marcin Juszkiewicz" <marcin.juszkiewicz@...aro.org>
Subject: RE: [PATCH v3 0/7] ia64: system call table generation support

> I suspect the offset logic in the system call generation script had a bug. That
> I fixed it in this patch series.
>
> Arnd and Eugene had shared few comments on adding new system call entry in the
> table and some other things. Appreciate if you can review this patch
> series so I can
> finalize system call table implementation for ia64 architecture.

The net effect of these is just to make it easier to add new system calls. Just
edit the table, instead of editing entry.S and unistd.h picking the next number
(and remembering to increase  the NR_syscalls). Right?

I'm currently baffled at which linker magic makes the unsupported system
calls alias to sys_ni_syscall.

I'm also uncertain whether allocating system call numbers and creating
entry points for all the unsupported syscalls is the right thing to do. Might
that puzzle and frustrate folks whose applications build, but then fail at
run-time with -ENOSYS.

-Tony