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;
Date:   Mon, 23 Mar 2020 11:58:04 +0000
From:   Mark Rutland <mark.rutland@arm.com>
To:     Catalin Marinas <catalin.marinas@arm.com>
Cc:     =?utf-8?B?UsOpbWk=?= Denis-Courmont <remi@remlab.net>,
        will@kernel.org, linux-arm-kernel@lists.infradead.org,
        james.morse@arm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] arm64: reduce trampoline data alignment
Message-ID: <20200323115804.GA2597@C02TD0UTHF1T.local>
References: <1938400.7m7sAWtiY1@basile.remlab.net>
 <20200319091407.51449-3-remi@remlab.net>
 <20200321134056.GB3052@mbp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200321134056.GB3052@mbp>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Mar 21, 2020 at 01:41:01PM +0000, Catalin Marinas wrote:
> On Thu, Mar 19, 2020 at 11:14:07AM +0200, Rémi Denis-Courmont wrote:
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index c36733d8cd75..ecad15443655 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -858,7 +858,7 @@ SYM_CODE_END(tramp_exit_compat)
> >  	.popsection				// .entry.tramp.text
> >  #ifdef CONFIG_RANDOMIZE_BASE
> >  	.pushsection ".rodata", "a"
> > -	.align PAGE_SHIFT
> > +	.align	4	// all .rodata must be in a single fixmap page
> >  SYM_DATA_START(__entry_tramp_data_start)
> >  	.quad	vectors
> >  SYM_DATA_END(__entry_tramp_data_start)
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 9b08f7c7e6f0..6a0e75f48e7b 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -599,9 +599,8 @@ static int __init map_entry_trampoline(void)
> >  	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> >  		extern char __entry_tramp_data_start[];
> >  
> > -		__set_fixmap(FIX_ENTRY_TRAMP_DATA,
> > -			     __pa_symbol(__entry_tramp_data_start),
> > -			     PAGE_KERNEL_RO);
> > +		pa_start = __pa_symbol(__entry_tramp_data_start) & PAGE_MASK;
> > +		__set_fixmap(FIX_ENTRY_TRAMP_DATA, pa_start, PAGE_KERNEL_RO);
> >  	}
> >  
> >  	return 0;
> 
> For some reason, I haven't investigated yet, a kernel with KASAN and 64K
> pages enabled does not boot (see the attached config). It seems to lock
> up when starting user space. Bisected to this commit, reverting it fixes
> the issue.

I think the issue might be due to ADRP + ADD :lo12: using 4K offsets,
and so patch 1 isn't quite right for !4K kernels, as we're not
accounting for 4 bits of the address when we try to generate it.

I'll check that now.

Thanks,
Mark.