From owner-cvs-src Thu Mar 6 14: 3:16 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 29E4837B401 for ; Thu, 6 Mar 2003 14:03:13 -0800 (PST) Received: from mail26a.sbc-webhosting.com (mail26a.sbc-webhosting.com [216.173.237.36]) by mx1.FreeBSD.org (Postfix) with SMTP id E2F9A43FBF for ; Thu, 6 Mar 2003 14:03:10 -0800 (PST) (envelope-from alc@imimic.com) Received: from www.imimic.com (64.143.12.21) by mail26a.sbc-webhosting.com (RS ver 1.0.77vs) with SMTP id 0896631388; Thu, 6 Mar 2003 15:09:48 -0500 (EST) Message-ID: <3E67AB12.5DC6E8B9@imimic.com> Date: Thu, 06 Mar 2003 14:09:54 -0600 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jake Burkholder 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 References: <200303060448.h264mKjG045767@repoman.freebsd.org> <20030306122555.C225@locore.ca> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 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 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. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message