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

[Andries Brouwer]

On Fri, Jun 25, 2004 at 12:42:26PM -0500, Makhlis, Lev wrote:

> > 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?

There is a good reason to do it always.
If one truncates, then the result is always unreliable.
If one replaces a too large value by -1, then any other value is reliable.
-
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/