Received: by 10.213.65.68 with SMTP id h4csp693358imn; Tue, 13 Mar 2018 18:35:43 -0700 (PDT) X-Google-Smtp-Source: AG47ELt5dEIHQHDv3kWVNlfONSvgXkGFJgWIB5Ef1aI2zHRkckbWBX6ebil8y67ErqTUfw6QnRKf X-Received: by 10.98.37.132 with SMTP id l126mr2586743pfl.102.1520991343893; Tue, 13 Mar 2018 18:35:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520991343; cv=none; d=google.com; s=arc-20160816; b=EFuHbGkIk8Ldgmm7xW/pxJM1HNst2ehfhcrQNH0eOFS5/52q7TqEZJT4FGFTwHsIfm lAIhOSK66IwOyti3XcdfrbBGIt8r9tdLJfYa/uBNpNpEC1s3ZMI0Z56V6GGGy0T2mRc0 huVqzeF49UROY+U7DTJOjs5caL9/9U895Kary3k58tB+wEiAHoFl2sHsuUBBgsifhIMZ bxy8jyBgjyy8La/TxPQ108cPkXZ9pm3V1ok9O1FwKlK6I+mtMs2HSlo/UEcbO65JEkR8 UBrLQZdn7Htso1XyfemAi2hNCfNefKaIwtyqHhKA7DunX38eFYqYu8bJnuWG5KXyhMup CPsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=tWfOtaCgG5WjDjZte8o4gYk8Hcyp1oAxQGw1ZFuStZE=; b=Q8bwhNI7pD1Wsv3liT3CjNHEFkHxCYEOhFPuCgD9ugf/T3srRg6RTMoCWbGXr4p6+G 0kv8LOZxf7441/mU0b7jemGq3gIMZrOIqLQFCIgQfz+ZUQV0AQo9dZ8TTvfhxYm+0xjz uIoPJAEIhW4U0GBb3Z0upSQ6X2TaNS9ULfdwsNKmS59dMf94PwhbV9alOI0Arynkv8tf u5dMcqsLauYZplQq052xXBkZilsr0T+bdIAFGny/maXmIgpaqPT7IbQ96iaEQX++Ll3r E91IcNbYVHHDV59g0NqwIkfJBedLsj2CBnG6TUna3Fo2mzMnB/3Kk0lSV/fk2t0J+JuL 9ffg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mtSvDK3w; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i3-v6si1069647pli.274.2018.03.13.18.35.29; Tue, 13 Mar 2018 18:35:43 -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=@gmail.com header.s=20161025 header.b=mtSvDK3w; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933181AbeCNBeW (ORCPT + 99 others); Tue, 13 Mar 2018 21:34:22 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:35210 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932732AbeCNBeU (ORCPT ); Tue, 13 Mar 2018 21:34:20 -0400 Received: by mail-io0-f196.google.com with SMTP id k21so2420493ioc.2 for ; Tue, 13 Mar 2018 18:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tWfOtaCgG5WjDjZte8o4gYk8Hcyp1oAxQGw1ZFuStZE=; b=mtSvDK3wQippUQFP8bw3wc1J1oAHd8hUj0n4e1n3fkMWB8H+RzjqgDenMRPX7tMSMK tf4UA2/cSkSU7xIyzF/x8FODOpuBzfkqAN9TT6ZzNPsN2eaX8YKaPYLQV7BODIgap/+q 0/PLi7RcgDzOZ6jNAL1pH8vFlWtJ58vP4H9QyR0wahgsLZ2kLUSWQcRbvN9E7cybQ6qG MsgI8F7uvv5R4VazSCf3bUXKk5/PTYpffblLekZOkAzobhI+4MvcN4TO8qVhbueYURMY sOoJJ4nelZHhwekXbZ5S5cflq7R5RxNsUNfEudrW0qqoV9S8roQKnV+mE/YyoH5oGY6L YfYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tWfOtaCgG5WjDjZte8o4gYk8Hcyp1oAxQGw1ZFuStZE=; b=DL0lO5lB43TEwvey/YnoMd5mtCBQI9s/SC6HTXPsjGkAkdbVttRoenZqzmKUAORsXj a60JF8CsVcWrztu+pLWUsIixypoNlGTH3KfCI9ZkrCAbTEjE9iAwJtWetB5rikzZahVT /7DQyxKAZfb+TaH/n0VwzeOci/3c45SSc8sb7BIT/XXFoVj7ErBII2Zn4PRyueha1Tae cGCS3/8NFboh4HafYPwGD0rPhGBjV/Haj7jXfQLVrv8WXgKWP9U3+KmXpeRyucpzKn44 /zmZ5RDxJDszRWK0RBTIdFW52wlM/kKhGXzWZ6nmylIp5l+xfq/ZEq7sW7K6MuW0SxQx xisw== X-Gm-Message-State: AElRT7FepKp7sWzx2SLfM693shqVHeml4olxn4BcjB4tft36e+k/px74 R8eONHKKibPz0pZ/dK2NUUwDFWX4OUCKOV5jMXA= X-Received: by 10.107.22.132 with SMTP id 126mr2978716iow.63.1520991260032; Tue, 13 Mar 2018 18:34:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.180.55 with HTTP; Tue, 13 Mar 2018 18:34:19 -0700 (PDT) In-Reply-To: <87sh93zmr6.fsf@xps13.shealevy.com> References: <87sh93zmr6.fsf@xps13.shealevy.com> From: Zong Li Date: Wed, 14 Mar 2018 09:34:19 +0800 Message-ID: Subject: Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit To: Shea Levy Cc: Palmer Dabbelt , Zong Li , albert@sifive.com, linux-riscv@lists.infradead.org, Linux Kernel Mailing List , greentime@andestech.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-03-14 5:30 GMT+08:00 Shea Levy : > Hi Palmer, > > Palmer Dabbelt writes: > >> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote: >>> These patches resolve the some issues of loadable module. >>> - symbol out of ranges >>> - unknown relocation types >>> >>> The reference of external variable and function symbols >>> cannot exceed 32-bit offset ranges in kernel module. >>> The module only can work on the 32-bit OS or the 64-bit >>> OS with sv32 virtual addressing. >>> >>> These patches will generate the .got, .got.plt and >>> .plt sections during loading module, let it can refer >>> to the symbol which locate more than 32-bit offset. >>> These sections depend on the relocation types: >>> - R_RISCV_GOT_HI20 >>> - R_RISCV_CALL_PLT >>> >>> These patches also support more relocation types >>> - R_RISCV_CALL >>> - R_RISCV_HI20 >>> - R_RISCV_LO12_I >>> - R_RISCV_LO12_S >>> - R_RISCV_RVC_BRANCH >>> - R_RISCV_RVC_JUMP >>> - R_RISCV_ALIGN >>> - R_RISCV_ADD32 >>> - R_RISCV_SUB32 >>> >>> Zong Li (11): >>> RISC-V: Add sections of PLT and GOT for kernel module >>> RISC-V: Add section of GOT.PLT for kernel module >>> RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module >>> RISC-V: Support CALL relocation type in kernel module >>> RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module >>> RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq >>> RISC-V: Support ALIGN relocation type in kernel module >>> RISC-V: Support ADD32 relocation type in kernel module >>> RISC-V: Support SUB32 relocation type in kernel module >>> RISC-V: Enable module support in defconfig >>> RISC-V: Add definition of relocation types >>> >>> arch/riscv/Kconfig | 5 ++ >>> arch/riscv/Makefile | 3 + >>> arch/riscv/configs/defconfig | 2 + >>> arch/riscv/include/asm/module.h | 112 +++++++++++++++++++++++ >>> arch/riscv/include/uapi/asm/elf.h | 24 +++++ >>> arch/riscv/kernel/Makefile | 1 + >>> arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++ >>> arch/riscv/kernel/module.c | 175 ++++++++++++++++++++++++++++++++++-- >>> arch/riscv/kernel/module.lds | 8 ++ >>> 9 files changed, 480 insertions(+), 6 deletions(-) >>> create mode 100644 arch/riscv/include/asm/module.h >>> create mode 100644 arch/riscv/kernel/module-sections.c >>> create mode 100644 arch/riscv/kernel/module.lds >> >> This is the second set of patches that turn on modules, and it has the same >> R_RISCV_ALIGN problem as the other one >> >> http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html >> >> It looks like this one uses shared libraries for modules instead of static >> objects. I think using shared objects is the right thing to do, as it'll allow >> us to place modules anywhere in the address space by having multiple GOTs and >> PLTs. > > Can you expand on this? It was my understanding that outside of the > context of multiple address spaces sharing code the GOT and PLT were > simply unnecessary overhead, what benefit would they bring here? > >> That's kind of complicated, though, so we can start with something >> simpler like this. Hi, The kernel module is a object file, it is not be linked by linker, the GOT and PLT sections will not be generated through -fPIC option, but it will generate the relative relocation type. As Palmer mention before, If we have GOT and PLT sections, we can put the module anywhere, even we support the KASLR in the kernel. For the ALIGN problem, the kernel module loader is difficult to remove or migrate the module's code like relax doing, so the remnant nop instructions harm the performance, I agree the point that adding the mno-relax option and checking the alignment in ALIGN type in module loader. >> That's kind of complicated, though, so we can start with something >> simpler like this. So what is the suggestion for that. Thanks a lot.