From mboxrd@z Thu Jan  1 00:00:00 1970
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
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <E13JuLT-0005k5-0V@anchor-post-31.mail.demon.net>
Topicbox-Message-UUID: f234d7d0-eac8-11e9-9e20-41e7f4b1d025

> 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