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

[Amerigo Wang]

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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/