Date: Thu, 6 Mar 2003 17:15:09 -0500 From: Jake Burkholder <jake@locore.ca> To: "Alan L. Cox" <alc@imimic.com> Cc: Alan Cox <alc@FreeBSD.org>, 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> In-Reply-To: <3E67AB12.5DC6E8B9@imimic.com>; from alc@imimic.com on Thu, Mar 06, 2003 at 02:09:54PM -0600 References: <200303060448.h264mKjG045767@repoman.freebsd.org> <20030306122555.C225@locore.ca> <3E67AB12.5DC6E8B9@imimic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030306171509.H225>