Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Jiaxun Yang <jiaxun.yang@flygoat.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: linux-mips@vger.kernel.org, clang-built-linux@googlegroups.com,
	Fangrui Song <maskray@google.com>,
	Kees Cook <keescook@chromium.org>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Paul Burton <paulburton@kernel.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Jouni Hogander <jouni.hogander@unikie.com>,
	Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>,
	Borislav Petkov <bp@suse.de>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5] MIPS: Truncate link address into 32bit for 32bit kernel
Date: Thu, 23 Apr 2020 13:42:52 +0800	[thread overview]
Message-ID: <B307BFAC-9973-4444-B69A-40B054210E84@flygoat.com> (raw)
In-Reply-To: <alpine.LFD.2.21.2004230036480.851719@eddie.linux-mips.org>



于 2020年4月23日 GMT+08:00 上午8:10:12, "Maciej W. Rozycki" <macro@linux-mips.org> 写到:
>On Wed, 22 Apr 2020, Jiaxun Yang wrote:
>
>> Reviewed-by: Maciej W. Rozycki <macro@linux-mips.org>
>
> Hmm, that was for an earlier version of the patch, and reviews obviously 
>do not automatically carry over to subsequent versions, as it cannot be 
>claimed that they are as good in the reviewer's eyes as the actual version 
>reviewed was.
>
>> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
>> index e1c44aed8156..68c0f22fefc0 100644
>> --- a/arch/mips/Makefile
>> +++ b/arch/mips/Makefile
>> @@ -288,12 +288,23 @@ ifdef CONFIG_64BIT
>>    endif
>>  endif
>>  
>> +# When linking a 32-bit executable the LLVM linker cannot cope with a
>> +# 32-bit load address that has been sign-extended to 64 bits.  Simply
>> +# remove the upper 32 bits then, as it is safe to do so with other
>> +# linkers.
>> +ifdef CONFIG_64BIT
>> +	load-ld			= $(load-y)
>> +else
>> +	load-ld			= $(subst 0xffffffff,0x,$(load-y))
>> +endif
>> +
>>  KBUILD_AFLAGS	+= $(cflags-y)
>>  KBUILD_CFLAGS	+= $(cflags-y)
>> -KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y)
>> +KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y) -DVMLINUX_LINK_ADDRESS=$(load-ld)
>>  KBUILD_CPPFLAGS += -DDATAOFFSET=$(if $(dataoffset-y),$(dataoffset-y),0)
>>  
>>  bootvars-y	= VMLINUX_LOAD_ADDRESS=$(load-y) \
>> +		  VMLINUX_LINK_ADDRESS=$(load-ld) \
>>  		  VMLINUX_ENTRY_ADDRESS=$(entry-y) \
>>  		  PLATFORM="$(platform-y)" \
>>  		  ITS_INPUTS="$(its-y)"
>
> Hmm, to be honest I find the nomenclature confusing: VMLINUX_LOAD_ADDRESS 
>and VMLINUX_LINK_ADDRESS sound like synonyms to me and also look very 
>similar, so I expect people will be confused and scratch their heads in 
>the future.  Due to the obscurity of the problem I think there is little 
>room for manoeuvre here really, but how about using LINKER_LOAD_ADDRESS 
>for the new variable?
>
> Alternatively, have you made any attempt to verify if actually replacing 
>the setting for VMLINUX_LOAD_ADDRESS would be safe?  Glancing over its use 
>there do not appear to be many places.

Limited experiments showed it should be fine...

But MIPS kernel has some design I'm not really familiar with like SYM32 for
64-bit kernel and special address space design for Trap-and-emul KVM.

I'm not 100 sure it's safe so I didn't do so.

>
>  Maciej

-- 
Jiaxun Yang

  reply	other threads:[~2020-04-23  5:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13  6:26 [PATCH v4] MIPS: Truncate link address into 32bit for 32bit kernel Jiaxun Yang
2020-04-13  6:59 ` Maciej W. Rozycki
2020-04-13  7:32   ` Jiaxun Yang
2020-04-13 15:34     ` Fangrui Song
2020-04-13 20:08       ` Maciej W. Rozycki
2020-04-13 20:06     ` Maciej W. Rozycki
2020-04-13 16:25 ` Kees Cook
2020-04-13 18:52 ` Nathan Chancellor
2020-04-22 14:32 ` [PATCH v5] " Jiaxun Yang
2020-04-22 22:16   ` Nathan Chancellor
2020-04-23  0:10   ` Maciej W. Rozycki
2020-04-23  5:42     ` Jiaxun Yang [this message]
2020-04-24 12:22       ` Maciej W. Rozycki
2020-05-04 15:46         ` Thomas Bogendoerfer
2020-05-04 16:09           ` Jiaxun Yang
2020-05-04 16:56             ` Thomas Bogendoerfer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B307BFAC-9973-4444-B69A-40B054210E84@flygoat.com \
    --to=jiaxun.yang@flygoat.com \
    --cc=bp@suse.de \
    --cc=clang-built-linux@googlegroups.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jouni.hogander@unikie.com \
    --cc=keescook@chromium.org \
    --cc=ldir@darbyshire-bryant.me.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=masahiroy@kernel.org \
    --cc=maskray@google.com \
    --cc=natechancellor@gmail.com \
    --cc=paulburton@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox