[PATCH] salinfo_decode silent exit in older 2.4s

[PATCH] salinfo_decode silent exit in older 2.4s

[dann frazier]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

I was playing with salinfo_decode on an older kernel (2.4.21 era) and it
would normally die silently right after exec.

This no longer happens because of a semantic difference that occurred in
later 2.4 kernels.  Older 2.4s would return -EINTR when they wanted
userspace to try again, while current 2.4s use -ERESTARTSYS.  (The
surrounding code is also somewhat different, but it looks like the idea
is the same).

If salinfo_decode detects an EINTR, it will silently exit the main loop.
This patch corrects the problem for me on older kernels, and should have
no effect for current kernels.  Hopefully this is what the author
originally intended.

Signed-off-by: dann frazier <dannf@hp.com>

--- salinfo-0.7.orig/salinfo_decode.c	Tue Oct  5 09:23:33 2004
+++ salinfo-0.7/salinfo_decode.c	Fri Apr  8 15:06:40 2005
@@ -235,7 +235,7 @@
 		char filename[PATH_MAX];
 		if (read(fd_event, text, sizeof(text)) <= 0) {
 			if (errno == EINTR)
-				ret = 0;
+				continue;
 			else
 				perror(event_filename);
 			goto out;




[-- Attachment #2: salinfo.patch --]
[-- Type: text/x-patch, Size: 324 bytes --]

--- salinfo-0.7.orig/salinfo_decode.c	Tue Oct  5 09:23:33 2004
+++ salinfo-0.7/salinfo_decode.c	Fri Apr  8 15:06:40 2005
@@ -235,7 +235,7 @@
 		char filename[PATH_MAX];
 		if (read(fd_event, text, sizeof(text)) <= 0) {
 			if (errno == EINTR)
-				ret = 0;
+				continue;
 			else
 				perror(event_filename);
 			goto out;

Re: [PATCH] salinfo_decode silent exit in older 2.4s

[Keith Owens]

On Fri, 08 Apr 2005 15:23:43 -0600, 
dann frazier <dannf@hp.com> wrote:
>I was playing with salinfo_decode on an older kernel (2.4.21 era) and it
>would normally die silently right after exec.
>
>This no longer happens because of a semantic difference that occurred in
>later 2.4 kernels.  Older 2.4s would return -EINTR when they wanted
>userspace to try again, while current 2.4s use -ERESTARTSYS.  (The
>surrounding code is also somewhat different, but it looks like the idea
>is the same).

ERESTARTSYS should never be seen by user space code.  The kernel should
either restart the current syscall or convert the code to EINTR before
returning to user space.  If you are seeing ERESTARTSYS in user space
then it is a kernel bug.

Re: [PATCH] salinfo_decode silent exit in older 2.4s

[dann frazier]

On Mon, 2005-04-11 at 09:58 +1000, Keith Owens wrote:
> On Fri, 08 Apr 2005 15:23:43 -0600, 
> dann frazier <dannf@hp.com> wrote:
> >I was playing with salinfo_decode on an older kernel (2.4.21 era) and it
> >would normally die silently right after exec.
> >
> >This no longer happens because of a semantic difference that occurred in
> >later 2.4 kernels.  Older 2.4s would return -EINTR when they wanted
> >userspace to try again, while current 2.4s use -ERESTARTSYS.  (The
> >surrounding code is also somewhat different, but it looks like the idea
> >is the same).
> 
> ERESTARTSYS should never be seen by user space code.  The kernel should
> either restart the current syscall or convert the code to EINTR before
> returning to user space.  If you are seeing ERESTARTSYS in user space
> then it is a kernel bug.

Right, that's not the problem I'm seeing.  The problem I'm seeing is
that older kernels return -EINTR, which causes salinfo_decode to
silently exit.

Re: [PATCH] salinfo_decode silent exit in older 2.4s

[Keith Owens]

On Mon, 11 Apr 2005 15:03:06 -0600, 
dann frazier <dannf@hp.com> wrote:
>On Mon, 2005-04-11 at 09:58 +1000, Keith Owens wrote:
>> On Fri, 08 Apr 2005 15:23:43 -0600, 
>> dann frazier <dannf@hp.com> wrote:
>> >I was playing with salinfo_decode on an older kernel (2.4.21 era) and it
>> >would normally die silently right after exec.
>> >
>> >This no longer happens because of a semantic difference that occurred in
>> >later 2.4 kernels.  Older 2.4s would return -EINTR when they wanted
>> >userspace to try again, while current 2.4s use -ERESTARTSYS.  (The
>> >surrounding code is also somewhat different, but it looks like the idea
>> >is the same).
>> 
>> ERESTARTSYS should never be seen by user space code.  The kernel should
>> either restart the current syscall or convert the code to EINTR before
>> returning to user space.  If you are seeing ERESTARTSYS in user space
>> then it is a kernel bug.
>
>Right, that's not the problem I'm seeing.  The problem I'm seeing is
>that older kernels return -EINTR, which causes salinfo_decode to
>silently exit.

I coded that exit on the assumption that the only reason salinfo_decode
would get -EINTR is from a signal.  salinfo_decode 0.7 does not have
alarms, so the only signal should be from an external event, i.e. when
the user wants to shut it down.  Before changing the behaviour, can you
find out why -EINTR is being returned in the first place.  IOW, what
event is causing -EINTR to be returned.

Re: [PATCH] salinfo_decode silent exit in older 2.4s

[dann frazier]

On Tue, 2005-04-12 at 09:03 +1000, Keith Owens wrote:
> I coded that exit on the assumption that the only reason salinfo_decode
> would get -EINTR is from a signal.  salinfo_decode 0.7 does not have
> alarms, so the only signal should be from an external event, i.e. when
> the user wants to shut it down.  Before changing the behaviour, can you
> find out why -EINTR is being returned in the first place.  IOW, what
> event is causing -EINTR to be returned.

hey Keith,
  An strace shows a SIGCHLD, for which a handler is registered.
Apparently this is the salinfo_decode_oem process?

Re: [PATCH] salinfo_decode silent exit in older 2.4s

[dann frazier]

On Wed, 2005-04-13 at 13:51 -0600, dann frazier wrote:
> On Tue, 2005-04-12 at 09:03 +1000, Keith Owens wrote:
> > I coded that exit on the assumption that the only reason salinfo_decode
> > would get -EINTR is from a signal.  salinfo_decode 0.7 does not have
> > alarms, so the only signal should be from an external event, i.e. when
> > the user wants to shut it down.  Before changing the behaviour, can you
> > find out why -EINTR is being returned in the first place.  IOW, what
> > event is causing -EINTR to be returned.
> 
> hey Keith,
>   An strace shows a SIGCHLD, for which a handler is registered.
> Apparently this is the salinfo_decode_oem process?

hey Keith,
  Did this reply answer your question, or do you need more information
from me?  It seems SIGCHLD is the corner case.  Does exit(0) make sense
for other signals?

Re: [PATCH] salinfo_decode silent exit in older 2.4s

[Keith Owens]

On Tue, 19 Apr 2005 15:51:28 -0600, 
dann frazier <dannf@hp.com> wrote:
>On Wed, 2005-04-13 at 13:51 -0600, dann frazier wrote:
>> On Tue, 2005-04-12 at 09:03 +1000, Keith Owens wrote:
>> > I coded that exit on the assumption that the only reason salinfo_decode
>> > would get -EINTR is from a signal.  salinfo_decode 0.7 does not have
>> > alarms, so the only signal should be from an external event, i.e. when
>> > the user wants to shut it down.  Before changing the behaviour, can you
>> > find out why -EINTR is being returned in the first place.  IOW, what
>> > event is causing -EINTR to be returned.
>> 
>> hey Keith,
>>   An strace shows a SIGCHLD, for which a handler is registered.
>> Apparently this is the salinfo_decode_oem process?
>
>hey Keith,
>  Did this reply answer your question, or do you need more information
>from me?  It seems SIGCHLD is the corner case.  Does exit(0) make sense
>for other signals?

Thanks, you answered my questions.  I have a lot of updates queued for
salinfo_decode to make it more resilient, your patch has been included
in that set, which I am stil testing.

Re: [PATCH] salinfo_decode silent exit in older 2.4s

[dann frazier]

On Wed, 2005-04-20 at 10:04 +1000, Keith Owens wrote:
> On Tue, 19 Apr 2005 15:51:28 -0600, 
> dann frazier <dannf@hp.com> wrote:
> >On Wed, 2005-04-13 at 13:51 -0600, dann frazier wrote:
> >> On Tue, 2005-04-12 at 09:03 +1000, Keith Owens wrote:
> >> > I coded that exit on the assumption that the only reason salinfo_decode
> >> > would get -EINTR is from a signal.  salinfo_decode 0.7 does not have
> >> > alarms, so the only signal should be from an external event, i.e. when
> >> > the user wants to shut it down.  Before changing the behaviour, can you
> >> > find out why -EINTR is being returned in the first place.  IOW, what
> >> > event is causing -EINTR to be returned.
> >> 
> >> hey Keith,
> >>   An strace shows a SIGCHLD, for which a handler is registered.
> >> Apparently this is the salinfo_decode_oem process?
> >
> >hey Keith,
> >  Did this reply answer your question, or do you need more information
> >from me?  It seems SIGCHLD is the corner case.  Does exit(0) make sense
> >for other signals?
> 
> Thanks, you answered my questions.  I have a lot of updates queued for
> salinfo_decode to make it more resilient, your patch has been included
> in that set, which I am stil testing.

Great - I'll go ahead and add this patch to the Debian salinfo package,
since that's where the problem was reported and where I tested the fix.
I'll resync with your next release when it is available.  Thanks.
-- 
dann frazier <dannf@hp.com>