Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp182589pxb; Thu, 27 Jan 2022 18:37:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJyxiBH5txZ1phihw9OUN43/grh9TIeXnihP76C2vRl/Zs0BvB6n8Pxc2rQeCCTiemxPuFV+ X-Received: by 2002:a17:907:1b0b:: with SMTP id mp11mr5211470ejc.499.1643337452795; Thu, 27 Jan 2022 18:37:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643337452; cv=none; d=google.com; s=arc-20160816; b=ZW+bc7/spcipMQqQIPoiHgNjVOUHC2kztljxmL1zlnK46kRV8yOuUnDXmTTlPC0N9f 5YQlDtPe9iR8x1Ws2wGD7HdoaDfskAsBbakj/L4DcY1HUL84HUAWFLYvur9aHjjWiNFO 12ZXP8jNCFmhogjOx2g4SGfOZcEyTpNkhfDMYQ9EKBBSK9K8HSEhHSSTkGj853xs24O0 7g+c83oaf6Ox1o1ozmHiHSadzWP1Iy9uLZ6mKnGCW76pOaT5UiulkmFNYJkfor/JeG5N 6VGDIj15YWsJ/rLsVoWfCXSBuzSJiKAv1y17QSokeWMN0rROBxJWfB8tP1+IZI9A/c/I YnDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=6yUloBoOC4lPpuUI0bgSFazEO3+i7SNhTlh+LnPkO1I=; b=gtpwTH5WRHKvFyiW2N35SdMT4s5XxfnhtvGqp88E5XGZk3DZreM1Yd/6b4vJZVlIk9 IJaCf58Zo1CGkOCuGiYV2BxBJp0RcnLk6Y6tie1xYo3uPnu7hE/oGTbOlhasfYuY8elp aTKeyxE2L/mJJ8mVxb6zYjPlLLzOVvqz2WxR63juq2HpcqGeOcri3shlywTzdfQYgFYe cgkBdPofrZEZ5va2iuGhozHiSe3Cu+dwBUqZKkqyvOoZnsif9Fy9ky4uSMK2BU9cNhl6 TJBQHOZMtj0D5Y7iqMAMLU1XCEIUb351U+hpTeEiqFad9GWW84d6mP0zZ19pExd4vtCT B2ug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h18si2734671ede.435.2022.01.27.18.37.07; Thu, 27 Jan 2022 18:37:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242000AbiA0NfI (ORCPT + 99 others); Thu, 27 Jan 2022 08:35:08 -0500 Received: from foss.arm.com ([217.140.110.172]:33558 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242027AbiA0NdR (ORCPT ); Thu, 27 Jan 2022 08:33:17 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ACC5B1063; Thu, 27 Jan 2022 05:33:16 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.14.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1C39D3F766; Thu, 27 Jan 2022 05:33:14 -0800 (PST) Date: Thu, 27 Jan 2022 13:33:02 +0000 From: Mark Rutland To: Sven Schnelle Cc: Steven Rostedt , Yinan Liu , linuxppc-dev@lists.ozlabs.org, Sachin Sant , linux-kernel@vger.kernel.org, ardb@kernel.org, keescook@chromium.org, hca@linux.ibm.com Subject: Re: [powerpc] ftrace warning kernel/trace/ftrace.c:2068 with code-patching selftests Message-ID: References: <20220124114548.30241947@gandalf.local.home> <0fa0daec-881a-314b-e28b-3828e80bbd90@linux.alibaba.com> <20220127074601.41a3773d@rorschach.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 27, 2022 at 02:16:31PM +0100, Sven Schnelle wrote: > Mark Rutland writes: > > > On Thu, Jan 27, 2022 at 07:46:01AM -0500, Steven Rostedt wrote: > >> On Thu, 27 Jan 2022 12:27:04 +0000 > >> Mark Rutland wrote: > >> > >> > Ah, so those non-ELF relocations for the mcount_loc table just mean "apply the > >> > KASLR offset here", which is equivalent for all entries. > >> > > >> > That makes sense, thanks! > >> > >> And this is why we were having such a hard time understanding each other ;-) > > > > ;) > > > > With that in mind, I think that we understand that the build-time sort works > > for: > > > > * arch/x86, becuase the non-ELF relocations for mcount_loc happen to be > > equivalent. > > > > * arch/arm, because there's no dynamic relocaiton and the mcount_loc entries > > have been finalized prior to sorting. > > > > ... but doesn't work for anyone else (including arm64) because the ELF > > relocations are not equivalent, and need special care that is not yet > > implemented. > > For s390 my idea is to just skip the addresses between __start_mcount_loc > and __stop_mcount_loc, because for these addresses we know that they are > 64 bits wide, so we just need to add the KASLR offset. > > I'm thinking about something like this: > > diff --git a/arch/s390/boot/compressed/decompressor.h b/arch/s390/boot/compressed/decompressor.h > index f75cc31a77dd..015d7e2e94ef 100644 > --- a/arch/s390/boot/compressed/decompressor.h > +++ b/arch/s390/boot/compressed/decompressor.h > @@ -25,6 +25,8 @@ struct vmlinux_info { > unsigned long rela_dyn_start; > unsigned long rela_dyn_end; > unsigned long amode31_size; > + unsigned long start_mcount_loc; > + unsigned long stop_mcount_loc; > }; > > /* Symbols defined by linker scripts */ > diff --git a/arch/s390/boot/startup.c b/arch/s390/boot/startup.c > index 1aa11a8f57dd..7bb0d88db5c6 100644 > --- a/arch/s390/boot/startup.c > +++ b/arch/s390/boot/startup.c > @@ -88,6 +88,11 @@ static void handle_relocs(unsigned long offset) > dynsym = (Elf64_Sym *) vmlinux.dynsym_start; > for (rela = rela_start; rela < rela_end; rela++) { > loc = rela->r_offset + offset; > + if ((loc >= vmlinux.start_mcount_loc) && > + (loc < vmlinux.stop_mcount_loc)) { > + (*(unsigned long *)loc) += offset; > + continue; > + } > val = rela->r_addend; > r_sym = ELF64_R_SYM(rela->r_info); > if (r_sym) { > @@ -232,6 +237,8 @@ static void offset_vmlinux_info(unsigned long offset) > vmlinux.rela_dyn_start += offset; > vmlinux.rela_dyn_end += offset; > vmlinux.dynsym_start += offset; > + vmlinux.start_mcount_loc += offset; > + vmlinux.stop_mcount_loc += offset; > } > > static unsigned long reserve_amode31(unsigned long safe_addr) > diff --git a/arch/s390/kernel/vmlinux.lds.S b/arch/s390/kernel/vmlinux.lds.S > index 42c43521878f..51c773405608 100644 > --- a/arch/s390/kernel/vmlinux.lds.S > +++ b/arch/s390/kernel/vmlinux.lds.S > @@ -213,6 +213,8 @@ SECTIONS > QUAD(__rela_dyn_start) /* rela_dyn_start */ > QUAD(__rela_dyn_end) /* rela_dyn_end */ > QUAD(_eamode31 - _samode31) /* amode31_size */ > + QUAD(__start_mcount_loc) > + QUAD(__stop_mcount_loc) > } :NONE > > /* Debugging sections. */ > > Not sure whether that would also work on power, and also not sure > whether i missed something thinking about that. Maybe it doesn't even > work. ;-) I don't know enough about s390 or powerpc relocs to say whether that works, but I can say that approach isn't going to work for arm64 without other signficant changes. I want to get the regression fixed ASAP, so can we take a simple patch for -rc2 which disables the build-time sort where it's currently broken (by limiting the opt-in to arm and x86), then follow-up per-architecture to re-enable it if desired/safe? Thanks, Mark.