Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3647690pxv; Mon, 19 Jul 2021 05:35:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbXhZ+GE4aWc2+rq84pcJWvKWSGizjIVaRQI+PE5ouKcQ7D8Xrhhvy58HVgh0QNDZRbIck X-Received: by 2002:a05:6e02:1d15:: with SMTP id i21mr16999569ila.307.1626698123572; Mon, 19 Jul 2021 05:35:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626698123; cv=none; d=google.com; s=arc-20160816; b=Kkhr1cgu1ryAizkO66aI5q+TAYcEVt/o77R/ryAUTrmrofnOj7Xcn4wMvh25FZWz8V dUxJ9to7X3+1ZPwK0Fj0PJZ4D47Lzo2g9vuxSw3ShH5kogrClPNwRaXchd3TeddKMHiv BPie6LMZB0PYg0dGlFro5evyI5pv40WimPbumb1MNE+zDq2Cl8nQkDGYXpAEpB/7uQCe mGr7NWMRcT0hDpN3Wy6uGBbGq/eczsmrKfGkPQqKttx58rvDiibAbIesWsPoQx9ME+Uv dyXacwb1CDdvgUfZql2tVTXFfSD/uP8/oLPNAfA9ZNp06Gby8vaZxFONQQISVpRuiPb/ NJKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=2iJvPsC6ukBGO3cNftlX9R7xbJOF2Z7UoI/Wtw8cKY0=; b=JFMNS0pJyCTsK+iO3m87/+IPoReWq47AY/shTKpqAqojaLbthQaHzNvw4XXiu3T+y+ JEUnNEjDkREzQco+5YWRA8jkNmLtynt/IU0cguzL+SUd9PiwcDJuQqLQiGRl1G95kvtE TwSakn0kBwf9K7caSNkuwlpJI4Rbi581J/YDASnzhJQgKOkUjCGGnW+I5Ka65M3Worq3 E8UoqYJ6bEEcz3P4+8QkIpbgD+AvBaz3R49I9ALL/yN+HZHVTLKYeyqxKhs985SJbbDt pVNjc8F4lWFY0Hf1yo73W45OXT9SDgUH6mSLAtGn9oPdV5GBpSnaoweOrELFiIwN8Zfq oR5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=1V2Hdxpn; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g17si19461645jaq.116.2021.07.19.05.35.11; Mon, 19 Jul 2021 05:35:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=1V2Hdxpn; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231533AbhGSLx4 (ORCPT + 99 others); Mon, 19 Jul 2021 07:53:56 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:57222 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236929AbhGSLxy (ORCPT ); Mon, 19 Jul 2021 07:53:54 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 72B432025A; Mon, 19 Jul 2021 12:34:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1626698073; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2iJvPsC6ukBGO3cNftlX9R7xbJOF2Z7UoI/Wtw8cKY0=; b=1V2Hdxpn4S17364BHRsNN2kAuHBJPZW4Y8suHHChc6wEUGdXxfnAzNS/dQdp2OHt30ruTi B/iIXCUMMy6qN2+ia62+JBc1gWK/dUJAd2doxx5fFuGj4ZfP/zS2Mr4eXF1hvEkwXBEEkI xfQpED6Pgyfvdi3cQ+0P419Q8/iJNUY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1626698073; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2iJvPsC6ukBGO3cNftlX9R7xbJOF2Z7UoI/Wtw8cKY0=; b=UhY5cevKft+Q/4dG+0soQM+eSC3skYAJewX/6yPH+/iCE590hbzViaKO/igLvmcPvbY16o xpzMGKkZIYp0rGBQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id F1C2813CE9; Mon, 19 Jul 2021 12:34:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id N2mVOFhx9WD5YwAAMHmgww (envelope-from ); Mon, 19 Jul 2021 12:34:32 +0000 Date: Mon, 19 Jul 2021 14:34:31 +0200 From: Joerg Roedel To: Peilin Ye Cc: x86@kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Jonathan Corbet , "H. Peter Anvin" , Cong Wang , Zefang Han , Wei Lin Chang , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH] docs: x86: Remove obsolete information about x86_64 vmalloc() faulting Message-ID: References: <20210622031910.141262-1-yepeilin.cs@gmail.com> <20210716060958.GA2197@PWN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210716060958.GA2197@PWN> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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