Re: [9fans] Kernel question: i386 test-and-set problem

[presotto@plan9.bell-labs.com]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

If it were at all possible for wakeup to be called with
r already freed, the code would be wrong to begin with
since r is an argument to wakeup.  Sleep and wakeup have to
be syncronized somewhat in the first place just to work.
Wakeup inherenly has to expect that the sleep won't
free r before it's called.  Since the sleep and wakeup
are called by code that knows about the structures the
Rendezvous is kept in, they can do this.  For example,
if we're descending a list that contains rendezvous
structures and the list operations are made atomic,
the structure won't be in the list if the returning
sleep freed it and the wakeup won't find it.

However, that is not true of postnote which is coming out
of left field and doesn't have any knowledge of the
deep structure of the process it is noting.  It can
take into account no invariants implicit in the process
itself.

[-- Attachment #2: Type: message/rfc822, Size: 2752 bytes --]

From: miller@hamnavoe.demon.co.uk
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Kernel question: i386 test-and-set problem
Date: Wed, 2 Aug 2000 09:32:59 0100
Message-ID: <E13JuLT-0005k5-0V@anchor-post-31.mail.demon.net>

> We did try your solution since it was the obious one.

Wasn't obvious to me.  It emerged from an attempt to sketch a
correctness proof and then derive a version of the algorithm
which would correspond to it.

> Process p now continues after the sleep:
> 
> 	process p:
> 		sleep(r);
> 		free(r)
> 
> Process y now does
> 
> 		xxx = malloc(234);
> 		xxx->a = 12;
> 
> And finally process x does its lock(r).  We've just
> clobbered some other processes kernel structure.

Ah.  It had not actually occurred to me that a kernel
process might be freeing a data structure while another
process still held a pointer into it.  How naive of me.

If the scenario above is really allowed, I don't see
why it isn't just as much a problem with the existing
kernel.  Even without the interference of postnote(),
we might have sleep(r) finding the wakeup condition
true and returning immediately, so that the free(r) and
malloc() could happen while or even before wakeup(r)
runs.  So when /sys/src/9/port/proc.c:#10217,#10286
is executed, r points to something which is no longer
a Rendez structure.  Therefore r->p could be anything,
and  the lock(&p->rlock) could clobber something or
even cause a memory fault.

Or am I missing something obvious again?

-- Richard