From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH v8 13/20] xenctx: change is_kernel_text() into kernel_addr(). Date: Wed, 02 Apr 2014 13:08:52 -0400 Message-ID: <533C4424.8040308@terremark.com> References: <1395947147-5262-1-git-send-email-dslutz@verizon.com> <1395947147-5262-14-git-send-email-dslutz@verizon.com> <1396361415.8667.199.camel@kazak.uk.xensource.com> <533B30A3.80808@terremark.com> <1396434845.8667.310.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1396434845.8667.310.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Don Slutz Cc: George Dunlap , Stefano Stabellini , Ian Jackson , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 04/02/14 06:34, Ian Campbell wrote: > On Tue, 2014-04-01 at 17:33 -0400, Don Slutz wrote: >> On 04/01/14 10:10, Ian Campbell wrote: >>> On Thu, 2014-03-27 at 15:05 -0400, Don Slutz wrote: >> >>>> kernel_end or the symbol "__brk_limit". The symbol "vgettimeofday" >>>> is used to mark the end of where modules can be loaded. >>> I can just about see from the vmlinux.lds.S why __brk_limit might be >>> somewhat relevant, but where does the use of vgettimeofday come from? >>> >>> The 3.2 kernel on my desktop doesn't list vgettimeofday in System.map >>> for example and in any case you can't rely on it not being moved around. >>> (you can't really rely on __brk_limit either, but it seems less likely >>> to move). >> I would guess you are running a 32 bit desktop. > No. 3.13-1-amd64 and I looked in System.map-3.13-1-amd64 > System.map-3.2.0-4-amd64 and System.map-3.9-1-amd64 which happened to be > present in /boot. I only find it in 2.6 kernels. Since I am dropping the module support this symbol is no longer checked for. >> Here is output of the same 3 stack pages in use guest that is paused: > You keep dropping in these massive output dumps without explaining what > they are supposed to illustrate. I have no idea what you think this is > telling me. This was in response to: >>> This shows that a kernel module is using a lot of stack. >> Does it? All I see is the four additional entries at the base, consuming >> about 0.5k which I suppose is a lot. I suppose those are stack frames >> corresponding to some module? Perhaps mark them as such with "unknown >> module function"? I was trying to tell you that the module code was using much more then 0.5k. It is just over 2 pages. But forgot to write this sentence 1st. Clearly what I am writing in e-mails is not at all clear to you. Will try to do better. >>>> + return KERNEL_TEXT_ADDR; >>>> + } >>>> + else >>>> + { >>>> + if ( kernel_text && >>>> + (addr >= kernel_text && >>>> + addr <= kernel_end) ) >>>> + return KERNEL_DATA_ADDR; >>>> + if ( kernel_mod_start && >>>> + (addr >= kernel_mod_start && >>>> + addr <= kernel_mod_end) ) >>>> + return KERNEL_MOD_ADDR; >>>> + } >>>> + return NOT_KERNEL_ADDR; >>>> } >>>> >>>> @@ -180,7 +223,14 @@ static void print_symbol(guest_word_t addr) >>>> if (addr==s->address) >>>> printf(" %s", s->name); >>>> else >>>> - printf(" %s+%#x", s->name, (unsigned int)(addr - s->address)); >>>> + { >>>> + unsigned long long offset = addr - s->address; >>>> + >>>> + if ( addr_type == KERNEL_MOD_ADDR && >>>> + offset > MAX_MOD_OFFSET ) >>>> + return; >>> Shouldn't kernel_addr have not returned KERNEL_MOD_ADDR in that case? >>> >> I did. > You did what? > I had meant to type "It". But that is also wrong. Somehow I dropped the not in "not returned KERNEL_MOD_ADDR". What I should have said: kernel_addr when checking for KERNEL_MOD_ADDR only does a range check. It does not search the symbols to see if the address is close enough. With these issues, I see no reason to attempt adding module support at this time. If you want I can also answer the later questions. -Don Slutz