IA32 syscall 311 not implemented on x86_64

IA32 syscall 311 not implemented on x86_64

[dragoran]

I started to get such messages in dmesg:
IA32 syscall 311 from mozilla-xremote not implemented
IA32 syscall 311 from firefox-bin not implemented
IA32 syscall 311 from mplayer not implemented
what is syscall 311  and what effect does this have?
I am using 2.6.16-1.2111_FC5 (2.6.16.14)

Re: IA32 syscall 311 not implemented on x86_64

[Chris Wedgwood]

On Sun, May 21, 2006 at 10:35:28AM +0200, dragoran wrote:

> IA32 syscall 311 from mozilla-xremote not implemented
> IA32 syscall 311 from firefox-bin not implemented
> IA32 syscall 311 from mplayer not implemented
> what is syscall 311  and what effect does this have?

sys_set_robust_list, I think it's futex related

> I am using 2.6.16-1.2111_FC5 (2.6.16.14)

probably best to bitch to Red Hat about this

Re: IA32 syscall 311 not implemented on x86_64

[dragoran]

Chris Wedgwood wrote:
> On Sun, May 21, 2006 at 10:35:28AM +0200, dragoran wrote:
>
>   
>> IA32 syscall 311 from mozilla-xremote not implemented
>> IA32 syscall 311 from firefox-bin not implemented
>> IA32 syscall 311 from mplayer not implemented
>> what is syscall 311  and what effect does this have?
>>     
>
> sys_set_robust_list, I think it's futex related
>   
ok but what does this do and what happens to this apps?
>   
>> I am using 2.6.16-1.2111_FC5 (2.6.16.14)
>>     
>
> probably best to bitch to Red Hat about this
>
>
>   

I did but got no reply yet

Re: IA32 syscall 311 not implemented on x86_64

[Chris Wedgwood]

On Sun, May 21, 2006 at 11:06:26AM +0200, dragoran wrote:

> ok but what does this do and what happens to this apps?

my guess is they fallback to something else and still work, but it's
only a guess

> I did but got no reply yet

does it happen with a mainline kernel?  a quick scan of the code shows
that syscall is wired up

Re: IA32 syscall 311 not implemented on x86_64

[dragoran]

Chris Wedgwood wrote:
> On Sun, May 21, 2006 at 11:06:26AM +0200, dragoran wrote:
>
>   
>> ok but what does this do and what happens to this apps?
>>     
>
> my guess is they fallback to something else and still work, but it's
> only a guess
>
>   
>> I did but got no reply yet
>>     
>
> does it happen with a mainline kernel?  a quick scan of the code shows
> that syscall is wired up
>
>
>   
the weird thing is that it suddenly started to appear (no kernel update)
can it be prelink related?

Re: IA32 syscall 311 not implemented on x86_64

[dragoran]

Chris Wedgwood wrote:
> On Sun, May 21, 2006 at 11:06:26AM +0200, dragoran wrote:
>
>   
>> ok but what does this do and what happens to this apps?
>>     
>
> my guess is they fallback to something else and still work, but it's
> only a guess
>
>   
>> I did but got no reply yet
>>     
>
> does it happen with a mainline kernel?  a quick scan of the code shows
> that syscall is wired up
>
>
>   
it seems that other people are seeing this to so I filled a bug @ 
redhat: (asked in the list first)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192586

Re: IA32 syscall 311 not implemented on x86_64

[Dave Jones]

On Sun, May 21, 2006 at 01:50:15AM -0700, Chris Wedgwood wrote:
 > On Sun, May 21, 2006 at 10:35:28AM +0200, dragoran wrote:
 > 
 > > IA32 syscall 311 from mozilla-xremote not implemented
 > > IA32 syscall 311 from firefox-bin not implemented
 > > IA32 syscall 311 from mplayer not implemented
 > > what is syscall 311  and what effect does this have?
 > 
 > sys_set_robust_list, I think it's futex related
 > 
 > > I am using 2.6.16-1.2111_FC5 (2.6.16.14)
 > 
 > probably best to bitch to Red Hat about this

It's a glibc problem really. They started using that syscall,
and 2.6.16 doesn't have it.  I might backport it to our next
.16 update just to shut it up if .17 takes much longer.

		Dave

-- 
http://www.codemonkey.org.uk

Re: IA32 syscall 311 not implemented on x86_64

[Ulrich Drepper]

On 5/21/06, Dave Jones <davej@redhat.com> 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.

Re: IA32 syscall 311 not implemented on x86_64

[Dave Jones]

On Sun, May 21, 2006 at 11:35:12AM -0700, Ulrich Drepper wrote:
 > On 5/21/06, Dave Jones <davej@redhat.com> 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.

		Dave

-- 
http://www.codemonkey.org.uk

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@redhat.com> 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@redhat.com>

--- 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

Re: IA32 syscall 311 not implemented on x86_64

[Chris Wedgwood]

On Sun, May 21, 2006 at 11:35:12AM -0700, Ulrich Drepper wrote:

> It's not a glibc problem really.  The problem is this stupid error
> message in the kernel.

It must have been added very recently surely?  Has this syscall
implemented and the FC kernel doesn't seem that old.

Did FC update glibc "ahead of it's kernel" in a sense?

> 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.

Is there a list or document anywhere which details what glibc's
requirements are when it comes to unimplemented syscalls and fallback
behavior?

Re: IA32 syscall 311 not implemented on x86_64

[Adrian Bunk]

On Sun, May 21, 2006 at 02:56:10PM -0400, Dave Jones wrote:
> 
> 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@redhat.com>
> 
> --- 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;
> +}
>...

Why can't we remove sys32_ni_syscall() and call sys_ni_syscall() 
instead if all we want to do is to return -ENOSYS?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: IA32 syscall 311 not implemented on x86_64

[Dave Jones]

On Sun, May 21, 2006 at 12:35:42PM -0700, Chris Wedgwood wrote:
 > On Sun, May 21, 2006 at 11:35:12AM -0700, Ulrich Drepper wrote:
 > 
 > > It's not a glibc problem really.  The problem is this stupid error
 > > message in the kernel.
 > 
 > It must have been added very recently surely?  Has this syscall
 > implemented and the FC kernel doesn't seem that old.

It was added in 2.6.17rc

		Dave

-- 
http://www.codemonkey.org.uk

Re: IA32 syscall 311 not implemented on x86_64

[Dave Jones]

On Sun, May 21, 2006 at 09:38:18PM +0200, Adrian Bunk wrote:
 > On Sun, May 21, 2006 at 02:56:10PM -0400, Dave Jones wrote:
 > > 
 > > 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@redhat.com>
 > > 
 > > --- 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;
 > > +}
 > >...
 > 
 > Why can't we remove sys32_ni_syscall() and call sys_ni_syscall() 
 > instead if all we want to do is to return -ENOSYS?

We could, though it's a more invasive patch, which would probably sprinkle
extra includes/externs over multiple files, for no practical gain
over having this tiny function isolated to this file.

		Dave

-- 
http://www.codemonkey.org.uk

Re: IA32 syscall 311 not implemented on x86_64

[Andi Kleen]

On Sunday 21 May 2006 20:56, Dave Jones wrote:
> 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@redhat.com> 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.

I never bought this argument because there are tons of printks in the kernel
that can be triggered by everybody.
 
> Actually it is kinda throttled, but only on process name.
> This patch just removes that stuff completely.
> (Also removes a bunch of trailing whitespace)

FF tree already has a different solution.

-Andi


> 

Re: IA32 syscall 311 not implemented on x86_64

[Dave Jones]

On Mon, May 22, 2006 at 12:19:08AM +0200, Andi Kleen wrote:

 > >  > 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.
 > 
 > I never bought this argument because there are tons of printks in the kernel
 > that can be triggered by everybody.

Then they should also be either rate limited, or removed.

 > > Actually it is kinda throttled, but only on process name.
 > > This patch just removes that stuff completely.
 > > (Also removes a bunch of trailing whitespace)
 > 
 > FF tree already has a different solution.

Adding a sysctl ? That seems way overkill to me.
What practical purpose does that printk solve ?

		Dave

-- 
http://www.codemonkey.org.uk

Re: IA32 syscall 311 not implemented on x86_64

[Andi Kleen]

On Monday 22 May 2006 00:28, Dave Jones wrote:
> On Mon, May 22, 2006 at 12:19:08AM +0200, Andi Kleen wrote:
> 
>  > >  > 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.
>  > 
>  > I never bought this argument because there are tons of printks in the kernel
>  > that can be triggered by everybody.
> 
> Then they should also be either rate limited, or removed.

Yes let's remove all that kernel debugging support. It is totally useless
for most users, isn't it?

Even if they are ratelimit you can still fill up /var.

> 
>  > > Actually it is kinda throttled, but only on process name.
>  > > This patch just removes that stuff completely.
>  > > (Also removes a bunch of trailing whitespace)
>  > 
>  > FF tree already has a different solution.
> 
> Adding a sysctl ? That seems way overkill to me.
> What practical purpose does that printk solve ?

Catching missing code in the compat layer.

-Andi

Re: IA32 syscall 311 not implemented on x86_64

[Andrew Morton]

Andi Kleen <ak@suse.de> wrote:
>
> On Sunday 21 May 2006 20:56, Dave Jones wrote:
> > 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@redhat.com> 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.
> 
> I never bought this argument because there are tons of printks in the kernel
> that can be triggered by everybody.
>  

Any time anyone identifies such a printk it gets instantly nuked.  So if
you know of more, please tell.

Re: IA32 syscall 311 not implemented on x86_64

[Dave Jones]

On Mon, May 22, 2006 at 12:37:57AM +0200, Andi Kleen wrote:
 > On Monday 22 May 2006 00:28, Dave Jones wrote:
 > > On Mon, May 22, 2006 at 12:19:08AM +0200, Andi Kleen wrote:
 > > 
 > >  > >  > 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.
 > >  > 
 > >  > I never bought this argument because there are tons of printks in the kernel
 > >  > that can be triggered by everybody.
 > > 
 > > Then they should also be either rate limited, or removed.
 > 
 > Yes let's remove all that kernel debugging support. It is totally useless
 > for most users, isn't it?

If a regular user can trip up debugging printks, yes, lets remove it.
Examples ?

		Dave

-- 
http://www.codemonkey.org.uk

Re: IA32 syscall 311 not implemented on x86_64

[Chris Wedgwood]

On Sun, May 21, 2006 at 07:48:21PM -0400, Dave Jones wrote:

> If a regular user can trip up debugging printks, yes, lets remove it.
> Examples ?

segfaults are printk reported on iamd64 machines, you can fork a lot
of those if you wanted

[2.6 patch] x86_64: don't printk for unimplemented 32bit syscalls

[Adrian Bunk]

On Sun, May 21, 2006 at 03:47:04PM -0400, Dave Jones wrote:
> On Sun, May 21, 2006 at 09:38:18PM +0200, Adrian Bunk wrote:
>  > On Sun, May 21, 2006 at 02:56:10PM -0400, Dave Jones wrote:
>  > > 
>  > > 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@redhat.com>
>  > > 
>  > > --- 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;
>  > > +}
>  > >...
>  > 
>  > Why can't we remove sys32_ni_syscall() and call sys_ni_syscall() 
>  > instead if all we want to do is to return -ENOSYS?
> 
> We could, though it's a more invasive patch, which would probably sprinkle
> extra includes/externs over multiple files, for no practical gain
> over having this tiny function isolated to this file.

Where exactly is the problem with the patch below (only compile tested 
due to lack of hardware)?

> 		Dave

cu
Adrian


<--  snip  -->


Don't let users spam the logs by using unimplemented 32bit syscalls.

Simply use sys_ni_syscall().

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 arch/x86_64/ia32/ia32entry.S |    2 +-
 arch/x86_64/ia32/sys_ia32.c  |   13 -------------
 2 files changed, 1 insertion(+), 14 deletions(-)

--- linux-git-x86_64/arch/x86_64/ia32/sys_ia32.c.old	2006-05-22 02:10:15.000000000 +0200
+++ linux-git-x86_64/arch/x86_64/ia32/sys_ia32.c	2006-05-22 02:10:24.000000000 +0200
@@ -508,19 +508,6 @@
 	return compat_sys_wait4(pid, stat_addr, options, NULL);
 }
 
-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;	       
-} 
-
 /* 32-bit timeval and related flotsam.  */
 
 asmlinkage long
--- linux-git-x86_64/arch/x86_64/ia32/ia32entry.S.old	2006-05-22 02:10:56.000000000 +0200
+++ linux-git-x86_64/arch/x86_64/ia32/ia32entry.S	2006-05-22 02:11:10.000000000 +0200
@@ -322,7 +322,7 @@
 
 ni_syscall:
 	movq %rax,%rdi
-	jmp  sys32_ni_syscall			
+	jmp sys_ni_syscall		
 
 quiet_ni_syscall:
 	movq $-ENOSYS,%rax

Re: IA32 syscall 311 not implemented on x86_64

[dragoran]

Dave Jones wrote:
> On Mon, May 22, 2006 at 12:37:57AM +0200, Andi Kleen wrote:
>  > On Monday 22 May 2006 00:28, Dave Jones wrote:
>  > > On Mon, May 22, 2006 at 12:19:08AM +0200, Andi Kleen wrote:
>  > > 
>  > >  > >  > 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.
>  > >  > 
>  > >  > I never bought this argument because there are tons of printks in the kernel
>  > >  > that can be triggered by everybody.
>  > > 
>  > > Then they should also be either rate limited, or removed.
>  > 
>  > Yes let's remove all that kernel debugging support. It is totally useless
>  > for most users, isn't it?
>
> If a regular user can trip up debugging printks, yes, lets remove it.
> Examples ?
>
> 		Dave
>
>   
allmost all selinux messages.

Re: IA32 syscall 311 not implemented on x86_64

[Dave Jones]

On Mon, May 22, 2006 at 07:59:24AM +0200, dragoran wrote:

 > >If a regular user can trip up debugging printks, yes, lets remove it.
 > >Examples ?
 > >
 > allmost all selinux messages.

I assume you mean AVC messages ? They indicate something that should be
fixed in selinux policy (or that your filesystem is incorrectly labelled
-- such as if you've booted with selinux=0 at any point).

They can also get filtered with the audit subsystem to /var/log/audit/, never
hitting the dmesg ringbuffer.

		Dave

-- 
http://www.codemonkey.org.uk

Re: IA32 syscall 311 not implemented on x86_64

[Denis Vlasenko]

On Monday 22 May 2006 01:37, Andi Kleen wrote:
> On Monday 22 May 2006 00:28, Dave Jones wrote:
> > On Mon, May 22, 2006 at 12:19:08AM +0200, Andi Kleen wrote:
> > 
> >  > >  > 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.
> >  > 
> >  > I never bought this argument because there are tons of printks in the kernel
> >  > that can be triggered by everybody.
> > 
> > Then they should also be either rate limited, or removed.
> 
> Yes let's remove all that kernel debugging support. It is totally useless
> for most users, isn't it?
> 
> Even if they are ratelimit you can still fill up /var.

If one has syslogd which does not rotate logs, [s]he gets what [s]he deserves.

There are two desirable properties of logs:
 (a) do not lose information (i.e. save entire log)
 (b) do not overflow log storage
and they are simply incompatible. You must pick one.

I took (b) and am a very happy user of daemontools' multilog ever since.
I never need to manually manage my logs again...
--
vda