Date: Thu, 07 Mar 2002 11:30:35 +0000 From: Peter Edwards <peter.edwards@openet-telecom.com> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD current users <current@freebsd.org>, Mckusick@mckusick.com Subject: Re: Contemplating THIS change to signals. Message-ID: <3C874F5B.4FF949F6@openet-telecom.com> References: <Pine.BSF.4.21.0203061544020.37321-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I mentioned something similar for a different reason. Go look at the last
part of the following message in the recent -hackers archives:
> Subject: ptrace bug?
> MessageId: <3C712885.A0A91264@openet-telecom.com>
(this was for -stable, BTW)
Having the suspend for the ptrace()ing parent done in issignal is a pain
when issignal is called multiple times by the debuggee before getting back
to userland. The debugger sees wait() return more than once reporting the
same signal depending on where the victim process was when it stopped, and
the code path back to userland. It's particularly noticable when the
ptrace(PT_CONTINUE) tries to continue the process with a signal, and the
signal arrives back at the debugger. The debugger has no idea wheather it
sees the signal because it tried to send it, or the same signal raised for
some other reason. The results of this can be seen in GDB frequently when
you use the "signal" command.
I suggested moving the ptrace handling to postsig(), but anything along the
lines of what you are mentioning seems like an improvement to me, and I'm
sure you're much more likely to know what you're doing :-) I only delved in
here briefly to try and work out some of the non-obvious behaviour of
ptrace().
Oh, and while your mucking with issignal(), any chance of looking at the bug
raised (and the patch) in the start of that message, and in PR kern/35175?
:-)
--
Peter
Julian Elischer wrote:
>
> Maybe this should be in -arch.. I couldn;t make my mind up,
> but..
>
> There is some behaviour in signals which seems
> 1/ un-neccesary
> 2/ potentially dangerous.
> in addition it is
> 3/ Definitly incompatible with KSEs.
>
> I am hoping that someone can give me a good reason why it is done, and
> failing that, I'm hoping people can give comments on my thoughts.
>
> The behavious in question was inherrited from BSD4.4-LITE2
>
> When the sleep code (tsleep,msleep, cv{stuff})
> checks to see if there is a pending signal that might cause the sleep
> to abort, it calls CURSIG() which calls issignal,
> which in turn might decide to actually suspend the process.
> (if the user hit ^Z for example)
>
> This is fine when CURSIG is called from userret(), because we are on the
> user boundary, however calling it from the sleep()
> call seems a rather UN-NICE thing to do.
>
> One could argue that it is safe because you are not allowed to sleep
> while holding resources (um is it not possible to sleep
> while holding a vnode?) but it seems that it is possible to hit ^Z
> at teh right moment while something is holding some resource
> (during what it expects to be a very short term sleep,) and end up
> blocking the whole system.
>
> I would argue that a process can be considered to be suspended even while
> it is running in kernel space. My definition of a suspended process
> would be one that id not running any user code. it is not making any
> headway on the userland program. This I put it to the group that
> it is sufficient to only suspend a process when it is crossing the user
> boundary. (returning to user space)
>
> My suggestion is to remove teh code in issignal() that perfoms the
> blocking actions and create a separate function that does that action.
> I would then call that function from userret() immediatly after the call
> to issignal(). The result would be that
> suspended processes would still not reach userland, but processes would
> not have to option of suspending indefinitly at sleep().
>
> The signal would still cut short the sleep, but the process would be
> allowed to proceed to the user boundary, at which point it would
> be suspended as before.
>
> If anyone has any reasons they think this is a bad idea, then please speak
> up. Neithe Matt (Dillon) nor I can see that stopping in msleep
> is required, and both of us are in fact un-easy with it.
>
> In a THREADED world it gets even more complicated, because
> the SUSPENDED state is a PER_PROCESS state, which means that
> you are not suspented until ALL THERADS have left userland
> and been counted as 'suspended'.
> Having some threads stopped 'near' msleep and others stopped at the
> userland boundary is asking for trouble in my opinion.
>
> I can not think of any downside to making the suspension
> (whether from ptrace, or a signal) only occur at the user boundary.
>
> If I hear NO arguments I'll take it that no-one can think of any reasons
> to not change the code. If yuo have a reason PLEASE speak up so that we
> can discuss it and try figure out whether it is real or can be
> gotten around in some manner.
>
> Julian
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C874F5B.4FF949F6>