[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070110.171520.23015257.davem@davemloft.net>
Date: Wed, 10 Jan 2007 17:15:20 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: jafo@...my.com
Cc: linux-kernel@...r.kernel.org
Subject: Re: select() setting ERESTARTNOHAND (514).
From: Sean Reifschneider <jafo@...my.com>
Date: Wed, 10 Jan 2007 18:04:29 -0700
> On Wed, Jan 10, 2007 at 04:27:47PM -0800, David Miller wrote:
> >It gets caught by the return into userspace code.
>
> Ok, so somehow it is leaking. I have a system in the lab that is the same
> hardware as production, but it currently has no, you know, hard drives in
> it, so some assembly is required. I'll see if I can reproduce it in a test
> environment and then see if I can get more information on when/where it is
> leaking.
If you're only seeing it in strace, that's expected due to some
unfortunate things in the way that x86 and x86_64 handle signal
return events via ptrace().
On sparc and sparc64 I fixed this long ago such that ptrace() will
update the user registers before ptrace parents are notified, and
therefore you'll never see those kernel internal error codes.
The upside of this is that you'll really need to see what value is
making it to the application. What the kernel is probably
doing is looping trying to restart the system call and sending
the signal. If it's doing that the application is being rewound
to call the system call again once the signal handler returns
(if that is even being run at all).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists