* Re: kernel: postnote patch
@ 2020-04-06 14:07 covertusername967
2020-04-07 7:26 ` [9front] " cinap_lenrek
0 siblings, 1 reply; 5+ messages in thread
From: covertusername967 @ 2020-04-06 14:07 UTC (permalink / raw)
To: covertusername967, 9front
Here is a new version of the patch that checks the length of the note
string BEFORE aquiring the p->debug lock if dolock is set (thanks
kvik).
diff -r 8c47f4302b74 sys/src/9/port/proc.c
--- a/sys/src/9/port/proc.c Sun Apr 05 23:26:52 2020 +0930
+++ b/sys/src/9/port/proc.c Mon Apr 06 08:48:52 2020 -0500
@@ -894,6 +894,9 @@
if(p == nil)
return 0;
+ if(strlen(n) == 0)
+ return 0;
+
if(dolock)
qlock(&p->debug);
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9front] Re: kernel: postnote patch
2020-04-06 14:07 kernel: postnote patch covertusername967
@ 2020-04-07 7:26 ` cinap_lenrek
2020-04-07 13:27 ` covertusername967
0 siblings, 1 reply; 5+ messages in thread
From: cinap_lenrek @ 2020-04-07 7:26 UTC (permalink / raw)
To: 9front
> Here is a new version of the patch that checks the length of the note
> string BEFORE aquiring the p->debug lock if dolock is set (thanks
> kvik).
>
> diff -r 8c47f4302b74 sys/src/9/port/proc.c
> --- a/sys/src/9/port/proc.c Sun Apr 05 23:26:52 2020 +0930
> +++ b /sys/src/9/port/proc.c Mon Apr 06 08:48:52 2020 -0500
> @@ -894,6 +894,9 @@
> if(p == nil)
> return 0;
>
> + if(strlen(n) == 0)
> + return 0;
> +
> if(dolock)
> qlock(&p->debug);
why?
we had no constraint on the note contents before.
what is this supposed to fix?
--
cinap
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9front] Re: kernel: postnote patch
2020-04-07 7:26 ` [9front] " cinap_lenrek
@ 2020-04-07 13:27 ` covertusername967
2020-04-07 15:14 ` ori
0 siblings, 1 reply; 5+ messages in thread
From: covertusername967 @ 2020-04-07 13:27 UTC (permalink / raw)
To: cinap_lenrek, 9front
> why?
>
> we had no constraint on the note contents before.
> what is this supposed to fix?
>
> --
> cinap
Currently, posting a blank note to a process will force it to
terminate "normally", i.e no exit status. I was just taking a
suggestion from Ori that it might be worth fixing, though it might be
better to force the exit status to be non-empty.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9front] Re: kernel: postnote patch
2020-04-07 13:27 ` covertusername967
@ 2020-04-07 15:14 ` ori
0 siblings, 0 replies; 5+ messages in thread
From: ori @ 2020-04-07 15:14 UTC (permalink / raw)
To: covertusername967, cinap_lenrek, 9front
>> why?
>>
>> we had no constraint on the note contents before.
>> what is this supposed to fix?
>>
>> --
>> cinap
>
> Currently, posting a blank note to a process will force it to
> terminate "normally", i.e no exit status. I was just taking a
> suggestion from Ori that it might be worth fixing, though it might be
> better to force the exit status to be non-empty.
Thinking about it a bit more, eh -- I'm less sure that it matters.
I'm wondering what you can make go wrong with this. If someone is
can send a signal, they've already got the keys to the kingdom.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9front] Re: kernel: postnote patch
@ 2020-04-07 1:17 Alex Musolino
0 siblings, 0 replies; 5+ messages in thread
From: Alex Musolino @ 2020-04-07 1:17 UTC (permalink / raw)
To: 9front
Is this really something we have to disallow? Perhaps it could
be useful to send a note to a process and have it exit cleanly?
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-04-07 15:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-06 14:07 kernel: postnote patch covertusername967
2020-04-07 7:26 ` [9front] " cinap_lenrek
2020-04-07 13:27 ` covertusername967
2020-04-07 15:14 ` ori
2020-04-07 1:17 Alex Musolino
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).