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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date: Sun, 17 Mar 2024 14:42:32 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Marc Zyngier <maz@...nel.org>, Linus Torvalds <torvalds@...ux-foundation.org>
CC: Oliver Upton <oliver.upton@...ux.dev>,
 Catalin Marinas <catalin.marinas@....com>,
 Mark Rutland <mark.rutland@....com>, Will Deacon <will@...nel.org>,
 linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [GIT PULL] KVM changes for Linux 6.9 merge window

Retrying without HTML.

Paolo

Il 17 marzo 2024 14:34:02 CET, Paolo Bonzini <pbonzini@...hat.com> ha scritto:
>[first time writing to lkml from phone so I hope the formatting isn't too bad]
>
>Il 17 marzo 2024 11:36:37 CET, Marc Zyngier <maz@...nel.org> ha scritto:
>>On Sat, 16 Mar 2024 16:01:47 +0000,
>>Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>>> > You can also make CONFIG_KVM_ARM64_RES_BITS_PARANOIA depend on !COMPILE_TEST.
>>> 
>>> No.
>>> 
>>> WTF is wrong with you?
>>> 
>>> You're saying "let's turn off this compile-time sanity check when
>>> we're doing compile testing".
>>>     https://lore.kernel.org/linux-next/20240222220349.1889c728@canb.auug.org.au/
>>> 
>>> and you're still trying to just *HIDE* this garbage?
>>> 
>>> Stop it.
>>
>>Well, if you really need to shout at someone, it should be me, as I
>>was the one who didn't get Stephen's hint last time.
>
>No problem with being shouted at, but "depends on !COMPILE_TEST" is actually something that *is* used for "maintainers will look at it, it shouldn't matter for linux-next compile testing". Most notably it's used for -Werror.
>
>When Stephen reported the failure, I should have noticed that the bandaid doesn't do anything to fix allyesconfig/allmodconfig. If there's anything I can blame you for, I thought/understood that you would be able to fix the failure between the report and the beginning of the merge window, so there's that small miscommunication but that's it.
>
>>I'll try to resurrect it as a selftest, or maybe just keep it out of
>>tree for my own use.
>
>I still believe that "depends on !COMPILE_TEST" is what you want here, but yeah keeping out of tree or even under a special make target is an option if Linus disagrees.
>
>Selftests have the advantage that they can be marked XFAIL, but I am not sure they're a good match here (also because the flip side is that I think XPASS fails the run).
>
>Paolo
Paolo


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ