From: Borislav Petkov <bp@alien8.de>
To: Tong Tiangen <tongtiangen@huawei.com>
Cc: "Luck, Tony" <tony.luck@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
"wangkefeng.wang@huawei.com" <wangkefeng.wang@huawei.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Naoya Horiguchi <naoya.horiguchi@nec.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Guohanjun <guohanjun@huawei.com>
Subject: Re: [PATCH -next v4 2/3] x86/mce: rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC
Date: Sat, 3 Feb 2024 10:43:09 +0100 [thread overview]
Message-ID: <20240203094309.GDZb4KrS2GWa5XtGeZ@fat_crate.local> (raw)
In-Reply-To: <4d974c1e-b3a8-8b21-88f4-e5f20b2fb654@huawei.com>
On Sat, Feb 03, 2024 at 03:56:04PM +0800, Tong Tiangen wrote:
> The goal of this patch:
> When #MC is triggered by copy_mc_user_highpage(), #MC is directly
> processed in the synchronously triggered do_machine_check() ->
> kill_me_never() -> memory_failure().
>
> And the current handling is to call memory_failure_queue() ->
> schedule_work_on() in the execution context, I think that's what
> "scheduling someone else to handle it at some future point is risky."
Ok, now take everything that was discussed on the thread and use it to
rewrite all your commit messages to explain *why* you're doing this, not
*what* you're doing - that is visible from the diff.
A possible way to structure them is:
1. Prepare the context for the explanation briefly.
2. Explain the problem at hand.
3. "It happens because of <...>"
4. "Fix it by doing X"
5. "(Potentially do Y)."
And some of those above are optional depending on the issue being
explained.
For more detailed info, see
Documentation/process/submitting-patches.rst,
Section "2) Describe your changes".
Also, to the tone, from Documentation/process/submitting-patches.rst:
"Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behaviour."
Also, do not talk about what your patch does - that should (hopefully) be
visible from the diff itself. Rather, talk about *why* you're doing what
you're doing.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2024-02-03 9:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 13:55 [PATCH -next v4 0/3] minor improvements for x86 mce processing Tong Tiangen
2024-01-11 13:55 ` [PATCH -next v4 1/3] x86/mce: remove redundant fixup type EX_TYPE_COPY Tong Tiangen
2024-01-30 21:09 ` Borislav Petkov
2024-02-01 11:02 ` Tong Tiangen
2024-02-01 12:43 ` Tong Tiangen
2024-01-11 13:55 ` [PATCH -next v4 2/3] x86/mce: rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC Tong Tiangen
2024-01-31 7:02 ` Borislav Petkov
2024-02-01 11:37 ` Tong Tiangen
2024-02-01 14:20 ` Borislav Petkov
2024-02-02 7:51 ` Tong Tiangen
2024-02-02 13:39 ` Borislav Petkov
2024-02-02 18:44 ` Luck, Tony
2024-02-02 19:42 ` Borislav Petkov
2024-02-02 21:36 ` Luck, Tony
2024-02-02 22:22 ` Borislav Petkov
2024-02-02 22:46 ` Luck, Tony
2024-02-03 7:56 ` Tong Tiangen
2024-02-03 9:43 ` Borislav Petkov [this message]
2024-02-04 1:52 ` Tong Tiangen
2024-01-11 13:55 ` [PATCH -next v4 3/3] x86/mce: set MCE_IN_KERNEL_COPY_MC for DEFAULT_MCE_SAFE exception Tong Tiangen
2024-01-15 13:25 ` [PATCH -next v4 0/3] minor improvements for x86 mce processing Kefeng Wang
2024-01-15 13:33 ` Borislav Petkov
2024-01-16 1:14 ` Kefeng Wang
2024-01-16 10:30 ` Borislav Petkov
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=20240203094309.GDZb4KrS2GWa5XtGeZ@fat_crate.local \
--to=bp@alien8.de \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=guohanjun@huawei.com \
--cc=hpa@zytor.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=naoya.horiguchi@nec.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tongtiangen@huawei.com \
--cc=tony.luck@intel.com \
--cc=wangkefeng.wang@huawei.com \
--cc=x86@kernel.org \
/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