| Message ID | 20240111135548.3207437-1-tongtiangen@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | minor improvements for x86 mce processing | expand |
Hi Borislav and Tony， On 2024/1/11 21:55, Tong Tiangen wrote: > In this patchset, we remove the unused macro EX_TYPE_COPY and centralize > the processing of memory-failure to do_machine_check() to avoid calling > memory_failure_queue() separately for different MC-Safe scenarios. In > addition, MCE_IN_KERNEL_COPYIN is renamed MCE_IN_KERNEL_COPY_MC to expand > its usage scope. The patchset is a followup[1], as Borislav suggested[2], we firstly cleanup unused EX_TYPE_COPY, then rename MCE_IN_KERNEL_COPYIN to reduce confusion, could you give us some comments about it, many thanks. > > [1]https://lore.kernel.org/linux-mm/20230526063242.133656-1-wangkefeng.wang@huawei.com/ > [2] https://lore.kernel.org/linux-edac/20230602160138.GDZHoSYsWoPAinMszk@fat_crate.local/ > since v3: > 1. Rebased on linux-next tag next-20240111. > 2. Delete duplicate commit references on patch 3. > > since v2: > 1. remove redundant fixup type EX_TYPE_COPY. > 2. rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC. > 3. update patch3's commit message and the processing logic of > EX_TYPE_DEFAULT_MCE_SAFE based on the discussion of [1]. > > Kefeng Wang (1): > x86/mce: set MCE_IN_KERNEL_COPY_MC for DEFAULT_MCE_SAFE exception > > Tong Tiangen (2): > x86/mce: remove redundant fixup type EX_TYPE_COPY > x86/mce: rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC > > arch/x86/include/asm/asm.h | 3 --- > arch/x86/include/asm/extable_fixup_types.h | 23 +++++++++++----------- > arch/x86/include/asm/mce.h | 8 ++++---- > arch/x86/kernel/cpu/mce/core.c | 2 +- > arch/x86/kernel/cpu/mce/severity.c | 7 +++---- > arch/x86/mm/extable.c | 9 --------- > mm/ksm.c | 1 - > mm/memory.c | 13 ++++-------- > 8 files changed, 23 insertions(+), 43 deletions(-) >
On Mon, Jan 15, 2024 at 09:25:57PM +0800, Kefeng Wang wrote: > could you give us some comments about it, many thanks. Since we have a (suspended¹) merge window currently: From: Documentation/process/maintainer-tip.rst Merge window ^^^^^^^^^^^^ Please do not expect large patch series to be handled during the merge window or even during the week before. Such patches should be submitted in mergeable state *at* *least* a week before the merge window opens. Exceptions are made for bug fixes and *sometimes* for small standalone drivers for new hardware or minimally invasive patches for hardware enablement. During the merge window, the maintainers instead focus on following the upstream changes, fixing merge window fallout, collecting bug fixes, and allowing themselves a breath. Please respect that. The release candidate -rc1 is the starting point for new patches to be applied which are targeted for the next merge window. ¹ https://lore.kernel.org/r/CAHk-=wjMWpmXtKeiN__vnNO4TcttZR-8dVvd_oBq%2BhjeSsWUwg@mail.gmail.com
On 2024/1/15 21:33, Borislav Petkov wrote: > On Mon, Jan 15, 2024 at 09:25:57PM +0800, Kefeng Wang wrote: >> could you give us some comments about it, many thanks. > > Since we have a (suspended¹) merge window currently: > > From: Documentation/process/maintainer-tip.rst > > Merge window > ^^^^^^^^^^^^ > > Please do not expect large patch series to be handled during the merge > window or even during the week before. Such patches should be submitted in > mergeable state *at* *least* a week before the merge window opens. > Exceptions are made for bug fixes and *sometimes* for small standalone > drivers for new hardware or minimally invasive patches for hardware > enablement. > > During the merge window, the maintainers instead focus on following the > upstream changes, fixing merge window fallout, collecting bug fixes, and > allowing themselves a breath. Please respect that. > > The release candidate -rc1 is the starting point for new patches to be > applied which are targeted for the next merge window. Oh, sure, we could resend after -rc1, thanks. > > ¹ https://lore.kernel.org/r/CAHk-=wjMWpmXtKeiN__vnNO4TcttZR-8dVvd_oBq%2BhjeSsWUwg@mail.gmail.com > Hope everything is OK!
On Tue, Jan 16, 2024 at 09:14:56AM +0800, Kefeng Wang wrote:
> Oh, sure, we could resend after -rc1, thanks.
No, no need to resend after -rc1.
What you should do, instead, is take the time to read the text I pasted
more carefully and get acquainted with the development process:
https://kernel.org/doc/html/latest/process/development-process.html
and especially this:
https://kernel.org/doc/html/latest/process/submitting-patches.html#don-t-get-discouraged-or-impatient
In those pages is a wealth of useful information.
In this patchset, we remove the unused macro EX_TYPE_COPY and centralize the processing of memory-failure to do_machine_check() to avoid calling memory_failure_queue() separately for different MC-Safe scenarios. In addition, MCE_IN_KERNEL_COPYIN is renamed MCE_IN_KERNEL_COPY_MC to expand its usage scope. [1]https://lore.kernel.org/linux-mm/20230526063242.133656-1-wangkefeng.wang@huawei.com/ since v3: 1. Rebased on linux-next tag next-20240111. 2. Delete duplicate commit references on patch 3. since v2: 1. remove redundant fixup type EX_TYPE_COPY. 2. rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC. 3. update patch3's commit message and the processing logic of EX_TYPE_DEFAULT_MCE_SAFE based on the discussion of [1]. Kefeng Wang (1): x86/mce: set MCE_IN_KERNEL_COPY_MC for DEFAULT_MCE_SAFE exception Tong Tiangen (2): x86/mce: remove redundant fixup type EX_TYPE_COPY x86/mce: rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC arch/x86/include/asm/asm.h | 3 --- arch/x86/include/asm/extable_fixup_types.h | 23 +++++++++++----------- arch/x86/include/asm/mce.h | 8 ++++---- arch/x86/kernel/cpu/mce/core.c | 2 +- arch/x86/kernel/cpu/mce/severity.c | 7 +++---- arch/x86/mm/extable.c | 9 --------- mm/ksm.c | 1 - mm/memory.c | 13 ++++-------- 8 files changed, 23 insertions(+), 43 deletions(-)