linux-kernel - Re: [PATCH v1] RISC-V: hwprobe: sort EXT_KEY()s in hwprobe_isa

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]

Message-ID: <5b974edc-0029-48a1-b181-6beef36869e1@rivosinc.com>
Date: Wed, 17 Jul 2024 15:47:26 +0200
From: Clément Léger <cleger@...osinc.com>
To: Conor Dooley <conor@...nel.org>
Cc: linux-riscv@...ts.infradead.org, Conor Dooley
 <conor.dooley@...rochip.com>, Paul Walmsley <paul.walmsley@...ive.com>,
 Palmer Dabbelt <palmer@...belt.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] RISC-V: hwprobe: sort EXT_KEY()s in hwprobe_isa_ext0()
 alphabetically



On 17/07/2024 15:42, Conor Dooley wrote:
> On Wed, Jul 17, 2024 at 03:34:06PM +0200, Clément Léger wrote:
>> On 17/07/2024 10:54, Conor Dooley wrote:
>>> From: Conor Dooley <conor.dooley@...rochip.com>
>>>
>>> Currently the entries appear to be in a random order (although according
>>> to Palmer he has tried to sort them by key value) which makes it harder
>>> to find entries in a growing list, and more likely to have conflicts as
>>> all patches are adding to the end of the list. Sort them alphabetically
>>> instead.
>>>
>>> Signed-off-by: Conor Dooley <conor.dooley@...rochip.com>
>>>  		if (has_fpu()) {
>>> -			EXT_KEY(ZFH);
>>> -			EXT_KEY(ZFHMIN);
>>> -			EXT_KEY(ZFA);
>>>  			EXT_KEY(ZCD);
>>>  			EXT_KEY(ZCF);
>>> +			EXT_KEY(ZFA);
>>> +			EXT_KEY(ZFH);
>>> +			EXT_KEY(ZFHMIN);
>>>  		}
>>>  #undef EXT_KEY
>>>  	}
>>
>> I'd prefer that to be done after removing the "if
>> (has_vector()/has_fpu()) by using the .validate callback for ISA
>> extension. This way, you'll have only a single commit reordering everything.
> 
> Right, and I do have some WIP for that here
> https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/log/?h=validate_fpu_and_vector
> but won't be sending that until it's cleaned up after the merge window.
> I was intentionally sending this during it so that there would be no
> moving pieces for this to conflict with - because it will conflict with
> any other patch adding things to the list tails.

Makes sense. If you think it's worth it:

Reviewed-by: Clément Léger <cleger@...osinc.com>

Thanks,

Clément