From: Robin Holt <holt@sgi.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Robin Holt <holt@sgi.com>, David Miller <davem@davemloft.net>,
dipankar@in.ibm.com, viro@zeniv.linux.org.uk, bcrl@kvack.org,
den@openvz.org, mingo@elte.hu, mszeredi@suse.cz, cmm@us.ibm.com,
npiggin@kernel.dk, xemul@openvz.org,
linux-kernel@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH V3] fs: allow for more than 2^31 files
Date: Thu, 30 Sep 2010 23:34:13 -0500 [thread overview]
Message-ID: <20101001043413.GN14068@sgi.com> (raw)
In-Reply-To: <1285879545.2705.4.camel@edumazet-laptop>
On Thu, Sep 30, 2010 at 10:45:45PM +0200, Eric Dumazet wrote:
> Le jeudi 30 septembre 2010 à 15:26 -0500, Robin Holt a écrit :
> > On Tue, Sep 28, 2010 at 05:46:51AM +0200, Eric Dumazet wrote:
> > > Le lundi 27 septembre 2010 à 15:36 -0700, David Miller a écrit :
> > ...
> >
> > > Fix is to let /proc/sys/fs/file-nr & /proc/sys/fs/file-max use long
> > > integers, and change af_unix to use an atomic_long_t instead of
> > > atomic_t.
> > >
> > > get_max_files() is changed to return an unsigned long.
> >
> > I _THINK_ we actually want get_max_files to return a long and have
> > the files_stat_struct definitions be longs. If we do not have it that
> > way, we could theoretically open enough files on a single cpu to make
> > get_nr_files return a negative without overflowing max_files. That,
> > of course, would require an insane amount of memory, but I think it is
> > technically more correct.
> >
>
> Number of opened file is technically a positive (or null) value, I have
> no idea why you want it being signed.
>
> >
> > > --- a/kernel/sysctl.c
> > > +++ b/kernel/sysctl.c
> > > @@ -1352,16 +1352,16 @@ static struct ctl_table fs_table[] = {
> > > {
> > > .procname = "file-nr",
> > > .data = &files_stat,
> > > - .maxlen = 3*sizeof(int),
> > > + .maxlen = sizeof(files_stat),
> > > .mode = 0444,
> > > - .proc_handler = proc_nr_files,
> > > + .proc_handler = proc_doulongvec_minmax,
> >
> > With this change, don't we lose the current nr_files value? I think
> > you need proc_nr_files to stay as it was. If you disagree, we should
> > probably eliminate the definitions for proc_nr_files as I don't believe
> > they are used anywhere else.
> >
>
> I have no idea why you think I changed something. I only made the value
> use 64bit on 64bit arches, so that we are not anymore limited to 2^31
> files.
The proc_handler used to be proc_nr_files() which would call
get_nr_files() and deposit the result in files_stat.nr_files then cascade
to proc_dointvec() which would dump the 3 values. Now it will dump the
three values, but not update the middle (nr_files) value first.
Robin
next prev parent reply other threads:[~2010-10-01 4:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-23 12:17 When booting a 16TB system, unix_create1 fails due to integer overflow Robin Holt
2010-09-23 12:53 ` Eric Dumazet
2010-09-23 13:53 ` Eric Dumazet
2010-09-23 14:10 ` Dipankar Sarma
2010-09-27 22:36 ` David Miller
2010-09-28 3:46 ` [PATCH V3] fs: allow for more than 2^31 files Eric Dumazet
2010-09-28 4:10 ` David Miller
2010-09-30 20:26 ` Robin Holt
2010-09-30 20:45 ` Eric Dumazet
2010-10-01 4:34 ` Robin Holt [this message]
2010-10-01 5:03 ` Eric Dumazet
2010-10-01 5:29 ` [PATCH V4] " Eric Dumazet
2010-10-01 13:38 ` Robin Holt
2010-10-05 7:32 ` Eric Dumazet
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=20101001043413.GN14068@sgi.com \
--to=holt@sgi.com \
--cc=bcrl@kvack.org \
--cc=cmm@us.ibm.com \
--cc=davem@davemloft.net \
--cc=den@openvz.org \
--cc=dipankar@in.ibm.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mszeredi@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=npiggin@kernel.dk \
--cc=viro@zeniv.linux.org.uk \
--cc=xemul@openvz.org \
/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.