linux-kernel - RE: [PATCH v6 05/21] x86/fpu: Make XFD initialization in __fpstate

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: <BN9PR11MB5276F6F3325A20E78E8DC0D58C519@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Tue, 11 Jan 2022 01:45:47 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Borislav Petkov <bp@...en8.de>, Paolo Bonzini <pbonzini@...hat.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Zeng, Guang" <guang.zeng@...el.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Wang, Wei W" <wei.w.wang@...el.com>,
        "Zhong, Yang" <yang.zhong@...el.com>
Subject: RE: [PATCH v6 05/21] x86/fpu: Make XFD initialization in
 __fpstate_reset() a function argument

> From: Borislav Petkov <bp@...en8.de>
> Sent: Tuesday, January 11, 2022 2:19 AM
> 
> On Mon, Jan 10, 2022 at 04:55:01PM +0100, Paolo Bonzini wrote:
> > So this means that "the author must be the first SoB" is not an absolute
> > rule.  In the case of this patch we had:
> >
> > From: Jing Liu <jing2.liu@...el.com>
> > ...
> > Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> > Signed-off-by: Jing Liu <jing2.liu@...el.com>
> > Signed-off-by: Yang Zhong <yang.zhong@...el.com>
> 
> Looking at Kevin's explanation, that should be:
> 
> Signed-off-by: Jing Liu <jing2.liu@...el.com>		# author
> Signed-off-by: Yang Zhong <yang.zhong@...el.com>	# v1 submitter
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>	# handler/reviewer
> Signed-off-by: Jing Liu <jing2.liu@...el.com>		# v2-v3 submitter
> Signed-off-by: Yang Zhong <yang.zhong@...el.com>	# v4-v5 submitter
> 
> > and the possibilities could be:
> >
> > 1) have two SoB lines for Jing (before and after Thomas)
> >
> > 2) add a Co-developed-by for Thomas as the first line
> 
> If Thomas would prefer. But then it becomes:
> 
> Signed-off-by: Jing Liu <jing2.liu@...el.com>           # author
> Signed-off-by: Yang Zhong <yang.zhong@...el.com>        # v1 submitter
> Co-developed-by: Thomas Gleixner <tglx@...utronix.de>	# co-author
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>     # handler/reviewer
> Signed-off-by: Jing Liu <jing2.liu@...el.com>           # v2-v3 submitter
> Signed-off-by: Yang Zhong <yang.zhong@...el.com>        # v4-v5 submitter
> 
> and that means, Thomas worked on that patch *after* Yang submitted v1.
> Which is the exact chronological order, as Kevin writes.
> 
> > 3) do exactly what the gang did ("remain practical and do only an SOB
> > chain")
> 
> Yes, but not change the SOB order.
> 
> Because if you do that, then it doesn't state what the exact path was
> the patch took and how it ended up upstream. And due to past fun stories
> with SCO, we want to track exactly how a patch ended up upstream. And I
> think this is the most important aspect of those SOB chains.
> 

This is exactly what we'd like to get clarified in this very special case.

Since Thomas didn't put a Co-developed-by in the first place, I prefer to
respecting his choice i.e.:

	From: Jing Liu <jing2.liu@...el.com>

	Signed-off-by: Jing Liu <jing2.liu@...el.com>
	Signed-off-by: Yang Zhong <yang.zhong@...el.com>
	Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
	Signed-off-by: Jing Liu <jing2.liu@...el.com>
	Signed-off-by: Yang Zhong <yang.zhong@...el.com>

Following this rule then the SoB order in all other patches also need
be fixed, e.g. both Jing's name and Yang's name will occur twice
to reflect the chronological order in most patches. But I'm not sure 
what's the best way to handle it since Paolo already puts the entire 
series in his tip. 

Can this series gets an exempt given all participated names already
have their SoB in this special case?

If must be fixed we can certainly provide updated SoB history for
every patch. The burden might be on Paolo's side and if it does happen
I really want to say sorry here for not getting this open clarified earlier...

Thanks
Kevin