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 7D726C77B73 for ; Wed, 24 May 2023 11:36:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CFADD6B0074; Wed, 24 May 2023 07:36:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C83716B0075; Wed, 24 May 2023 07:36:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B72A5900003; Wed, 24 May 2023 07:36:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A787A6B0074 for ; Wed, 24 May 2023 07:36:21 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 66916120455 for ; Wed, 24 May 2023 11:36:21 +0000 (UTC) X-FDA: 80824945362.08.C0F4747 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf13.hostedemail.com (Postfix) with ESMTP id 6975020010 for ; Wed, 24 May 2023 11:36:19 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=ht6ofR8u; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684928179; 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=IrcDzYmhu8YnZyOkD8Y9IWzMy9nfi4qvlTYstslpPT8=; b=ITlMvWgeRA/Hc2JD52G6pEocKPKM2FmrhWDAtmSkD4NcTxIssb4prbo6sJicSrP5qXevyE JL6hjJrJqp1NSSMNDfoQcm6r8xjgiXo7dFxi4Jlo8NSKY60IBASMoCIJ30iSu8Npo1GxEZ D0nw6z2CcECXgYsTG+s7aApVF1IIDSo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=ht6ofR8u; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684928179; a=rsa-sha256; cv=none; b=Ivpr4auqCNASYaQW0lEIS0zTyy1U1HAJzcLJNspymTnUKIGap36cvVxbGi9qhcvky60Yk2 CK4YX3LZZ60Mie1Hc/kqmfMnVAJi2kiOwag5TzJoWGcZAJiCgaGcIWB+7u4omoYEYtqxlJ O7cm2UKzBlCBWWuv7pzi2ApYHyuF2KM= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2af177f12a5so10376151fa.2 for ; Wed, 24 May 2023 04:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684928177; x=1687520177; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=IrcDzYmhu8YnZyOkD8Y9IWzMy9nfi4qvlTYstslpPT8=; b=ht6ofR8uUauWSsC3vteWImS3uagqtX5d6bYRZOwYuXUFm+RYk6BYvuzYppmsnuq+Z/ GLoDmH2L/8LtxstVQ2TdOG8CCUW54/hilPfJyBGXBYgEYqH48VVqcyP1Fn8dfsG+KAeu Y1rAlFC0AtUAGX4c+98e5rC7yNixCq5XswCkOytaU49Sbmug0sFT/STnEAU7y266qnWA pNJ7PqXQhvELHinCwriTLAFWVtpam3uB0ThmOa52t0p/nCY8ZQ9pxlJK0ds+B58Y/p6P GneyvWrchi7YLJ+2CfPHZJ7HBbNIcXzukqRA8phHf33bWBswuIl6IPyBT/spVgdgHx0X NvjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684928177; x=1687520177; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IrcDzYmhu8YnZyOkD8Y9IWzMy9nfi4qvlTYstslpPT8=; b=IgQ0nGxZZqBiuzzvrafAstjUHNLm1gLxOm8wkip9oL5LBzHmWVI97IoBXjmQAcBWom SQrXW9fdhL3YGRNqVXpjrS0yRmtRv7B68eQXzfVkFfeVBLe3qW0002zzsM3Mj/HVLvaE DsFDXtu+9+S/xQx646AHJcPmRh8tQJPI1g/+3m+4YW6OxNekFPMFBJ8McaoC9d2dkuxv yuQjPwEgtIHU3cBdPkuv9VTjd/aEtHxcp1g49GIKNgFygxs3+XaZExlr3WdtwOb39RFv H9J5cA8XN6wRlFFQiVf7Uc+/pgxq43cI2Cu/+nLUCxOlHY9ePzB9CxSiBtK67ro+k5D8 Yh/w== X-Gm-Message-State: AC+VfDzAKPWDb62JXVbHB22lhdAnReNjDwM0ErJJ9TwDb/B9AnvdAkFR uwvL7anFKNO3vbMQBC8r/uU= X-Google-Smtp-Source: ACHHUZ6Zw33PxKQS0qfg/qi51Hmu7zsu0wx8zhG6ru6rQEI8SXbuci+UDZ8hHj8vXxlbu4wA5k1y1g== X-Received: by 2002:a2e:98d4:0:b0:2af:1c91:d712 with SMTP id s20-20020a2e98d4000000b002af1c91d712mr6573281ljj.39.1684928177101; Wed, 24 May 2023 04:36:17 -0700 (PDT) Received: from pc636 (host-90-235-19-70.mobileonline.telia.com. [90.235.19.70]) by smtp.gmail.com with ESMTPSA id y15-20020a2e978f000000b002ac8164d77fsm2061648lji.86.2023.05.24.04.36.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 May 2023 04:36:16 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 24 May 2023 13:36:14 +0200 To: Baoquan He Cc: Thomas Gleixner , 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 Message-ID: References: <20230523135902.517032811@linutronix.de> <20230523140002.575854344@linutronix.de> <87mt1um508.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 6975020010 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: bkznz3c7hounqa5d73fnj5zjhcqszb4i X-HE-Tag: 1684928179-221106 X-HE-Meta: U2FsdGVkX18TTzr/nx3p71MBwdVpvzksrlZ76HsSRlyl4QbDY035FMRI2fwUskfxgUxpy3f1fN/y0T0FDD7evv1fixq9BrLqoJMGny9ycSGdBWtTxRmZgrO4bQlGjewD9ng/9DhtMFFAawZasY+RJiL2yaXDiPhOj8nUC/LKHPcVLQQjHNarZEWnqZNqeP32xjgA9YD1AqjMvpECnP4HJezsdkuKU0RoU0mC1qldfjTG7ePrkHyrS4xVODMwPTFNu+qUGfFabP1Z3h23+iEPKnMa55rZcRtX1HcZTg3cxierB0YsXEwhNXclUWJLg4pLubCcakSAiYnsmgutGiBLV7BuxvYiYd/IPLsvHvdVsU47fZN+95Kn3XLg6z2lD5lQFEceEVp8NHrxOXT2N72UBnftFkCNFEAUgxTwCuI0/b4EuJAN17XZ+ac9+Bfs7OpB/Mofq7qhtzhbEVvmV4TUfxkuxvRASwDGJdk5ORsXi0upmDA3NOyyJvCLY8tQLnSZ+S1WXFe3FdG5OLrZJozXC/Cb3YzuK1cxmaCN1go02RpY2OIIdM9Y3bnB+E9qsPanFO3Zb8yvnQG3QGr1cYa2+Ep2dIya/dMEejzZoliLsbWbeEBwImBZjPouGZFQZHG/UW9wT4IGPs3c3Mm/VxaNNv9XewNUQglOFw+hvXOMssYaFQx9JX1iv98idoocsVt2L5ET1eUVMuuQJV1AoY6LfuCUI7cjH6oLmjOeze5fOtAv0ztzUiRiyI1ME+3oLYhgxjaouSFUEf43EoXUa0elNTI94wLyYNLoww024dd8nG+26zwh8dcRZ5Q2wR2TW9Q0YafV3SWlQfzRxvDX6/0vZ1552oBhelZMLwOT+3s07qArTjnVlRbOGIreAYAtvLPU+JekhMinmcNQh2R3ZeLc4vBcHmBoL2EoFEY5fkWVq821y0QadSCZLlt0rZByizig5fODa0xu3METQcOrMQa Hpy99PTG XpIGyGmT/+k1FIRMhW5tSGEGcCZCGlLlF4vl2ZQl62PMGrNaNIkL05sL7DzGA9BZjkW0ksklmcFdO5nuN70nFRLmanYtPbpsUk+1iaSiVHEVxIVZkrbxuMAUWjsoe25ux1pIkQUdf1ML40hwBNGL6WiXWepfXO7LvgKD7dBqnPDRhNpbsgoHcE6psmwfNnTySRsVRTarDX/GNsY1QvDpFxAKvMf22m36wlUM4gN0j26rj6ieEv9nVtiOl++3wA1ffO24YLoEbGyzdGx/bSHEQnjxhTeoELZ7639bSvYz/3qUpjZJMCdtQ5C1tU4bzrKbFU5jExthJPu6Iudh9pty1/EAT39BEVEYHS8ksLkEDD0boGPrMVDCL7/WnkQa92KpPFcEjZWlMG3ICfI65MY2DypVivK4H0Pz+j7if62YggDkx2A0= 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 07:24:43PM +0800, Baoquan He wrote: > On 05/24/23 at 11:51am, Thomas Gleixner wrote: > > 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(); > > > vb_free(Y) > vb->dirty += order; > if (vb->dirty == VMAP_BBMAP_BITS) // Condition is _false_ > free_vmap_block(); > -->free_vmap_area_noflush() > -->merge_or_add_vmap_area(va, > &purge_vmap_area_root, &purge_vmap_area_list); > > The last mapped region will be freed and added to purge list via > vb_free(), it will be flushed with other va in purge list. When it's > mapped via vb_alloc(), it's detached from vbq->free list. When it's > freed via vb_alloc(), it's added to purge list, and flushed, the thing > is duplicated flushing, no missing flush seen here? > > > > > So because $X is not yet unmapped the block is neither on the free list > > nor on purge_vmap_area_list. > > Yeah, because $X is not yet unmapped, the block could have unmapped part > flushed, or unflushed. For unflushed part, it's got flushed with $X > altogether in the purge list. > If we gurantee that vb is fully flushed, then just do not add it it purge list: @@ -2086,12 +2090,7 @@ static void free_vmap_block(struct vmap_block *vb) BUG_ON(tmp != vb); z = addr_to_cvz(vb->va->va_start); - - spin_lock(&z->busy.lock); - unlink_va(vb->va, &z->busy.root); - spin_unlock(&z->busy.lock); - - free_vmap_area_noflush(vb->va); + free_vmap_area(vb->va); kfree_rcu(vb, rcu_head); } and directly return back into global vmap heap. -- Uladzislau Rezki