From mboxrd@z Thu Jan  1 00:00:00 1970
From: presotto@plan9.bell-labs.com
Message-Id: <200008021320.JAA22272@cse.psu.edu>
Date: Wed,  2 Aug 2000 09:20:00 -0400
To: miller@hamnavoe.demon.co.uk, 9fans@cse.psu.edu
Subject: Re: [9fans] Kernel question: i386 test-and-set problem
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-pqpuzybbzqmndsrodfcnacjtmq"
Topicbox-Message-UUID: f2b08a92-eac8-11e9-9e20-41e7f4b1d025

This is a multi-part message in MIME format.
--upas-pqpuzybbzqmndsrodfcnacjtmq
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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.

--upas-pqpuzybbzqmndsrodfcnacjtmq
Content-Type: message/rfc822
Content-Disposition: inline

Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Wed Aug  2 05:13:07 EDT 2000
Received: from cse.psu.edu ([130.203.3.50]) by plan9; Wed Aug  2 05:13:06 EDT 2000
Received: from localhost (majordom@localhost)
	by cse.psu.edu (8.8.8/8.8.8) with SMTP id EAA16632;
	Wed, 2 Aug 2000 04:58:18 -0400 (EDT)
Received: by claven.cse.psu.edu (bulk_mailer v1.5); Wed, 2 Aug 2000 04:58:02 -0400
Received: (from majordom@localhost)
	by cse.psu.edu (8.8.8/8.8.8) id EAA16586
	for 9fans-outgoing; Wed, 2 Aug 2000 04:57:56 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89])
	by cse.psu.edu (8.8.8/8.8.8) with ESMTP id EAA16580
	for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 04:57:49 -0400 (EDT)
From: miller@hamnavoe.demon.co.uk
Received: from hamnavoe.demon.co.uk ([158.152.225.204] helo=hamnavoe)
	by anchor-post-31.mail.demon.net with smtp (Exim 2.12 #1)
	id 13JuLT-0005k5-0V
	for 9fans@cse.psu.edu; Wed, 2 Aug 2000 09:57:48 +0100
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>
Sender: owner-9fans@cse.psu.edu
Reply-To: 9fans@cse.psu.edu
Precedence: bulk

> 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

--upas-pqpuzybbzqmndsrodfcnacjtmq--