From owner-cvs-all Fri Nov 6 11:36:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17945 for cvs-all-outgoing; Fri, 6 Nov 1998 11:36:26 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17938 for ; Fri, 6 Nov 1998 11:36:24 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id LAA00920; Fri, 6 Nov 1998 11:36:01 -0800 (PST) (envelope-from dillon) Date: Fri, 6 Nov 1998 11:36:01 -0800 (PST) From: Matthew Dillon Message-Id: <199811061936.LAA00920@apollo.backplane.com> To: Tor.Egge@fast.no Cc: cvs-committers@FreeBSD.ORG Subject: Re: sendfile.2 (was Re: cvs commit: ...) References: <199811060401.UAA00767@apollo.backplane.com> <199811061214.NAA01603@midten.fast.no> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk :> to implement. A simple MAP_PRIVATE replacement of __srefill() and maybe :> a little code to avoid unnecessary copy-on-write ops. : :Enabling vfs_ioopts does most of this implicitly. Unfortunately, :there is a bug involved, that might cause a deadlock when :reading the last "fragment" of the file. : :The same deadlock can be triggered by explicit use of mmap, e.g. PR 8416. : :- Tor Egge We have the choice of either implementing automatic deadlock detection (icky), allowing the already non-zero shared count to be bumped and risking resource starvation (also icky), or keeping track of shared locks with an extra linked-in structure on a per-pid basis in order to specifically allow the recursive-shared-lock case to override an exclusive lock request. Actually, that isn't a bad idea. Why not use the supervisor stack to manage the locks and formally require that locks either (a) not be held past the procedure obtaining them or (b) that if a procedure is supposed to return a locked object, that the lock extension structure be passed to the procedure as an argument. procedure() { lock_extension_structure fubar; /* * shared_lock links fubar into the lock structure */ shared_lock(&someLock, &fubar); ... do stuff that might result in recursive locks ... /* * must always unlock since fubar goes invalid on the return from * procedure. */ shared_unlock(&fubar); } There are major advantages to this scheme. Amoung other things, we win big if we formally disallow these sorts of locks to be held past the return-from-procedure. No more cases of "Who really controls that lock"... if a procedure is supposed to return a locked object, the caller *must* supply the lock extension structure to the procedure. There would be no other way to do it. (also note: I'm not talking about VM page structure locks, only vnode and inode style 'temporary' locks). The advantages: * no allocation of structures. * coding of locks and especially the returning of an object with a retained lock becomes crystal clear. No more confusion over who owns the lock or whether an object is supposed to be returned in a locked state. * debugging is easier - both shared and exclusive locks can be tracked rather then just exclusive locks. Many of the lockups we've had in the past have been due to shared locks that we could track. * system can later be extended to deal with deadlock detection * system can deal with recursive shared locks (i.e. not block on recursive shared locks within a pid in the face of a pending exclusive lock, block otherwise). * the unlock call can wakeup lock holders even more easily then it is done now. The disadvantages: * linked lists are used, but it should be pointed out that linked lists are already used in tsleep/wakeup. With the new system, processes tsleep on the lock extension structure so the linked lists on wakeup become degenerate. The linked lists effectively migrate to the lock structure (i.e. we have a linked list of lock extension structures applied to the lock). Not much of a disadvantage, IMHO. * critical state is stored on the supervisor stack. Not much of a disadvantage here either. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message