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