From: Andrew Morton <akpm@linux-foundation.org>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: Amerigo Wang <xiyou.wangcong@gmail.com>,
tao.ma@oracle.com, linux-kernel@vger.kernel.org,
adobriyan@gmail.com, mtk.manpages@gmail.com,
Yasunori Goto <y-goto@jp.fujitsu.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [RESEND Patch] kcore: remove its pointless size
Date: Wed, 1 Jul 2009 17:12:49 -0700 [thread overview]
Message-ID: <20090701171249.004968e8.akpm@linux-foundation.org> (raw)
In-Reply-To: <m14otwq94e.fsf@fess.ebiederm.org>
On Wed, 01 Jul 2009 16:25:05 -0700 ebiederm@xmission.com (Eric W. Biederman) wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
> >> 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?
>
> Which is better than showing a random number of dubious relationship
> to the size we normally show. That code is just a maintenance problem.
Well it's not just that st_size is wrong before the first read. It's
also wrong after memory hot-add, up until the next 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.
>
> Memory hot add I expect is the excuse. There is more that could be
> done. But this patch is an obvious bit of chipping away nonsense
> code.
We have the infrastructure to get this right, I think:
- run
proc_root_kcore->size = get_kcore_size(...)
within proc_kcore_init()
- register a memory-hotplug notifier and each time memory goes online
or offline, rerun
proc_root_kcore->size = get_kcore_size(...)
- stop running get_kcore_size() within read_kcore().
I suspect that read_kcore() will not behave well if a memory hotplug
operation happens concurrently. But that's a separate problem.
(hopefully cc's some memory-hotplug people)
Or we just leave /proc/kcore's st_size at zero. It's a pretty hopeless
exercise trying to get this "right", as nobody can safely _use_ that
size - it can be wrong as soon as the caller has read from it.
next prev parent reply other threads:[~2009-07-02 0:13 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 4:03 /proc/kcore has a unreasonable size(281474974617600) in x86_64 2.6.30-rc8 Tao Ma
2009-06-05 5:38 ` Andrew Morton
2009-06-05 6:59 ` Tao Ma
2009-06-05 7:56 ` Amerigo Wang
2009-06-05 8:57 ` Tao Ma
2009-06-05 9:09 ` Américo Wang
2009-06-05 9:14 ` Andrew Morton
2009-06-05 9:30 ` Tao Ma
2009-06-05 9:51 ` Amerigo Wang
2009-06-05 14:26 ` Tao Ma
2009-06-05 17:50 ` Yinghai Lu
2009-06-06 14:37 ` Tao Ma
2009-06-06 22:21 ` Yinghai Lu
2009-06-08 1:52 ` Amerigo Wang
2009-06-08 6:02 ` Tao Ma
2009-06-08 6:41 ` Américo Wang
2009-06-08 8:00 ` Tao Ma
2009-06-09 0:43 ` Américo Wang
2009-06-09 4:10 ` Eric W. Biederman
2009-06-11 5:09 ` Amerigo Wang
2009-06-11 14:12 ` Eric W. Biederman
2009-06-12 7:54 ` Tao Ma
2009-06-13 4:09 ` [Patch BUGFIX] kcore: fix its wrong size on x86_64 Amerigo Wang
2009-06-13 4:20 ` Eric W. Biederman
2009-06-15 2:14 ` Amerigo Wang
2009-06-15 5:59 ` Tao Ma
2009-06-15 7:00 ` Amerigo Wang
2009-06-15 8:34 ` Tao Ma
2009-06-15 9:00 ` Amerigo Wang
2009-06-15 10:10 ` Eric W. Biederman
2009-06-15 22:10 ` TaoMa
2009-06-15 19:48 ` Eric W. Biederman
2009-06-15 17:01 ` Tao Ma
2009-06-15 10:08 ` Eric W. Biederman
2009-06-16 15:29 ` Américo Wang
2009-06-16 19:27 ` Eric W. Biederman
2009-06-18 3:00 ` Amerigo Wang
2009-06-18 3:37 ` Eric W. Biederman
2009-06-18 4:40 ` Amerigo Wang
2009-06-18 5:41 ` Eric W. Biederman
2009-06-22 8:54 ` [Patch] kcore: remove its pointless size Amerigo Wang
2009-06-30 10:08 ` [RESEND Patch] " Amerigo Wang
2009-07-01 21:47 ` Andrew Morton
2009-07-01 23:25 ` Eric W. Biederman
2009-07-02 0:12 ` Andrew Morton [this message]
2009-07-02 0:41 ` KAMEZAWA Hiroyuki
2009-07-17 22:29 ` Andrew Morton
2009-07-21 2:09 ` KAMEZAWA Hiroyuki
2009-07-21 8:46 ` KAMEZAWA Hiroyuki
2009-07-21 9:36 ` [RFC][PATCH 0/3] kcore: clean up and update ram information properly KAMEZAWA Hiroyuki
2009-07-21 9:38 ` [RFC][PATCH 1/3] kcore: use usual list ops in kclist KAMEZAWA Hiroyuki
2009-07-21 9:39 ` [RFC][PATCH 2/3] kcore: add kclist type information KAMEZAWA Hiroyuki
2009-07-21 9:41 ` [RFC][PATCH 3/3] kcore: rebuild RAM information based on io resource information KAMEZAWA Hiroyuki
2009-07-21 11:29 ` [RFC][PATCH 0/3] kcore: clean up and update ram information properly Andi Kleen
2009-07-22 0:27 ` KAMEZAWA Hiroyuki
2009-07-02 9:28 ` [RESEND Patch] kcore: remove its pointless size Amerigo Wang
2009-06-05 5:49 ` /proc/kcore has a unreasonable size(281474974617600) in x86_64 2.6.30-rc8 Amerigo Wang
2009-06-05 6:07 ` Tao Ma
2009-06-05 6:43 ` Amerigo Wang
2009-06-05 6:56 ` Tao Ma
2009-06-05 8:00 ` Amerigo Wang
2009-06-05 9:01 ` Tao Ma
2009-06-05 9:20 ` Amerigo Wang
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=20090701171249.004968e8.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=adobriyan@gmail.com \
--cc=ebiederm@xmission.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=tao.ma@oracle.com \
--cc=xiyou.wangcong@gmail.com \
--cc=y-goto@jp.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.