Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 May 2009 09:32:01 -0500
From:      Stacey Son <sson@freebsd.org>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r192859 - in head: share/man/man4 sys/conf sys/dev/ksyms sys/kern sys/modules sys/modules/ksyms sys/sys
Message-ID:  <4A1D4EE1.5040902@freebsd.org>
In-Reply-To: <20090527111741.GH1927@deviant.kiev.zoral.com.ua>
References:  <200905262139.n4QLd9pI074530@svn.freebsd.org> <20090527111741.GH1927@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov wrote:
> On Tue, May 26, 2009 at 09:39:09PM +0000, Stacey Son wrote:
>   
>> Author: sson
>> Date: Tue May 26 21:39:09 2009
>> New Revision: 192859
>> URL: http://svn.freebsd.org/changeset/base/192859
>>
>> Log:
>>   Add the ksyms(4) pseudo driver.  The ksyms driver allows a process to
>>   get a quick snapshot of the kernel's symbol table including the symbols
>>   from any loaded modules (the symbols are all merged into one symbol
>>   table).  Unlike like other implementations, this ksyms driver maps
>>   memory in the process memory space to store the snapshot at the time
>>   /dev/ksyms is opened.  It also checks to see if the process has already
>>   a snapshot open and won't allow it to open /dev/ksyms it again until it
>>   closes first.  This prevents kernel and process memory from being
>>   exhausted.  Note that /dev/ksyms is used by the lockstat(1) command.
>>   
>>   Reviewed by:	gallatin kib (freebsd-arch)
>>   Approved by:	gnn (mentor)
>>     
>
> What is the reason to have ksyms_unmap() ?
 

ksyms_unmap() is used to free the mapping of the memory when /dev/ksyms 
is closed or if the driver fails to create the symbol table snapshot.

> Why do you think that checking
> for the present mapping of the freed region is neccessary ?

ksyms_unmap() does check to make sure the memory region is mapped since 
it is possible that the process could have unmap it or changed its 
protection before calling close().   I haven't looked at vm_map_delete() 
closely but maybe it make makes this check as well.  If so, this check 
might be redundant.

-stacey.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A1D4EE1.5040902>