From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752048AbdCMOUy (ORCPT ); Mon, 13 Mar 2017 10:20:54 -0400 Received: from mail-ve1eur01on0109.outbound.protection.outlook.com ([104.47.1.109]:16138 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751941AbdCMOUr (ORCPT ); Mon, 13 Mar 2017 10:20:47 -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: [PATCHv6 4/5] x86/mm: check in_compat_syscall() instead TIF_ADDR32 for mmap(MAP_32BIT) To: Thomas Gleixner References: <20170306141721.9188-1-dsafonov@virtuozzo.com> <20170306141721.9188-5-dsafonov@virtuozzo.com> <35a16a2c-c799-fe0c-2689-bf105b508663@virtuozzo.com> <4f802f8b-07a6-f8cd-71fc-943e40714d1b@virtuozzo.com> CC: , <0x7f454c46@gmail.com>, Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , Borislav Petkov , , , Cyrill Gorcunov , "Kirill A. Shutemov" , Michael Kerrisk From: Dmitry Safonov Message-ID: <2a7e5737-2f5a-02c7-bf74-9371190a0370@virtuozzo.com> Date: Mon, 13 Mar 2017 17:17:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: DB6P191CA0017.EURP191.PROD.OUTLOOK.COM (10.175.236.155) To HE1PR0801MB1737.eurprd08.prod.outlook.com (10.168.149.149) X-MS-Office365-Filtering-Correlation-Id: aa693ea3-85b3-49dd-fd3f-08d46a1c22ce X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR0801MB1737; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;3:lC2juNvOlKSN6ni/anesuG7ubUjQbUYb7YGxowbIYmf+EFCTpdDEdGISsWZKgrCcdhIuzk+5qDIfNve8ZWet8XCGy9MeLbfIzkN/qlD1+Na4bViDQcEIY1Q8XX4pl2lyhvSHkV6bazKnfNi1C8pXl74HKe9TIIKDIul3c7z4SjjDEllKQNfbrzwdkCmd6PWWBKHd/6u4in6QtfiZ0iUjWB3P56vRhmmVTKwBz1XLtbDkNDxzI5zWfxxDr3ikuVUYDgElAznrqyjboZ+f1NrhZA==;25:PvRlW4oUroMya6TKjjWaO6Wswbi/yc6q0AUX2t18HrP7JCnFIGvq9kY6O3RZ10JW31UkRxfMVzCJ+vNz0PEUmeQIgbexK9qMDTo2TamiKqtN2TPpvt++j6EyMWU/AIc0pdzivPeO3Y5UxIp4DopTf3uasUwkum0ldX1NYpAtOPnQsiPrqt9Um07gatTenUIVpGt73hlLosHks+Pp+YX0Zr3DkPJoX41iecwTC+kxxoJOpxQYxP9vmAD1ZbkrGvDdSPRfRNsBvY2ui6h5xNcGcr2q4ryVhj7xeQ3dCTSTFjjYGuTy7bImHqnd0dUng9JdaBYGIJ3Z1YTl3azFnZXchsfRWwdyy7m6bC7KhdRXIpHf0jMuJIigJIXfEIrK+9SmVytzRhoWsVKvrTDT/3a0QZZe9dOPwPf0LE9kZtBrs4rzrs7LcWaJS4lAbeXb3OkjJzHNdelOVO/fD8Grt5veRg== X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;31:4dfKNKrr5T5IjmiW5pzoP+CD7xZFjEEvv7Nm8U4/wm0f/zW9sdhNlbi7/fS6ZEGkNg1KT4CJ5/PhCRXr7ttZClBiGJllieaLTm5sNY07UXVQHR4ECKEgzOWAKpqMIFi87866GVUfj/wTr9xGapPy6kMhiAqdEeUjsUnwynkh2MXrUj37VVBSCZMVTf2Uk6U1qmffl2IHSXtKDaWmmAPHlYHapiImOTpF8at+B2g5UqeOOtuwZoJfQwAM6ioya7o+wpB6OdeiEmQlhDsCGFB9dw==;20:9PNf7OYiMRo/K7B3972W1m/JwiLadSwrv02fNfyn6Ozln6Dh9e8NcpDg5eDbQZIHUAbzHiBFIJqBDBXm4rQrzTNqgKBQPxl2XNzYo2QxaThb9ooEmGz8E/ZiOyMFtGFZ+YEfOucRzEy+m7L9tlzB8/voxhi21MfgO/yPLfyo3NR40VZUbx9l4xAF02lb6OybN/aIP8/zG/FxoxB6hn2MfRodAul85y/Pp47EFmb3t07DmI8KJZVQ8oUy5FnE3L1VexHbhWpmsSnJrrmIvCWJXreZCRuPkDMjDBL/Q3ekV51rnQpjlgyRKt1UVIdsJCCCTYcfgsNiSfl8JBQA/9x9GxITu/E4P/2W9ycGcTv8p/nJ6sIVlcw8yONVhMrynpWXYU0CgJ1Qu9MUNBraN/Fl/Ms/7ws5DXvzoZfGBade7rA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(20161123562025)(6072148);SRVR:HE1PR0801MB1737;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1737; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;4:M8huBCPmRtnHQoj1lEVEyRandX5n3HpbNinEYOr/B2TBSvZofCGhFH60VYjlZLbzhsipU+S9lhIb4kswYmGPnd61eZCewJVm7whZjgcbIzLZk264kFj2ikD+er9lS+C2KhDswzQxpehVjT10E3zRqOmGc5pQqJgrf6CKHTQLh2hjzba1rQ8YQNIZ7Mj0s1zyUdS9fndzJUA9XtAYWZLrNbQ8cbL4rcy5d8VFDsmKTw2OaACTa8LJCjBJ/MZWCRfJk98xANo2Xy3AOv8k2zxiU8Hv2hu3iI/4EOQH+V3N/h4trpkJRMsNzlheAtahFk17jB+y85+zhg4k7EoFyluwb+70R1rB5x0DWfzrtd8qUNRJMKTAuxIa2yraNR4I/TmUSzFmSy0RfaYXJuZDGavtUtA3rMBBOtxUksBE/bz0Q+wb01nzN4aZbhbZQe+9iyCnS3Y3K3YWulVoXtd+Yaha++o3fMo18kURA5djADGB0QbWA9ylD61HDSQJeDaTPl8Z5+gxHFPkLdpoClFUx4qRiiX+d5UmIIrfr5L6zi6hVBOeJeWGd/wx0+5jwEy0cZjT3qj1xQkoxOReCOxTHtS4YIg/wfwFBtjbo9ZHT5kHdAzYFCqiUNLoBGZ9DFp8DX67tEhKmzc3Omp6r5t8bIaJNw== X-Forefront-PRVS: 0245702D7B X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(39830400002)(39410400002)(39450400003)(377454003)(24454002)(33646002)(4001350100001)(230700001)(7736002)(38730400002)(4326008)(305945005)(110136004)(6246003)(53546006)(86362001)(36756003)(3846002)(6116002)(189998001)(31696002)(23746002)(83506001)(7416002)(53936002)(6666003)(65826007)(76176999)(47776003)(81166006)(6916009)(42186005)(54906002)(2950100002)(50986999)(54356999)(8676002)(31686004)(5660300001)(66066001)(93886004)(2906002)(65806001)(90366009)(50466002)(229853002)(77096006)(25786008)(6486002)(65956001);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR0801MB1737;H:[172.16.25.13];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;HE1PR0801MB1737;23:O3iNv7UxODsoNx1BHIYmYn4ArVbFL9+saiy?= =?Windows-1252?Q?zXVTD8LfhNIScUtu5uTuGDwE/n7102t8C5hU4Zng8qe+4hXYjtxt6Mxq?= =?Windows-1252?Q?ogQf5v+m+J+D7yTtnle9MAT3+Lpg9ohAqhpWS6Pry11jnfCnNtnj9sjY?= =?Windows-1252?Q?elF90Nm6de7OIyjNrjOdDWGYOTvzD4cZKvoN0ebkSGgDk/kPq8tGXAmw?= =?Windows-1252?Q?d8TNiCAbMm6PXy/j8ILLj28eBSoaxZuK1QtcF4hZdLHT51dHDIKP41oC?= =?Windows-1252?Q?yVSIpVXyRsUK6IjMbWFjH4V3yRQfgnpYp1qkcTp9I6BYaVK9XEbt45HF?= =?Windows-1252?Q?cc0pXgUqstbYfbnFhrxgJMR4VCM1KU8dPgwo7A0to7rDULhqzjOFFDD7?= =?Windows-1252?Q?2xfFT2T7Jx1CmoRlRYZ2mAbImeUjoLVgR9BknEzpv9CnutLOjwBkdeZ7?= =?Windows-1252?Q?/cmZmLOVfRkKS0ylPEcUpcjJ2Hk7Gz8/b3iVHncGsk7Nq0XgoIH+ZgzT?= =?Windows-1252?Q?a66F84lv0Eke0Pa42SFjRFbOx0BLoDFZ+NX+XIb4ODJlRF3V3t/yCvQC?= =?Windows-1252?Q?yuR4a9mqKFaNUPSgB52LiM8ubUBFT3L6zVGKpfEGr2V4n4oef5lnE4+F?= =?Windows-1252?Q?CQSq8mRB801m4YXG3fy8mDgq2LOsqgVUbiP1bRTU5pTgG9rnpnG5pdSL?= =?Windows-1252?Q?PJnuFHCT7z95hof0uONzQ3Znhai3E/kJIDMa9TzufiCXj6OoV72twM5r?= =?Windows-1252?Q?4qTwBA6u1sKLA/gJC6xdMBlubFIEzXv+WnmZwVmeku6mmb52tvYcIyUu?= =?Windows-1252?Q?Ni8uLgLQ1Ym6vAPYUTZ/lI6ffiRh1+niLEEjeOqZDkbbaqmMGKZ7s/uv?= =?Windows-1252?Q?u2xJGGO8uYS8oX64Vbolsdg4s2CClCff5t+LrwyvRkQaspgcdCsfv7Km?= =?Windows-1252?Q?O7YpmAPBfbBpjIadSivzcLo7GuIFhxWHMW69LVIW3JOcGTIwpYfRSZyq?= =?Windows-1252?Q?p4yyEHBpr8GudNIZTGzgV2is5sD2PAqis+7Zeeq81+JfFEcoXrmmYLw/?= =?Windows-1252?Q?VhPnPkJOV/wNLDEHU235pK0vCOpfL9LtvwO77L5OgCJYuGjgm6Yc3xvl?= =?Windows-1252?Q?Kxl3Mvb2jD6QK5ZqQkwnTY1w0BbePvzd1ORAeLoCcK7oicTT7gmwZa+r?= =?Windows-1252?Q?S5r/dkXnIMeRtHbFYPJ8hrBCIz1EmKLoP3hHCCpNdaxDfZ+oO/BMnT0q?= =?Windows-1252?Q?bjHqsM0m1wlBdbOIUU7xPdbAxUlk0PeFdnAAPgmnmPzOS6260mOh8cZX?= =?Windows-1252?Q?ISfXN43U2BWnbsvfP+PBl0+IlmmNmt6KxaVFJtlMtvAfWUD1OeBsNT7K?= =?Windows-1252?Q?bleLSBV2AModiqEekiqgnpO0rKviHxTl/4Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;6:F8UwJG3PIqQQNUyQ5ikRrLbVtmq6aF5nNhYOrOAX0jL15XcKkQj+IMPtuzIm5nUmQOjdvC9HUDHJd/q35iVRWCtrmXSXYNDgSjIn67+4m9Z+iZP0MYJ40nHwLc/ghQw/OiO/IYZxc0j2krxSQhoSMK48mIWZcKmlLAkArVwyrALOWDCTZBgpPDrX0xwC3Sj23w1vzxCbdgSeWiJjRV8pGwdNq5pdmXG2yUUIzqsOFSneOZtZzMkpPy5m+rGrVAvpLhuNPeAd38QRwtz8dXpPHebvkmtBghHUFyrK5155uxEbRnnzXNx+YSFrqz0J9AUIKZGO9Tkche9vOJEV3OgqvYPIjTZd6s7CCqzOsJcmoon96ELu39yVhw2q4DdzJ4tvKg/PuGcpLVcTwxQ1rQFgjg==;5:f5AkGm4RQLWLYAraLEtfksfz8AV7u5stMUqQDEEpuzXpMDcav5kl9R8nLlgsPDNW1wegn2jEXYANgInsJ6vsYUgYW+AeemylcO+y8DIsW9VgkgOX2BsNU0XnrP4Iun0FozK+zXCBSVKI8E1z6HHPI9dES85N3pJbPsd0fk3vy1g=;24:pV08wOaAffFocwleA25UA4iwy4WhFrQuSB5u9s9C8z1EXaZR6j4PJQTYLvnutRXZCpaWQLqBSgyZUe8Bxj1B18fMsHfXpMwRd1/WmgWqRhY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;7:+e2re3hBJmB987qqNb8o2hkkx6sDq2SApKmnm+VK1bAuQKCSnLjpy5yyvrTAMqkJBKTev0OkjGNrehQHhXTYi4UaiUEUXo/z1dcm9625BRVMQ5rO7Jx0Soo6FInkoXi0zz0YWk7Qs3vF2FuuPmFjKR03uH8yDfUZbV8DSNRp7lmgvgAZVwP6EuMIHIHXCmpjE5mWxMxQFy8yyms6SnjMGl2utHLbZWXR99Y3IgFLJblSu214HAtLwo3D/HPIZ3m6oKiorFVC3/knXZIzO3n8hMLbNiCHnywm7iqNP+LvOJeXZQC72/IoAu5dBmTv036de7ydCOLm+whB/IJ2EGw1aA==;20:GRpPZyFikKkgQd2so3tcX3aX9AqbY8SfCXOMTzkhudtR0OgvV2lWb9hTN9t/802xMfGWowlAyHjOCP9GamFymx8Bj91QeG+EdugZ3o9tn4txWPhC94xRRKl2r3c+d08vFLu6P9jesn7SXjlpGsY+BYLBIIjVUqQ/PeIX0wjxvjI= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2017 14:20:42.4029 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1737 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/13/2017 05:03 PM, Thomas Gleixner wrote: > On Mon, 13 Mar 2017, Dmitry Safonov wrote: >> On 03/13/2017 04:47 PM, Thomas Gleixner wrote: >>> On Mon, 13 Mar 2017, Dmitry Safonov wrote: >>>> On 03/13/2017 12:39 PM, Thomas Gleixner wrote: >>>>> On Mon, 6 Mar 2017, Dmitry Safonov wrote: >>>>> >>>>>> Result of mmap() calls with MAP_32BIT flag at this moment depends >>>>>> on thread flag TIF_ADDR32, which is set during exec() for 32-bit apps. >>>>>> It's broken as the behavior of mmap() shouldn't depend on exec-ed >>>>>> application's bitness. Instead, it should check the bitness of mmap() >>>>>> syscall. >>>>>> How it worked before: >>>>>> o for 32-bit compatible binaries it is completely ignored. Which was >>>>>> fine when there were one mmap_base, computed for 32-bit syscalls. >>>>>> After introducing mmap_compat_base 64-bit syscalls do use computed >>>>>> for 64-bit syscalls mmap_base, which means that we can allocate 64-bit >>>>>> address with 64-bit syscall in application launched from 32-bit >>>>>> compatible binary. And ignoring this flag is not expected behavior. >>>>> >>>>> Well, the real question here is, whether we should allow 32bit >>>>> applications >>>>> to obtain 64bit mappings at all. We can very well force 32bit >>>>> applications >>>>> into the 4GB address space as it was before your mmap base splitup and >>>>> be >>>>> done with it. >>>> >>>> Hmm, yes, we could restrict 32bit applications to 32bit mappings only. >>>> But the approach which I tried to follow in the patches set, it was do >>>> not base the logic on the bitness of launched applications >>>> (native/compat) - only base on bitness of the performing syscall. >>>> The idea was suggested by Andy and I made mmap() logic here independent >>>> from original application's bitness. >>>> >>>> It also seems to me simpler: >>>> if 32-bit application wants to allocate 64-bit mapping, it should >>>> long-jump with 64-bit segment descriptor and do `syscall` instruction >>>> for 64-bit syscall entry path. So, in my point of view after this dance >>>> the application does not differ much from native 64-bit binary and can >>>> have 64-bit address mapping. >>> >>> Works for me, but it lacks documentation ..... >> >> Sure, could you recommend a better place for it? >> Should it be in-code comment in x86 mmap() code or Documentation/* >> change or a patch to man-pages? > > I added a comment in the code and fixed up the changelogs. man-page needs > some care as well. Big thanks, Thomas! I'll make a patch for man-pages on the week. > > Thanks, > > tglx > -- Dmitry From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f70.google.com (mail-it0-f70.google.com [209.85.214.70]) by kanga.kvack.org (Postfix) with ESMTP id 652846B0388 for ; Mon, 13 Mar 2017 10:20:47 -0400 (EDT) Received: by mail-it0-f70.google.com with SMTP id m27so47418698iti.7 for ; Mon, 13 Mar 2017 07:20:47 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40133.outbound.protection.outlook.com. [40.107.4.133]) by mx.google.com with ESMTPS id u131si7473731itf.72.2017.03.13.07.20.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Mar 2017 07:20:46 -0700 (PDT) Subject: Re: [PATCHv6 4/5] x86/mm: check in_compat_syscall() instead TIF_ADDR32 for mmap(MAP_32BIT) References: <20170306141721.9188-1-dsafonov@virtuozzo.com> <20170306141721.9188-5-dsafonov@virtuozzo.com> <35a16a2c-c799-fe0c-2689-bf105b508663@virtuozzo.com> <4f802f8b-07a6-f8cd-71fc-943e40714d1b@virtuozzo.com> From: Dmitry Safonov Message-ID: <2a7e5737-2f5a-02c7-bf74-9371190a0370@virtuozzo.com> Date: Mon, 13 Mar 2017 17:17:00 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, 0x7f454c46@gmail.com, Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , Borislav Petkov , x86@kernel.org, linux-mm@kvack.org, Cyrill Gorcunov , "Kirill A. Shutemov" , Michael Kerrisk On 03/13/2017 05:03 PM, Thomas Gleixner wrote: > On Mon, 13 Mar 2017, Dmitry Safonov wrote: >> On 03/13/2017 04:47 PM, Thomas Gleixner wrote: >>> On Mon, 13 Mar 2017, Dmitry Safonov wrote: >>>> On 03/13/2017 12:39 PM, Thomas Gleixner wrote: >>>>> On Mon, 6 Mar 2017, Dmitry Safonov wrote: >>>>> >>>>>> Result of mmap() calls with MAP_32BIT flag at this moment depends >>>>>> on thread flag TIF_ADDR32, which is set during exec() for 32-bit apps. >>>>>> It's broken as the behavior of mmap() shouldn't depend on exec-ed >>>>>> application's bitness. Instead, it should check the bitness of mmap() >>>>>> syscall. >>>>>> How it worked before: >>>>>> o for 32-bit compatible binaries it is completely ignored. Which was >>>>>> fine when there were one mmap_base, computed for 32-bit syscalls. >>>>>> After introducing mmap_compat_base 64-bit syscalls do use computed >>>>>> for 64-bit syscalls mmap_base, which means that we can allocate 64-bit >>>>>> address with 64-bit syscall in application launched from 32-bit >>>>>> compatible binary. And ignoring this flag is not expected behavior. >>>>> >>>>> Well, the real question here is, whether we should allow 32bit >>>>> applications >>>>> to obtain 64bit mappings at all. We can very well force 32bit >>>>> applications >>>>> into the 4GB address space as it was before your mmap base splitup and >>>>> be >>>>> done with it. >>>> >>>> Hmm, yes, we could restrict 32bit applications to 32bit mappings only. >>>> But the approach which I tried to follow in the patches set, it was do >>>> not base the logic on the bitness of launched applications >>>> (native/compat) - only base on bitness of the performing syscall. >>>> The idea was suggested by Andy and I made mmap() logic here independent >>>> from original application's bitness. >>>> >>>> It also seems to me simpler: >>>> if 32-bit application wants to allocate 64-bit mapping, it should >>>> long-jump with 64-bit segment descriptor and do `syscall` instruction >>>> for 64-bit syscall entry path. So, in my point of view after this dance >>>> the application does not differ much from native 64-bit binary and can >>>> have 64-bit address mapping. >>> >>> Works for me, but it lacks documentation ..... >> >> Sure, could you recommend a better place for it? >> Should it be in-code comment in x86 mmap() code or Documentation/* >> change or a patch to man-pages? > > I added a comment in the code and fixed up the changelogs. man-page needs > some care as well. Big thanks, Thomas! I'll make a patch for man-pages on the week. > > Thanks, > > tglx > -- Dmitry -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org