From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79411C77B73 for ; Wed, 24 May 2023 09:51:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1AFBC6B0074; Wed, 24 May 2023 05:51:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15F36900003; Wed, 24 May 2023 05:51:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04ED2900002; Wed, 24 May 2023 05:51:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E85636B0074 for ; Wed, 24 May 2023 05:51:39 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BF683A0926 for ; Wed, 24 May 2023 09:51:39 +0000 (UTC) X-FDA: 80824681518.01.E2163B7 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf02.hostedemail.com (Postfix) with ESMTP id 010CE80012 for ; Wed, 24 May 2023 09:51:37 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=eVGRA0kV; dkim=pass header.d=linutronix.de header.s=2020e header.b="JsNu/nMe"; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf02.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684921898; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HF0G4L72tdUvGq44KgOARsZN5Kg9lJl0ewFVDqzoCSo=; b=axQt2JcqXtRQLOHhbbf9buS2FsmUi70VSgTK9J2Nq+2uilaATUOwyprHt0soN4tjaF6FQr GIEJ0/hPNTYAAG7Cni2JcjkpYuQzoRH+PynNqQVwekMO6UGWX1/57vE6O27kYdeAmB90XS bANqH07NFaQvqFz5hQ+xzQstTvqAaWM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=eVGRA0kV; dkim=pass header.d=linutronix.de header.s=2020e header.b="JsNu/nMe"; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf02.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684921898; a=rsa-sha256; cv=none; b=dDCj0B2riLOdn47grBuz1payZzKGCdBz//o6WHO4HtBcyE4T7Z91oPHIhEx8Qn5dXBJNvm bLps6bJUJ8MB10grN0LeDSipoyhPwBTvV8GQ3pEYzw+nrsy/kcgb8M+ROGCOa9vmqHS4CU zMPJPnxfcqRVwUp2DeirYCzqbflk8uM= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684921895; h=from:from:reply-to:subject:subject: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=HF0G4L72tdUvGq44KgOARsZN5Kg9lJl0ewFVDqzoCSo=; b=eVGRA0kV5tMYuYuwHWa+8Y5PUjUQVixheOm133iZaYUeCD1NMPOjy/fmjz3Av5BWAeXKA2 Eo6TFHjhxhIjozkgQxx2l5EWlK92dXcpRJXjc85YUA8YuXFau+qHB7efbVFWxyENnFSSax 4lL/U6MCEyMEZCIDVi25cjeP9XAu1GuFksSiH9OAl6CrrlLcGPexnTnLLdyrkwqeS166Bt kY22Fh/KVGkefNHxkuR3cJA/Ky12ZfCSM9Z+lm+FWARg+5J4eU0CszW/wrrMnU49nFxSce d3/QDifSjtuCg8xGgrO31MiyddAKz1vIiPcPFcDH3yBi5iB+Ky8qkzG5rIjqsQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684921895; h=from:from:reply-to:subject:subject: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=HF0G4L72tdUvGq44KgOARsZN5Kg9lJl0ewFVDqzoCSo=; b=JsNu/nMeGfNUuw/TBQ4FMPo89awRHZaGw1vzjCjGzxGB91ZOTfwVch8l/NUAVPJ3tWgZQJ lZhREtI3xK0r+/Dw== To: Baoquan He Cc: linux-mm@kvack.org, Andrew Morton , Christoph Hellwig , Uladzislau Rezki , Lorenzo Stoakes , Peter Zijlstra Subject: Re: [patch 1/6] mm/vmalloc: Prevent stale TLBs in fully utilized blocks In-Reply-To: References: <20230523135902.517032811@linutronix.de> <20230523140002.575854344@linutronix.de> Date: Wed, 24 May 2023 11:51:35 +0200 Message-ID: <87mt1um508.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Stat-Signature: b4z1mknin8tg7nbaa5oqu9sp5gpxr955 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 010CE80012 X-HE-Tag: 1684921897-37442 X-HE-Meta: U2FsdGVkX18lkbzQwX9wgpnawq/dwe8P1NrltcglMadWhnjQurGtB8+4Ljt+srch+H242KSMmGDnYqS2wRvHI9QHs3wLL3TrwbMbjylbs0vwVsPRfKfRXCprHGHtLQWC0Go9CtWa7BM0N7oWUBuKuqsb9ETMPkg0o8GdIZd94yrDSTSbJPJ2LIXqmIU1LxknZgFDoMLe/uDgG9rWMRZFsWvBhiVLNI14/0JMXrHWzVnfFpbM7+1tNXC3iz/H/CiMBhSr+t0heMna1SJlKibACLLghgU5M7pIUz7uOD6V3ue8wk65YD4DTzOtDQOt2UAYpc+RuwE8/LE+3CsBqd3qjmDD1+GRr5PjWAaGLDdcUMNEOL+NTpUOd8NzQaVw3hYFVQZwiY2MGAHUhV8BfH4BuwiylIk+Qmu/31zOXaSfAB4pf3C9fssyNncqpXawhgaN2nfSinpLAmuTfO0OKstxHV4A+S0E+eSXK3QBjgeu1bkBebOh1pLDUejJjh2FXL9EDIyBGSJbVsqLSZpzEaTIX1e6uTITH5aM5VGSts+N9C6uBtJknPg31CM92ov4k/Z5/IgTHAcf3/1q8FOA5znByu9tdMYEDYCud2dtxYuZghTaTKPJE17wY0dDkl4Lo+zVkvyd4LgYjNurxLjgWpfdZbk82Sg4BlJ2rjTA/Y6ZdXjKjcqNenvsBVJJRMl/QDV0gGwoNpPFlQHyN4zWwC75ltdqVS9XZt8Zzi+Lx2eJhbNYMARUOyz+IIZwZnDNQGSbPwGYY121qAGasvViZ/Y6VbX6OxarusIRwfopcOVp9VpbSyXnuQBDFMJo/Ou7OjaOKywZWCiXd48x4HoJ+k6H/Qc/JOLh23R4yABPEfXUCfkRX2RFiAi09lCYc6rOKpXE2xV5Hx8Kf5jD8NCtBgpCdCIJSREaGCX16+CIlhMoc7bcMhLB2QievirlLpwrOrZDfO3Ku38wNzWmn2iv+uT Zz995SaY 9XYXCkpAOJv3nrfMrhjKt/TuCUlKkJWmTY0tdfOz8WXQ0bLg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, May 24 2023 at 17:25, Baoquan He wrote: > On 05/23/23 at 04:02pm, Thomas Gleixner wrote: >> _vm_unmap_aliases() is used to ensure that no unflushed TLB entries for a >> page are left in the system. This is required due to the lazy TLB flush >> mechanism in vmalloc. >> >> This is tried to achieve by walking the per CPU free lists, but those do >> not contain fully utilized vmap blocks because they are removed from the >> free list once the blocks free space became zero. > > The problem description is not accurate. This is tried to achieve for > va associated with vmap_block by walking the per CPU free lists, those > fully utilized vmap blocks can still be flushed in __purge_vmap_area_lazy() > by calculating the [min:max] of purge_vmap_area_list, because va of > vmap_blocks will be added to purge_vmap_area_list too via vb_free(). No. The fully utilized block cannot be purged when there are still active mappings on it. Again: X = vb_alloc() ... Y = vb_alloc() vb->free -= order; if (!vb->vb_free) list_del(vb->free_list); ... vb_free(Y) vb->dirty += order; if (vb->dirty == VMAP_BBMAP_BITS) // Condition is _false_ free_block(); So because $X is not yet unmapped the block is neither on the free list nor on purge_vmap_area_list. Thanks, tglx