[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-parisc
Subject: Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
From: James Bottomley <James.Bottomley () HansenPartnership ! com>
Date: 2015-02-22 19:42:50
Message-ID: 1424634170.2146.119.camel () HansenPartnership ! com
[Download RAW message or body]
On Sun, 2015-02-22 at 20:16 +0100, Helge Deller wrote:
> On 22.02.2015 20:13, James Bottomley wrote:
> > On Sun, 2015-02-22 at 19:07 +0100, Helge Deller wrote:
> > > > > > > SHMLBA is 4096 /* (1 << PGSHIFT) */ on hpux.
> > > > > > >
> > > > > > > The following is in <asm-generic/shmparam.h>:
> > > > > > > #define SHMLBA PAGE_SIZE /* attach addr a multiple of this */
> > > > > > >
> > > > > > > Shared mappings are handled with
> > > > > > > asm/shmparam.h:#define SHM_COLOUR 0x00400000 /* shared mappings \
> > > > > > > colouring */
> > > > > >
> > > > > > So how is the sys-v ipc problem fixed? There the user is told to select
> > > > > > an address which is a multiple of SHMLBA. Programs that do this today
> > > > > > will start to break on writeable mappings if we set SHMLBA to PAGE_SIZE
> > > > > > because the colour will be wrong.
> > > > >
> > > > >
> > > > > The code returns -EINVAL. See arch_get_unmapped_area.
> > > >
> > > > But that's not a solution. Let me try to illustrate: I have an existing
> > > > application, it uses sys-v ipc and selects a shmat address based on the
> > > > multiple of SHMLBA for a writeable mapping. Today it works.
> > >
> > > It will work as well with SHMBLA=4096, if you just use SHM_RND too
> > > (and most applications do have SHM_RND).
> > > man shmat says:
> > > * If shmaddr isn't NULL and SHM_RND is specified in shmflg, the attach occurs \
> > > at the address equal to shmaddr rounded down to the nearest \
> > > multiple of SHMLBA.
> > > * Otherwise, shmaddr must be a page-aligned address at which the attach occurs.
> > >
> > > So, even here shmaddr is mentioned to be page-aligned (4k), not
> > > SHMLBA-aligned (4M in your case).
> >
> > I think that part is x86. All the other VI architectures impose their
> > VI colour constrainst in SHMLBA. We're the odd one out because we have
> > a huge stride (everyone else is small multiples of pages).
> >
> > But agree if no applications are affected, we can make the ABI change.
> >
> > > > Tomorrow
> > > > when you make this change, it fails with -EINVAL. That's breaking an
> > > > existing application because chances are the app will just report the
> > > > failure and exit.
> > >
> > > Tomorrow? This change is *already* implemented in eglibc since a year or
> > > so and I don't see any applications which break because of SHMBLA=4096...
> >
> > Is eglibc a big enough sample to make the claim that no applications
> > will be broken?
>
> Try yourself:
> https://parisc.wiki.kernel.org/index.php/Debian_Ports_Installation
> Just install debian 8.0 (aka unstable for hppa). KDE, Xfce, libreoffice,
> and a all others packages just work out of the box.
I know, I do, but that's sort of expected: most modern linux apps use
mmap. It's the older stuff that uses sys-v ipc, but perhaps for us this
doesn't matter.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic