From mboxrd@z Thu Jan 1 00:00:00 1970 From: Helge Deller Subject: Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address Date: Sun, 22 Feb 2015 20:16:43 +0100 Message-ID: <54EA2B1B.10406@gmx.de> References: <20131219191750.GC2881@blackmetal.musicnaut.iki.fi> <5313A12E.7010307@gmx.de> <20140401182627.GA3285@drone.musicnaut.iki.fi> <533B0A57.2060700@gmx.de> <533C7C9A.5080703@gmx.de> <533DB961.9010607@gmx.de> <533DC3E8.5010701@gmx.de> <1424560158.2146.22.camel@HansenPartnership.com> <54E9141B.4050009@gmx.de> <1424563046.2146.41.camel@HansenPartnership.com> <1424625475.2146.88.camel@Han senPartnership.com> <1424627938.2146.103.camel@HansenPartnership.com> <54EA1ADC.60701@gmx.de> <1424632396.2146.116.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Cc: John David Anglin , Carlos O'Donell , Aaro Koskinen , Mike Frysinger , linux-parisc To: James Bottomley Return-path: In-Reply-To: <1424632396.2146.116.camel@HansenPartnership.com> List-ID: List-Id: linux-parisc.vger.kernel.org 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 : >>>>>> #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. Helge