mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Borislav Petkov <bp@alien8.de>, "Tian, Kevin" <kevin.tian@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Zeng, Guang" <guang.zeng@intel.com>,
	"Liu, Jing2" <jing2.liu@intel.com>, "Christopherson,,
	Sean" <seanjc@google.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"Wang, Wei W" <wei.w.wang@intel.com>,
	"Zhong, Yang" <yang.zhong@intel.com>
Subject: Re: [PATCH v6 05/21] x86/fpu: Make XFD initialization in __fpstate_reset() a function argument
Date: Mon, 10 Jan 2022 15:18:26 +0100	[thread overview]
Message-ID: <761a554a-d13f-f1fb-4faf-ca7ed28d4d3a@redhat.com> (raw)
In-Reply-To: <Ydvz0g+Bdys5JyS9@zn.tnic>

On 1/10/22 09:52, Borislav Petkov wrote:
> On Mon, Jan 10, 2022 at 05:15:44AM +0000, Tian, Kevin wrote:
>> Thanks for pointing it out! Actually this is one area which we didn't get
>> a clear answer from 'submitting-patches.rst'
> 
> Are you sure? I see
> 
> "Any further SoBs (Signed-off-by:'s) following the author's SoB are from
> people handling and transporting the patch, but were not involved in its
> development. SoB chains should reflect the **real** route a patch took
> as it was propagated to the maintainers and ultimately to Linus, with
> the first SoB entry signalling primary authorship of a single author."

Say a patch went A->B->C->A->D and all of {A,B,C} were involved in the 
development at different times.  The above text says "any further SoBs 
are from people not involved in its development", in other words it 
doesn't cover the case of multiple people handling different versions of 
a patch submission.

The only clear thing from the text would be "do not remove/move the 
author's Signed-off-by", but apart from that it's wild wild west and 
there are contradictions everywhere.

For example:

1) checkpatch.pl wants "Co-developed-by" to be immediately followed by 
"Signed-off-by".  Should we imply that all SoB entries preceded by 
Co-developed-by do not exactly reflect the route that the patch took 
(since there could be multiple back and forth)?

2) if the author sends the patches but has co-developers, should they be 
first (because they're the author) or last (because they're the one 
actually sending the patch out)?


Any consistent rules that I could come up with are too baroque to be 
practical:

1) a sequence consisting of {SoB,Co-developed-by,SoB} does not 
necessarily reflect a chain from the first signoff to the second signoff

2) if you are a maintainer committing a patch so that it will go to 
Linus, just add your SoB line.

3) if you pick up someone else's branch or posted series, and you are 
not in the existing SoB chain, you must add a Co-developed-by and SoB 
line for yourself.  Do not use the document the changes in brackets: 
that is only done by the maintainers when they make changes and do not 
repost for review.

The maintainers must already have a bad case of Stockholm syndrome for 
not having automated this kind of routine check, but it would be even 
worse if we were to inflict this on the developers.  In the end, IMHO 
the real rules that matter are:

- there should be a SoB line for the author

- the submitter must always have the last SoB line

- SoB lines shall never be removed

- maintainers should prefer merge commits when moving commits from one 
tree to the other

- merge commits should have a SoB line too

Everything else, including the existence of Co-developed-by lines, is an 
unnecessary complication.

Paolo


  reply	other threads:[~2022-01-10 14:18 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-07 18:54 [PATCH v6 00/21] AMX support for KVM Paolo Bonzini
2022-01-07 18:54 ` [PATCH v6 01/21] x86/fpu: Extend fpu_xstate_prctl() with guest permissions Paolo Bonzini
2022-01-07 18:54 ` [PATCH v6 02/21] x86/fpu: Prepare guest FPU for dynamically enabled FPU features Paolo Bonzini
2022-01-07 18:54 ` [PATCH v6 03/21] kvm: x86: Fix xstate_required_size() to follow XSTATE alignment rule Paolo Bonzini
2022-01-07 18:54 ` [PATCH v6 04/21] kvm: x86: Exclude unpermitted xfeatures at KVM_GET_SUPPORTED_CPUID Paolo Bonzini
2022-01-23  6:22   ` Like Xu
2022-01-24  7:18     ` Tian, Kevin
2022-01-07 18:54 ` [PATCH v6 05/21] x86/fpu: Make XFD initialization in __fpstate_reset() a function argument Paolo Bonzini
2022-01-07 19:43   ` Borislav Petkov
2022-01-10  5:15     ` Tian, Kevin
2022-01-10  8:52       ` Borislav Petkov
2022-01-10 14:18         ` Paolo Bonzini [this message]
2022-01-10 15:25           ` Borislav Petkov
2022-01-10 15:55             ` Paolo Bonzini
2022-01-10 18:18               ` Borislav Petkov
2022-01-11  1:45                 ` Tian, Kevin
2022-01-07 18:54 ` [PATCH v6 06/21] x86/fpu: Add guest support to xfd_enable_feature() Paolo Bonzini
2022-01-07 18:54 ` [PATCH v6 07/21] x86/fpu: Provide fpu_enable_guest_xfd_features() for KVM Paolo Bonzini
2022-01-10  5:25   ` Tian, Kevin
2022-01-07 18:54 ` [PATCH v6 08/21] kvm: x86: Enable dynamic xfeatures at KVM_SET_CPUID2 Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 09/21] x86/fpu: Provide fpu_update_guest_xfd() for IA32_XFD emulation Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 10/21] kvm: x86: Add emulation for IA32_XFD Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 11/21] x86/fpu: Prepare xfd_err in struct fpu_guest Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 12/21] kvm: x86: Intercept #NM for saving IA32_XFD_ERR Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 13/21] kvm: x86: Emulate IA32_XFD_ERR for guest Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 14/21] kvm: x86: Disable RDMSR interception of IA32_XFD_ERR Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 15/21] kvm: x86: Add XCR0 support for Intel AMX Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 16/21] kvm: x86: Add CPUID " Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 17/21] x86/fpu: Add uabi_size to guest_fpu Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 18/21] kvm: x86: Add support for getting/setting expanded xstate buffer Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 19/21] kvm: selftests: Add support for KVM_CAP_XSAVE2 Paolo Bonzini
2022-01-17 16:51   ` Janis Schoetterl-Glausch
2022-01-18  2:06     ` Wang, Wei W
2022-01-07 18:55 ` [PATCH v6 20/21] x86/fpu: Provide fpu_sync_guest_vmexit_xfd_state() Paolo Bonzini
2022-01-07 18:55 ` [PATCH v6 21/21] kvm: x86: Disable interception for IA32_XFD on demand Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=761a554a-d13f-f1fb-4faf-ca7ed28d4d3a@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=bp@alien8.de \
    --cc=guang.zeng@intel.com \
    --cc=jing2.liu@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=wei.w.wang@intel.com \
    --cc=yang.zhong@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®