I've got ENOMEM error when tried to allocate SYSV's shared memory buffer
greater than 1G on machine with 16G RAM. Some investigation did show that
there is small error in sys/kern/sysv_shm.c file - variable "size" has
"int" type that may overflow on big values.
How-To-Repeat: Just try to allocate big shared memory buffer

On Wednesday 17 October 2007 11:40 am, Ed Maste wrote:
> The following reply was made to PR kern/113218; it has been noted
> by GNATS.
>
> From: Ed Maste <emaste@phaedrus.sandvine.ca>
> To: bug-followup@FreeBSD.org, vasim@resume-bank.ru
> Cc:
> Subject: Re: kern/113218: [sysvipc] [patch] Overflow in shmget's
> memory size check Date: Wed, 17 Oct 2007 11:10:11 -0400
>
> Presumably changing shm_segsz from int to size_t means we'll need
> to add a 32-bit compat shmctl as well as a backwards-compatibility
> one for older FreeBSD 6/7 64-bit apps?
Yes, correct. But struct oshmid_ds is already taken. Do you think I
have to add OMG_we_broke_shmid_ds? ;-) Seriously, I think we should
do it for 7.0 before it gets too late. Maybe 6.3 can live without it
because shminfo was not increased on the branch. Or maybe we can add
the feature with compat shim later only on the branch. What do you
think?
Jung-uk Kim

On Wed, Oct 17, 2007 at 12:11:09PM -0400, Jung-uk Kim wrote:
> > Presumably changing shm_segsz from int to size_t means we'll need
> > to add a 32-bit compat shmctl as well as a backwards-compatibility
> > one for older FreeBSD 6/7 64-bit apps?
>
> Yes, correct. But struct oshmid_ds is already taken. Do you think I
> have to add OMG_we_broke_shmid_ds? ;-)
Yeah, it's a shame, and we already have an oshmctl syscall. I don't
know what naming convention we'd use, but we probably end up with
the existing oshmctl, shmctl_5x in 32- and 64-bit versions, and then
the modified shmctl in 32- and 64-bit versions. Maybe the following?
shmctl
shmctl_5x
freebsd32_shmctl_5x
shmctl
freebsd32_shmctl
> Seriously, I think we should
> do it for 7.0 before it gets too late. Maybe 6.3 can live without it
> because shminfo was not increased on the branch. Or maybe we can add
> the feature with compat shim later only on the branch. What do you
> think?
Yeah, getting this into 7.0 would be very very good. I'll need to get
it in 6.x as well at work, although I can probably break the ABI there
so that part is less of a concern for me. Probably the issue causes
the most grief with big Postgres installations which will most likely
want to use 7.x anyhow in short order for the better scalability.

On Wednesday 17 October 2007 01:40 pm, Ed Maste wrote:
> The following reply was made to PR kern/113218; it has been noted
> by GNATS.
>
> From: Ed Maste <emaste@phaedrus.sandvine.ca>
> To: Jung-uk Kim <jkim@FreeBSD.org>
> Cc: bug-followup@FreeBSD.org, vasim@resume-bank.ru
> Subject: Re: kern/113218: [sysvipc] [patch] Overflow in shmget's
> memory size check Date: Wed, 17 Oct 2007 13:35:44 -0400
>
> On Wed, Oct 17, 2007 at 12:11:09PM -0400, Jung-uk Kim wrote:
> > > Presumably changing shm_segsz from int to size_t means we'll
> > > need to add a 32-bit compat shmctl as well as a
> > > backwards-compatibility one for older FreeBSD 6/7 64-bit apps?
> >
> > Yes, correct. But struct oshmid_ds is already taken. Do you
> > think I have to add OMG_we_broke_shmid_ds? ;-)
>
> Yeah, it's a shame, and we already have an oshmctl syscall. I
> don't know what naming convention we'd use, but we probably end up
> with the existing oshmctl, shmctl_5x in 32- and 64-bit versions,
> and then the modified shmctl in 32- and 64-bit versions. Maybe the
> following?
>
> shmctl
> shmctl_5x
> freebsd32_shmctl_5x
> shmctl
> freebsd32_shmctl
>
> > Seriously, I think we should
> > do it for 7.0 before it gets too late. Maybe 6.3 can live
> > without it because shminfo was not increased on the branch. Or
> > maybe we can add the feature with compat shim later only on the
> > branch. What do you think?
>
> Yeah, getting this into 7.0 would be very very good. I'll need to
> get it in 6.x as well at work, although I can probably break the
> ABI there so that part is less of a concern for me. Probably the
> issue causes the most grief with big Postgres installations which
> will most likely want to use 7.x anyhow in short order for the
> better scalability.
Actually there is another way. We can add a upper half in struct
shmid_kernel. Then we can aggregate the lower half
(shmid_ds.shm_segsz) and the upper half to get real shm_segsz. But
it is ugly and userland will not see the upper half, e.g., ipcs -b.
Jung-uk Kim

It turns out this has been discussed a number of times already, and
there's another issue that Robert Watson brought up that needs to be
dealt with at the same time. That is, ipc_perm needs to get fixed:
[ipc.h]
/*
* XXX almost all members have wrong types.
*/
struct ipc_perm {
unsigned short cuid; /* creator user id */
unsigned short cgid; /* creator group id */
unsigned short uid; /* user id */
unsigned short gid; /* group id */
unsigned short mode; /* r/w permission */
unsigned short seq; /* sequence # (to generate unique ipcid) */
key_t key; /* user specified msg/sem/shm key */
};
These should be:
uid_t cuid
gid_t cgid
uid_t uid
gid_t gid
mode_t mode
? seq
key_t key
(I'm not sure what type seq should have.) Anyhow, we'll have to deal
with the ABI issue for sem and msg in addition to shm then.

Hi there.
Is there any chance to have this functionality (ability to allocate more
than 2G of SHM) in 7.0-R ?
I have a huge postgresql installation and now i'm suffering from this
limitation. It's nice to know that new release is very fast (according
to Kris's presentation on MeetBSD), but this limit is a real pain.
Perhaps 7-Branch is good moment for ABI brekage (IMHO better break when
updating 6.X -> 7.0 than 7.0 -> 7.X).
Personally i'd rather wait longer for 7.0 without this limtation.
Best regards
Piotr Rybicki