Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1069191imm; Thu, 31 May 2018 14:47:07 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKilfiwr4rB65oP+AbeR/HCygqMiwHsKd2qZ5mE8RadzUB25KsrwpWSRdvZCwd3yoszhttj X-Received: by 2002:a17:902:9a4b:: with SMTP id x11-v6mr8647700plv.176.1527803227900; Thu, 31 May 2018 14:47:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527803227; cv=none; d=google.com; s=arc-20160816; b=yoytmP5RJjVt3ZZUx+OjsgdZC8gLr6naOnVHL4YoGe3QzoHnRVvA3So5ej1ooiqNYj 45v5m2YibKv9ehU27SkwP9Ok5JI2mlRG30lH9LSk+5hyvDo2vwXj7lgRrP++60himzWE yKL1sb1tcki0pX+n4nocVncPEinAVaViifUPEJnAqtmDexj2MLitFiWXUGD81pwhiF5b OTTikpKCuFojDkEOG3X17pfLXkoBlDZubBV4uk1loAMaOzDN1muefErk3z6krEaXdPL2 ztmNw9PhLjMdagkgywfUeeJWBZOtAlQ9BuQloRid+DrcWfLOh5dBbP0cbjkivVjV7aDH GteQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=ylQbn+kTcsvbI9Acu3YwAKdfb+pxBkA6MoWhmJtipeY=; b=wihEFcYtQne9NvnUVvjaSscRhDIsecw7s5zTLiV6KmTSnZYyOmI04wLedTJ6tOkQA8 mYtc5CamNr2lz6JyAYdlJIkrc3yR8AmXixGgvsr6zKJPI6QWNqoHQyPhrqocXiJ5RnX+ YK9KBmBGz9kmv3nUZXSkkT4uJjuqv7eTa38AWILOJCakshgeurEWwZe58ov/SQ7MwFeO 8p36M/eb8/UHN9IxS/w8O1Lw/H27XxCbrxKxZRR33xEq7skVvjuWsBFo6EFBiKNlfY0V LBZnGKUAUVQyXajoctbBZ7wbGPSwbPbYS6HnD66LzBxx3QdF/pyUWHNLRZDphIoKdcHJ o0NA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=oEF3gtgl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l1-v6si5302754plt.389.2018.05.31.14.46.53; Thu, 31 May 2018 14:47:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=oEF3gtgl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750868AbeEaVqY (ORCPT + 99 others); Thu, 31 May 2018 17:46:24 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:34044 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750715AbeEaVqX (ORCPT ); Thu, 31 May 2018 17:46:23 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4VLkHos156485; Thu, 31 May 2018 21:46:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=ylQbn+kTcsvbI9Acu3YwAKdfb+pxBkA6MoWhmJtipeY=; b=oEF3gtglw7iVkICnIzwZ6gTDiomKTA34V0hHhbKXy0SdmDmyWTbOFmJrxsaPSPOWYrH6 TvS+ufSEnRZYyu+7on+F1q0oEGfqBUpprTk0PuVufaktchjNKkwzmclpy/4Xt2mBRMkm OWD+LemCotteRGucjgDpgVSeonnhsnn7GBzJ5PRecTjr806brH3xceMLgJ6FDkTD3Mh4 YYsasOk96EbR+ycYwDDzMJANlCQLJrrK/KCMxoM/j5BIr3soTjrr4IDF0GIgCtETbulL Hjby2okt50o1TW+2dF1HumqryGCcIECWwgjn7l5CF61kOSeadMk3S+pQ+i3CvmlbSzYp Kg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2janje0ytp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 31 May 2018 21:46:17 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w4VLkG2f030325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 31 May 2018 21:46:16 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w4VLkG8Z014843; Thu, 31 May 2018 21:46:16 GMT Received: from [192.168.1.164] (/50.38.38.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 31 May 2018 14:46:16 -0700 Subject: Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map To: Michal Hocko Cc: Andrew Morton , linux-mm@kvack.org, LKML , libhugetlbfs@googlegroups.com References: <20171129144219.22867-1-mhocko@kernel.org> <20171129144219.22867-3-mhocko@kernel.org> <93ce964b-e352-1905-c2b6-deedf2ea06f8@oracle.com> <20180530080212.GA27180@dhcp22.suse.cz> <20180530162501.GB15278@dhcp22.suse.cz> <1f6be96b-12ac-9a03-df90-386dab02369d@oracle.com> <20180531092425.GM15278@dhcp22.suse.cz> From: Mike Kravetz Message-ID: <29bd73d1-ceed-0e4d-324a-b9ae87c4da4e@oracle.com> Date: Thu, 31 May 2018 14:46:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180531092425.GM15278@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8910 signatures=668702 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805310240 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/31/2018 02:24 AM, Michal Hocko wrote: > I am not an expert on the load linkers myself so I cannot really answer > this question. Please note that ppc had something similar. See > ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments"). > Maybe we need to sprinkle more of those at other places? I finally understand the issue, and it is NOT a problem with the kernel. The issue is with old libhugetlbfs provided linker scripts, and yes, starting with v4.17 people who run libhugetlbfs tests on x86 (at least) will see additional failures. I'll try to work this from the libhugetlbfs side. In the unlikely event that anyone knows about those linker scripts, assistance and/or feedback would be appreciated. Read on only if you want additional details about this failure. The executable files which are now failing are created with the elf_i386.xB linker script. This script is provided for pre-2.17 versions of binutils. binutils-2.17 came out aprox in 2007, and this script is disabled by default if binutils-2.17 or later is used. The only way to create executables with this script today is by setting the HUGETLB_DEPRECATED_LINK env variable. This is what libhugetlbfs tests do to simply continue testing the old scripts. I previously was mistaken about which tests were causing the additional failures. The example I previously provided failed on v4.16 as well as v4.17-rc kernels. So, please ignore that information. For an executable that runs on v4.16 and fails on v4.17-rc, here is a listing of elf sections that the kernel will attempt to load. Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x08048000 0x08048000 0x11c24 0x11c24 R E 0x1000 LOAD 0x011c24 0x08059c24 0x08059c24 0x10d04 0x10d04 RW 0x1000 LOAD 0x023000 0x09000000 0x09000000 0x00000 0x10048 RWE 0x1000 The first section is loaded without issue. elf_map() will create a vma based on the following: map_addr ELF_PAGESTART(addr) 8048000 ELF_PAGEALIGN(size) 12000 File_offset 0 We then attempt to load the following section with: map_addr ELF_PAGESTART(addr) 8059000 ELF_PAGEALIGN(size) 12000 File_offset 11000 This results in, Uhuuh, elf segment at 8059000 requested but the memory is mapped already Note that the last page of the first section overlaps with the first page of the second section. Unlike the case in ad55eac74f20, the access permissions on section 1 (RE) are different than section 2 (RW). If we allowed the previous MAP_FIXED behavior, we would be changing part of a read only section to read write. This is exactly what MAP_FIXED_NOREPLACE was designed to prevent. -- Mike Kravetz