lkml.org 
[lkml]   [2004]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] [SYSVIPC] Change shm_tot from int to size_t
Date
Andries Brouwer wrote:
> 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.
>

I've looked around and couldn't find anything that returns -1 as a value
(as opposed to returning an error) when the value won't fit in 32 bits.
Here's what I've found (assuming a 32-bit app in all cases):
* sys_statfs, which fails with EOVERFLOW if any of the values won't fit
* sys_sysinfo, which scales the values down up to a PAGE_SIZE factor,
and silently truncates them if they are still too large
* BLKGETSIZE ioctl, which fails with EFBIG if the kernel itself is 32-bit,
but silently truncates if the kernel is 64-bit
* BLKGETSIZE64 ioctl, which always silently truncates
* HDIO_GETGEO ioctl (.start is ulong), which always silently truncates
I'm sure there are some other examples...

What do you think about following the example of sys_statfs in sys_shmctl?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.095 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site