All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jiang <dave.jiang@intel.com>
To: Ingo Molnar <mingo@kernel.org>, Dan Williams <dan.j.williams@intel.com>
Cc: Tony Luck <tony.luck@intel.com>,
	linux-nvdimm@lists.01.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-fsdevel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	hch@lst.de, linux-edac@vger.kernel.org
Subject: Re: [PATCH v6 11/13] x86/mm/pat: Prepare {reserve, free}_memtype() for "decoy" addresses
Date: Tue, 24 Jul 2018 08:46:06 -0700	[thread overview]
Message-ID: <896ea559-8fe5-9b2a-e763-407fae55cc01@intel.com> (raw)
In-Reply-To: <20180724073641.GA15984@gmail.com>



On 07/24/2018 12:36 AM, Ingo Molnar wrote:
> 
> * Dan Williams <dan.j.williams@intel.com> wrote:
> 
>> In preparation for using set_memory_uc() instead set_memory_np() for
>> isolating poison from speculation, teach the memtype code to sanitize
>> physical addresses vs __PHYSICAL_MASK.
>>
>> The motivation for using set_memory_uc() for this case is to allow
>> ongoing access to persistent memory pages via the pmem-driver +
>> memcpy_mcsafe() until the poison is repaired.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: Tony Luck <tony.luck@intel.com>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Cc: <linux-edac@vger.kernel.org>
>> Cc: <x86@kernel.org>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> ---
>>  arch/x86/mm/pat.c |   16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
>> index 1555bd7d3449..6788ffa990f8 100644
>> --- a/arch/x86/mm/pat.c
>> +++ b/arch/x86/mm/pat.c
>> @@ -512,6 +512,17 @@ static int free_ram_pages_type(u64 start, u64 end)
>>  	return 0;
>>  }
>>  
>> +static u64 sanitize_phys(u64 address)
>> +{
>> +	/*
>> +	 * When changing the memtype for pages containing poison allow
>> +	 * for a "decoy" virtual address (bit 63 clear) passed to
>> +	 * set_memory_X(). __pa() on a "decoy" address results in a
>> +	 * physical address with it 63 set.
>> +	 */
>> +	return address & __PHYSICAL_MASK;
> 
> s/it/bit

Thanks Ingo! I'll update when I pull in the patch.

> 
> Thanks,
> 
> 	Ingo
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
> 
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Dave Jiang <dave.jiang@intel.com>
To: Ingo Molnar <mingo@kernel.org>, Dan Williams <dan.j.williams@intel.com>
Cc: Tony Luck <tony.luck@intel.com>,
	linux-nvdimm@lists.01.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-fsdevel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	hch@lst.de, linux-edac@vger.kernel.org
Subject: Re: [PATCH v6 11/13] x86/mm/pat: Prepare {reserve, free}_memtype() for "decoy" addresses
Date: Tue, 24 Jul 2018 08:46:06 -0700	[thread overview]
Message-ID: <896ea559-8fe5-9b2a-e763-407fae55cc01@intel.com> (raw)
In-Reply-To: <20180724073641.GA15984@gmail.com>



On 07/24/2018 12:36 AM, Ingo Molnar wrote:
> 
> * Dan Williams <dan.j.williams@intel.com> wrote:
> 
>> In preparation for using set_memory_uc() instead set_memory_np() for
>> isolating poison from speculation, teach the memtype code to sanitize
>> physical addresses vs __PHYSICAL_MASK.
>>
>> The motivation for using set_memory_uc() for this case is to allow
>> ongoing access to persistent memory pages via the pmem-driver +
>> memcpy_mcsafe() until the poison is repaired.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: Tony Luck <tony.luck@intel.com>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Cc: <linux-edac@vger.kernel.org>
>> Cc: <x86@kernel.org>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> ---
>>  arch/x86/mm/pat.c |   16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
>> index 1555bd7d3449..6788ffa990f8 100644
>> --- a/arch/x86/mm/pat.c
>> +++ b/arch/x86/mm/pat.c
>> @@ -512,6 +512,17 @@ static int free_ram_pages_type(u64 start, u64 end)
>>  	return 0;
>>  }
>>  
>> +static u64 sanitize_phys(u64 address)
>> +{
>> +	/*
>> +	 * When changing the memtype for pages containing poison allow
>> +	 * for a "decoy" virtual address (bit 63 clear) passed to
>> +	 * set_memory_X(). __pa() on a "decoy" address results in a
>> +	 * physical address with it 63 set.
>> +	 */
>> +	return address & __PHYSICAL_MASK;
> 
> s/it/bit

Thanks Ingo! I'll update when I pull in the patch.

> 
> Thanks,
> 
> 	Ingo
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
> 

WARNING: multiple messages have this Message-ID (diff)
From: Dave Jiang <dave.jiang@intel.com>
To: Ingo Molnar <mingo@kernel.org>, Dan Williams <dan.j.williams@intel.com>
Cc: Tony Luck <tony.luck@intel.com>,
	linux-nvdimm@lists.01.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-fsdevel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	hch@lst.de, linux-edac@vger.kernel.org
Subject: [v6,11/13] x86/mm/pat: Prepare {reserve, free}_memtype() for "decoy" addresses
Date: Tue, 24 Jul 2018 08:46:06 -0700	[thread overview]
Message-ID: <896ea559-8fe5-9b2a-e763-407fae55cc01@intel.com> (raw)

On 07/24/2018 12:36 AM, Ingo Molnar wrote:
> 
> * Dan Williams <dan.j.williams@intel.com> wrote:
> 
>> In preparation for using set_memory_uc() instead set_memory_np() for
>> isolating poison from speculation, teach the memtype code to sanitize
>> physical addresses vs __PHYSICAL_MASK.
>>
>> The motivation for using set_memory_uc() for this case is to allow
>> ongoing access to persistent memory pages via the pmem-driver +
>> memcpy_mcsafe() until the poison is repaired.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: Tony Luck <tony.luck@intel.com>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Cc: <linux-edac@vger.kernel.org>
>> Cc: <x86@kernel.org>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> ---
>>  arch/x86/mm/pat.c |   16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
>> index 1555bd7d3449..6788ffa990f8 100644
>> --- a/arch/x86/mm/pat.c
>> +++ b/arch/x86/mm/pat.c
>> @@ -512,6 +512,17 @@ static int free_ram_pages_type(u64 start, u64 end)
>>  	return 0;
>>  }
>>  
>> +static u64 sanitize_phys(u64 address)
>> +{
>> +	/*
>> +	 * When changing the memtype for pages containing poison allow
>> +	 * for a "decoy" virtual address (bit 63 clear) passed to
>> +	 * set_memory_X(). __pa() on a "decoy" address results in a
>> +	 * physical address with it 63 set.
>> +	 */
>> +	return address & __PHYSICAL_MASK;
> 
> s/it/bit

Thanks Ingo! I'll update when I pull in the patch.

> 
> Thanks,
> 
> 	Ingo
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
>
---
To unsubscribe from this list: send the line "unsubscribe linux-edac" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2018-07-24 15:46 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-14  4:49 [PATCH v6 00/13] mm: Teach memory_failure() about ZONE_DEVICE pages Dan Williams
2018-07-14  4:49 ` Dan Williams
2018-07-14  4:49 ` [PATCH v6 01/13] device-dax: Convert to vmf_insert_mixed and vm_fault_t Dan Williams
2018-07-14  4:49   ` Dan Williams
2018-07-14  4:49 ` [PATCH v6 02/13] device-dax: Enable page_mapping() Dan Williams
2018-07-14  4:49   ` Dan Williams
2018-07-14  4:49 ` [PATCH v6 03/13] device-dax: Set page->index Dan Williams
2018-07-14  4:49   ` Dan Williams
2018-07-14  4:49 ` [PATCH v6 04/13] filesystem-dax: " Dan Williams
2018-07-14  4:49   ` Dan Williams
2018-07-14  4:49 ` [PATCH v6 05/13] mm, madvise_inject_error: Disable MADV_SOFT_OFFLINE for ZONE_DEVICE pages Dan Williams
2018-07-14  4:49   ` Dan Williams
2018-07-17  6:47   ` Naoya Horiguchi
2018-07-17  6:47     ` Naoya Horiguchi
2018-07-14  4:50 ` [PATCH v6 06/13] mm, dev_pagemap: Do not clear ->mapping on final put Dan Williams
2018-07-14  4:50   ` Dan Williams
2018-07-14  4:50   ` Dan Williams
2018-07-23 16:12   ` Dave Jiang
2018-07-23 16:12     ` Dave Jiang
2018-07-23 16:12     ` Dave Jiang
2018-07-23 16:23     ` Jerome Glisse
2018-07-23 16:23       ` Jerome Glisse
2018-07-23 16:23       ` Jerome Glisse
2018-07-23 16:23       ` Jerome Glisse
2018-07-14  4:50 ` [PATCH v6 07/13] mm, madvise_inject_error: Let memory_failure() optionally take a page reference Dan Williams
2018-07-14  4:50   ` Dan Williams
2018-07-17  6:52   ` Naoya Horiguchi
2018-07-14  4:50 ` [PATCH v6 08/13] mm, memory_failure: Collect mapping size in collect_procs() Dan Williams
2018-07-14  4:50   ` Dan Williams
2018-07-14  4:50 ` [PATCH v6 09/13] filesystem-dax: Introduce dax_lock_mapping_entry() Dan Williams
2018-07-14  4:50   ` Dan Williams
2018-08-06  9:21   ` Jan Kara
2018-08-06  9:21     ` Jan Kara
2018-07-14  4:50 ` [PATCH v6 10/13] mm, memory_failure: Teach memory_failure() about dev_pagemap pages Dan Williams
2018-07-14  4:50   ` Dan Williams
2018-07-14  4:50   ` Dan Williams
2018-08-06  9:27   ` Jan Kara
2018-08-06  9:27     ` Jan Kara
2018-08-06  9:27     ` Jan Kara
2018-08-06  9:27     ` Jan Kara
2018-07-14  4:50 ` [PATCH v6 11/13] x86/mm/pat: Prepare {reserve, free}_memtype() for "decoy" addresses Dan Williams
2018-07-14  4:50   ` [v6,11/13] " Dan Williams
2018-07-14  4:50   ` [PATCH v6 11/13] " Dan Williams
2018-07-24  7:36   ` Ingo Molnar
2018-07-24  7:36     ` [v6,11/13] " Ingo Molnar
2018-07-24  7:36     ` [PATCH v6 11/13] " Ingo Molnar
2018-07-24 15:46     ` Dave Jiang [this message]
2018-07-24 15:46       ` [v6,11/13] " Dave Jiang
2018-07-24 15:46       ` [PATCH v6 11/13] " Dave Jiang
2018-07-14  4:50 ` [PATCH v6 12/13] x86/memory_failure: Introduce {set, clear}_mce_nospec() Dan Williams
2018-07-14  4:50   ` [v6,12/13] " Dan Williams
2018-07-14  4:50   ` [PATCH v6 12/13] " Dan Williams
2018-07-14  4:50 ` [PATCH v6 13/13] libnvdimm, pmem: Restore page attributes when clearing errors Dan Williams
2018-07-14  4:50   ` Dan Williams
2018-07-19 17:57 ` [PATCH v6 00/13] mm: Teach memory_failure() about ZONE_DEVICE pages Dave Jiang
2018-07-19 17:57   ` Dave Jiang
2018-07-24  7:39   ` Ingo Molnar
2018-07-24  7:39     ` Ingo Molnar

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=896ea559-8fe5-9b2a-e763-407fae55cc01@intel.com \
    --to=dave.jiang@intel.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=hch@lst.de \
    --cc=hpa@zytor.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.