From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 010C0C433EF for ; Fri, 15 Apr 2022 02:14:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89DDD6B008A; Thu, 14 Apr 2022 22:14:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 84DD26B008C; Thu, 14 Apr 2022 22:14:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C8BF6B0092; Thu, 14 Apr 2022 22:14:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 5BD866B008A for ; Thu, 14 Apr 2022 22:14:55 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1AE8D27C1B for ; Fri, 15 Apr 2022 02:14:55 +0000 (UTC) X-FDA: 79357495350.20.4C323F8 Received: from esa5.hgst.iphmx.com (esa5.hgst.iphmx.com [216.71.153.144]) by imf24.hostedemail.com (Postfix) with ESMTP id 2F5D2180005 for ; Fri, 15 Apr 2022 02:14:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1649988892; x=1681524892; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=WhFCPjpcY73NOr+2vy/xILbKOpm8U3lMJb79Q6mDq7Q=; b=Rk5yBGaZordH3cqw2on/lA05Lgy2gegWKmIptCkIz2ZR8EYUAJC4KWsV 3f4vszrj3lFdxh6+nKuPaaj/lQF3hUJojiT6bS4VTXcBLoYoriALlQBtR HrzAYy78HzoBVAtXIYmmZpryDvNT9Ic++croUSjquaMJXlLBvLnEB0pAv SXKBuJaccSXOuMdGoDRQolZgp5EnoxxBZ2DEaPBBVYHT4uIHjbhOlx6YW oBZsXTB0x4UTpSQtELcsJyjRFlg+GPhiOtu9k81sdpXujTtF7Pkzg9kG+ NAl4oEEY1n7qsDlxBPr/bh0W0Qh1c+oIHXSSqDoC/z6L0tnD02e859riv A==; X-IronPort-AV: E=Sophos;i="5.90,261,1643644800"; d="scan'208";a="197962190" Received: from h199-255-45-15.hgst.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 15 Apr 2022 10:14:51 +0800 IronPort-SDR: Lm+QCQ5nDyt1bJvyOVKrRlD32JkOxiesz6wLe1IzGfkyvYqj3uvnObd53eokZIP0pOM4owPaLZ qMyNw2Ur+pRnXETnsgyl1r03g7F7QEiq47RGqUmgMuwow9mat3fxD3P9QdieDeA09AvKU3Mkf5 jDvSBbKZ3d2reNmy2HXJY29JvH8c/puUGG0JWlqde1IJgmCmmxqeCwDarmoBJKIr/IujMxtB2w WeouYMez6v2XmlqB/TK4ipBjC7+AkWW8p5jMF9jujj9sJiVts8gP0urlzqefpgzZiFNIR5RDzI zRhvPmHiulbvKK7FUnuQntBR Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 14 Apr 2022 18:45:16 -0700 IronPort-SDR: jltVxy9hRZzJF9GyKb7+VIZViYB/SL4v114k+jKBaT1R0Qn2GSp2bu3+78pH8LRC+YMQFBAMNn wEpWHWjSuwImj7PTvDA+OHPRbCfJt5kfZQrlKqu9A4aqEGGLYL59FN8wEFXM0W9A3eo7TfcSg/ oxgfxmLJfH8mxU3OLjDvJYzG/pmZZDTHkQO4GGJ1c5OhdAnPuK/oiFECs745Fb5k0IeKOzhpSq 4cjJZGPxD1HKHJiy1MGg/c4G9BCNtYrAmJv57F0tYqq/ks7+P7W3cSTSRU2oR2vCjXH/TLsBsz vlQ= WDCIronportException: Internal Received: from usg-ed-osssrv.wdc.com ([10.3.10.180]) by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 14 Apr 2022 19:14:53 -0700 Received: from usg-ed-osssrv.wdc.com (usg-ed-osssrv.wdc.com [127.0.0.1]) by usg-ed-osssrv.wdc.com (Postfix) with ESMTP id 4Kffzb3KgZz1SHwl for ; Thu, 14 Apr 2022 19:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= opensource.wdc.com; h=content-transfer-encoding:content-type :in-reply-to:organization:from:references:to:content-language :subject:user-agent:mime-version:date:message-id; s=dkim; t= 1649988890; x=1652580891; bh=WhFCPjpcY73NOr+2vy/xILbKOpm8U3lMJb7 9Q6mDq7Q=; b=Je/KTCSORMEIBsQ9wzBGLn5Wo3UMd7sE2lFIN5Rq985Iji1IXPo iCJAyaGCoha060/PbFVDMlRHJdhkSml8b/ir9aQH0DW7YizZa4FJ8QHNCOYppqNh jQlNFP3Xr0a0A/TeSI4Ho9yv9ik71juA9gPCZuqPfgjxiQk1HuRcSJHExbup/3rQ vUvoOoSHzb37h6QKTl1KAxr5rWJR97jWSIwd3cllkfiVUVboU+58h0RwM9e4gH2Y PZ5Ft3VsQheRqzXZAu0A8Ri+FeNfH1qm5fjisfcTFrSmit2G6RwzCUgXvyBEzhoB HCjDVfmcMu9bKJ8hWcwmN7thSnoedePTA9g== X-Virus-Scanned: amavisd-new at usg-ed-osssrv.wdc.com Received: from usg-ed-osssrv.wdc.com ([127.0.0.1]) by usg-ed-osssrv.wdc.com (usg-ed-osssrv.wdc.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iQ8d1Om5--Pf for ; Thu, 14 Apr 2022 19:14:50 -0700 (PDT) Received: from [10.225.163.9] (unknown [10.225.163.9]) by usg-ed-osssrv.wdc.com (Postfix) with ESMTPSA id 4KffzX2zWTz1Rvlx; Thu, 14 Apr 2022 19:14:48 -0700 (PDT) Message-ID: <1ad275e2-8c7b-4b13-06f2-e2be13155185@opensource.wdc.com> Date: Fri, 15 Apr 2022 11:14:47 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v2] binfmt_flat: do not stop relocating GOT entries prematurely on riscv Content-Language: en-US To: Niklas Cassel Cc: Alexander Viro , Eric Biederman , Kees Cook , Paul Walmsley , Palmer Dabbelt , Albert Ou , Greg Ungerer , Mike Frysinger , "stable@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-riscv@lists.infradead.org" References: <20220414091018.896737-1-niklas.cassel@wdc.com> <6ee62ced-7a49-be56-442d-ba012782b8e2@opensource.wdc.com> <9a9a4dcf-0ea1-01ac-d599-16c10b547beb@opensource.wdc.com> From: Damien Le Moal Organization: Western Digital Research In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 2F5D2180005 X-Stat-Signature: yuryz3kihrtap4kyh37gwuzr3mhxjc6s Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=wdc.com header.s=dkim.wdc.com header.b=Rk5yBGaZ; dkim=pass header.d=opensource.wdc.com header.s=dkim header.b="Je/KTCSO"; spf=pass (imf24.hostedemail.com: domain of "prvs=0972008b0=damien.lemoal@opensource.wdc.com" designates 216.71.153.144 as permitted sender) smtp.mailfrom="prvs=0972008b0=damien.lemoal@opensource.wdc.com"; dmarc=pass (policy=quarantine) header.from=opensource.wdc.com X-Rspamd-Server: rspam01 X-HE-Tag: 1649988892-960182 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000010, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 4/15/22 11:11, Niklas Cassel wrote: > On Fri, Apr 15, 2022 at 10:13:31AM +0900, Damien Le Moal wrote: >> On 4/15/22 10:08, Niklas Cassel wrote: >>> On Fri, Apr 15, 2022 at 09:56:38AM +0900, Damien Le Moal wrote: >>>> On 4/15/22 09:30, Niklas Cassel wrote: >>>>> On Fri, Apr 15, 2022 at 08:51:27AM +0900, Damien Le Moal wrote: >>>>>> On 4/14/22 18:10, Niklas Cassel wrote: >>> >>> (snip) >>> >>>> So if we are sure that we can just skip the first 16B/8B for riscv, I >>>> would not bother checking the header content. But as mentioned, the >>>> current code is fine too. >>> >>> That was my point, I'm not sure that we can be sure that we can always >>> skip it in the future. E.g. if the elf2flt linker script decides to swap >>> the order of .got and .got.plt for some random reason in the future, >>> we would skip data that really should have been relocated. >> >> Good point. Your current patch is indeed better then. BUT that would also >> mean that the skip header function needs to be called inside the loop >> then, no ? If the section orders are reversed, we would still need to skip >> that header in the middle of the relocation loop... > > So this is theoretical, but if the sections were swapped in the linker > script, and we have the patch in $subject applied, we will not skip data > that needs to be relocated. But after relocating all the entries in the > .got section we will still break too early, if we actually had any > .got.plt entries after the .got.plt header. The .got.plt entries would > not get relocated. > > However, the elf2flt maintainer explicitly asked ut to fix the kernel or > binutils, so that they can continue using the exact same linker script > that it has been using forever. (And we shouldn't need to change binutils > just for the bFLT format.) > > So the chance that the linker script changes in practice is really small. > (This .got.plt vs .got hasn't changed in 19 years.) > > But if it does, we will just have one problem instead of two :) > However, I think that applying this patch is sufficient for now, > since it makes the code work with the existing elf2flt linker script. > > Adapting the code to also handle this theoretical layout of the linker > script would just complicate things even more. I'm not even sure if we > would be able to handle this case, since the information about the .got > and .got.plt section sizes is lost once the ELF has been converted to > bFLT. OK. All good then. I maintain my reviewed-by tag :) -- Damien Le Moal Western Digital Research