Re: [RESEND Patch] kcore: remove its pointless size

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 30 Jun 2009 18:08:50 +0800
Amerigo Wang <xiyou.wangcong@gmail.com> wrote:

> 
> Linus fixes wrong size of /proc/kcore problem in commit 9063c61fd5cbd.
> 
> But its size still looks insane, since it never equals to the size
> of physical memory.

Better changelogs, please!

I think that what you're saying is that the stat.st_size field of the
/proc/kcore inode does not equal the amount of physical memory, and
that you think it should do so?

If that is correct then it would be appropriate to explain what value
the stat.st_size field has before the patch and afterwards.  Just
calling it "insane" isn't optimal.

> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: mtk.manpages@gmail.com
> 
> (Andrew, could you please just cut off the kernel part from below? :)
> 
> ---
> diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
> index 59b43a0..eca5201 100644
> --- a/fs/proc/kcore.c
> +++ b/fs/proc/kcore.c
> @@ -405,9 +405,6 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos)
>  static int __init proc_kcore_init(void)
>  {
>  	proc_root_kcore = proc_create("kcore", S_IRUSR, NULL, &proc_kcore_operations);
> -	if (proc_root_kcore)
> -		proc_root_kcore->size =
> -				(size_t)high_memory - PAGE_OFFSET + PAGE_SIZE;
>  	return 0;
>  }
>  module_init(proc_kcore_init);

AFAICT this means that proc_root_kcore->size will remain uninitialised
until a process opens and reads from /proc/kcore.  So on initial boot
the `ls' output will presumably show a size of zero, and this will
change once /proc/kcore has been read?

If so, should we run get_kcore_size() in proc_kcore_init(), perhaps?

In fact, do we need to run get_kcore_size() more than once per boot? 
AFAICT we only run kclist_add() during bootup, so if proc_kcore_init()
is called at the appropriate time, we can permanently cache its result?

In which case get_kcore_size() and kclist_add() can be marked __init.

Maybe that's all wrong - I didn't look terribly closely.