linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Christoph Hellwig <hch@lst.de>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Fei Li <fei1.li@intel.com>, Nathan Chancellor <nathan@kernel.org>,
	Wupeng Ma <mawupeng1@huawei.com>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v2 2/3] x86/mm/pat: fix VM_PAT handling in COW mappings
Date: Thu, 4 Apr 2024 21:20:06 +0200	[thread overview]
Message-ID: <bced0912-4e30-4354-93f3-d6075952b5b5@redhat.com> (raw)
In-Reply-To: <20240403151249.0f4fc5b4f8c07630fbbb6338@linux-foundation.org>

On 04.04.24 00:12, Andrew Morton wrote:
> On Wed,  3 Apr 2024 23:21:30 +0200 David Hildenbrand <david@redhat.com> wrote:
> 
>> PAT handling won't do the right thing in COW mappings: the first PTE
>> (or, in fact, all PTEs) can be replaced during write faults to point at
>> anon folios. Reliably recovering the correct PFN and cachemode using
>> follow_phys() from PTEs will not work in COW mappings.
>>
>> ...
>>
>> Reported-by: Wupeng Ma <mawupeng1@huawei.com>
>> Closes: https://lkml.kernel.org/r/20240227122814.3781907-1-mawupeng1@huawei.com
>> Fixes: b1a86e15dc03 ("x86, pat: remove the dependency on 'vm_pgoff' in track/untrack pfn vma routines")
>> Fixes: 5899329b1910 ("x86: PAT: implement track/untrack of pfnmap regions for x86 - v3")
> 
> These are really old.  Should we backport this?

I was asking that question myself.

With the reproducer, the worst thing that happens on most systems is the 
warning. On !RAM and with PAT, there could be memory leaks and other 
surprises.

Likely, we should just backport it to stable. Should not be too hard to 
backport to stable kernels I guess/hope.

-- 
Cheers,

David / dhildenb



  reply	other threads:[~2024-04-04 19:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-03 21:21 [PATCH v2 0/3] " David Hildenbrand
2024-04-03 21:21 ` [PATCH v2 1/3] [mm-unstable] Revert "mm: move follow_phys to arch/x86/mm/pat/memtype.c" David Hildenbrand
2024-04-03 21:21 ` [PATCH v2 2/3] x86/mm/pat: fix VM_PAT handling in COW mappings David Hildenbrand
2024-04-03 22:12   ` Andrew Morton
2024-04-04 19:20     ` David Hildenbrand [this message]
2024-04-04 20:01       ` Andrew Morton
2024-04-07  2:08   ` mawupeng
2024-04-03 21:21 ` [PATCH v2 3/3] mm: move follow_phys to arch/x86/mm/pat/memtype.c David Hildenbrand
2024-04-03 22:09 ` [PATCH v2 0/3] x86/mm/pat: fix VM_PAT handling in COW mappings Andrew Morton
2024-04-05  7:00   ` Christoph Hellwig

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=bced0912-4e30-4354-93f3-d6075952b5b5@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fei1.li@intel.com \
    --cc=hch@lst.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mawupeng1@huawei.com \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nathan@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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