On Wed, Apr 26, 2006 at 06:56:39PM +0530, Rachita Kothiyal wrote:
> ----- Forwarded message from [EMAIL PROTECTED] (Cliff Wickman) -----
> 
> Date: Wed, 26 Apr 2006 07:19:06 -0500
> To: [EMAIL PROTECTED]
> 
> Subject: dumping kernel pages
> From: [EMAIL PROTECTED] (Cliff Wickman)
> 
> 
> 
> 
> Hi Rachita,
> 
>   I saw your name associated with the kdump project 
> (lse.sourceforge.net/kdump).
>   I have a question for you -- or someone in the project.  (Please point me
>   to the proper person, if it's not you)
> 
>   I'm a linux maintainer at SGI.  And have just recently been addressing
> a problem that the 2.6.16 kernel creates for lkcd.
> 
>   The problem briefly:
>     Multi-page kernel allocations are represented by the single page structure
>     associated with the first page of the allocation.  The page structures
>     associated with the other pages are unintialized.
> 
>   I submitted a patch (below) to lkcd to work around it.
>   I did ping David Howells of Red Hat and Nick Piggin of SuSE, as they
> seem to be the authors of this change.  Their reply (at bottom) adds
> some confidence that this is a good way to fix it.
> 
>   I don't know if kdump yet implements dumping only kernel pages.  I see
> it on the to-do list in this paper:
> http://lse.sourceforge.net/kdump/documentation/ols2oo5-kdump-paper.pdf
> 
> 
>   Have you encountered the problem?   And how you intend to address it?
> 
>   Thanks.
> 
> -Cliff Wickman
>   

Hi Cliff,

All the discussion related to kdump generally happens on fastboot mailing
list. I have cc-ed this mail to fastboot.

As far as kernel pages only dump, currently there is some effort going on
from Ken'ichi Ohmichi. Please have a look at this thread.

http://marc.theaimsgroup.com/?l=osdl-fastboot&m=114441776909729&w=2

Thanks
Maneesh

> 
> 
> Subject: [PATCH 1/1] ia64: enable LKCD to capture second stack page
> From: Cliff Wickman <[EMAIL PROTECTED]>
> 
> In SLES10 (2.6.16) LKCD is unable to capture the second page of
> the 2-page task/stack allocation.
> 
> Multi-page kernel allocations are represented by the single page structure
> associated with the first page of the allocation.  The page structures
> associated with the other pages are unintialized.
> 
> The simplest fix is to make the task/stack allocation a compound page.
> 
> This fix will not enable LKCD to capture pages allocated by some
> driver, for example, that allocates a multi-page area without specifying
> the __GFP_COMP flag.
> (Some other fix is probably needed in the long run to make all kernel
>  multi-page allocations detectable without making them compound pages.)
> 
> Then a change is made to LKCD's kernel page identifying function
> (kernel_page())
> to capture small compound pages.  (the patch below arbitrarily captures
> up to order 3 (8 pages))
> 
> Diffed against 2.6.16
> 
> Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]>
> ---
> 
> ---
>  drivers/dump/dump_filters.c    |    3 ++-
>  include/asm-ia64/thread_info.h |    2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> Index: linux/drivers/dump/dump_filters.c
> ===================================================================
> --- linux.orig/drivers/dump/dump_filters.c
> +++ linux/drivers/dump/dump_filters.c
> @@ -57,7 +57,8 @@ int dump_low_page(struct page *p)
>  static inline int kernel_page(struct page *p)
>  {
>       return (PageReserved(p) && !PageInuse(p)) ||
> -             (!PageLRU(p) && !PageCompound(p) && PageInuse(p));
> +             (!PageLRU(p) && PageInuse(p))     ||
> +             (PageCompound(p) && (long)p->lru.prev < 4);
>  }
> 
>  static inline int user_page(struct page *p)
> Index: linux/include/asm-ia64/thread_info.h
> ===================================================================
> --- linux.orig/include/asm-ia64/thread_info.h
> +++ linux/include/asm-ia64/thread_info.h
> @@ -74,7 +74,7 @@ struct thread_info {
>  #define end_of_stack(p) (unsigned long *)((void *)(p) + IA64_RBS_OFFSET)
> 
>  #define __HAVE_ARCH_TASK_STRUCT_ALLOCATOR
> -#define alloc_task_struct()  ((task_t *)__get_free_pages(GFP_KERNEL,
> KERNEL_STACK_SIZE_ORDER))
> +#define alloc_task_struct()  ((task_t *)__get_free_pages(GFP_KERNEL |
> __GFP_COMP, KERNEL_STACK_SIZE_ORDER))
>  #define free_task_struct(tsk)        free_pages((unsigned long) (tsk),
> KERNEL_STACK_SIZE_ORDER)
> 
>  #endif /* !__ASSEMBLY */
> 
> 
> -----------------
> Date: Sat, 22 Apr 2006 13:56:12 +1000
> From: Nick Piggin <[EMAIL PROTECTED]>
> To: David Howells <[EMAIL PROTECTED]>
> CC: Cliff Wickman <[EMAIL PROTECTED]>
> Subject: Re: set_page_refs
> 
> David Howells wrote:
> > Cliff Wickman <[EMAIL PROTECTED]> wrote:
> > 
> >>  I'm a Linux maintainer at SGI, and have a question about the proper
> >>fix for a problem we're seeing in writing LKCD dumps.
> >>  It involves internal.h, of which you are the author.
> >>
> >>  The dumper is not capturing the second page of a task/stack, where those
> >>occupy a 2-page allocation.
> >>
> >>  The dumper is simply translating a range of physical addresses to page
> >>structures, then examining the state of those page structures.
> >>
> >>  But with the introduction of set_page_refs(), the page reference count
> >>is only initialized in the first page structure.
> >>
> >>  
> >>  I see a couple ways to fix this.
> >>  - make the task/stack pages a compound page
> >>  - make set_page_refs() call set_page_count() for all page structures,
> >>    regardless of CONFIG_MMU
> >>
> >>  What do you think the proper fix would be?
> > 
> > 
> > I think Nick Piggin may have changed this recently.
> 
> Yeah, we're moving toward compound pages for all these types of things
> (including nommu). So making those pages compound pages should be the
> right thing to do.
> -- 
> SUSE Labs, Novell Inc.
> Send instant messages to your online friends http://au.messenger.yahoo.com 
> 
> ----- End forwarded message -----
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot

Reply via email to