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>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000924103303.M9141>