All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.