RE: [PATCH] [SYSVIPC] Change shm_tot from int to size_t

[Makhlis, Lev]

Andries Brouwer wrote:
> On Fri, Jun 25, 2004 at 10:41:13AM -0500, Makhlis, Lev wrote:
> 
> > I see that shm_tot (the total number of pages in shm segments) in
> > ipc/shm.c is defined as int, even though its max value 
> (shmall) is size_t.
> > 
> > Admittedly, it only matters for systems with >8TB memory, 
> but shouldn't
> > shm_tot also be size_t?  The attached patch makes it so.
> 
> > -static int shm_tot; /* total number of shared memory pages */
> > +static size_t shm_tot; /* total number of shared memory pages */
> 
> First, please avoid attachments.
> 
> Secondly, this makes shm_tot unsigned. Have you checked all places
> where it occurs in an inequality to see whether the semantics did
> change? (It looks OK.)

Yes -- it looked to me like the semantics would be more correct, since
currently, "if (shm_tot + numpages >= shm_ctlall)" will break when
shm_tot wraps around MAX_INT and becomes negative.

> 
> Thirdly, shm_tot is transmitted to userspace (via the SHM_INFO ioctl)
> as an unsigned long. If it is necessary to make it larger, then we
> must do something with this ioctl. For example, return -1 there
> in case the actual value does not fit in an unsigned long.

The SHM_INFO shmctl is actually how I found it in the first place.
But we have the same situation with many other values.  For example,
shm_ctlmax, shm_ctlall and shm_segsz can all potentially be 64-bit wide
in the kernel and are exported into potentially 32-bit userspace values.
We don't return -1 for any of those if they don't fit.  Is there a
special reason to do it in this case?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/