[patch] Assigning syscall numbers for testing

[patch] Assigning syscall numbers for testing

[Keith Owens]

It is clear (to me at least) that developers have problems assigning
syscall numbers for testing, before their code is accepted into the
kernel.  Developers have to worry about collisions with everybody else
who is testing syscalls.  More importantly, the user space code has to
"know" what the testing syscall number is this week.  As a minor
problem, strace cannot report on testing syscalls, except to print the
number.

The patch below dynamically assigns a syscall number to a name and
exports the number and name via /proc.  Dynamic assignment removes the
collision problem.  Exporting via /proc allows user space code to
automatically find out what the syscall number is this week.  strace
could read the /proc output to print the syscall name, although it
still cannot print the arguments.

This facility must only be used while testing code, until the
developer's code is accepted by Linus when it should be assigned a
permanent syscall number.  Anybody caught using this kernel facility
for code that is in Linus's kernel will be hung, drawn, quartered then
forced to write in COBOL.

To dynamically register a syscall number, ignoring error checking :-

  #include <linux/dynamic_syscalls.h>

  printk(KERN_DEBUG "Assigned syscall number %d for %s\n",
     register_dynamic_syscall("attrctl", DYNAMIC_SYSCALL_FUNC(sys_attrctl)),
     "attrctl");

There is no deregister function.  Syscalls are _not_ supported in
modules, there is no architecture independent way of handling the
branch from the syscall handler to a module.  I know that people have
done syscalls in modules but unless they have coded some architecture
dependent assembler glue, I guarantee that their code will break on
ia64 and ppc64.  In any case, Linus has said that syscalls are not
supported in modules.  Ignore the modules howto, it is hopelessly out
of date.

User space code should open /proc/dynamic_syscalls, read the lines
looking for their syscall name, extract the number and call the glibc
syscall() function using that number.  Do not use the _syscalln()
functions, they require a constant syscall number at compile time.

If the code cannot open /proc/dynamic_syscalls or cannot find the
desired syscall name, fall back to the assigned syscall number (if any)
or fail if there is no assigned syscall number.  By falling back to the
assigned syscall number, new versions of the user space code are
backwards compatible, on older kernels it will use the dynamic syscall
number, on newer kernels it will use the assigned number.

The patch has support for i386 and ia64.  Each architecture needs
include/asm-$(ARCH)/dynamic_syscalls.h defining the range of dynamic
syscalls and information about entries in sys_call_table.  On archs
that use function pointers, DYNAMIC_SYSCALL_FUNCADDR must extract the
function address from the descriptor.

The patch is against 2.4.17 but should fit 2.4.16 and 2.5 as well.
Enjoy.

diff -urN 2.4.16-pristine/fs/proc/proc_misc.c 2.4.16-syscalls/fs/proc/proc_misc.c
--- 2.4.16-pristine/fs/proc/proc_misc.c	Fri Nov 23 17:36:14 2001
+++ 2.4.16-syscalls/fs/proc/proc_misc.c	Fri Dec 21 22:21:13 2001
@@ -36,6 +36,7 @@
 #include <linux/init.h>
 #include <linux/smp_lock.h>
 #include <linux/seq_file.h>
+#include <linux/dynamic_syscalls.h>
 
 #include <asm/uaccess.h>
 #include <asm/pgtable.h>
@@ -320,6 +321,13 @@
 	return proc_calc_metrics(page, start, off, count, eof, len);
 }
 
+static int dynamic_syscalls_read_proc(char *page, char **start, off_t off,
+				 int count, int *eof, void *data)
+{
+	int len = get_dynamic_syscalls_list(page);
+	return proc_calc_metrics(page, start, off, count, eof, len);
+}
+
 static int partitions_read_proc(char *page, char **start, off_t off,
 				 int count, int *eof, void *data)
 {
@@ -511,6 +519,7 @@
 #endif
 		{"stat",	kstat_read_proc},
 		{"devices",	devices_read_proc},
+		{"dynamic_syscalls",	dynamic_syscalls_read_proc},
 		{"partitions",	partitions_read_proc},
 #if !defined(CONFIG_ARCH_S390)
 		{"interrupts",	interrupts_read_proc},
diff -urN 2.4.16-pristine/include/asm-i386/dynamic_syscalls.h 2.4.16-syscalls/include/asm-i386/dynamic_syscalls.h
--- 2.4.16-pristine/include/asm-i386/dynamic_syscalls.h	Thu Jan  1 10:00:00 1970
+++ 2.4.16-syscalls/include/asm-i386/dynamic_syscalls.h	Sat Dec 22 00:08:59 2001
@@ -0,0 +1,21 @@
+#ifndef _ASM_DYNAMIC_SYSCALLS_H
+#define _ASM_DYNAMIC_SYSCALLS_H
+
+#include <linux/sys.h>
+
+/* The first and last numbers do not have to be 100% accurate, register_dynamic_syscall
+ * will find the first free entry.  The offset and type must be accurate.
+ */
+
+#define DYNAMIC_SYSCALL_OFFSET		0
+#define DYNAMIC_SYSCALL_FIRST		226
+#define DYNAMIC_SYSCALL_LAST		NR_syscalls-1
+#define DYNAMIC_SYSCALL_T		long
+
+/* This is a noop on most systems.  It does real work on architectures that use
+ * function descriptors.  See asm-ia64/dynamic_syscalls.h for an example.
+ */
+
+#define DYNAMIC_SYSCALL_FUNCADDR(f)	(DYNAMIC_SYSCALL_T)(f)
+
+#endif /* _ASM_DYNAMIC_SYSCALLS_H */
diff -urN 2.4.16-pristine/include/asm-ia64/dynamic_syscalls.h 2.4.16-syscalls/include/asm-ia64/dynamic_syscalls.h
--- 2.4.16-pristine/include/asm-ia64/dynamic_syscalls.h	Thu Jan  1 10:00:00 1970
+++ 2.4.16-syscalls/include/asm-ia64/dynamic_syscalls.h	Sat Dec 22 00:09:08 2001
@@ -0,0 +1,28 @@
+#ifndef _ASM_DYNAMIC_SYSCALLS_H
+#define _ASM_DYNAMIC_SYSCALLS_H
+
+#include <linux/sys.h>
+
+/* The first and last numbers do not have to be 100% accurate, register_dynamic_syscall
+ * will find the first free entry.  The offset and type must be accurate.
+ */
+
+#define DYNAMIC_SYSCALL_OFFSET		1024
+#define DYNAMIC_SYSCALL_FIRST		(1217-DYNAMIC_SYSCALL_OFFSET)
+#define DYNAMIC_SYSCALL_LAST		NR_syscalls-1
+#define DYNAMIC_SYSCALL_T		long long
+
+/* IA64 function parameters do not point to the function itself, they point to a
+ * descriptor containing the 64 bit address of the function and the global
+ * pointer.  Dereference the function pointer to get the real function address,
+ * the syscall table requires direct addresses.
+ *
+ * This will almost certainly destroy your kernel if the syscall function is in
+ * a module because it will be entered with the wrong global pointer.
+ * Don't do that.
+ */
+
+#include <linux/types.h>
+#define DYNAMIC_SYSCALL_FUNCADDR(f)	({DYNAMIC_SYSCALL_T *fp = (DYNAMIC_SYSCALL_T *)(f); fp[0];})
+
+#endif /* _ASM_DYNAMIC_SYSCALLS_H */
diff -urN 2.4.16-pristine/include/linux/dynamic_syscalls.h 2.4.16-syscalls/include/linux/dynamic_syscalls.h
--- 2.4.16-pristine/include/linux/dynamic_syscalls.h	Thu Jan  1 10:00:00 1970
+++ 2.4.16-syscalls/include/linux/dynamic_syscalls.h	Fri Dec 21 23:24:14 2001
@@ -0,0 +1,10 @@
+#ifndef _LINUX_DYNAMIC_SYSCALLS_H
+#define _LINUX_DYNAMIC_SYSCALLS_H
+
+extern int get_syscalls_list(char *page);
+extern int register_dynamic_syscall(const char *name, void (*func)(void));
+extern int unregister_dynamic_syscall(const char *name);
+
+#define DYNAMIC_SYSCALL_FUNC(f) (void (*)(void))(&f)
+
+#endif /* _LINUX_DYNAMIC_SYSCALLS_H */
diff -urN 2.4.16-pristine/init/main.c 2.4.16-syscalls/init/main.c
--- 2.4.16-pristine/init/main.c	Fri Nov 23 17:36:28 2001
+++ 2.4.16-syscalls/init/main.c	Fri Dec 21 23:23:20 2001
@@ -794,6 +794,8 @@
 #endif
 }
 
+#include <linux/dynamic_syscalls.h>
+
 static int init(void * unused)
 {
 	lock_kernel();
@@ -808,6 +810,8 @@
 	 */
 	free_initmem();
 	unlock_kernel();
+
+	printk("registered %d\n", register_dynamic_syscall("test", DYNAMIC_SYSCALL_FUNC(register_dynamic_syscall)));
 
 	if (open("/dev/console", O_RDWR, 0) < 0)
 		printk("Warning: unable to open an initial console.\n");
diff -urN 2.4.16-pristine/kernel/Makefile 2.4.16-syscalls/kernel/Makefile
--- 2.4.16-pristine/kernel/Makefile	Mon Sep 24 11:16:37 2001
+++ 2.4.16-syscalls/kernel/Makefile	Sat Dec 22 00:07:03 2001
@@ -14,7 +14,7 @@
 obj-y     = sched.o dma.o fork.o exec_domain.o panic.o printk.o \
 	    module.o exit.o itimer.o info.o time.o softirq.o resource.o \
 	    sysctl.o acct.o capability.o ptrace.o timer.o user.o \
-	    signal.o sys.o kmod.o context.o
+	    signal.o sys.o kmod.o context.o dynamic_syscalls.o
 
 obj-$(CONFIG_UID16) += uid16.o
 obj-$(CONFIG_MODULES) += ksyms.o
diff -urN 2.4.16-pristine/kernel/dynamic_syscalls.c 2.4.16-syscalls/kernel/dynamic_syscalls.c
--- 2.4.16-pristine/kernel/dynamic_syscalls.c	Thu Jan  1 10:00:00 1970
+++ 2.4.16-syscalls/kernel/dynamic_syscalls.c	Sat Dec 22 00:05:56 2001
@@ -0,0 +1,115 @@
+/*
+ *  kernel/dynamic_syscalls.c
+ *
+ *  (C) 2001 Keith owens <kaos@sgi.com>
+ *
+ *  Assign dynamic syscall numbers for testing.  Code that has not been assigned
+ *  an official syscall number can use these functions to get a dynamic syscall
+ *  number during testing.  It only works for syscall code that is built into
+ *  the kernel, there is no architecture independent way of handling a syscall
+ *  when the code is in a module, not to mention that such code would be
+ *  horribly racy against module unload.  None of the functions should be
+ *  exported, to prevent modules calling this code by mistake.
+ *
+ *  NOTE: This facility is only to be used during testing.  When your code is
+ *        ready to be included in the mainstream kernel, you must get official
+ *        syscall numbers from whoever controls the syscall numbers.
+ */
+
+#include <asm/dynamic_syscalls.h>
+
+#ifdef DYNAMIC_SYSCALL_FIRST
+
+#include <linux/kernel.h>
+#include <linux/smp.h>
+#include <linux/sched.h>
+#include <linux/errno.h>
+#include <linux/brlock.h>
+
+static rwlock_t dynamic_syscalls_lock = RW_LOCK_UNLOCKED;
+static const char *dynamic_syscalls_name[DYNAMIC_SYSCALL_LAST-DYNAMIC_SYSCALL_FIRST+1];
+extern DYNAMIC_SYSCALL_T sys_call_table[];
+
+/**
+ * get_dynamic_syscalls_list - print the list of dynamic syscall numbers
+ * @page: output buffer
+ *
+ * Description: Fill up a /proc buffer to print the dynamically assigned syscall
+ * numbers.  Assumes that the data will not exceed the size of the /proc page.
+ **/
+
+int get_dynamic_syscalls_list(char *page)
+{
+	int i, len;
+	len = sprintf(page, "Dynamic syscall numbers:\n");
+	read_lock(&dynamic_syscalls_lock);
+	for (i = 0; i < sizeof(dynamic_syscalls_name)/sizeof(dynamic_syscalls_name[0]) ; i++) {
+		if (dynamic_syscalls_name[i]) {
+			len += sprintf(page+len, "%3d %s 0x%lx\n",
+				i+DYNAMIC_SYSCALL_FIRST, dynamic_syscalls_name[i], sys_call_table[i+DYNAMIC_SYSCALL_FIRST]);
+		}
+	}
+	read_unlock(&dynamic_syscalls_lock);
+	return len;
+}
+
+/**
+ * register_dynamic_syscall - assign a dynamic syscall number.
+ * @name: the name of the syscall, used by user space code to find the number.
+ *        Use a unique name, if there is any possibility of conflict with
+ *        other test syscalls then include your company or initials in the name.
+ * @func: address of function to be invoked by this syscall name.  If the
+ *        function is in a module then the results are undefined.
+ *
+ * Description: Find the first syscall that has a null name pointer and the
+ *              entry in the syscall table is the same as syscall 0.  This
+ *              assumes that syscall 0 is always sys_ni_syscall and unused
+ *              slots are set to sys_ni_syscall.
+ *
+ * Returns: < 0, an error occured, the return value is the error number.
+ *          > 0, the syscall number that has been assigned.
+ **/
+
+int register_dynamic_syscall(const char *name, void (*func)(void))
+{
+	int i, ret = -EBUSY;
+	printk("register_dynamic_syscall %s %p\n", name, func);
+	write_lock(&dynamic_syscalls_lock);
+	for (i = 0; i < sizeof(dynamic_syscalls_name)/sizeof(dynamic_syscalls_name[0]) ; i++) {
+		printk("i %d dynamic_syscalls_name[i] %p\n", i, dynamic_syscalls_name[i]);
+		printk("i+DYNAMIC_SYSCALL_FIRST %d sys_call_table[i+DYNAMIC_SYSCALL_FIRST] %p\n", i+DYNAMIC_SYSCALL_FIRST, (void *)(sys_call_table[i+DYNAMIC_SYSCALL_FIRST]));
+		if (dynamic_syscalls_name[i] == NULL && sys_call_table[i+DYNAMIC_SYSCALL_FIRST] == sys_call_table[0]) {
+			printk("found syscall %d\n", i+DYNAMIC_SYSCALL_FIRST);
+			dynamic_syscalls_name[i] = name;
+			sys_call_table[i+DYNAMIC_SYSCALL_FIRST] = DYNAMIC_SYSCALL_FUNCADDR(func);
+			printk("updated\n");
+			ret = i+DYNAMIC_SYSCALL_FIRST+DYNAMIC_SYSCALL_OFFSET;
+			break;
+		}
+	}
+	write_unlock(&dynamic_syscalls_lock);
+	return ret;
+}
+
+/**
+ * unregister_dynamic_syscall - release a dynamic assigned syscall number.
+ * @name: the name of the syscall.
+ **/
+
+int unregister_dynamic_syscall(const char *name)
+{
+	int i, ret = -EINVAL;
+	write_lock(&dynamic_syscalls_lock);
+	for (i = 0; i < sizeof(dynamic_syscalls_name)/sizeof(dynamic_syscalls_name[0]) ; i++) {
+		if (dynamic_syscalls_name[i] && strcmp(dynamic_syscalls_name[i], name) == 0) {
+			dynamic_syscalls_name[i] = NULL;
+			sys_call_table[i+DYNAMIC_SYSCALL_FIRST] = sys_call_table[0];
+			ret = 0;
+			break;
+		}
+	}
+	write_unlock(&dynamic_syscalls_lock);
+	return ret;
+}
+
+#endif	/* DYNAMIC_SYSCALL_FIRST */

[patch] Assigning syscall numbers for testing

[Keith Owens]

Resend, previous mail had the wrong version of the patch.

It is clear (to me at least) that developers have problems assigning
syscall numbers for testing, before their code is accepted into the
kernel.  Developers have to worry about collisions with everybody else
who is testing syscalls.  More importantly, the user space code has to
"know" what the testing syscall number is this week.  As a minor
problem, strace cannot report on testing syscalls, except to print the
number.

The patch below dynamically assigns a syscall number to a name and
exports the number and name via /proc.  Dynamic assignment removes the
collision problem.  Exporting via /proc allows user space code to
automatically find out what the syscall number is this week.  strace
could read the /proc output to print the syscall name, although it
still cannot print the arguments.

This facility must only be used while testing code, until the
developer's code is accepted by Linus when it should be assigned a
permanent syscall number.  Anybody caught using this kernel facility
for code that is in Linus's kernel will be hung, drawn, quartered then
forced to write in COBOL.

To dynamically register a syscall number, ignoring error checking :-

  #include <linux/dynamic_syscalls.h>

  printk(KERN_DEBUG "Assigned syscall number %d for %s\n",
     register_dynamic_syscall("attrctl", DYNAMIC_SYSCALL_FUNC(sys_attrctl)),
     "attrctl");

There is no deregister function.  Syscalls are _not_ supported in
modules, there is no architecture independent way of handling the
branch from the syscall handler to a module.  I know that people have
done syscalls in modules but unless they have coded some architecture
dependent assembler glue, I guarantee that their code will break on
ia64 and ppc64.  In any case, Linus has said that syscalls are not
supported in modules.  Ignore the modules howto, it is hopelessly out
of date.

User space code should open /proc/dynamic_syscalls, read the lines
looking for their syscall name, extract the number and call the glibc
syscall() function using that number.  Do not use the _syscalln()
functions, they require a constant syscall number at compile time.

If the code cannot open /proc/dynamic_syscalls or cannot find the
desired syscall name, fall back to the assigned syscall number (if any)
or fail if there is no assigned syscall number.  By falling back to the
assigned syscall number, new versions of the user space code are
backwards compatible, on older kernels it will use the dynamic syscall
number, on newer kernels it will use the assigned number.

The patch has support for i386 and ia64.  Each architecture needs
include/asm-$(ARCH)/dynamic_syscalls.h defining the range of dynamic
syscalls and information about entries in sys_call_table.  On archs
that use function pointers, DYNAMIC_SYSCALL_FUNCADDR must extract the
function address from the descriptor.

The patch is against 2.4.17 but should fit 2.4.16 and 2.5 as well.
Enjoy.

Index: 17.1/kernel/Makefile
--- 17.1/kernel/Makefile Tue, 18 Sep 2001 13:43:44 +1000 kaos (linux-2.4/k/3_Makefile 1.1.10.2 644)
+++ 17.1(w)/kernel/Makefile Sat, 22 Dec 2001 22:21:06 +1100 kaos (linux-2.4/k/3_Makefile 1.1.10.2 644)
@@ -14,7 +14,7 @@ export-objs = signal.o sys.o kmod.o cont
 obj-y     = sched.o dma.o fork.o exec_domain.o panic.o printk.o \
 	    module.o exit.o itimer.o info.o time.o softirq.o resource.o \
 	    sysctl.o acct.o capability.o ptrace.o timer.o user.o \
-	    signal.o sys.o kmod.o context.o
+	    signal.o sys.o kmod.o context.o dynamic_syscalls.o
 
 obj-$(CONFIG_UID16) += uid16.o
 obj-$(CONFIG_MODULES) += ksyms.o
Index: 17.1/fs/proc/proc_misc.c
--- 17.1/fs/proc/proc_misc.c Thu, 22 Nov 2001 11:15:28 +1100 kaos (linux-2.4/o/b/48_proc_misc. 1.1.1.1.1.1.1.8 644)
+++ 17.1(w)/fs/proc/proc_misc.c Sat, 22 Dec 2001 22:13:37 +1100 kaos (linux-2.4/o/b/48_proc_misc. 1.1.1.1.1.1.1.8 644)
@@ -36,6 +36,7 @@
 #include <linux/init.h>
 #include <linux/smp_lock.h>
 #include <linux/seq_file.h>
+#include <linux/dynamic_syscalls.h>
 
 #include <asm/uaccess.h>
 #include <asm/pgtable.h>
@@ -320,6 +321,13 @@ static int devices_read_proc(char *page,
 	return proc_calc_metrics(page, start, off, count, eof, len);
 }
 
+static int dynamic_syscalls_read_proc(char *page, char **start, off_t off,
+				 int count, int *eof, void *data)
+{
+	int len = get_dynamic_syscalls_list(page);
+	return proc_calc_metrics(page, start, off, count, eof, len);
+}
+
 static int partitions_read_proc(char *page, char **start, off_t off,
 				 int count, int *eof, void *data)
 {
@@ -511,6 +519,7 @@ void __init proc_misc_init(void)
 #endif
 		{"stat",	kstat_read_proc},
 		{"devices",	devices_read_proc},
+		{"dynamic_syscalls",	dynamic_syscalls_read_proc},
 		{"partitions",	partitions_read_proc},
 #if !defined(CONFIG_ARCH_S390)
 		{"interrupts",	interrupts_read_proc},
Index: 17.1/kernel/dynamic_syscalls.c
--- 17.1/kernel/dynamic_syscalls.c Sat, 22 Dec 2001 22:21:58 +1100 kaos ()
+++ 17.1(w)/kernel/dynamic_syscalls.c Sat, 22 Dec 2001 22:18:29 +1100 kaos (linux-2.4/O/f/42_dynamic_sy  644)
@@ -0,0 +1,93 @@
+/*
+ *  kernel/dynamic_syscalls.c
+ *
+ *  (C) 2001 Keith owens <kaos@sgi.com>
+ *
+ *  Assign dynamic syscall numbers for testing.  Code that has not been assigned
+ *  an official syscall number can use these functions to get a dynamic syscall
+ *  number during testing.  It only works for syscall code that is built into
+ *  the kernel, there is no architecture independent way of handling a syscall
+ *  when the code is in a module, not to mention that such code would be
+ *  horribly racy against module unload.  None of the functions should be
+ *  exported, to prevent modules calling this code by mistake.
+ *
+ *  NOTE: This facility is only to be used during testing.  When your code is
+ *        ready to be included in the mainstream kernel, you must get official
+ *        syscall numbers from whoever controls the syscall numbers.
+ */
+
+#include <asm/dynamic_syscalls.h>
+
+#ifdef DYNAMIC_SYSCALL_FIRST
+
+#include <linux/kernel.h>
+#include <linux/smp.h>
+#include <linux/sched.h>
+#include <linux/errno.h>
+#include <linux/brlock.h>
+
+static rwlock_t dynamic_syscalls_lock = RW_LOCK_UNLOCKED;
+static const char *dynamic_syscalls_name[DYNAMIC_SYSCALL_LAST-DYNAMIC_SYSCALL_FIRST+1];
+extern DYNAMIC_SYSCALL_T sys_call_table[];
+
+/**
+ * get_dynamic_syscalls_list - print the list of dynamic syscall numbers
+ * @page: output buffer
+ *
+ * Description: Fill up a /proc buffer to print the dynamically assigned syscall
+ * numbers.  Assumes that the data will not exceed the size of the /proc page.
+ **/
+
+int get_dynamic_syscalls_list(char *page)
+{
+	int i, len;
+	len = sprintf(page, "Dynamic syscall numbers:\n");
+	read_lock(&dynamic_syscalls_lock);
+	for (i = 0; i < sizeof(dynamic_syscalls_name)/sizeof(dynamic_syscalls_name[0]) ; i++) {
+		if (dynamic_syscalls_name[i]) {
+			len += sprintf(page+len, "%d %s 0x%" DYNAMIC_SYSCALL_FMT "x\n",
+				i+DYNAMIC_SYSCALL_FIRST,
+				dynamic_syscalls_name[i],
+				sys_call_table[i+DYNAMIC_SYSCALL_FIRST]);
+		}
+	}
+	read_unlock(&dynamic_syscalls_lock);
+	return len;
+}
+
+/**
+ * register_dynamic_syscall - assign a dynamic syscall number.
+ * @name: the name of the syscall, used by user space code to find the number.
+ *        Use a unique name, if there is any possibility of conflict with
+ *        other test syscalls then include your company or initials in the name.
+ * @func: address of function to be invoked by this syscall name.  If the
+ *        function is in a module then the results are undefined.
+ *
+ * Description: Find the first syscall that has a null name pointer and the
+ *              syscall table entry is empty.
+ *
+ * Returns: < 0, an error occured, the return value is the error number.
+ *          > 0, the syscall number that has been assigned.
+ **/
+
+int register_dynamic_syscall(const char *name, void (*func)(void))
+{
+	int i, ret = -EBUSY;
+	write_lock(&dynamic_syscalls_lock);
+	for (i = 0; i < sizeof(dynamic_syscalls_name)/sizeof(dynamic_syscalls_name[0]) ; i++) {
+		if (dynamic_syscalls_name[i] == NULL && sys_call_table[i+DYNAMIC_SYSCALL_FIRST] == DYNAMIC_SYSCALL_EMPTY) {
+			dynamic_syscalls_name[i] = name;
+			sys_call_table[i+DYNAMIC_SYSCALL_FIRST] = DYNAMIC_SYSCALL_FUNCADDR(func);
+			ret = i+DYNAMIC_SYSCALL_FIRST+DYNAMIC_SYSCALL_OFFSET;
+			break;
+		}
+	}
+	write_unlock(&dynamic_syscalls_lock);
+	return ret;
+}
+
+/* No unregister_dynamic_syscall function.  Syscalls are not supported in
+ * modules.  
+ */
+
+#endif	/* DYNAMIC_SYSCALL_FIRST */
Index: 17.1/include/linux/dynamic_syscalls.h
--- 17.1/include/linux/dynamic_syscalls.h Sat, 22 Dec 2001 22:21:58 +1100 kaos ()
+++ 17.1(w)/include/linux/dynamic_syscalls.h Sat, 22 Dec 2001 22:13:37 +1100 kaos (linux-2.4/O/f/43_dynamic_sy  644)
@@ -0,0 +1,9 @@
+#ifndef _LINUX_DYNAMIC_SYSCALLS_H
+#define _LINUX_DYNAMIC_SYSCALLS_H
+
+extern int get_dynamic_syscalls_list(char *page);
+extern int register_dynamic_syscall(const char *name, void (*func)(void));
+
+#define DYNAMIC_SYSCALL_FUNC(f) (void (*)(void))(&f)
+
+#endif /* _LINUX_DYNAMIC_SYSCALLS_H */
Index: 17.1/include/asm-ia64/dynamic_syscalls.h
--- 17.1/include/asm-ia64/dynamic_syscalls.h Sat, 22 Dec 2001 22:21:58 +1100 kaos ()
+++ 17.1(w)/include/asm-ia64/dynamic_syscalls.h Sat, 22 Dec 2001 22:13:37 +1100 kaos (linux-2.4/O/f/44_dynamic_sy  644)
@@ -0,0 +1,28 @@
+#ifndef _ASM_DYNAMIC_SYSCALLS_H
+#define _ASM_DYNAMIC_SYSCALLS_H
+
+#include <linux/sys.h>
+
+#define DYNAMIC_SYSCALL_T		long long
+#define DYNAMIC_SYSCALL_FMT		"ll"
+
+/* IA64 function parameters do not point to the function itself, they point to a
+ * descriptor containing the 64 bit address of the function and the global
+ * pointer.  Dereference the function pointer to get the real function address,
+ * the syscall table requires direct addresses.
+ *
+ * This will almost certainly destroy your kernel if the syscall function is in
+ * a module because it will be entered with the wrong global pointer.
+ * Don't do that.
+ */
+
+#include <linux/types.h>
+#define DYNAMIC_SYSCALL_FUNCADDR(f)	({DYNAMIC_SYSCALL_T *fp = (DYNAMIC_SYSCALL_T *)(f); fp[0];})
+
+#define DYNAMIC_SYSCALL_OFFSET		1024
+#define DYNAMIC_SYSCALL_FIRST		240
+#define DYNAMIC_SYSCALL_LAST		NR_syscalls-1
+#define DYNAMIC_SYSCALL_EMPTY		DYNAMIC_SYSCALL_FUNCADDR(&ia64_ni_syscall)
+extern long ia64_ni_syscall(void);	/* No need to define parameters */
+
+#endif /* _ASM_DYNAMIC_SYSCALLS_H */
Index: 17.1/include/asm-i386/dynamic_syscalls.h
--- 17.1/include/asm-i386/dynamic_syscalls.h Sat, 22 Dec 2001 22:21:58 +1100 kaos ()
+++ 17.1(w)/include/asm-i386/dynamic_syscalls.h Sat, 22 Dec 2001 22:13:37 +1100 kaos (linux-2.4/O/f/45_dynamic_sy  644)
@@ -0,0 +1,21 @@
+#ifndef _ASM_DYNAMIC_SYSCALLS_H
+#define _ASM_DYNAMIC_SYSCALLS_H
+
+#include <linux/sys.h>
+
+#define DYNAMIC_SYSCALL_T		long
+#define DYNAMIC_SYSCALL_FMT		"l"
+
+/* This is a noop on most systems.  It does real work on architectures that use
+ * function descriptors.  See asm-ia64/dynamic_syscalls.h for an example.
+ */
+
+#define DYNAMIC_SYSCALL_FUNCADDR(f)	(DYNAMIC_SYSCALL_T)(f)
+
+#define DYNAMIC_SYSCALL_OFFSET		0
+#define DYNAMIC_SYSCALL_FIRST		240
+#define DYNAMIC_SYSCALL_LAST		NR_syscalls-1
+#define DYNAMIC_SYSCALL_EMPTY		DYNAMIC_SYSCALL_FUNCADDR(&sys_ni_syscall)
+extern long sys_ni_syscall(void);	/* No need to define parameters */
+
+#endif /* _ASM_DYNAMIC_SYSCALLS_H */

Re: [patch] Assigning syscall numbers for testing

[Alan Cox]

> User space code should open /proc/dynamic_syscalls, read the lines
> looking for their syscall name, extract the number and call the glibc
> syscall() function using that number.  Do not use the _syscalln()
> functions, they require a constant syscall number at compile time.

Simple brutal and to the point. Also it means a dynamic library can 
switch to real syscalls and dynamic apps will migrate fine.

One request - can we specify a namespace of the form

['vendorid'].[call]

vendorid is the wrong phrase but "some sane way of knowing whose syscall
it is" - it would be bad for andrea-aio and ben-aio to use the same names..


Alan

Re: [patch] Assigning syscall numbers for testing

[Keith Owens]

On Sat, 22 Dec 2001 14:12:45 +0000 (GMT), 
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> User space code should open /proc/dynamic_syscalls, read the lines
>> looking for their syscall name, extract the number and call the glibc
>> syscall() function using that number.  Do not use the _syscalln()
>> functions, they require a constant syscall number at compile time.
>
>Simple brutal and to the point. Also it means a dynamic library can 
>switch to real syscalls and dynamic apps will migrate fine.
>
>One request - can we specify a namespace of the form
>
>['vendorid'].[call]
>
>vendorid is the wrong phrase but "some sane way of knowing whose syscall
>it is" - it would be bad for andrea-aio and ben-aio to use the same names..

Did that in the comments.

/**
 * register_dynamic_syscall - assign a dynamic syscall number.
 * @name: the name of the syscall, used by user space code to find the number.
 *        Use a unique name, if there is any possibility of conflict with
 *        other test syscalls then include your company or initials in the name.

Re: [patch] Assigning syscall numbers for testing

[Benjamin LaHaise]

On Sat, Dec 22, 2001 at 10:28:55PM +1100, Keith Owens wrote:
> The patch below dynamically assigns a syscall number to a name and
> exports the number and name via /proc.  Dynamic assignment removes the
> collision problem.  Exporting via /proc allows user space code to
> automatically find out what the syscall number is this week.  strace
> could read the /proc output to print the syscall name, although it
> still cannot print the arguments.

Doesn't work.  You've still got problems running binaries compiled against 
newer kernels (say, glibc supporting a new syscall) against the dynamic 
syscall.  Numbers don't work, plain and simple.

		-ben

Re: [patch] Assigning syscall numbers for testing

[Davide Libenzi]

On Sat, 22 Dec 2001, Keith Owens wrote:

[...]

<>
On Wed, 19 Dec 2001, Benjamin LaHaise wrote:

> What I'm saying is that for more people to play with it, it needs to be
> more widely available.  The set of developers that read linux-kernel and
> linux-aio aren't giving much feedback.  I do not expect the code to go
> into 2.5 at this point in time.  All I need is a set of syscall numbers
> that aren't going to change should this implementation stand up to the
> test of time.

It would be nice to have a cooperation between glibc and the kernel to
have syscalls mapped by name, not by number.
With name->number resolved by crtbegin.o reading a public kernel table
or accessing a fixed-ID kernel map function and filling a map.
So if internally ( at the application ) sys_getpid has index 0, the
sysmap[0] will be filled with the id retrieved inside the kernel by
looking up "sys_getpid".
Eat too spicy today ?
<>

So i did not eat too spicy that day :)




- Davide

Re: [patch] Assigning syscall numbers for testing

[Keith Owens]

On Sat, 22 Dec 2001 14:01:26 -0500, 
Benjamin LaHaise <bcrl@redhat.com> wrote:
>On Sat, Dec 22, 2001 at 10:28:55PM +1100, Keith Owens wrote:
>> The patch below dynamically assigns a syscall number to a name and
>> exports the number and name via /proc.  Dynamic assignment removes the
>> collision problem.  Exporting via /proc allows user space code to
>> automatically find out what the syscall number is this week.  strace
>> could read the /proc output to print the syscall name, although it
>> still cannot print the arguments.
>
>Doesn't work.  You've still got problems running binaries compiled against 
>newer kernels (say, glibc supporting a new syscall) against the dynamic 
>syscall.  Numbers don't work, plain and simple.

You did not read my mail all the way through, did you?  I said -

If the [user space] code cannot open /proc/dynamic_syscalls or cannot
find the desired syscall name, fall back to the assigned syscall number
(if any) or fail if there is no assigned syscall number.  By falling
back to the assigned syscall number, new versions of the user space
code are backwards compatible, on older kernels it will use the dynamic
syscall number, on newer kernels it will use the assigned number.

Re: [patch] Assigning syscall numbers for testing

[Benjamin LaHaise]

On Sun, Dec 23, 2001 at 10:18:26AM +1100, Keith Owens wrote:
> You did not read my mail all the way through, did you?  I said -
> 
> If the [user space] code cannot open /proc/dynamic_syscalls or cannot
> find the desired syscall name, fall back to the assigned syscall number
> (if any) or fail if there is no assigned syscall number.  By falling
> back to the assigned syscall number, new versions of the user space
> code are backwards compatible, on older kernels it will use the dynamic
> syscall number, on newer kernels it will use the assigned number.

No, that's not the case I'm talking about: what happens when a vendor 
starts shipping this patch and Linus decides to add a new syscall that 
uses a syscall number that the old kernel used for dynamic syscalls?

		-ben
-- 
Fish.

Re: [patch] Assigning syscall numbers for testing

[Keith Owens]

On Sat, 22 Dec 2001 18:25:57 -0500, 
Benjamin LaHaise <bcrl@redhat.com> wrote:
>On Sun, Dec 23, 2001 at 10:18:26AM +1100, Keith Owens wrote:
>> You did not read my mail all the way through, did you?  I said -
>> 
>> If the [user space] code cannot open /proc/dynamic_syscalls or cannot
>> find the desired syscall name, fall back to the assigned syscall number
>> (if any) or fail if there is no assigned syscall number.  By falling
>> back to the assigned syscall number, new versions of the user space
>> code are backwards compatible, on older kernels it will use the dynamic
>> syscall number, on newer kernels it will use the assigned number.
>
>No, that's not the case I'm talking about: what happens when a vendor 
>starts shipping this patch and Linus decides to add a new syscall that 
>uses a syscall number that the old kernel used for dynamic syscalls?

That is why the dynamic syscall range starts well above the currently
allocated range.  If you are looking at my first mail then the patch is
wrong, in my second mail with the correct patch (first patch line is
17.1/kernel/Makefile) the dynamic range starts at 240.

Re: [patch] Assigning syscall numbers for testing

[Chris Vandomelen]

> No, that's not the case I'm talking about: what happens when a vendor
> starts shipping this patch and Linus decides to add a new syscall that
> uses a syscall number that the old kernel used for dynamic syscalls?

Isn't that a non-issue, based on the patch that was sent? So, you change
a few #define statements to point to other unused slots in the syscall
table, and you're good to go.

If I understood correctly, /proc/dynamic_syscalls contains the information
about dynamically registered syscall name->number associations, which are
placed beyond the end of the currently registered set of syscalls. Later
on down the line when we have 500 syscalls (exaggeration of course), the
patch should still work as intended by just telling it that the empty
slots in the syscall table begin at 501. So now your syscall that was
registered as syscall 241 with the dynamic syscall patch in 2.4.17 now
gets number 502 (or anything else for that matter) with the same patch
under 5.4.23. Whee.

Chris

Re: [patch] Assigning syscall numbers for testing

[Keith Owens]

On Sat, 22 Dec 2001 20:04:24 -0800 (PST), 
Chris Vandomelen <chrisv@b0rked.dhs.org> wrote:
>> No, that's not the case I'm talking about: what happens when a vendor
>> starts shipping this patch and Linus decides to add a new syscall that
>> uses a syscall number that the old kernel used for dynamic syscalls?
>
>If I understood correctly, /proc/dynamic_syscalls contains the information
>about dynamically registered syscall name->number associations, which are
>placed beyond the end of the currently registered set of syscalls. Later
>on down the line when we have 500 syscalls (exaggeration of course), the
>patch should still work as intended by just telling it that the empty
>slots in the syscall table begin at 501. So now your syscall that was
>registered as syscall 241 with the dynamic syscall patch in 2.4.17 now
>gets number 502 (or anything else for that matter) with the same patch
>under 5.4.23. Whee.

I'm glad somebody understands the code :).

Re: [patch] Assigning syscall numbers for testing

[Benjamin LaHaise]

On Sun, Dec 23, 2001 at 04:10:21PM +1100, Keith Owens wrote:
> I'm glad somebody understands the code :).

There are two directions of binary compatibility: forwads and backwards.  
Your patch breaks forwards compatibility if used outside the main tree.  Try 
to understand this.

		-ben
-- 
Fish.

Re: [patch] Assigning syscall numbers for testing

[Davide Libenzi]

On Sun, 23 Dec 2001, Benjamin LaHaise wrote:

> On Sun, Dec 23, 2001 at 04:10:21PM +1100, Keith Owens wrote:
> > I'm glad somebody understands the code :).
>
> There are two directions of binary compatibility: forwads and backwards.
> Your patch breaks forwards compatibility if used outside the main tree.  Try
> to understand this.

Guys, doing this in the correct way is not difficult, just we need glibc
cooperation. The module ( app or sl ) will have a table of system call
mappings :

unsinged sysmap[];

and it'll know that sys_getpid is entry 0, etc... ( static knowledge ).
When invoking sys_getpid it'll load the syscall # register with sysmap[0]
and then it'll invoke the syscall entry. Current system call will retain
their current #ID and this will provide backward compatibility.
The table is filled at module initialization time by calling ( for
performance reasons ) a fixed #ID system call sys_namemap(), that will use
an internal hashed map of system names to #ID, and will return the #ID
given a system call name. If the module require a system call that it's
not present inside the loading kernel, it'll fail the module load.
glibc ver >= N will require kernel ver >= M ( that will have the
sys_namemap() function ). System call names should be placed in a special
gcc section where they can be easily looped at init time to fill the
sysmap[] table. Where does it break ?




- Davide

Re: [patch] Assigning syscall numbers for testing

[Keith Owens]

On Sun, 23 Dec 2001 12:06:04 -0500, 
Benjamin LaHaise <bcrl@redhat.com> wrote:
>On Sun, Dec 23, 2001 at 04:10:21PM +1100, Keith Owens wrote:
>> I'm glad somebody understands the code :).
>
>There are two directions of binary compatibility: forwads and backwards.  
>Your patch breaks forwards compatibility if used outside the main tree.  Try 
>to understand this.

Too vague, give me an example with real code and effects.

Re: [patch] Assigning syscall numbers for testing

[Doug Ledford]

Keith Owens wrote:

> On Sun, 23 Dec 2001 12:06:04 -0500, 
> Benjamin LaHaise <bcrl@redhat.com> wrote:
> 
>>On Sun, Dec 23, 2001 at 04:10:21PM +1100, Keith Owens wrote:
>>
>>>I'm glad somebody understands the code :).
>>>
>>There are two directions of binary compatibility: forwads and backwards.  
>>Your patch breaks forwards compatibility if used outside the main tree.  Try 
>>to understand this.
>>
> 
> Too vague, give me an example with real code and effects.


Well, I'm not going to mess with code, but here's the example.  Say you 
start at syscall 240 for dynamic registration.  Someone then submits a patch 
to Linus that he accepts and which uses syscalls 240 and 241.  Now, you can 
modify the base of your patch, but if it has been accepted into any real 
kernels anywhere, then someone could inadvertently end up running a user 
space app compiled against Linus' new kernel and that uses the newly 
allocated syscalls 240 and 241.  If that's run on an older kernel with your 
patch, then you call into the wrong syscalls with the wrong data.  That's 
how forward compatibility is broken.  Ben's point is that you can move the 
numbers up as high as you want, move them around as often as you want, but 
unless either A) Linus grants your dynamic range as an *official* set of 
syscall numbers or B) you get rid of the numbers entirely, it is never 
guaranteed to be compatible with binaries compiled against newer kernels.





-- 

  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: [patch] Assigning syscall numbers for testing

[Doug Ledford]

Alan Cox wrote:

>>Well, I'm not going to mess with code, but here's the example.  Say you 
>>start at syscall 240 for dynamic registration.  Someone then submits a patch 
>>
> 
> The number you start at depends on the kernel you run.
> 
> 
>>modify the base of your patch, but if it has been accepted into any real 
>>kernels anywhere, then someone could inadvertently end up running a user 
>>space app compiled against Linus' new kernel and that uses the newly 
>>allocated syscalls 240 and 241.  If that's run on an older kernel with your 
>>
> 
> The code on execution will read the syscall numbers from procfs. It will
> find new numbers and call those. Its a very simple implementation of lazy
> binding. It only breaks if you actually run out of syscalls, and then it
> fails safe.
> 
> Alan
> 
> 

No it doesn't.  You are *assuming* that *all* code will check the lazy 
syscall bindings.  My example was about code using the predefined syscall 
number for new functions on an older kernel where those functions don't 
exist, but where they overlap with the older dynamic syscall numbers.  In 
short, the patch is safe for code that uses the lazy binding, but it can 
still overlap with future syscall numbers and code that doesn't use the lazy 
binding but instead uses predefined numbers.

-- 

  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: [patch] Assigning syscall numbers for testing

[Alan Cox]

> Well, I'm not going to mess with code, but here's the example.  Say you 
> start at syscall 240 for dynamic registration.  Someone then submits a patch 

The number you start at depends on the kernel you run.

> modify the base of your patch, but if it has been accepted into any real 
> kernels anywhere, then someone could inadvertently end up running a user 
> space app compiled against Linus' new kernel and that uses the newly 
> allocated syscalls 240 and 241.  If that's run on an older kernel with your 

The code on execution will read the syscall numbers from procfs. It will
find new numbers and call those. Its a very simple implementation of lazy
binding. It only breaks if you actually run out of syscalls, and then it
fails safe.

Alan

Re: [patch] Assigning syscall numbers for testing

[David Lang]

you miss the point, the syscall numbers will not nessasarily be consistant
from boot to boot so if your code does not check for them it's seriously
broken (and remember this is only for stuff in experimental status). The
hope is that most if not all of the real checking can end up being done in
glibc

David Lang



 On Mon, 24 Dec 2001, Doug Ledford wrote:

> Date: Mon, 24 Dec 2001 12:06:19 -0500
> From: Doug Ledford <dledford@redhat.com>
> To: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Cc: Keith Owens <kaos@ocs.com.au>, Benjamin LaHaise <bcrl@redhat.com>,
>      linux-kernel@vger.kernel.org
> Subject: Re: [patch] Assigning syscall numbers for testing
>
> Alan Cox wrote:
>
> >>Well, I'm not going to mess with code, but here's the example.  Say you
> >>start at syscall 240 for dynamic registration.  Someone then submits a patch
> >>
> >
> > The number you start at depends on the kernel you run.
> >
> >
> >>modify the base of your patch, but if it has been accepted into any real
> >>kernels anywhere, then someone could inadvertently end up running a user
> >>space app compiled against Linus' new kernel and that uses the newly
> >>allocated syscalls 240 and 241.  If that's run on an older kernel with your
> >>
> >
> > The code on execution will read the syscall numbers from procfs. It will
> > find new numbers and call those. Its a very simple implementation of lazy
> > binding. It only breaks if you actually run out of syscalls, and then it
> > fails safe.
> >
> > Alan
> >
> >
>
> No it doesn't.  You are *assuming* that *all* code will check the lazy
> syscall bindings.  My example was about code using the predefined syscall
> number for new functions on an older kernel where those functions don't
> exist, but where they overlap with the older dynamic syscall numbers.  In
> short, the patch is safe for code that uses the lazy binding, but it can
> still overlap with future syscall numbers and code that doesn't use the lazy
> binding but instead uses predefined numbers.
>
> --
>
>   Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
>        Please check my web site for aic7xxx updates/answers before
>                        e-mailing me about problems
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [patch] Assigning syscall numbers for testing

[David Lang]

so this just means that an eye needs to be kept on the non-dynamic
syscalls  and up the starting point for dynamic syscalls significantly
before we run out of space for the non-dynamic ones.

running software that depends on features in a new kernel on a
significantly older kernel is always questionable, if you software really
needs to do that you need to watch for a bunch of things.

David Lang


On Mon, 24 Dec 2001, Doug Ledford wrote:

> Date: Mon, 24 Dec 2001 13:13:29 -0500
> From: Doug Ledford <dledford@redhat.com>
> To: David Lang <david.lang@digitalinsight.com>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, Keith Owens <kaos@ocs.com.au>,
>      Benjamin LaHaise <bcrl@redhat.com>, linux-kernel@vger.kernel.org
> Subject: Re: [patch] Assigning syscall numbers for testing
>
> David Lang wrote:
>
> > you miss the point, the syscall numbers will not nessasarily be consistant
> > from boot to boot so if your code does not check for them it's seriously
> > broken (and remember this is only for stuff in experimental status). The
> > hope is that most if not all of the real checking can end up being done in
> > glibc
>
>
> No, I'm not missing the point.  Try to follow with me here, this isn't
> rocket science.  *NOT* *ALL* *SOFTWARE* *IS* *OR* *WILL* *BE* *USING*
> *DYNAMIC* *SYSCALLS*.  Your scenario is fine if you want to convert all
> existing software to dynamic syscalls.  However, my scenario specifically
> dealt with software that *DOES* *NOT* use dynamic syscalls (and which
> doesn't need to because the syscalls it *does* use have been allocated).
>
> Since people are having such a hard time with this, let me spell it out in
> more detail.  Assume the following scenario:
>
> Linux 2.4.17 + dynamic syscall patch.  Dynamic syscalls start at 240.
>
> Linux 2.4.18 comes out, and now there are two *new* *official* *statically*
> *allocated* syscalls at 240 and 241 (they are SYSGETAMIBLKHEAD and
> SYSSETAMIBLKHEAD).
>
> A new piece of software (or an existing one, doesn't matter) is written to
> take advantage of the new syscalls.  It uses the *predefined* syscall
> numbers and is compiled against 2.4.18.  It relies upon -ENOSYS (as is
> typical for non-dynamic syscalls) to indicate if the kernel doesn't support
> the intended syscalls.
>
> Now, someone without realizing the implications of what's going on, runs
> this new program on a machine running the 2.4.17 + dynamic syscall patch.
>
> BOOM!
>
> So, to reiterate my points.  This *IS* *NOT* *SAFE* unless either A) the
> dynamic syscall number range is officially allocated *before* the patch goes
> into use to avoid these collisions later or B) you switch *all* software to
> using dynamic syscalls (which does have a performance impact on the software
> and which would also require lots of work).
>
>
> > David Lang
> >
> >
> >
> >  On Mon, 24 Dec 2001, Doug Ledford wrote:
> >
> >
> >>Date: Mon, 24 Dec 2001 12:06:19 -0500
> >>From: Doug Ledford <dledford@redhat.com>
> >>To: Alan Cox <alan@lxorguk.ukuu.org.uk>
> >>Cc: Keith Owens <kaos@ocs.com.au>, Benjamin LaHaise <bcrl@redhat.com>,
> >>     linux-kernel@vger.kernel.org
> >>Subject: Re: [patch] Assigning syscall numbers for testing
> >>
> >>Alan Cox wrote:
> >>
> >>
> >>>>Well, I'm not going to mess with code, but here's the example.  Say you
> >>>>start at syscall 240 for dynamic registration.  Someone then submits a patch
> >>>>
> >>>>
> >>>The number you start at depends on the kernel you run.
> >>>
> >>>
> >>>
> >>>>modify the base of your patch, but if it has been accepted into any real
> >>>>kernels anywhere, then someone could inadvertently end up running a user
> >>>>space app compiled against Linus' new kernel and that uses the newly
> >>>>allocated syscalls 240 and 241.  If that's run on an older kernel with your
> >>>>
> >>>>
> >>>The code on execution will read the syscall numbers from procfs. It will
> >>>find new numbers and call those. Its a very simple implementation of lazy
> >>>binding. It only breaks if you actually run out of syscalls, and then it
> >>>fails safe.
> >>>
> >>>Alan
> >>>
> >>>
> >>>
> >>No it doesn't.  You are *assuming* that *all* code will check the lazy
> >>syscall bindings.  My example was about code using the predefined syscall
> >>number for new functions on an older kernel where those functions don't
> >>exist, but where they overlap with the older dynamic syscall numbers.  In
> >>short, the patch is safe for code that uses the lazy binding, but it can
> >>still overlap with future syscall numbers and code that doesn't use the lazy
> >>binding but instead uses predefined numbers.
> >>
> >>--
> >>
> >>  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
> >>       Please check my web site for aic7xxx updates/answers before
> >>                       e-mailing me about problems
> >>
> >>-
> >>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >>the body of a message to majordomo@vger.kernel.org
> >>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>Please read the FAQ at  http://www.tux.org/lkml/
> >>
> >>
> >
>
>
>
> --
>
>   Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
>        Please check my web site for aic7xxx updates/answers before
>                        e-mailing me about problems
>

Re: [patch] Assigning syscall numbers for testing

[Doug Ledford]

David Lang wrote:

> you miss the point, the syscall numbers will not nessasarily be consistant
> from boot to boot so if your code does not check for them it's seriously
> broken (and remember this is only for stuff in experimental status). The
> hope is that most if not all of the real checking can end up being done in
> glibc


No, I'm not missing the point.  Try to follow with me here, this isn't 
rocket science.  *NOT* *ALL* *SOFTWARE* *IS* *OR* *WILL* *BE* *USING* 
*DYNAMIC* *SYSCALLS*.  Your scenario is fine if you want to convert all 
existing software to dynamic syscalls.  However, my scenario specifically 
dealt with software that *DOES* *NOT* use dynamic syscalls (and which 
doesn't need to because the syscalls it *does* use have been allocated).

Since people are having such a hard time with this, let me spell it out in 
more detail.  Assume the following scenario:

Linux 2.4.17 + dynamic syscall patch.  Dynamic syscalls start at 240.

Linux 2.4.18 comes out, and now there are two *new* *official* *statically* 
*allocated* syscalls at 240 and 241 (they are SYSGETAMIBLKHEAD and 
SYSSETAMIBLKHEAD).

A new piece of software (or an existing one, doesn't matter) is written to 
take advantage of the new syscalls.  It uses the *predefined* syscall 
numbers and is compiled against 2.4.18.  It relies upon -ENOSYS (as is 
typical for non-dynamic syscalls) to indicate if the kernel doesn't support 
the intended syscalls.

Now, someone without realizing the implications of what's going on, runs 
this new program on a machine running the 2.4.17 + dynamic syscall patch.

BOOM!

So, to reiterate my points.  This *IS* *NOT* *SAFE* unless either A) the 
dynamic syscall number range is officially allocated *before* the patch goes 
into use to avoid these collisions later or B) you switch *all* software to 
using dynamic syscalls (which does have a performance impact on the software 
and which would also require lots of work).


> David Lang
> 
> 
> 
>  On Mon, 24 Dec 2001, Doug Ledford wrote:
> 
> 
>>Date: Mon, 24 Dec 2001 12:06:19 -0500
>>From: Doug Ledford <dledford@redhat.com>
>>To: Alan Cox <alan@lxorguk.ukuu.org.uk>
>>Cc: Keith Owens <kaos@ocs.com.au>, Benjamin LaHaise <bcrl@redhat.com>,
>>     linux-kernel@vger.kernel.org
>>Subject: Re: [patch] Assigning syscall numbers for testing
>>
>>Alan Cox wrote:
>>
>>
>>>>Well, I'm not going to mess with code, but here's the example.  Say you
>>>>start at syscall 240 for dynamic registration.  Someone then submits a patch
>>>>
>>>>
>>>The number you start at depends on the kernel you run.
>>>
>>>
>>>
>>>>modify the base of your patch, but if it has been accepted into any real
>>>>kernels anywhere, then someone could inadvertently end up running a user
>>>>space app compiled against Linus' new kernel and that uses the newly
>>>>allocated syscalls 240 and 241.  If that's run on an older kernel with your
>>>>
>>>>
>>>The code on execution will read the syscall numbers from procfs. It will
>>>find new numbers and call those. Its a very simple implementation of lazy
>>>binding. It only breaks if you actually run out of syscalls, and then it
>>>fails safe.
>>>
>>>Alan
>>>
>>>
>>>
>>No it doesn't.  You are *assuming* that *all* code will check the lazy
>>syscall bindings.  My example was about code using the predefined syscall
>>number for new functions on an older kernel where those functions don't
>>exist, but where they overlap with the older dynamic syscall numbers.  In
>>short, the patch is safe for code that uses the lazy binding, but it can
>>still overlap with future syscall numbers and code that doesn't use the lazy
>>binding but instead uses predefined numbers.
>>
>>--
>>
>>  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
>>       Please check my web site for aic7xxx updates/answers before
>>                       e-mailing me about problems
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at  http://www.tux.org/lkml/
>>
>>
> 



-- 

  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: [patch] Assigning syscall numbers for testing

[Doug Ledford]

Alan Cox wrote:

>>syscall bindings.  My example was about code using the predefined syscall 
>>number for new functions on an older kernel where those functions don't 
>>exist, but where they overlap with the older dynamic syscall numbers.  In 
>>short, the patch is safe for code that uses the lazy binding, but it can 
>>still overlap with future syscall numbers and code that doesn't use the lazy 
>>binding but instead uses predefined numbers.
>>
> 
> Now I follow you. So if Linus takes that patch he needs to allocate a block
> of per architecture dynamic syscall number space for it to use. Negative
> syscall numbers seem the most promising approach ?
> 
> 

Something like that.  It needs to be a large enough range to reasonably 
support the maximum number of expected syscalls that could possibly be in 
testing at one time (which is a total guesstimate if you ask me), and it 
should hopefully be up high so that we aren't allocating new numbers around 
it.  However, I think it needs to be allocated *regardless* of whether Linus 
takes the patch into his kernel.  Even if the patch is simply used outside 
Linus's kernel, it still needs the allocation to truly be safe.

-- 

  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: [patch] Assigning syscall numbers for testing

[Alan Cox]

> syscall bindings.  My example was about code using the predefined syscall 
> number for new functions on an older kernel where those functions don't 
> exist, but where they overlap with the older dynamic syscall numbers.  In 
> short, the patch is safe for code that uses the lazy binding, but it can 
> still overlap with future syscall numbers and code that doesn't use the lazy 
> binding but instead uses predefined numbers.

Now I follow you. So if Linus takes that patch he needs to allocate a block
of per architecture dynamic syscall number space for it to use. Negative
syscall numbers seem the most promising approach ?

Re: [patch] Assigning syscall numbers for testing

[Doug Ledford]

David Lang wrote:

> so this just means that an eye needs to be kept on the non-dynamic
> syscalls  and up the starting point for dynamic syscalls significantly
> before we run out of space for the non-dynamic ones.
> 
> running software that depends on features in a new kernel on a
> significantly older kernel is always questionable, if you software really
> needs to do that you need to watch for a bunch of things.


No.  This is different.  Calling a syscall and expecting to get either A) 
the syscall you intended or B) -ENOSYS is an accepted, safe practice under 
Unix/Linux.  This breaks that practice.





-- 

  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: [patch] Assigning syscall numbers for testing

[Alan Cox]

> it.  However, I think it needs to be allocated *regardless* of whether Linus 
> takes the patch into his kernel.  Even if the patch is simply used outside 
> Linus's kernel, it still needs the allocation to truly be safe.

Negative numbers are safe until Linus has 2^31 syscalls, at which point
quite frankly we would have a few other problems including the fact that
the syscall table won't fit in kernel mapped memory.

I'm sure we could get Linus to agree not to use negative numbers out of
spite.

Re: [patch] Assigning syscall numbers for testing

[Russell King]

On Mon, Dec 24, 2001 at 07:05:31PM +0000, Alan Cox wrote:
> > it.  However, I think it needs to be allocated *regardless* of whether Linus 
> > takes the patch into his kernel.  Even if the patch is simply used outside 
> > Linus's kernel, it still needs the allocation to truly be safe.
> 
> Negative numbers are safe until Linus has 2^31 syscalls, at which point
> quite frankly we would have a few other problems including the fact that
> the syscall table won't fit in kernel mapped memory.

Please leave the allocation of the exact number space to the port
maintainers discression.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [patch] Assigning syscall numbers for testing

[Alan Cox]

> > Negative numbers are safe until Linus has 2^31 syscalls, at which point
> > quite frankly we would have a few other problems including the fact that
> > the syscall table won't fit in kernel mapped memory.
> 
> Please leave the allocation of the exact number space to the port
> maintainers discression.

Sorry.. I'm talking about x86 here. Linus is the x86 port maintainer as
well so we have to plan it out that way. For non x86 sure.

Alan

Re: [patch] Assigning syscall numbers for testing

[Edgar Toernig]

Russell King wrote:
> 
> On Mon, Dec 24, 2001 at 07:05:31PM +0000, Alan Cox wrote:
> > > it.  However, I think it needs to be allocated *regardless* of whether Linus
> > > takes the patch into his kernel.  Even if the patch is simply used outside
> > > Linus's kernel, it still needs the allocation to truly be safe.
> >
> > Negative numbers are safe until Linus has 2^31 syscalls, at which point
> > quite frankly we would have a few other problems including the fact that
> > the syscall table won't fit in kernel mapped memory.
> 
> Please leave the allocation of the exact number space to the port
> maintainers discression.

Why not assign 1 syscall that gets the name of an experimental syscall
as its first argument and does the demultiplexing?

Ciao, ET.

Re: [patch] Assigning syscall numbers for testing

[Andreas Steinmetz]

On 24-Dec-2001 Edgar Toernig wrote:
> Russell King wrote:
>> 
>> On Mon, Dec 24, 2001 at 07:05:31PM +0000, Alan Cox wrote:
>> > > it.  However, I think it needs to be allocated *regardless* of whether
>> > > Linus
>> > > takes the patch into his kernel.  Even if the patch is simply used
>> > > outside
>> > > Linus's kernel, it still needs the allocation to truly be safe.
>> >
>> > Negative numbers are safe until Linus has 2^31 syscalls, at which point
>> > quite frankly we would have a few other problems including the fact that
>> > the syscall table won't fit in kernel mapped memory.
>> 
>> Please leave the allocation of the exact number space to the port
>> maintainers discression.
> 
> Why not assign 1 syscall that gets the name of an experimental syscall
> as its first argument and does the demultiplexing?
> 

Please, no multiplexing. A well defined range (small as it may be) open to
developers (and thus collision) will do.

> Ciao, ET.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andreas Steinmetz
D.O.M. Datenverarbeitung GmbH

Re: [patch] Assigning syscall numbers for testing

[Keith Owens]

On Mon, 24 Dec 2001 13:13:29 -0500, 
Doug Ledford <dledford@redhat.com> wrote:
>David Lang wrote:
>Since people are having such a hard time with this, let me spell it out in 
>more detail.  Assume the following scenario:
>
>Linux 2.4.17 + dynamic syscall patch.  Dynamic syscalls start at 240.
>
>Linux 2.4.18 comes out, and now there are two *new* *official* *statically* 
>*allocated* syscalls at 240 and 241 (they are SYSGETAMIBLKHEAD and 
>SYSSETAMIBLKHEAD).
>
>A new piece of software (or an existing one, doesn't matter) is written to 
>take advantage of the new syscalls.  It uses the *predefined* syscall 
>numbers and is compiled against 2.4.18.  It relies upon -ENOSYS (as is 
>typical for non-dynamic syscalls) to indicate if the kernel doesn't support 
>the intended syscalls.
>
>Now, someone without realizing the implications of what's going on, runs 
>this new program on a machine running the 2.4.17 + dynamic syscall patch.
>
>BOOM!

i386 dynamic syscall table starts at 240.  Last assigned syscall entry
is currently 225, leaving room for 14 new assigned syscalls.  2.4.0
(January 5 2001) had 222 syscalls, so 2.4 added 3 assigned syscalls in
just under a year.  At that rate the dynamic syscall range is safe for
4 years.  I make the reasonable assumption that new syscalls are
assigned monotonically, that Linus does not arbitrarily assign numbers
with gaps between them.

You can argue about whether the gap will close in 2 or 4 years.  I
suspect it will be longer than 4 years because syscall growth has been
dropping off since 2.0.

You will only get a problem when :-

* The assigned numbers reach the dynamic range _and_
* A program with an assigned syscall that overlaps the old dynamic
  range runs on a 4 year old kernel _and_
* The 4 year old kernel has the dynamic syscall patch _and_
* Some code on the 4 year old kernel is using dynamic syscalls.

A problem will only arise if _all_ of those criteria are met.  In
particular the old kernel must still be running application code that
uses dynamic syscalls, no dynamic syscalls used == no problem.

My patch is for _testing_ syscalls, not for long term use instead of
getting assigned syscall numbers.  Even if you run a brand new
application on a 4 year old kernel, you will not still be running
testing code on the old kernel.

I agree that it would be nice to have a permanently reserved dynamic
range and if my patch goes into the kernel that is exactly what I will
ask Linus for.  Even if there is no reserved dynamic range, the risk of
causing problems with new applications on old kernels is miniscule.

ps.  Bah, humbug!

Re: [patch] Assigning syscall numbers for testing

[Russell King]

On Tue, Dec 25, 2001 at 01:18:26PM +1100, Keith Owens wrote:
> i386 dynamic syscall table starts at 240.  Last assigned syscall entry
> is currently 225, leaving room for 14 new assigned syscalls.  2.4.0
> (January 5 2001) had 222 syscalls, so 2.4 added 3 assigned syscalls in
> just under a year.

Erm, there's a rather obvious flaw in your argument here - 2.4 is supposed
to be a stable kernel with relatively few features appearing in it.  We're
now into 2.5.  We've already seen several people trying to get new syscall
numbers between 2.5.0 and 2.5.1, which is also a relatively short
timeframe.

Lets look at some more realistic timeframe.  These figures are for i386:

	2.2.20	- 190 syscalls, last one is sys_vfork
	2.4.17	- 225 syscalls, last one is sys_readahead

So, between these two stable kernel series, _35_ syscalls have been added.
If we assume this trend will continue through 2.5, then we'll be up to
260 syscalls when 2.6 or 3.0 is out.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [patch] Assigning syscall numbers for testing

[Riley Williams]

Hi David.

> so this just means that an eye needs to be kept on the non-dynamic
> syscalls and up the starting point for dynamic syscalls
> significantly before we run out of space for the non-dynamic ones.

How far in advance do you call "significantly"? I know of dedicated
systems still running Linux 1.2.12, and I use 2.0 series kernels on
some of my systems, so your solution is a non-starter in my book.

I'd say that there are only three options for safely dealing with
this problem...

 1. Allocate a fixed range for dynamic syscalls that can NEVER be
    used by static ones. If the static syscalls hit the bottom of
    it, they skip it and restart just above its top.

    Two variants of this have been proposed so far...

 	a.	Negative syscall numbers are dynamic.

 	b.	Syscall numbers with the MSB set are dynamic.

    ...and these are essentially variants on the same thing.

 2. Each syscall includes a flag stating whether it's a static
    or dynamic one, with separate jump tables for each. This
    would be something that is currently always the same state
    for existing static syscalls.

    One variant of this would be to redefine the syscall number
    as being two fields, with the MSB as the static/dynamic flag
    and the rest as the syscall number. This would incorporate
    option (1b) as a variant of this option.

 3. Have separate syscall entry points for static and dynamic
    syscalls.

...and anything else is at risk from the scenario referred to.

> running software that depends on features in a new kernel on a
> significantly older kernel is always questionable, if you software
> really needs to do that you need to watch for a bunch of things.

Very true, but not necessarily relevant.

>>> you miss the point, the syscall numbers will not nessasarily be
>>> consistant from boot to boot so if your code does not check for
>>> them it's seriously broken (and remember this is only for stuff
>>> in experimental status). The hope is that most if not all of the
>>> real checking can end up being done in glibc

>> No, I'm not missing the point. Try to follow with me here, this
>> isn't rocket science. *NOT* *ALL* *SOFTWARE* *IS* *OR* *WILL* *BE*
>> *USING* *DYNAMIC* *SYSCALLS*. Your scenario is fine if you want to
>> convert all existing software to dynamic syscalls. However, my
>> scenario specifically dealt with software that *DOES* *NOT* use
>> dynamic syscalls (and which doesn't need to because the syscalls it
>> *does* use have been allocated).
>>
>> Since people are having such a hard time with this, let me spell it
>> out in more detail. Assume the following scenario:
>>
>> Linux 2.4.17 + dynamic syscall patch. Dynamic syscalls start at 240.

Assume they finish at 255 for my comments below.

>> Linux 2.4.18 comes out, and now there are two *new* *official*
>> *statically* *allocated* syscalls at 240 and 241 (they are
>> SYSGETAMIBLKHEAD and SYSSETAMIBLKHEAD).

Preventing this would require that solution (1) has been implemented,
in which case the new syscalls would be 256 and 257 as 240 through 255
are reserved for the dynamic syscalls.

>> A new piece of software (or an existing one, doesn't matter) is
>> written to take advantage of the new syscalls. It uses the
>> *predefined* syscall numbers and is compiled against 2.4.18. It
>> relies upon -ENOSYS (as is typical for non-dynamic syscalls) to
>> indicate if the kernel doesn't support the intended syscalls.
>>
>> Now, someone without realizing the implications of what's going
>> on, runs this new program on a machine running the 2.4.17+dynamic
>> syscall patch.
>>
>> BOOM!
>>
>> So, to reiterate my points. This *IS* *NOT* *SAFE* unless either
>>
>>  A) the dynamic syscall number range is officially allocated
>>     *before* the patch goes into use to avoid these collisions
>>     later or
>>
>>  B) you switch *all* software to using dynamic syscalls (which
>>     does have a performance impact on the software and which
>>     would also require lots of work).

Best wishes from Riley.