All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <jroedel@suse.de>
To: Peilin Ye <yepeilin.cs@gmail.com>
Cc: x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Jonathan Corbet <corbet@lwn.net>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Zefang Han <hanzefang@gmail.com>,
	Wei Lin Chang <r09922117@csie.ntu.edu.tw>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] docs: x86: Remove obsolete information about x86_64 vmalloc() faulting
Date: Mon, 19 Jul 2021 14:34:31 +0200	[thread overview]
Message-ID: <YPVxV/KdDBqgTaqE@suse.de> (raw)
In-Reply-To: <20210716060958.GA2197@PWN>

Hi,

On Fri, Jul 16, 2021 at 02:09:58AM -0400, Peilin Ye wrote:
> This information is out-of-date, and it took me quite some time of
> ftrace'ing before I figured it out...  I think it would be beneficial to
> update, or at least remove it.
> 
> As a proof that I understand what I am talking about, on my x86_64 box:
> 
>   1. I allocated a vmalloc() area containing linear address `addr`;
>   2. I manually pagewalked `addr` in different page tables, including
>      `init_mm.pgd`;
>   3. The corresponding PGD entries for `addr` in different page tables,
>      they all immediately pointed at the same PUD table (my box uses
>      4-level paging), at the same physical address;
>   4. No "lazy synchronization" via page fault handling happened at all,
>      since it is the same PUD table pre-allocated by
>      preallocate_vmalloc_pages() during boot time.

Yes, this is the story for x86-64, because all PUD/P4D pages for the vmalloc
area are pre-allocated at boot. So no faulting or synchronization needs
to happen.

On x86-32 this is a bit different. Pre-allocation of PMD/PTE pages is
not an option there (even less when 4MB large-pages with 2-level paging
come into the picture).

So what happens there is that vmalloc related changes to the init_mm.pgd
are synchronized to all page-tables in the system. But this
synchronization is subject to race conditions in a way that another CPU
might vmalloc an area below a PMD which is not fully synchronized yet.

When this happens there is a fault, which is handled as a vmalloc()
fault on x86-32 just as before. So vmalloc faults still exist on 32-bit,
they are just less likely as they used to be.

Regards,

	Joerg

  reply	other threads:[~2021-07-19 12:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22  3:19 [PATCH] docs: x86: Remove obsolete information about x86_64 vmalloc() faulting Peilin Ye
2021-07-16  6:09 ` Peilin Ye
2021-07-19 12:34   ` Joerg Roedel [this message]
2021-07-20  4:50     ` Peilin Ye

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=YPVxV/KdDBqgTaqE@suse.de \
    --to=jroedel@suse.de \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=hanzefang@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=r09922117@csie.ntu.edu.tw \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xiyou.wangcong@gmail.com \
    --cc=yepeilin.cs@gmail.com \
    /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.