Message ID | 1478010323-13076-8-git-send-email-adhemerval.zanella@linaro.org |
---|---|
State | New |
Headers | show |
On Nov 01 2016, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: > This patch add a direct call to semget syscall if it is defined by > kernel headers. That does not mean that the running kernel provides it. Andreas.
On Tue, 1 Nov 2016, Andreas Schwab wrote: > On Nov 01 2016, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: > > > This patch add a direct call to semget syscall if it is defined by > > kernel headers. > > That does not mean that the running kernel provides it. Specifically, this sort of patch series needs to be accompanied by an analysis of when the relevant syscalls were added for each supported architecture (and subarchitecture for cases with multiple syscall tables for different ABNs). If present (in the syscall table as well as in asm/unistd.h) in the minimum kernel version, OK, otherwise you need appropriate __ASSUME_* conditionals (even if not present in the latest kernel, it might be added in future, so you should have those conditionals now to avoid breaking things when current glibc is compiled with future kernel headers).
On 01/11/2016 14:40, Joseph Myers wrote: > On Tue, 1 Nov 2016, Andreas Schwab wrote: > >> On Nov 01 2016, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: >> >>> This patch add a direct call to semget syscall if it is defined by >>> kernel headers. >> >> That does not mean that the running kernel provides it. > > Specifically, this sort of patch series needs to be accompanied by an > analysis of when the relevant syscalls were added for each supported > architecture (and subarchitecture for cases with multiple syscall tables > for different ABNs). If present (in the syscall table as well as in > asm/unistd.h) in the minimum kernel version, OK, otherwise you need > appropriate __ASSUME_* conditionals (even if not present in the latest > kernel, it might be added in future, so you should have those conditionals > now to avoid breaking things when current glibc is compiled with future > kernel headers). Indeed, I did not consider the case of latest kernel headers. Based on current Linux approach and historical implementation for sysv IPC I think we can assume that either the kernel only supports the old 'ipc' syscall or all the sysvipc syscall wire-up. Do you know if we do require an __ASSUME for each syscall?
On Tue, Nov 1, 2016 at 1:16 PM, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: > On 01/11/2016 14:40, Joseph Myers wrote: >> On Tue, 1 Nov 2016, Andreas Schwab wrote: >> >>> On Nov 01 2016, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: >>> >>>> This patch add a direct call to semget syscall if it is defined by >>>> kernel headers. >>> >>> That does not mean that the running kernel provides it. >> >> Specifically, this sort of patch series needs to be accompanied by an >> analysis of when the relevant syscalls were added for each supported >> architecture (and subarchitecture for cases with multiple syscall tables >> for different ABNs). If present (in the syscall table as well as in >> asm/unistd.h) in the minimum kernel version, OK, otherwise you need >> appropriate __ASSUME_* conditionals (even if not present in the latest >> kernel, it might be added in future, so you should have those conditionals >> now to avoid breaking things when current glibc is compiled with future >> kernel headers). > > Indeed, I did not consider the case of latest kernel headers. Based > on current Linux approach and historical implementation for sysv IPC > I think we can assume that either the kernel only supports the old > 'ipc' syscall or all the sysvipc syscall wire-up. Do you know if we > do require an __ASSUME for each syscall? It wouldn't have made sense to add direct syscalls for some but not all of the APIs that were multiplexed, so I would think one __ASSUME is enough. zw
On Tue, 1 Nov 2016, Adhemerval Zanella wrote: > Indeed, I did not consider the case of latest kernel headers. Based > on current Linux approach and historical implementation for sysv IPC > I think we can assume that either the kernel only supports the old > 'ipc' syscall or all the sysvipc syscall wire-up. Do you know if we > do require an __ASSUME for each syscall? If your analysis shows that all the syscalls were always wired up (in both places, syscall table and asm/unistd.h) at the same time, you can just use a single __ASSUME (or if by mistake some architectures were only partially wired up, you could still use a single __ASSUME if it's conservatively safe).
diff --git a/sysdeps/unix/sysv/linux/semget.c b/sysdeps/unix/sysv/linux/semget.c index 52189fd..739346b 100644 --- a/sysdeps/unix/sysv/linux/semget.c +++ b/sysdeps/unix/sysv/linux/semget.c @@ -16,13 +16,10 @@ License along with the GNU C Library; if not, see <http://www.gnu.org/licenses/>. */ -#include <errno.h> #include <sys/sem.h> #include <ipc_priv.h> -#include <stdlib.h> /* for definition of NULL */ - #include <sysdep.h> -#include <sys/syscall.h> +#include <errno.h> /* Return identifier for array of NSEMS semaphores associated with KEY. */ @@ -30,5 +27,9 @@ int semget (key_t key, int nsems, int semflg) { - return INLINE_SYSCALL (ipc, 5, IPCOP_semget, key, nsems, semflg, NULL); +#ifdef __NR_semget + return INLINE_SYSCALL_CALL (semget, key, nsems, semflg); +#else + return INLINE_SYSCALL_CALL (ipc, IPCOP_semget, key, nsems, semflg, NULL); +#endif }