Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address

From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Helge Deller <deller@gmx.de>
Cc: John David Anglin <dave.anglin@bell.net>,
	Carlos O'Donell <carlos@systemhalted.org>,
	Aaro Koskinen <aaro.koskinen@iki.fi>,
	Mike Frysinger <vapier@gentoo.org>,
	linux-parisc <linux-parisc@vger.kernel.org>
Subject: Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
Date: Sun, 22 Feb 2015 11:42:50 -0800	[thread overview]
Message-ID: <1424634170.2146.119.camel@HansenPartnership.com> (raw)
In-Reply-To: <54EA2B1B.10406@gmx.de>

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