From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934654AbdERLXT (ORCPT ); Thu, 18 May 2017 07:23:19 -0400 Received: from mail-db5eur01on0125.outbound.protection.outlook.com ([104.47.2.125]:6372 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S934003AbdERLXJ (ORCPT ); Thu, 18 May 2017 07:23:09 -0400 Authentication-Results: virtuozzo.com; dkim=none (message not signed) header.d=none;virtuozzo.com; dmarc=none action=none header.from=virtuozzo.com; Subject: Re: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs To: Russell King - ARM Linux CC: Will Deacon , , <0x7f454c46@gmail.com>, References: <20170414100953.4703-1-dsafonov@virtuozzo.com> <571024bf-892d-4d08-dd9e-654b1e28c23e@virtuozzo.com> <20170425173546.GS17774@n2100.armlinux.org.uk> From: Dmitry Safonov Message-ID: <4ba91200-3bc7-e6b0-69c1-40430b1b7e05@virtuozzo.com> Date: Thu, 18 May 2017 14:22:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170425173546.GS17774@n2100.armlinux.org.uk> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: HE1PR09CA0080.eurprd09.prod.outlook.com (2603:10a6:7:3d::24) To DB6PR0801MB1734.eurprd08.prod.outlook.com (2603:10a6:4:3a::21) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB6PR0801MB1734: X-MS-Office365-Filtering-Correlation-Id: 3fd52b2d-64a1-4b1b-39bc-08d49de03e6f X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201703131423075)(201703031133081);SRVR:DB6PR0801MB1734; X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1734;3:gxmtRf8V0TugtaJ+7F5UqcmhK8fuc3hTKAHjYNNRBCkk11eC0rgpH9lUK81QIXzsbteJuWOboa6fQMARQT1r6q93oEHiQpZNq6y6fYmr6YUi/VnHRJW+kR67UHUh3FB2peWcL8ZNi0k30Z//y/D9I40x0fOzF/GV/Dk3FSO+8mM8Rn4fukftpuO0ZwlJyxohmXxoiP0eKzG/lz6p1HRT0HudfktSQJGFYT/zz1lJwZNTuBSRncj9w1+9KU1MT+NZdN0ms2tdxHZY+Vy2AXuQrAo6u/bhAPgF++3T0lfxsV71gHXXWc9Jl8775lz6MAsr2cIy9GUk/s6ehL98Ac/8HA==;25:Iwm/KR0y8rAsnfkA8G1YrlHvTtv9s4TXKoqBLrlKB+fq+1e5AkOmYWANDCn893LCKhQCtyZubJ9SxgQDXp0vdyTjnpXC1vgu/UET96vJ0dtGSSVRVmbCpABd+Qzsiick9yb0r8XGDZGNH7f3+xalFX69zuxnE2X1F2bhTnuEVn3QMVso+Y2wt8yV+oVilaADxaghFXxdJd9iDwphhpSljxR6/6jriWcIOdP2jDUqBVhPxf8bv9YkJ9BcxZo5zY34K6ZuPDkBQKpvKWkPMlxLEsb4fZrmaoSAziCkbyBx4felgCNbm8JIhGPErAiV85MDPmc5bl3+6G6n+CvSoVVZRdte1M3nP4byb1Gramn4TXiI1AVgth2j5T0YJSb1Vww0X6pPzAk9ulQI1BjwEwtA8cESJ2nf3GVU0i47dXOAQgqFQaJBdbP+x7RwIyylWYgUA7ZXqRn4bfnwotSwMzHqnF1E4ruFKQqQWQFcwyLMyU8= X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1734;31:2zN0QhaPL1oqkv+b3g/n/b8t/X/Rt+PFTTeJQkCTQZIzzA6JEf9nc4yeCXjwS6JYJzsmdYi7yg2F4FhIhlVbw8gTxeiGpvQj/nb+bKfyKPS6Fw3rsrL6QUDhMzY9Hv0qGSnyLjbp5pj9VpA+5If9v8r81UIb/S7yN3I0asm7ByLEcaQ7sGdV+cb8dLZHj39ErcdAgYju2PbjLF6TqNNmlkcdPfKmI4yCJtMt8/XEXMjocd2Z8GdNsAAgFsGVpp5HEAP80/OgvGh31Q4EznE5yw==;20:So7sYML10iZyhk3oYNahWHbaajyhk6khF2nw7/NfuE3lZvcSVF8zdu9NFPH6GcZ0iMyfw28tBbPSCKLA66aqTSNy0PqJVBNzf4OZvNa9gdVprzxderDVc8aTTePUbJxmOlIWiajfJUj3neJrXnID3yp8+APyYE3eXxL3bn3d7+6a003FNyzYmuP0lw+i2lGNrmnCuEGh07IydAukuuQ9+j5+YvrGKq2tmzjziq1WXz1kUEHO9jmwCMvP99/vkRfl0JKZwWL/lu+4PS0E72fyvXaTCx9Yifu3yzvcpw0ntqY6yGqAwzR+N9UaoDQK5xV0mmLb7thqZXOcboiSE/e53sMiA0FKGSXDHUbXG/n5gNcYLO4sF5g/on6xl3hCwIaMDzdlhwUslMro80sy7wELTCEJI0mWDJh7+OWT2V3jzp8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148);SRVR:DB6PR0801MB1734;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0801MB1734; X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1734;4:Je2Jo9C1zWkwia5EoDt+x2o61gKyUH7abfVpdky/tkJ4cl3LoP2wRyIwbEYBMd/lYU4sx1TCIH0yasDcTLB9CY5qy75oJyZky9aiJqAzOjhREo0r2g1yZT0ubGWhmJUt9ZFFdvRBqg2Gw+hiPSmgFtBJvk3avsjg2aN2YYkpzUrUPSC+BAG4k3/8PvoEjkws2uarVMPcAGr/ah3DgI7uK5REe8PreacGiISRT0ajpvJRX2prNKgDqcSs2Cmh/F4ffUIuyj6JvwMGM9te+ozgQ6BEeWPi1Un+teGXe7QF6TFCvMI6doaNIK7O6qM26C6Enes3p1cjelc4OJ/MHzTZQ05L84JFJf6tF3myeJ4m9Jag9Gb6ksBRFV0Bg6QrEuPQoR8m1AftsOIibpOHFz+NBuvN2+jONdMHIKQFDOlCmCiONo1PBBbQkgiPu/GSmIsF93O3uIfFqoSfX8ft4a8Gm0FVTpL91BjfKD+aHOFb6cYLv4G3/IFNXl6CtgfD/xJp4wgaNe99cEKa8xhcz41hyt8YHuKtX2RYTLvtzlsidR/7aQ6RKxOKoJQzhsL3zw7wO9iqCz3Cs/2SmcPRlY61NspjcJW4UCfZUyHUr7r+Tym9SAX8XKstcUlcamvZMvj1AWbbcN7vPqVGSEkKrBkOaccjxIYbnFc2Z2UG+L8x2d3yGH5EVjHxedoDvivGmy4pV7vwHYAxZQtitMEzZ+vmuiHlqdrnyNuL7JKHhKahRMW8LUCi13yvqU1c5f9ThzjAtT2LpWuf+Txtlah9MoleCDXKpEgv+tueLwXylTlz7kI= X-Forefront-PRVS: 0311124FA9 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(39410400002)(39450400003)(39400400002)(39840400002)(24454002)(377454003)(23676002)(53936002)(50466002)(6246003)(7736002)(4001350100001)(83506001)(54906002)(110136004)(8676002)(65826007)(81166006)(31696002)(3846002)(6666003)(6116002)(189998001)(478600001)(229853002)(86362001)(5660300001)(64126003)(42186005)(6916009)(33646002)(38730400002)(230700001)(31686004)(53546009)(77096006)(25786009)(6486002)(2950100002)(65806001)(76176999)(50986999)(54356999)(66066001)(4326008)(36756003)(65956001);DIR:OUT;SFP:1102;SCL:1;SRVR:DB6PR0801MB1734;H:[172.16.24.230];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA4MDFNQjE3MzQ7MjM6VkM0RngyTGJydnJnNGwzdUN4eW1Zb1Za?= =?utf-8?B?bk0zbXMwSitEaTRmR2J3U2srYmJ6ZHdQbEdqTEhEaEN0VXhBZUR2c29XK1ov?= =?utf-8?B?UkFGQWhtUXZnMzZUUGJoOGFkY2ZTbGZ4ZXhiTk5GVXdhQjRqbmJuV1JsQUJG?= =?utf-8?B?T24wK1lBL0kyNkxiOWZSNHFGb2d4NDZFOU9uamlrbTU5N21LZVZoWGgvSkw4?= =?utf-8?B?MVVmOTZqa0lLUytpdDVsV1ZMSEZpZVB4a3ZoYUduOWxScWs3T1FuNFhJeExN?= =?utf-8?B?eGcyaXVCeWlGRW5tR3BYN1ozTnpsV0JhQm0vd1N3bGRjWmI4VVUxZHFocnNa?= =?utf-8?B?RTNTUzEzMjM0bkRSLzJ6NWNzdjJwVzJoUk1lZTljVi90bjFoOHBzdzlMd0xk?= =?utf-8?B?U0VUWUcvM2M5MitFYURkSjhCS2h1Zys5RGREd2d5bnNBS2g2YjdtaGY4ZnJW?= =?utf-8?B?b2NNVlBqeVFRcG5VUTNKWHk2TkxBRGJTbDJ3ejZPYUtSL21RWTFoVlNVUEww?= =?utf-8?B?U2lzWlA1dXg0L2JiMTA1OExvdFdsbGViQkIrRHNoMXFtWEFtTktldlJiUFBK?= =?utf-8?B?QU12WFVlYWd0d0VuazdpU1NLNTE2NHZtSW9wYUQ1ZmNBaWNZbWJaRUxWeDBu?= =?utf-8?B?cXRFK1BFZ05Oc25rZEh5dXVNdk5Tek9WK0Ira1J3M3FHNEFNWFptTTAzeW9P?= =?utf-8?B?dlNkWFI0SU94aFVpZy9RbjExRmFJODNyTFNVUUVjNlBudm1aVEovNmZ2V0Iv?= =?utf-8?B?aERUdmhQRlNsTTFBdEhqdUxtZjVQK0x2Y0xFbzMwOVEyN29saGtqaGs5eFNY?= =?utf-8?B?RXVxTUJvcE0wSWsvYUwrWEFlS1BESnlCU0NNak0wVHBOMDJvMkNta20yWEFG?= =?utf-8?B?UVZzaXM1WWJEeFBpeExRdHVCU29na2lHam91M0hTdDB2UFU0QlRiL3lVSy9H?= =?utf-8?B?MlNxU3k3RFE0d1E1OVJCTy9Vd21Odk1CdHJVQ2Rud0c1dHlDVFJKZlcrTEp4?= =?utf-8?B?NktGQkFYQWdUVzBlTkZZMGVPWUhHK1dYYm5xT0xjTTA1aEdzR0drMDE4L2NT?= =?utf-8?B?WTJtVnYrb1FtclhqMkp4Y3ZDTFI5Q0tqbE5qSm9YMlRRK0xLM2pXSWx6K2tp?= =?utf-8?B?WVFDRmpSZkxmMXdTaERvdG9QVmFVTUkveWxlRExRVDRaanZmWVVhNXUwdEZN?= =?utf-8?B?L1lLRmg5b3BOV2U2cVFWbWdOempQK3JIaE5zbm1DVDZCYTVadGFBU0JpOHhT?= =?utf-8?B?ZVppejZKeUhlVmhUV0VIdmg4Vm43ZWhUU3lZQXBYb3lsWkU4WWZJSWtBOWlB?= =?utf-8?B?UURmQXhjK2t4WGVxOFVqZEdYTTlxWjNjQkx4cnMwOHFUTkFQd3NoR0RSczIz?= =?utf-8?B?cjNKWWNmVUpIOHJBUnFheGREQWZSQUp0eXpmakMxQThseTI5NURPb21Va0Zk?= =?utf-8?B?TWx3UytHN3lINXA2UWJBNnI0Wm8vVmE3SXNkb1lwQkZRNWVmK29JWUVHbE9z?= =?utf-8?B?N2VJUlRyVHRsR0c1SG04OEkyR3lFMFFGYzBDMHFRcngySFhmTmViMmxiTHZj?= =?utf-8?B?bTIyU0Vwam1qSFNCZVNhdWI5NzAwN2JxdGZjSGk2RUNUQXpNeDFVOGdxZ0N6?= =?utf-8?B?L216c0FoV3JtSzVDYW5jNEEzbzE0SDZheDB6YVpjbVVhYVZ5NVpnVG9semRB?= =?utf-8?Q?xnrUot9LroiSFZvOXRwA=3D?= X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1734;6:q0Sqxydvrbtr4lHCT1v1aKgf+JsFXrvyyvHl6LRuIxHD8TQVs7nCTFZeuti/kWIrqP+vswOmwYQ7RoYtdCMEMICWY3WuMGqWEvL/VQozMurb29erBwGiccs9mQSobmAI3c6MpNEFVxTg0WZ0W9RbaUkSnHwg4QPdeEBsVsMpb6oSUycrPlXmS94BNpM/4BfvJ5fD/y78IGJtYhUck9NJ4tTIq7aIHsu4DAyqu7KROUy81sCpTcv5q21Y+eGxZFsVu6Qi2QBE7hJKep7aLhbtvqlqcqcBJVeg/6BTlL2NXxvyyt1THrB/2Obw0wYx03yooq721+FpWbHXzZyXH8d4wLFyWUjywcwLrerznNScXWmtbBAtyirO4XuzQqSaj6iPbGBRP2JytMLbnZ/FThlL2Lpbp2yDNLJrXPydtFzMs2V2WHW64LkHhC4sIJUTYGjMzWSIEQinIj3gO9dT0qdnO7cFmxOJbIJFMo5qaceKd0hg0KGaxhPjrGITTnX1gVd3SDQGWrHnI1bUGeaFM8rEag==;5:ZdpHqwofhVlAOdattwi9GHUN66au0KrY8XmR0CoVeYjjjXWI3rKe97sL0K9OOKLabKHlUNnblAwTErKqa+5lbc3HdP7Bf7qYUlJ7+QkT9e3XeDokvHUObp/LBKFlntdnKrl3EHYhoJpFYoys7/HNfg==;24:nZdLDuBtxjVG16CiaMp9RHv5ecsQegk+m3CNAZ9079ZtToBnDzYxgp9EOxPoTjILVVDDrpNiTUTBl59QHPtz4NcDffHDtdior5NMte7hAFw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1734;7:y/WQ8zHieLzJAFZ9EMFTy3bWGMISFUmAdnJ2gu/XnO+zJAJ88sHYtnCC9/MkfwTFWK1M0wgCLoXEQknDnzek16+32aJHBC1XI2Q7GTVck5eE6dog/0Cxndalz8YVuPQzENosvAkOjF+MrN6Q4m3ie7/00nAEfZaFPPL3EWR+UpIf1U6GXImQveBiCnksmWS5YuZBrjnY3wNWizAaGtTW4XoAa+bqFyjY08h4NLVz5PtIGjcKb0UvdBBob++PepS98f7Hiy+Tlct+s2veikMW08ENqqKJGcKUWBp5r5Om1k5pfqPLngS0N+7db2U9bDjB/PBvcdf1zswg2qasNB31kQ==;20:6tjx9ss60ch14eDixiw4IeXdKTmI40BOwjQykPgmh7ND3dQEZuD4/e/qXwGV90mn89WsT70hk5EGaoBjS+UnZs8CradnpXq62pWURzOqhmJCxMrELNM8a/LGpd9Bl4a8ad3QiiZ23CnR6nDCfvzfHGTWQ8Iegu4y/aInWBlpRoc= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2017 11:23:00.3917 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1734 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/25/2017 08:35 PM, Russell King - ARM Linux wrote: > On Tue, Apr 25, 2017 at 08:19:21PM +0300, Dmitry Safonov wrote: >> On 04/14/2017 01:09 PM, Dmitry Safonov wrote: >>> On ARMv6 CPUs with VIPT caches there are aliasing issues: if two >>> different cache line indexes correspond to the same physical >>> address, then changes made to one of the alias might be lost >>> or they can overwrite each other. To overcome aliasing issues, >>> the align for shared mappings was introduced with: >>> >>> commit 4197692eef113eeb8e3e413cc70993a5e667e5b8 >>> Author: Russell King >>> Date: Wed Apr 28 22:22:33 2004 +0100 >>> >>> [ARM] Fix shared mmap()ings for ARM VIPT caches. >>> >>> This allows us to appropriately align shared mappings on VIPT caches >>> with aliasing issues. >>> >>> Which introduced 4 pages align with SHMLBA, which resulted in >>> unique physical address after any tag in cache (because two upper bits >>> corresponding to page address get unused in tags). >>> >>> As this workaround is not needed by non-VIPT caches (like most armv7 >>> CPUs which have PIPT caches), ARM mmap() code checks if cache is VIPT >>> aliasing for MAP_SHARED. >>> >>> The problem here is in shmat() syscall: >>> 1. if shmaddr is NULL then do_shmat() uses arch_get_unmapped_area() >>> to allocate shared mapping. >>> 2. if shmaddr is specified then do_shmat() checks that address has >>> SHMLBA alignment regardless to CPU cache aliasing. >>> >>> Which results on ARMv7 CPUs that shmat() with NULL shmaddr may return >>> non-SHMLBA aligned address (page-aligned), but shmat() with the same >>> address will fail. >>> >>> That is not critical issue for CRIU as after shmat() with NULL address, > > CRIU? Please try to keep use of acronyms to a minimum. > >>> we can mremap() resulted shmem to restore shared memory mappings on the >>> same address where they were on checkpointing. >>> But it's still worth fixing because we can't reliably tell from >>> userspace if the platform has VIPT cache, and so this mremap() >>> workaround is done with HUGE warning that restoring application, that >>> uses SHMBLA-unaligned shmem on ARMv6 CPU with VIPT cache may result >>> in data corruptions. >>> >>> I also changed SHMLBA build-time check to init-time WARN_ON(), as >>> it's not constant afterward. > > I'm not happy with this. SHMLBA is defined by POSIX to be a constant, > which means that if we want to have any kind of binary compatibility > between different architecture versions, SHMLBA must be constant across > all variants of the architecture. > > Making it dependent on the cache architecture means that userspace's > assumptions can be broken. Increasing it is not an issue (since SHMLBA > is defined to be the address multiple - an address that is aligned to > 4-page is also by definition aligned to 1-page.) So what I did back in > 2004 wasn't a problem. > > However, reducing it (as you're now suggesting) is - newly built programs > are built today with: > > #define SHMLBA (__getpagesize () << 2) > > so we must not allow the kernel to return addresses that violate that. > As I say, we can't reduce SHMLBA now. So, we violate this on return address with shmat(smid, NULL, shmflg) when shmaddr == 0. But we don't do this on shmat(smid, shmaddr, shmflg) where shmaddr should be SHMLBA-aligned. That API looks unexpected and creates difficulties, which I've workarounded in CRIU, but still might worth fixing. -- Dmitry