From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <9front-bounces@9front.inri.net>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4
Received: from 9front.inri.net (9front.inri.net [168.235.81.73])
	by inbox.vuxu.org (Postfix) with ESMTP id 139C9260DA
	for <ml@inbox.vuxu.org>; Tue,  9 Apr 2024 03:37:30 +0200 (CEST)
Received: from duke.felloff.net ([216.126.196.34]) by 9front; Mon Apr  8 21:35:31 -0400 2024
Message-ID: <4AC534CA35A24BB9795CAA0C12A2DEA0@felloff.net>
Date: Tue, 09 Apr 2024 03:35:20 +0200
From: cinap_lenrek@felloff.net
To: 9front@9front.org
In-Reply-To: <ZhR-AdtKy7ksMRme@alice>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: compliant storage core injection content-driven replication hardware 
Subject: Re: [9front] Re: commit b3a26fb633f4649fc202b77c0184184b756960e7
Reply-To: 9front@9front.org
Precedence: bulk

> Perhaps I'm missing something but is it safe to call ready
> outside of the p->rlock?

I do not see any issue with calling ready() outside
of the p->rlock.

In sleep, we set the process state to Wakeme
only when we have both locks. From there on, we'r
committed to go to sleep and we can call ready()
on it (once).

Double ready should not happen as we clear r->p and p->r.

> I thought it was a requirement for a Rendez to be kept
> around by other means if there is a possibility that it may
> be accessed by other proc.

I do not know of any such requirements. The sleep and
wakeup paper is also silent on this topic and the bug
is also right there in the listed code.

The only requirement i know is that Proc's must never
be re-used as something other than a Proc.

> So isn't the Rendez on the stack in semacquire the actual problem?

I can see this being a issue also if the Rendez or QLock
is in dynamically allocated memory. Not just the stack.

I also dont like the Rendez on the stack and i know
we can even save some memory by just using &up->sleep
as the rendezvous point instead of embedding it the
Sema struct. But this isnt addressing the problem at hand.

> ...

> The key change is to zero r->p immediately after saving it
> to p so the critical section involving r is just:

>	lock(r)
>	p = r->p
>	r->p = nil
>	unlock(r)

Maybe, tho i wanted to address the problem at hand.

> What do you think?

I'm going back to sleep :)

--
cinap