Date: Fri, 12 Apr 2002 17:08:42 -0400 From: Jake Burkholder <jake@locore.ca> To: Alan Cox <alc@cs.rice.edu> Cc: Thomas Moestl <tmm@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern sys_pipe.c Message-ID: <20020412170842.B10110@locore.ca> In-Reply-To: <Pine.GSO.4.33.0204121536490.11123-100000@cs.rice.edu>; from alc@cs.rice.edu on Fri, Apr 12, 2002 at 03:42:37PM -0500 References: <200204121938.g3CJcfk69260@freefall.freebsd.org> <Pine.GSO.4.33.0204121536490.11123-100000@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Apparently, On Fri, Apr 12, 2002 at 03:42:37PM -0500, Alan Cox said words to the effect of; > > > On Fri, 12 Apr 2002, Thomas Moestl wrote: > > > tmm 2002/04/12 12:38:41 PDT > > > > Modified files: > > sys/kern sys_pipe.c > > Log: > > Do not use pmap_kextract() to find out the physical address of a user > > belong to a user virtual address; while this happens to work on some > > architectures, it can't on sparc64, since user and kernel virtual > > address spaces overlap there (the distinction between them is done via > > separate address space identifiers). > > > > Why not pmap_extract() on the map->pmap? pmap_extract() is the equivalent > of pmap_kextract() for ordinary pmap's, i.e., not the kernel pmap. > > Alan Because the sparc64 pmap uses a hash table like structure for non-kernel pmaps with fixed size buckets. If there are too many hash collisions a mapping can be forced out causing a replacement and a soft fault on the next access. Basically, pmap_extract is not guaranteed to work for ordinary pmaps. Jake > > > Instead, look up the page in the vm_map of the process in question. > > > > Reviewed by: jake > > > > Revision Changes Path > > 1.102 +17 -6 src/sys/kern/sys_pipe.c > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020412170842.B10110>