Date: Wed, 29 Nov 2000 12:55:09 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: arch@freebsd.org Subject: serious problem with mutexs and userland visibility? Message-ID: <20001129125508.O8051@fw.wintelcom.net>
next in thread | raw e-mail | index | archive | help
I'm looking from opinions from those who have: 1) been working closely on SMPng. 2) have a lot of experience with doing the right thing with header files and untangling evil dependencies. 3) have dealt with this situation on other operating systems. I recently locked down struct ucred, not a big deal, basically just a mutex in each struct to protect the refcount. Unfortunetly struct ucred is used by some userland utils and sys/ucred is included in sys/mount.h as well as sys/user.h, this creates somewhat of a problem, forcing all users of sys/ucred.h to include sys/mutex.gh. I have a patch here that sort of takes care of this problem, the problem is that I had to add sys/mutex.h includes to both sys/mount.h and sys/user.h, this doesn't make me very happy. It actually removes some bogus includes of sys/ucred from userland. http://people.FreeBSD.org/~alfred/mpsafe/bde.diff (you can all guess why it's called "bde.diff" :) ) What I'd like to do is make a struct 'kucred' which contains the mutex and either contains a struct ucred or all the fields of struct ucred. 'kucred' will be used by the kernel and I'll write helper functions/macros to convert between the two. This looks like a lot of drudgework, but I'm ok with it. However if it becomes the only way to deal with this situation we may have a lot of drudgework ahead of us when this issue starts popping up with other structures. For instance, the uidinfo struct isn't currently exported to the user, however it would be nice if it was to determine how far off one was from exceeding thier limits. We would need another kernel/userland convertion pair for this facility if anyone wanted to export the information contained in this structure. If the general concensus is that exporting sys/mutex.h to userland is to be avoided, but OK when necessary than I'd rather just apply the patch I have right now. Right now I'm of the opion of "by any means necessary", meaning I really don't care about the visibility, proceeding with the mpsafe work is far more important that polluting our headers right now. I'm just concerned about taking it too far. BSD/os gets around the struct ucred problem by having a single ucred mutex used for the entire system, I don't like this because even though it's a very short term lock, it will be cache contested heavily between processors causing large amounts of bus traffic. I also don't like the BSD/os approach, because it doesn't address the problem of mutexes being inside structures declared in userland included headers, it just avoids it for this specific case. 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?20001129125508.O8051>