Someone had alot of fun...!
Meanwhile, I fried two SD cards this morning trying to get my Pi running
Plan 9 again, and now have no money to get another card or reader. The
things we do... and to think I wanted to try Krystians GPIO code...
Good work Conor! I'm going to have to reread your thesis
A new build of CPython 2.7.6 with Mercurial 2.8.2 has been uploaded
to sources. I’ve skipped the contrib route this time as there
seems to be an error at the final stages of trying to update the
log every time I’ve tried.
% cd /n/sources/contrib/jas
% md5sum *.arch.bz2
0320a65038443107c69dc80d21
On Thu Jan 2 20:24:29 EST 2014, cinap_len...@felloff.net wrote:
> good job.
thanks you you!
- erik
good job.
--
cinap
On Thu Jan 2 19:33:37 EST 2014, cinap_len...@felloff.net wrote:
> ah, yes.
i ran some tests on this version, and it seems to work fine across
tick timer wraparound. this was done by artificially setting sys->ticks
negative
on boot. also, there was some cheezy added code to the timer check loop
ah, yes.
--
cinap
i think the list insertion code needs a single-read
test that f->alarm != 0. to prevent the 0 from
acting like a fencepost. e.g. trying to insert -10 into
list -40 -30 0 -20.
if(alarms.head) {
l = &alarms.head;
for(f = *l; f; f = f->palarm) {
>>
On Thu Jan 2 18:18:54 EST 2014, cinap_len...@felloff.net wrote:
> that said, just holding alarms qlock while setting up->alarm = 0
> is not enougth when you want to guarantee that no alarms will be
> delivered when the alarm(0) syscall returns. you would also need to
> remove a potentially posted
that said, just holding alarms qlock while setting up->alarm = 0
is not enougth when you want to guarantee that no alarms will be
delivered when the alarm(0) syscall returns. you would also need to
remove a potentially posted alarm note from your note array and
reset up->notepending (all under debu
and yes. you can get follow up alarm on alarm(0); when the alarm had
already triggered. this is unavoidable. say, the alarm could'v posted
the note just before you called alarm(0); as well, but the note was
not delivered yet. once the alarm() syscall returns to userspace, it
would pickup the posted
said other. it is ok to send the note when p->alarms is non-zero
while holding the p->debug lock. it might just change to zero
after our check but this is ok. we will send the note but pexit()
will not make it to put the process on the freelist until we
release the debug qlock.
--
cinap
On Thu Jan 2 18:02:33 EST 2014, cinap_len...@felloff.net wrote:
> exactly. but you cannot set it to non-zero value again. which is
> what we are interested in to prevent sending the note when the
> process has been reused.
it's also important for alarm(0) to complete or not complete. without
hol
exactly. but you cannot set it to non-zero value again. which is
what we are interested in to prevent sending the note when the
process has been reused.
--
cinap
On Thu Jan 2 17:54:50 EST 2014, cinap_len...@felloff.net wrote:
> no. the debug qlock is so the process wont exit. once you hold it,
> the process might be running, might be in the process of exiting
> might have been already exited or might have been reused.
>
> the key here is that while you ho
i know. i fixed that too. :)
--
cinap
no. the debug qlock is so the process wont exit. once you hold it,
the process might be running, might be in the process of exiting
might have been already exited or might have been reused.
the key here is that while you hold it. it wont make it to the
process freelist when not already there. it w
On Thu Jan 2 17:32:08 EST 2014, quans...@quanstro.net wrote:
> On Thu Jan 2 16:55:59 EST 2014, cinap_len...@felloff.net wrote:
> > i was investigating all callers of postnote() for bugs that could
> > lead to spurious notes like the alarm race i described before. btw
> > this has been fixed too.
On Thu Jan 2 16:55:59 EST 2014, cinap_len...@felloff.net wrote:
> i was investigating all callers of postnote() for bugs that could
> lead to spurious notes like the alarm race i described before. btw
> this has been fixed too. the key is to recheck p->alarm while holding
> p->debug qlock. once yo
i was investigating all callers of postnote() for bugs that could
lead to spurious notes like the alarm race i described before. btw
this has been fixed too. the key is to recheck p->alarm while holding
p->debug qlock. once you have it, the process cannot exit under you.
--
cinap
> ; cd /proc/$pid; pwd
> /proc/75189
> ; cat noteid
> 76810 ;
> ; auth/none
> ; cd /proc/$pid; pwd
> /proc/75192
> ; cat noteid
> cat: can't open noteid: 'noteid' permission denied
never mind. different process. how did you find this, anyway?
- erik
thats because cat tries to open the noteid file of
your rc shell (running as none). and not the noteid
file of its own process (cat).
static void
nonone(Proc *p)
{
if(p == up)
return;
if(strcmp(up->user, "none") != 0)
return;
if(iseve())
On Thu Jan 2 16:33:33 EST 2014, cinap_len...@felloff.net wrote:
> a process running as "none" can only access its own (calling) process.
>
> but noteid write allows it to change the noteid of its own process to
> a nother group (also running as none) which allows it to send notes
> to that group.
a process running as "none" can only access its own (calling) process.
but noteid write allows it to change the noteid of its own process to
a nother group (also running as none) which allows it to send notes
to that group.
this has to be prevented.
--
cinap
no, its not. because "none" can indeed open its own noteid file.
nonone makes sure that it cannot open the noteid file of a process
*different* from up when up->user == "none".
--
cinap
On Thu Jan 2 16:19:12 EST 2014, cinap_len...@felloff.net wrote:
> one can change the note group of a process with devproc
> by writing noteid file.
>
> case Qnoteid:
> id = atoi(a);
> if(id == p->pid) {
> p->noteid = id;
>
one can change the note group of a process with devproc
by writing noteid file.
case Qnoteid:
id = atoi(a);
if(id == p->pid) {
p->noteid = id;
break;
}
t = proctab(0);
26 matches
Mail list logo
