Date: Fri, 12 Apr 2002 17:53:50 -0500 (CDT) From: Alan Cox <alc@cs.rice.edu> To: Jake Burkholder <jake@locore.ca> 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: <Pine.GSO.4.33.0204121742380.11123-100000@cs.rice.edu> In-Reply-To: <20020412170842.B10110@locore.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Apr 2002, Jake Burkholder wrote: > 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. > The previous line is a vm_fault_quick() that should trigger the soft fault so that pmap_extract() returns a useful value. Alan 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?Pine.GSO.4.33.0204121742380.11123-100000>