linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tong Tiangen <tongtiangen@huawei.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, <wangkefeng.wang@huawei.com>,
	Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Tony Luck <tony.luck@intel.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-edac@vger.kernel.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: Fri, 2 Feb 2024 15:51:12 +0800	[thread overview]
Message-ID: <39c1e4d2-b1d0-91ae-595e-1add4698dd7f@huawei.com> (raw)
In-Reply-To: <20240201142016.GFZbuooG9CRoK90U2C@fat_crate.local>



在 2024/2/1 22:20, Borislav Petkov 写道:
> On Thu, Feb 01, 2024 at 07:37:25PM +0800, Tong Tiangen wrote:
>> 在 2024/1/31 15:02, Borislav Petkov 写道:
>>> On Thu, Jan 11, 2024 at 09:55:47PM +0800, Tong Tiangen wrote:
>>>> Currently, there are some kernel memory copy scenarios is also mc safe
>>>> which use copy_mc_to_kernel() or copy_mc_user_highpage().
>>>
>>> Both of those end up in copy_mc_enhanced_fast_string() which does
>>> EX_TYPE_DEFAULT_MCE_SAFE.
>>
>> OK, how about this commit msg change? :)
>>
>> Currently, there are some kernel memory copy scenarios is also mc safe
>> which use copy_mc_to_kernel() or copy_mc_user_highpage(), **both of those
>> end up in copy_mc_enhanced_fast_string() or copy_mc_fragile() which does
>> EX_TYPE_DEFAULT_MCE_SAFE.**
>>
>> In these scenarios, posion pages need to be isolated too. Therefore, a
>> macro similar to MCE_IN_KERNEL_COPYIN is required. For this reason, we
>> can rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC, the new macro
>> can be applied to both user-to-kernel mc safe copy and kernel-to-kernel
>> mc safe copy.
> 
> Maybe my question wasn't clear: why is that renaming churn needed at
> all? What are you "fixing" here?
> 
> What is the problem that you're encountering which needs fixing?

This patch is a prepare patch and the next patch is a fix patch, the
complete logic of the two patches is as follows:

The problem i'm encountering:
-------------------------------
In the x86 mce processing, error_context() setting macro
MCE_IN_KERNEL_COPYIN to identify copy from user(user-to-kernel copy) for
fixup_type EX_TYPE_UACCESS.

Then do_machine_check() uses macro MCE_IN_KERNEL_COPYIN to isolate
posion page in memory_failure().

Currently, there are some kernel memory copy scenarios is also mc safe
which use copy_mc_to_kernel() or copy_mc_user_highpage(), these kernel-
to-kernel copy use fixup_type EX_TYPE_DEFAULT_MCE_SAFE. In these
scenarios, posion pages need to be isolated too and the current
implementation is to actively call memory_failure_queue() when the copy
fails.

Calling memory_failure_queue() separately is not a good implementation,
call it uniformly in do_machine_check() is more reasonable.

Solution:
----------
A macro similar to MCE_IN_KERNEL_COPYIN is required, so we can rename
MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC, the new macro can be
applied to both user-to-kernel mc safe copy and kernel-to-kernel mc safe
copy, in error_context(),we can set MCE_IN_KERNEL_COPY_MC for both
fixup_type EX_TYPE_UACCESS and EX_TYPE_DEFAULT_MCE_SAFE.



Do you think it's clear to say so and then we can merge the two patches
to make the complete logic clearer in commit msg ?

Many thanks.
Tong.

> 
> Thx.
> 


  reply	other threads:[~2024-02-02  7:51 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 [this message]
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
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=39c1e4d2-b1d0-91ae-595e-1add4698dd7f@huawei.com \
    --to=tongtiangen@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --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=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