public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Grant <grantma@anathoth.gen.nz>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PROBLEM:  rt_sigsuspend() does not return EINTR on 2.6.16-rc2+
Date: Mon, 06 Mar 2006 21:28:05 +1300	[thread overview]
Message-ID: <1141633685.7634.13.camel@localhost.localdomain> (raw)
In-Reply-To: <1141557862.3764.47.camel@pmac.infradead.org>

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

David,

OK, a major piece of software is broken for mounting removable media. A
kernel upgrade from 2.6.15 SHOULDn't do that.  

Could you please tell me where go I go next?

Thanks and Cheers,

Matthew Grant

On Sun, 2006-03-05 at 11:24 +0000, David Woodhouse wrote:
> On Sun, 2006-03-05 at 14:26 +1300, Matthew Grant wrote:
> > Problem is that new sys_rt_sigsuspend in kernel/signal.c in 2.6.16-rc2+
> > does not return EINTR.
> 
> It does for me -- try the trivial test case at
> http://david.woodhou.se/sigsusptest.c
> 
> If you strace that under old and new kernels you'll see a difference in
> the strace output, but it should be entirely cosmetic. The old code
> would incestuously call do_signal() inside sys_rt_sigsuspend(), and
> would never need to use the mechanism we have for restarting system
> calls. Either it would know it delivered a signal and it would return
> -EINTR, or it would know that it _didn't_, and it would loop for itself.
> Now it behaves like all the other restartable syscalls, and ptrace will
> actually see the -ERESTARTNOHAND return code which later gets converted
> by the signal code either to -EINTR or to an actual restart, as
> appropriate.
> 
> In short, I think what you've picked up on in the strace output is
> entirely cosmetic, and shouldn't affect the behaviour of the program in
> any way. In each case, it comes back from the signal and goes
> immediately into gettimeofday() and then poll() -- it _has_ come out of
> the sigsuspend(). You then find that poll() gives different results in
> each case, and I'd be inclined to suspect that the _real_ change in
> behaviour goes from that point.
> 
> > I think David woodhouse may be responsible for this....
> 
> I read lkml sporadically; usually better to Cc me when I'm to blame :)
> 
-- 
Matthew Grant <grantma@anathoth.gen.nz>
Matthew's UNIX Box

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2006-03-06  8:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-05  1:26 PROBLEM: rt_sigsuspend() does not return EINTR on 2.6.16-rc2+ Matthew Grant
2006-03-05 11:24 ` David Woodhouse
2006-03-06  8:28   ` Matthew Grant [this message]
2006-03-06 10:45     ` Andrew Morton
2006-03-06 11:25       ` Paul Mackerras
2006-03-06 11:30         ` David Woodhouse
2006-03-06 11:31     ` David Woodhouse

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=1141633685.7634.13.camel@localhost.localdomain \
    --to=grantma@anathoth.gen.nz \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@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