Re: IA32 syscall 311 not implemented on x86_64

[Dave Jones]

On Sun, May 21, 2006 at 02:50:00PM -0400, Dave Jones wrote:
 > On Sun, May 21, 2006 at 11:35:12AM -0700, Ulrich Drepper wrote:
 >  > On 5/21/06, Dave Jones <davej@xxxxxxxxxx> wrote:
 >  > >It's a glibc problem really.
 >  > 
 >  > It's not a glibc problem really.  The problem is this stupid error
 >  > message in the kernel.  We rely in many dozens of places on the kernel
 >  > returning ENOSYS in case a syscall is not implemented and we deal with
 >  > it appropriately.  There is absolutely no justification to print these
 >  > messages except perhaps in debug kernels.  IMO the sys32_ni_syscall
 >  > functions should just return ENOSYS unless you select a special debug
 >  > kernel.  One doesn't need the kernel to detect missing syscall
 >  > implementations, strace can do this as well.
 > 
 > You make a good point.  In fact, given it's unthrottled, someone
 > with too much time on their hands could easily fill up a /var
 > just by calling unimplemented syscalls this way.

Actually it is kinda throttled, but only on process name.
This patch just removes that stuff completely.
(Also removes a bunch of trailing whitespace)

Signed-off-by: Dave Jones <davej@xxxxxxxxxx>

--- linux-2.6.16.noarch/arch/x86_64/ia32/sys_ia32.c~	2006-05-21 14:50:57.000000000 -0400
+++ linux-2.6.16.noarch/arch/x86_64/ia32/sys_ia32.c	2006-05-21 14:51:48.000000000 -0400
@@ -522,17 +522,9 @@ sys32_waitpid(compat_pid_t pid, unsigned
 }
 
 int sys32_ni_syscall(int call)
-{ 
-	struct task_struct *me = current;
-	static char lastcomm[sizeof(me->comm)];
-
-	if (strncmp(lastcomm, me->comm, sizeof(lastcomm))) {
-		printk(KERN_INFO "IA32 syscall %d from %s not implemented\n",
-		       call, me->comm);
-		strncpy(lastcomm, me->comm, sizeof(lastcomm));
-	} 
-	return -ENOSYS;	       
-} 
+{
+	return -ENOSYS;
+}
 
 /* 32-bit timeval and related flotsam.  */
 
-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/