linux-kernel - RE: [PATCH] x86/tdx: Support vmalloc() for tdx_enc_status

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <SA1PR21MB1317C5633D8F537A73A1CE17BFA42@SA1PR21MB1317.namprd21.prod.outlook.com>
Date: Wed, 10 Jul 2024 09:20:46 +0000
From: Dexuan Cui <decui@...rosoft.com>
To: Borislav Petkov <bp@...en8.de>
CC: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Dave Hansen
	<dave.hansen@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo
 Molnar <mingo@...hat.com>, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, "open list:X86 TRUST
 DOMAIN EXTENSIONS (TDX)" <linux-coco@...ts.linux.dev>, "open list:X86
 ARCHITECTURE (32-BIT AND 64-BIT)" <linux-kernel@...r.kernel.org>, Michael
 Kelley <mikelley@...rosoft.com>, Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@...ux.intel.com>, Rick Edgecombe
	<rick.p.edgecombe@...el.com>, Kai Huang <kai.huang@...el.com>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH] x86/tdx: Support vmalloc() for tdx_enc_status_changed()

> From: Borislav Petkov <bp@...en8.de>
> [...]
> If I queue it after -rc1, it'll be only in tip and linux-next for an
> additional 7 week cycle and I can always whack it if it breaks something. If
> it doesn't, I can send it mainline in the 6.12 merge window.
> 
> But we won't have to revert it mainline.
> 
> See the difference?

Got it. Thanks for the explanation!

> If you're calling the difference between what I reverted and what you're
> sending now unsubstantial:
> 
> [...]

I didn't expect that 'diff' could generate so many lines of changes :-)

> especially for a patch which is already known to break things and where
> we're  especially careful, then yes, we strongly disagree here.
>
> So yes, it will definitely not go in now.

Understood.
 
> When version N introduces changes like above in what is already non-
> trivial code, you drop all tags. And if people want to review it again,
> then they  should give you those R-by tags.
> 
> Also, think about it: your patch broke a use case. How much are those R-by
> tags worth if the patch is broken? And why do you want to hold on to
> them so badly?
> 
> If a patch needs to be reverted because it breaks a use case, all reviewed
> and acked tags should simply be removed too. It is that simple.
> 
> --
> Regards/Gruss,
>     Boris.

Got it. Will reflect all the comments into the next version.