From: Robin Holt <holt@sgi.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Robin Holt <holt@sgi.com>,
linux-kernel@vger.kernel.org, Alex Thorlton <athorlton@sgi.com>
Subject: Re: [PATCH] Sys V shared memory limited to 8TiB.
Date: Wed, 10 Apr 2013 21:42:23 -0500 [thread overview]
Message-ID: <20130411024223.GM3658@sgi.com> (raw)
In-Reply-To: <20130410161507.b12128ee3df446eb9b86d8cf@linux-foundation.org>
On Wed, Apr 10, 2013 at 04:15:07PM -0700, Andrew Morton wrote:
> On Tue, 9 Apr 2013 21:39:24 -0500 Robin Holt <holt@sgi.com> wrote:
>
> > Trying to run an application which was trying to put data into half
> > of memory using shmget(), we found that having a shmall value below
> > 8EiB-8TiB would prevent us from using anything more than 8TiB. By setting
> > kernel.shmall greater that 8EiB-8TiB would make the job work.
> >
> > In the newseg() function, ns->shm_tot which, at 8TiB is INT_MAX.
>
> You have way too much memory.
>
> > ipc/shm.c:
> > 458 static int newseg(struct ipc_namespace *ns, struct ipc_params *params)
> > 459 {
> > ...
> > 465 int numpages = (size + PAGE_SIZE -1) >> PAGE_SHIFT;
> > ...
> > 474 if (ns->shm_tot + numpages > ns->shm_ctlall)
> > 475 return -ENOSPC;
> >
> > ...
> >
> > --- a/include/linux/ipc_namespace.h
> > +++ b/include/linux/ipc_namespace.h
> > @@ -43,8 +43,8 @@ struct ipc_namespace {
> >
> > size_t shm_ctlmax;
> > size_t shm_ctlall;
> > + unsigned long shm_tot;
> > int shm_ctlmni;
> > - int shm_tot;
> > /*
> > * Defines whether IPC_RMID is forced for _all_ shm segments regardless
> > * of shmctl()
>
> I reviewed everything for fallout from this and don't see any obvious
> issues.
>
> I do wonder about the appropriateness of the unsigned long type. Most
> (but by no means all) code in this area uses size_t, and the
> above-quoted ns->shm_ctlall is size_t.
The only reason I went with unsigned long instead of size_t was most
places in the kernel track stuff I recalled that was tracking stuff
in pages used unsigned longs. Also, I found shm_tot field in shm_info
structure was an unsigned long so this felt like a natural fit. I would
happily changed to size_t. Whatever you feel is right.
> And the above-quoted num_pages is `int'. Both the size and signedness
> of `int' make no sense - what happens if the incoming ipc_params.u.size
> is >2G?
>
> So I'll add this, and ask whether ipc_namespace.shm_tot should be size_t?
>
> --- a/ipc/shm.c~ipc-sysv-shared-memory-limited-to-8tib-fix
> +++ a/ipc/shm.c
> @@ -462,7 +462,7 @@ static int newseg(struct ipc_namespace *
> size_t size = params->u.size;
> int error;
> struct shmid_kernel *shp;
> - int numpages = (size + PAGE_SIZE -1) >> PAGE_SHIFT;
> + size_t numpages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
I was holding off from that change only because I was asking for this
to go to stable and this doubles the size of the patch. ;)
> struct file * file;
> char name[13];
> int id;
> _
Thank you,
Robin
next prev parent reply other threads:[~2013-04-11 2:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-10 2:39 [PATCH] Sys V shared memory limited to 8TiB Robin Holt
2013-04-10 23:15 ` Andrew Morton
2013-04-11 2:42 ` Robin Holt [this message]
2013-04-11 21:07 ` Andrew Morton
2013-04-11 21:10 ` Robin Holt
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=20130411024223.GM3658@sgi.com \
--to=holt@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=athorlton@sgi.com \
--cc=linux-kernel@vger.kernel.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.