From owner-freebsd-hackers Wed Dec 8 21:30:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 02E0B15323 for ; Wed, 8 Dec 1999 21:30:43 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA46209; Wed, 8 Dec 1999 21:30:37 -0800 (PST) (envelope-from dillon) Date: Wed, 8 Dec 1999 21:30:37 -0800 (PST) From: Matthew Dillon Message-Id: <199912090530.VAA46209@apollo.backplane.com> To: freebsd-hackers@FreeBSD.ORG Cc: Kirk McKusick Subject: mmap/write case brought up again - maybe its time to... Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Someone brought up the mmap/write case up again - that's a deadlock case that we haven't fixed yet where you write from one descriptor into shared writeable file-backed memory area and, from another process, do the vise-versa. Maybe it's time to make filesystem locks recursive by default. Doing so will allow the above case to be fixed 100% by allowing the read() and write() code to pre-lock the underlying vnodes in the correct order (by pointer comparison) prior to digging into them. I think Kirk may be the best person to make this determination - I seem to recall there being some (minor?) issues. Implementing recursive locks may be as simple as adding LK_RECURSE to vn_lock() but I haven't researched it heavily. This may also tie-in well with the revamping of the VOP code later on. There is a significant amount of complexity in the VOP code in having to deal with non-recursive locks when a passed argument is supposed to be locked and remain locked on return, the return argument is supposed to be locked, and the returned argument winds up being the same as the passed argument. With recursive locks as the norm we can remove nearly all of those special cases leaving just the one that deals with ".." (or perhaps dealing with namei directory locks in a different way). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message