linux-kernel - Re: [RESEND Patch] kcore: remove its pointless size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090701144742.6ce3535b.akpm@linux-foundation.org>
Date:	Wed, 1 Jul 2009 14:47:42 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Amerigo Wang <xiyou.wangcong@...il.com>
Cc:	xiyou.wangcong@...il.com, ebiederm@...ssion.com, tao.ma@...cle.com,
	linux-kernel@...r.kernel.org, adobriyan@...il.com,
	mtk.manpages@...il.com
Subject: Re: [RESEND Patch] kcore: remove its pointless size

On Tue, 30 Jun 2009 18:08:50 +0800
Amerigo Wang <xiyou.wangcong@...il.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@...hat.com>
> Cc: mtk.manpages@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/