From owner-freebsd-arch  Sun Sep 24 10:33: 8 2000
Delivered-To: freebsd-arch@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8012D37B422; Sun, 24 Sep 2000 10:33:03 -0700 (PDT)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e8OHX3p27873;
	Sun, 24 Sep 2000 10:33:03 -0700 (PDT)
Date: Sun, 24 Sep 2000 10:33:03 -0700
From: Alfred Perlstein <bright@wintelcom.net>
To: arch@freebsd.org
Cc: cp@freebsd.org, bmilekic@freebsd.org
Subject: need advice, fsetown annoyances and mpsafeness.
Message-ID: <20000924103303.M9141@fw.wintelcom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Take this scenario into account:

1) one sets a socket S for SIGIO delivery on an event to pid N
2) N exits
3) evetually before 'S' is destroyed a second process happens to
   get pid N.
4) an event happens on 'S' and the wrong process 'N' is notified.

Well this isn't possible in FreeBSD because we hang a struct sigio
off of the object that is going to be delivering signals as well
as the struct proc/pgrp that is to recieve them.

When the proc/pgrp is destroyed funsetownlst() is called on the
list of sigio structs hanging from the proc/pgrp.

What it then does is walk through the sigio structs hung from itself
and using a back-pointer that points to the pointer within the
object (socket/tty) it raises splhigh and NULLs it out, lowers spl,
then frees the sigio.

  	s = splhigh();
	*(sigio->sio_myref) = NULL;
	splx(s);

If an object is destroyed it is responsible for freeing the attached
sigio struct in nearly the same way... raising splhigh and delinking
itself from the list of sigios attached to the proc/pgrp

This is a problem because it's pretty complicated to make mpsafe.

Solutions come to mind:

1) embedding the sigio within the object.
   problems: structure bloat, not really sure if it helps
2) removing the burden of sigio destruction from the proc/pgrp destruction
   routines, instead the proc can just walk the sigios and set a
   flag is set such that the sigio is not to be delivered, it is
   then entirely up to the object (socket/tty) to free() the sigio.

   the sigio linked list manipulation can be hinged off the process
   mutex we will need to add to the proc and pgrp structures.

   if a sigio is going to be changed you must aquire the proc/pgrp lock
   of the process/group you are removing the structure from before
   doing the unlinking and change otherwise you race against process
   exit.

Option 2 seems a lot clearer to me and it also seems to address all
the problems here without any hackish like solution

I'm going to be investigating the BSD/os way of handling this, but
it seems that they don't take into account for pid wraparound at
a glance.

Questions?  Comments?

I'm really looking for either, encouragement (hey '2' looks cool),
alternate locking suggestions, or a redesign of the sigio way that
is more mpsafe.

Is anyone else starting to hate monolithic kernel design? :)

thanks,
-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message