public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] salinfo_decode silent exit in older 2.4s
Date: Mon, 11 Apr 2005 23:03:34 +0000	[thread overview]
Message-ID: <19100.1113260614@ocs3.ocs.com.au> (raw)
In-Reply-To: <1112995423.7189.133.camel@krebs.dannf>

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.


  parent reply	other threads:[~2005-04-11 23:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-08 21:23 [PATCH] salinfo_decode silent exit in older 2.4s dann frazier
2005-04-10 23:58 ` Keith Owens
2005-04-11 21:03 ` dann frazier
2005-04-11 23:03 ` Keith Owens [this message]
2005-04-13 19:51 ` dann frazier
2005-04-19 21:51 ` dann frazier
2005-04-20  0:04 ` Keith Owens
2005-04-20  2:14 ` dann frazier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19100.1113260614@ocs3.ocs.com.au \
    --to=kaos@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox