linux-um archives
 help / color / mirror / Atom feed
* [uml-devel] SKAS leftovers: having fun with old code relicts (aka PTRACE_SIGPENDING)
@ 2005-03-06 18:49 Blaisorblade
  2005-03-08  0:00 ` [uml-devel] " Jeff Dike
  0 siblings, 1 reply; 2+ messages in thread
From: Blaisorblade @ 2005-03-06 18:49 UTC (permalink / raw)
  To: Jeff Dike; +Cc: user-mode-linux-devel

Ok, what I discovered today is just funny...

A little, ignarious programmer (me) was porting the SKAS patch to x86_64, and 
proof-checking the sizes of vars.

While looking at PTRACE_SIGPENDING, he realized that in the i386 version we 
copy a sigset_t value (child->pending.signal), which is 64-bit wide, to a 
"unsigned long", i.e. 32-bit wide*.

        case PTRACE_SIGPENDING:
                ret = copy_to_user((unsigned long *) data,
                                   &child->pending.signal,
                                   sizeof(child->pending.signal));
                break;

"What the fuck!" said the ignarious programmer (me), and he went looking 
carefully to each and every usage of PTRACE_SIGPENDING in the Uml code, to 
check why nobody sees the world collapsing (maybe the callers are correct 
anyway, he thought):

 $ find arch/um/ include/asm-um/ |xargs grep PTRACE_SIGPENDING
arch/um/kernel/ptrace.c:        case PTRACE_SIGPENDING:
arch/um/include/skas_ptrace.h:#define PTRACE_SIGPENDING 53

He checked better, and better, distrusting the Truth discovered by his poor 
and liable mate, Lord Grep... but at last he couldn't ignore the Truth: 
PTRACE_SIGPENDING is a (broken) relict!

After this story, we come to the question: Jeff, what I missed (apart that 
probably it was used in releases before SKAS3)?

Could I delete PTRACE_SIGPENDING from the SKAS patch?

I wouldn't for the sake of compatibility, but since the interface has never 
been used by SKAS, and probably (if somebody else used it) it didn't work 
well, I'm not certain.

*Actually, even if we write 64-bit to a 32-bit pointer above, this is done 
also for PTRACE_LDT, so type of the cast is just cosmetical. The point is 
that it's misleading for the reader.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [uml-devel] Re: SKAS leftovers: having fun with old code relicts (aka PTRACE_SIGPENDING)
  2005-03-06 18:49 [uml-devel] SKAS leftovers: having fun with old code relicts (aka PTRACE_SIGPENDING) Blaisorblade
@ 2005-03-08  0:00 ` Jeff Dike
  0 siblings, 0 replies; 2+ messages in thread
From: Jeff Dike @ 2005-03-08  0:00 UTC (permalink / raw)
  To: Blaisorblade; +Cc: user-mode-linux-devel

blaisorblade@yahoo.it said:
> After this story, we come to the question: Jeff, what I missed (apart
> that  probably it was used in releases before SKAS3)?

I don't think it was ever used.  The thinking was race avoidance - if a
signal hit the process at the same time that it started a system call, or two
signals came in at the same time, UML would handle the first, then 
PTRACE_SIGPENDING to see if there were any more that needed handling.  However,
the userspace process doesn't receive any signals apart from SIGVTALRM, so
this is somewhat moot.

If the userspace process did receive important signals (like SIGIO), then not
using this could lead to situations where the one running process sleeps for
a long time, leaving a SIGIO trapped on the userspace process.  And this
could lead to deadlocks when the SIGIO was for the I/O that the process was
sleeping on.

> Could I delete PTRACE_SIGPENDING from the SKAS patch? 

Yup.

				Jeff



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-03-07 23:06 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-06 18:49 [uml-devel] SKAS leftovers: having fun with old code relicts (aka PTRACE_SIGPENDING) Blaisorblade
2005-03-08  0:00 ` [uml-devel] " Jeff Dike

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox