From owner-cvs-src Thu Mar 6 14:12: 5 2003 Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16F2F37B401; Thu, 6 Mar 2003 14:12:02 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1533F43F75; Thu, 6 Mar 2003 14:12:01 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h26MF9xS005564; Thu, 6 Mar 2003 17:15:09 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h26MF9CU005563; Thu, 6 Mar 2003 17:15:09 -0500 (EST) Date: Thu, 6 Mar 2003 17:15:09 -0500 From: Jake Burkholder To: "Alan L. Cox" Cc: Alan Cox , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_syscalls.c Message-ID: <20030306171509.H225@locore.ca> References: <200303060448.h264mKjG045767@repoman.freebsd.org> <20030306122555.C225@locore.ca> <3E67AB12.5DC6E8B9@imimic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3E67AB12.5DC6E8B9@imimic.com>; from alc@imimic.com on Thu, Mar 06, 2003 at 02:09:54PM -0600 Sender: owner-cvs-src@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apparently, On Thu, Mar 06, 2003 at 02:09:54PM -0600, Alan L. Cox said words to the effect of; > Jake Burkholder wrote: > > > > Apparently, On Wed, Mar 05, 2003 at 08:48:20PM -0800, > > Alan Cox said words to the effect of; > > > > > alc 2003/03/05 20:48:20 PST > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/kern uipc_syscalls.c > > > Log: > > > Remove GIANT_REQUIRED from sf_buf_free(). > > > > pmap_qenter and pmap_qremove remove aren't MP-safe on sparc64 and probebly > > ia64 (sparc64 has to maintain virtual address alias chains). This isn't > > that big of a deal, just please keep it in mind before removing giant from > > other parts of the system. I'll see about adding some locking for sparc64. > > > > Thanks. I see what you mean. There is something else to worry about > here as well. On i386 and alpha, pmap_remove_all() has no effect on > mappings created by pmap_qenter(). It appears to me on sparc64, the > pmap_qenter() mapping will be removed by a pmap_remove_all(). > > We actually depend on pmap_remove_all() not affecting mappings by > pmap_qenter(). For example, consider a page that has been vmapbuf()ed > for direct I/O. If the page is freed by the application (e.g., > munmap()) before the direct I/O completed, pmap_remove_all() must not > remove vmapbuf()'s mapping. The user mappings will be "managed" and have the managed bit set in the tte (TD_PV (poor name probably)), the kernel mappings entered with pmap_qenter/pmap_kenter won't so pmap_remove_all will skip them. Same thing with the rest of the functions that deal with pv entries. I think the only problem it actually causes is pmap_page_is_mapped returns true even if there are unmanaged mappings. There are various ways to deal with this, I just haven't gotten around to it. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message