From patchwork Thu Apr 3 19:41:21 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Helge Deller X-Patchwork-Id: 3933841 Return-Path: X-Original-To: patchwork-linux-parisc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1067B9F387 for ; Thu, 3 Apr 2014 19:41:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id EC301202EA for ; Thu, 3 Apr 2014 19:41:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E43D92026D for ; Thu, 3 Apr 2014 19:41:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753440AbaDCTll (ORCPT ); Thu, 3 Apr 2014 15:41:41 -0400 Received: from mout.gmx.net ([212.227.15.19]:50638 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753434AbaDCTlk (ORCPT ); Thu, 3 Apr 2014 15:41:40 -0400 Received: from [192.168.178.60] ([84.173.13.175]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MMBiP-1WNnhf2FvZ-0080gv; Thu, 03 Apr 2014 21:41:22 +0200 Message-ID: <533DB961.9010607@gmx.de> Date: Thu, 03 Apr 2014 21:41:21 +0200 From: Helge Deller User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John David Anglin , Carlos O'Donell CC: Aaro Koskinen , Mike Frysinger , linux-parisc Subject: Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address References: <20131219191750.GC2881@blackmetal.musicnaut.iki.fi> <201312191619.05005.vapier@gentoo.org> <5313A12E.7010307@gmx.de> <20140401182627.GA3285@drone.musicnaut.iki.fi> <533B0A57.2060700@gmx.de> <533C7C9A.5080703@gmx.de> In-Reply-To: X-Enigmail-Version: 1.6 X-Provags-ID: V03:K0:DTgxTdtzRSqDU2gKgie6c25iW1Hb9pehDO1u1WwqplhVbm7rwh0 CYSupik09a2XmIHHcAJWlhkX/9pzVheTk6gOTx/M5rvtDPbS7zCpxMGgNXYdDreNf9nXPOY CN4GjCCwUkMARebgd8DAaxBmna/IugK7+d8uYaRtrvdCpe3qMN+e9CNCV6pnVdVk3wfjHhQ sgv5iT5Po/dwZxXZry9+Q== Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_TVD_MIME_EPI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 04/02/2014 11:41 PM, John David Anglin wrote: > On 4/2/2014 5:09 PM, Helge Deller wrote: >> On 04/02/2014 09:09 PM, Carlos O'Donell wrote: >>> On Tue, Apr 1, 2014 at 2:49 PM, Helge Deller wrote: >>>> Yes. >>>> But it's not a kernel bug. Kernel 3.14 and previous stable releases are OK. >>>> >>>> I did proposed a glibc change in my previous mail (http://www.spinics.net/lists/linux-parisc/msg05384.html). >>>> Debian bug report with patch is here: >>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741243 >>>> >>>> And this is what I proposed: >>>> >>>> A trivial FIX/workaround would be to change libc-mmap.h like this: >>>> #ifdef __hppa__ >>>> #define MAP_FIXED_ALIGNMENT 4096 >>>> #else >>>> #define MAP_FIXED_ALIGNMENT SHMLBA >>>> #endif >>>> >>>> That works because then the new aligned address is then the same as the original >>>> (the mmap call returns 4k aligned addresses, so it stays unchanged), but I'm not sure >>>> if such a patch would be acceptable. >>>> Do you have another idea/proposal? >>> The responsibility for fixing this falls to me, but I've been busy. >> No problem. >> >>> If someone wants to propose a patch for glibc please email >>> libc-alpha@sourceware.org, TO me, and I'll review and commit the patch >>> granted that you show you've done the appropriate testing. >>> >>> Otherwise I'll get to this at some point in the next couple of weeks :-( >> Hi Carlos, >> >> I'm not really sure if my patch is the best way to go. Technically it's correct >> and it's tested since all our debian buildservers currently run with this patch. >> But all other options would probably involve more code changes. >> >> So, I think I'm happy if you can look at it at some point when you find time. >> Your input would be very valuable here. > I'm wondering if kernel value for SHMLBA shouldn't change to PAGE_SIZE to better > reflect that attach addresses are page aligned. The color alignment for shared maps > seems a separate issue which maybe userspace doesn't need to worry about. I think this is a very interesting idea and it should be pretty simple! The attached patch for eglibc should resolve it. And the attached patch for kernel isn't necessary, but makes it clear that the colouring is important. I did tested the kernel patch - and it seems to work without problems. I'm not sure if this might introduce userspace compile problems though (although unlikely). Helge diff -up ./ports/sysdeps/unix/sysv/linux/hppa/bits/shm.h.org ./ports/sysdeps/unix/sysv/linux/hppa/bits/shm.h --- ./ports/sysdeps/unix/sysv/linux/hppa/bits/shm.h.org 2014-04-03 13:20:43.644098000 -0600 +++ ./ports/sysdeps/unix/sysv/linux/hppa/bits/shm.h 2014-04-03 13:22:15.840098000 -0600 @@ -36,7 +36,7 @@ #define SHM_UNLOCK 12 /* unlock segment (root only) */ /* Segment low boundary address multiple. */ -#define SHMLBA 0x00400000 /* address needs to be 4 Mb aligned */ +#define SHMLBA (__getpagesize ()) /* Type to count number of attaches. */ typedef unsigned long int shmatt_t;