This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Possible bug in sysdeps/unix/sysv/linux/powerpc/mmap64.c


> Date: Sat, 19 May 2001 21:54:57 -0700
> From: "H . J . Lu" <hjl@lucon.org>
> Cc: drepper@cygnus.com, howarth@bromo.med.uc.edu,
>         libc-alpha@sourceware.cygnus.com

> On Sat, May 19, 2001 at 08:30:08PM -0700, Geoff Keating wrote:
> > > Cc: Jack Howarth <howarth@bromo.med.uc.edu>, libc-alpha@sourceware.cygnus.com
> > > Reply-To: drepper@cygnus.com (Ulrich Drepper)
> > > From: Ulrich Drepper <drepper@redhat.com>
> > > Date: 19 May 2001 16:33:21 -0700
> > > 
> > > "H . J . Lu" <hjl@lucon.org> writes:
> > > 
> > > > 1. Even on PPC, the kernel page size may change.
> > > > 2. Linux may have variable page size one day.
> > 
> > Hi HJ,
> > 
> > I understood at the time that even if the kernel page size changed,
> > and even if linux implemented a variable page size, this syscall would
> > still need a shift of 12.  The constant 12 is part of the ABI and not
> > necessarily related to the actual page size.
> 
> It is very odd. As far as I know, Linux implements the SVR4/ELF ABI
> only to the extend of calling conventions and relocations. We.never
> implemented the binary interface of system calls and library functions.
> I don't know why the SVR4 PPC ABI speficies the page size and why we
> care what it says about the page size for mmap. For all I know, under
> Linux,

This is not the SVR4 ABI, it is the Linux syscall ABI.

> # man mmap
> ....
>        offset should ordinarily be a multiple of  the  page  size
>        returned by getpagesize(2).

My manpage for mmap doesn't have this.  It probably should.

> and posix/tst-mmap.c in glibc does the same. To me, Linux/PPC doesn't
> follow the Linux/glibc ABI. Did I miss something?

This is not the glibc ABI, it is the syscall ABI.  There's no
necessary relationship between the two.  The kernel is free to return
EINVAL for additional values of OFFSET, if the actual page size is
larger than 4k.  I don't believe any hardware can support page sizes
less than 4k, so that case won't occur.

This does seem to mean that the mmap() syscall can't support files
larger than 16T.  It'd probably be a good idea to at least produce an
error code if someone tries specifying such a huge OFFSET.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]