mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, qiuxishi@huawei.com,
	paul.gortmaker@windriver.com
Subject: Re: [PATCH v2] not adding modules range to kcore if it's equal to vmcore range
Date: Wed, 16 Jul 2014 07:48:35 +0800	[thread overview]
Message-ID: <20140715234835.GA2297@dhcp-17-102.nay.redhat.com> (raw)
In-Reply-To: <20140715151600.b561ab770b5b0f9a2200b49f@linux-foundation.org>

On 07/15/14 at 03:16pm, Andrew Morton wrote:
> On Sun, 13 Jul 2014 09:05:46 +0800 Baoquan He <bhe@redhat.com> wrote:
> 
> > On some ARCHs modules range is eauql to vmalloc range. E.g on i686
> > "#define MODULES_VADDR   VMALLOC_START"
> > "#define MODULES_END     VMALLOC_END"
> > This will cause 2 duplicate program segments in /proc/kcore, makes
> > user confused. In this patch a judgment added to check if modules
> > range is equal to vmalloc range. If yes, just skip adding the modules
> > range.
> > 
> > ...
> >
> > --- a/fs/proc/kcore.c
> > +++ b/fs/proc/kcore.c
> > @@ -610,8 +610,10 @@ static void __init proc_kcore_text_init(void)
> >  struct kcore_list kcore_modules;
> >  static void __init add_modules_range(void)
> >  {
> > -	kclist_add(&kcore_modules, (void *)MODULES_VADDR,
> > -			MODULES_END - MODULES_VADDR, KCORE_VMALLOC);
> > +	if (MODULES_VADDR != VMALLOC_START) {
> > +		kclist_add(&kcore_modules, (void *)MODULES_VADDR,
> > +				MODULES_END - MODULES_VADDR, KCORE_VMALLOC);
> > +	}
> >  }
> >  #else
> >  static void __init add_modules_range(void)
> 
> But if some application or script is using the modules range, won't
> this patch cause breakage on some architectures?

Hi Andrew,

Thanks for your review and comments.

Since in this situation the modules range and the vmalloc range are
the same, and from the print of /proc/kcore you can't differentiate
them, I guess people may not care it.

Unless people assume the range after vmalloc is modules range in script.
But if someone did this, his/her program is not carefully considered.
Entries of kcore are not fixed, E.g in x86-64 kcore_vsyscall exists
while it doesn't exist in i686. AFAIK, usually people use address range
to judge what area it is, E.g in makedumpfile, one user space utility
of kdump, below function is used to check the type of virtual address in
x86-64.

int                                                                                                               
is_vmalloc_addr(ulong vaddr)                                                                                      
{                                                                                                                 
        /*                                                                                                        
         *  vmalloc, virtual memmap, and module space as VMALLOC space.                                           
         */                                                                                                       
        return ((vaddr >= VMALLOC_START && vaddr <= VMALLOC_END)                                                  
            || (vaddr >= VMEMMAP_START && vaddr <= VMEMMAP_END)                                                   
            || (vaddr >= MODULES_VADDR && vaddr <= MODULES_END));                                                 
}

In i686, the code is 

int
is_vmalloc_addr_x86(unsigned long vaddr)
{
        return (info->vmalloc_start && vaddr >= info->vmalloc_start);
}

So I think people should check entries of kcore by range it spans,
not which line the entry could be in. When I tried to read /proc/kcore,
I was confused why the same line comes up twice. It could be better to
remove the confusion, from my personal opinion.

Thanks
Baoquan


> 

  reply	other threads:[~2014-07-15 23:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-13  0:42 [PATCH] " Baoquan He
2014-07-13  1:05 ` [PATCH v2] " Baoquan He
2014-07-15 22:16   ` Andrew Morton
2014-07-15 23:48     ` Baoquan He [this message]
2014-07-31  8:50     ` Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140715234835.GA2297@dhcp-17-102.nay.redhat.com \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=qiuxishi@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®