All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
To: Dave Hansen <dave.hansen@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: "Harry Yoo (Oracle)" <42.hyeyoo@gmail.com>,
	<linux-kernel@vger.kernel.org>, <osalvador@suse.de>,
	<byungchul@sk.com>, <dave.hansen@linux.intel.com>,
	<luto@kernel.org>, <peterz@infradead.org>,
	<max.byungchul.park@sk.com>, <max.byungchul.park@gmail.com>,
	<x86@kernel.org>
Subject: Re: [PATCH 1/1] x86/vmemmap: Use direct-mapped VA instead of vmemmap-based VA
Date: Fri, 7 Mar 2025 10:56:04 +0200	[thread overview]
Message-ID: <eb8a6e71-601a-435f-a79b-ce95ee012c8f@intel.com> (raw)
In-Reply-To: <716f5a42-6828-4f0e-9002-d3bd5c4ad363@intel.com>

Sorry for the late reply.

On 3/6/25 6:09 PM, Dave Hansen wrote:
> On 3/5/25 19:46, Andrew Morton wrote:
>> Can we please have review from x86 maintainers?
> 
> I didn't respond here because I thought this was the same problem from
> the same contributor that we addressed in another thread:
> 
>> https://lore.kernel.org/all/d1da214c-53d3-45ac-a8b6-51821c5416e4@intel.com/
> 
> I think this approach is a hack. It basically requires that every bit of
> code that _might_ update (and then use) a PGD in the init_mm know how to
> find the direct map alias and then use that instead. This would further
> specialize the x86 code. I have no reason to believe that this is truly
> an x86-specific problem. Are we really the only arch that has a
> per-process PGD that maps the shared kernel page tables?
> 
currently the scenario that causes this issue only happens on x86, 
therfore I did a hotfix to make sure it would not affect other archtecture.

And I agree, I don't think this is an x86 only issue, and if there is a 
scenario that can cause the situation I reported on other platforms, I 
think it is possible.
> The right solution (like I mentioned in the other thread) is to sync the
> PGDs more aggressively. Syncing them is expensive, of course, but it's a
> pretty darn rare operation.
I'll send a new patch that introdues helper functions suggested by Dave 
above.

Thank you for not forgetting this issue and bringing it back to the surface.

Thanks,

G.G.

      reply	other threads:[~2025-03-07  8:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-17 11:41 [PATCH 0/1] x86/vmemmap: x86/vmemmap: Use direct-mapped VA instead of vmemmap-based VA Gwan-gyeong Mun
2025-02-17 11:41 ` [PATCH 1/1] " Gwan-gyeong Mun
2025-02-18  5:27   ` Harry Yoo (Oracle)
2025-02-18  5:43     ` Andrew Morton
2025-02-18 10:02       ` Gwan-gyeong Mun
2025-03-06  3:46         ` Andrew Morton
2025-03-06 16:09           ` Dave Hansen
2025-03-07  8:56             ` Gwan-gyeong Mun [this message]

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=eb8a6e71-601a-435f-a79b-ce95ee012c8f@intel.com \
    --to=gwan-gyeong.mun@intel.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=byungchul@sk.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=max.byungchul.park@gmail.com \
    --cc=max.byungchul.park@sk.com \
    --cc=osalvador@suse.de \
    --cc=peterz@infradead.org \
    --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.