Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 24 May 2022 12:41:27 +0530
From:   "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Subject: Re: linux-next: changed messages in qemu boot
To:     Michael Ellerman <mpe@ellerman.id.au>,
        Stephen Rothwell <sfr@canb.auug.org.au>
Cc:     Christophe Leroy <christophe.leroy@csgroup.eu>,
        Linux =?iso-8859-1?q?Kernel=0A?= Mailing List 
        <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>,
        PowerPC <linuxppc-dev@lists.ozlabs.org>
References: <20220520233602.2738d87c@canb.auug.org.au>
        <1653069342.3xtfot6wli.naveen@linux.ibm.com>
        <87czg3mzyi.fsf@mpe.ellerman.id.au>
In-Reply-To: <87czg3mzyi.fsf@mpe.ellerman.id.au>
MIME-Version: 1.0
User-Agent: astroid/4d6b06ad (https://github.com/astroidmail/astroid)
Message-Id: <1653375606.b65qo262yf.naveen@linux.ibm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Michael Ellerman wrote:
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
>> Stephen Rothwell wrote:
>=20
>> The below diff fixes it for me:
>>
>> diff --git a/arch/powerpc/kernel/trace/ftrace.c b/arch/powerpc/kernel/tr=
ace/ftrace.c
>> index 46c002a8388804..7418da705d43ac 100644
>> --- a/arch/powerpc/kernel/trace/ftrace.c
>> +++ b/arch/powerpc/kernel/trace/ftrace.c
>> @@ -746,7 +746,7 @@ int __init ftrace_dyn_arch_init(void)
>> =20
>>         reladdr =3D addr - kernel_toc_addr();
>> =20
>> -       if (reladdr >=3D SZ_2G || reladdr < -SZ_2G) {
>> +       if (reladdr >=3D SZ_2G || reladdr < -_UL(SZ_2G)) {
>>                 pr_err("Address of %ps out of range of kernel_toc.\n",
>>                                 (void *)addr);
>>                 return -1;
>=20
> I did:
>=20
> 	if (reladdr >=3D SZ_2G || reladdr < -(long)SZ_2G) {

That was my first attempt.

> Which more closely matches what the old code did, and I think is more
> obvious? ie. we don't want to negate the unsigned value, we want a
> signed value, and then the negative of that.

When you put it like that... :D
In hindsight, I agree though -- _UL() isn't necessarily better.


Thanks,
Naveen