linux-kernel - Re: [PATCH] MIPS: Fix build error due to PTR used in more places

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 4 Feb 2022 10:26:23 +0100
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Guenter Roeck <linux@...ck-us.net>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>, linux-mips@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: Fix build error due to PTR used in more places

Hi, this is your Linux kernel regression tracker speaking.

On 31.01.22 11:08, Thomas Bogendoerfer wrote:
> On Sun, Jan 30, 2022 at 08:37:25AM -0800, Guenter Roeck wrote:
>> On Tue, Jan 25, 2022 at 03:19:44PM +0100, Thomas Bogendoerfer wrote:
>>> Use PTR_WD instead of PTR to avoid clashes with other parts.
>>>
>>> Signed-off-by: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
>>
>> Building mips:cavium_octeon_defconfig ... failed
>> --------------
>> Error log:
>> arch/mips/cavium-octeon/octeon-memcpy.S: Assembler messages:
>> arch/mips/cavium-octeon/octeon-memcpy.S:187: Error: unrecognized opcode `ptr 9b,l_exc'
>> ...
>>
>> Missed one place in Cavium assembler code.
>>
>> arch/mips/cavium-octeon/octeon-memcpy.S:        PTR     9b, handler;
>>
>> #regzbot introduced: fa62f39dc7e2

@Guenter: thx for getting the regression tracked!

> d'oh, fix sent.

Sadly you didn't link to the report about the issue using a "Link:" tag,
as explained by both Documentation/process/submitting-patches.rst and
Documentation/process/5.Posting.rst

Could you please do so in the future? Than would make my life as a Linux
kernel's regression tracker a lot easier, as my regression tracking bot
would then have been able to automatically detect the patch posting and
the commit (I for now decided to not make the bot rely on the "Fixes:"
tag alone, as that might do the wrong thing if one commit causes
multiple regressions).

Anyway: I no big deal (just makes regression tracking a lot harder), I
can tell regzbot manually about the fix:

#regzbot introduced: 50317b636e7184d

Ciao, Thorsten