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: <20090702092807.GC6372@cr0.nay.redhat.com>
Date:	Thu, 2 Jul 2009 17:28:07 +0800
From:	Amerigo Wang <xiyou.wangcong@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Amerigo Wang <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 Wed, Jul 01, 2009 at 02:47:42PM -0700, Andrew Morton wrote:
>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?


No, it is expected to be more than the amount of physical memory.


>
>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.

Yup!

My bad, I just mentioned this in the earlier email in this thread,
but I forgot it put it here. Sorry for this!

>
>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?

Yes, exactly...

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

Yes, we can, but I think leaving this like what the rest /proc files
behave is better.

>
>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.

A quick grep shows kclist_add() can be marked as __init, but I don't
know if anyone will use it in other parts in the future.

I prefer leaving it as it is.
--
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/