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)
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
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
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
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?
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
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
On 5/21/06, Dave Jones <[email protected]> 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.
On Sun, May 21, 2006 at 11:35:12AM -0700, Ulrich Drepper wrote:
> On 5/21/06, Dave Jones <[email protected]> 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
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 <[email protected]> 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 <[email protected]>
--- 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
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?
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 <[email protected]>
>
> --- 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
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
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 <[email protected]>
> >
> > --- 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
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 <[email protected]> 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
>
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
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
Andi Kleen <[email protected]> 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 <[email protected]> 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.
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
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
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 <[email protected]>
> > >
> > > --- 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 <[email protected]>
---
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
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.
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
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