linux-kernel - Re: [PATCH v3] x86/mce: Set PG_hwpoison page flag to avoid the capture kernel panic

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: <916aa2dc-ea1e-4f23-a958-fa36dfb66af9@intel.com>
Date:   Tue, 17 Oct 2023 09:39:36 +0800
From:   Zhiquan Li <zhiquan1.li@...el.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     "Luck, Tony" <tony.luck@...el.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "patches@...ts.linux.dev" <patches@...ts.linux.dev>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "naoya.horiguchi@....com" <naoya.horiguchi@....com>
Subject: Re: [PATCH v3] x86/mce: Set PG_hwpoison page flag to avoid the
 capture kernel panic

On 2023/10/14 18:18, Borislav Petkov wrote:
> You should slow down and take the time to read the document I pointed
> you at.

I'd like to revise the tag list as below for next version, and reference
rules are following each action.  Please correct me if I still
understand the rules in submitting-patches.rst wrongly.

	Co-developed-by: Youquan Song <youquan.song@...el.com>
	Signed-off-by: Youquan Song <youquan.song@...el.com>
	Signed-off-by: Zhiquan Li <zhiquan1.li@...el.com>
	Reviewed-by: Naoya Horiguchi <naoya.horiguchi@....com>
	Cc: Borislav Petkov <bp@...en8.de>


1) As the author of the initial patch and the person who submitting the
patch, I put my SoB following Youquan's tags per below rule:

	Notably, the last Signed-off-by: must always be that of the
	developer submitting the patch.


2) Remove Tony's SoB.  I had confirmed with him, he needn't
Co-developed-by: tag, so the SoB added by himself in V1 and V2 should be
removed.
In fact, I'm not sure how to deal with such SoB for "RESEND" case.
While resent V2 I retained the SoB to reflect the chain.  According to
my understanding, the RESEND process emphasizes "not modifying".


3) Remove Ingo's SoB.  Because a new version means a new review cycle,
the SoB added in V2 should be reset to reflect the *new* real route,
unless Ingo needs a Co-developed-by: tag. Relative rule is following:

	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.

I missed this point while I sent V3 :-(


4) Keep Naoya's Reviewed-by: according to below rule, because there is
no substantial change in V3.

	Both Tested-by and Reviewed-by tags, once received on mailing
	list from tester or reviewer, should be added by author to the
	applicable patches when sending next versions. However if the
	patch has changed substantially in following version, these tags
	might not be applicable anymore and thus should be removed.


5) Add Cc: tag to you per below rule :-)

	This is the only tag which might be added without an explicit
	action by the person it names - but it should indicate that this
	person was copied on the patch. This tag documents that
	potentially interested parties have been included in the
	discussion.

Best Regards,
Zhiquan