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 AE961C7EE29 for ; Mon, 22 May 2023 20:21:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D390F900003; Mon, 22 May 2023 16:21:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE8DF900002; Mon, 22 May 2023 16:21:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD799900003; Mon, 22 May 2023 16:21:45 -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 AF1A1900002 for ; Mon, 22 May 2023 16:21:45 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6D9F01A04B8 for ; Mon, 22 May 2023 20:21:45 +0000 (UTC) X-FDA: 80819011770.02.C69883F Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf06.hostedemail.com (Postfix) with ESMTP id 711D3180010 for ; Mon, 22 May 2023 20:21:43 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=EhymQpNw; dkim=pass header.d=linutronix.de header.s=2020e header.b=wScO0UbD; spf=pass (imf06.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684786903; 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=AFyDdrNfDMTGz0u/4banmJEyHD174FF54Cx7p9E0A3M=; b=5d99BajHZHZWEjd0ceTp4/LZHELr9e+swasXF0cvD95bmpMWFEoYdpCpSSespQPad4q9S2 wVRYLTvbIu28gRBRkNVfDnVvI+IvqHEo/dCnov8SCd20h55TCfE4mwuVwfehNjrBj5eEjy CB2s+N9uN/p3wJMzUm+BXKu4uMlTchw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684786903; a=rsa-sha256; cv=none; b=McGwtzMxIauq0Ne2TWg6QUekRRhByVelmvpjTmRhia0/k1UxWmmkjelq4M7GH9a3jbHAtl 1elZ86Wb7pzCy2+S05nsaakNkgMYjNQg/Yf6cB5iqNn2W7k9O6+Ipmc/gjVsIqe/LGITE0 ugdcvrvzYM3GSI/elEoUb+Xu7B4Cy4w= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=EhymQpNw; dkim=pass header.d=linutronix.de header.s=2020e header.b=wScO0UbD; spf=pass (imf06.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684786901; 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=AFyDdrNfDMTGz0u/4banmJEyHD174FF54Cx7p9E0A3M=; b=EhymQpNwxtWYjL4M3bS1DqflRcgGfG3pUNkJV+Y8wk4ReYTYmcgdJpYnOWlJIINIUngqyD FI2Q6PybRJ5fC2F8xnw0Cyc/FQkadCj/4L8Ukyv95qU6QoWKdrn6MFelQymiBWxgPkFRe4 6z9xTapEeFzKfBunPoW8gDpGdormfBF/HpxHI3ae+1e7ge2zCvQwRDtdJ8z7DonnCjwpnG fxzzNfALH+uJRtnC2Xo97LLDSgnCGohck+mke3aDzkMiWdKW4hVmX18Qy0mONAfpp77zJk h84upynSnu4gPhl84+/76EGlY3ViTCWjgQ4yJ0spKidYl4EpjqpdUImMNpMCPA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684786901; 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=AFyDdrNfDMTGz0u/4banmJEyHD174FF54Cx7p9E0A3M=; b=wScO0UbDn9kaXC1c5FVtMOE4sm5IXBiPBvq0kbuTX2Mh48Y8El1K/mwoP+yrfC4thWHLR0 lagzXFUCBPxiHQDw== To: Baoquan He Cc: "Russell King (Oracle)" , Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Uladzislau Rezki , Lorenzo Stoakes , Peter Zijlstra , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier , x86@kernel.org, Nadav Amit Subject: Re: [RFC PATCH 3/3] mm/vmalloc.c: change _vm_unmap_aliases() to do purge firstly In-Reply-To: References: <874joc8x7d.ffs@tglx> <87r0rg73wp.ffs@tglx> <87edng6qu8.ffs@tglx> <87cz2w415t.ffs@tglx> <87jzx1xou9.ffs@tglx> <87wn10wp45.ffs@tglx> Date: Mon, 22 May 2023 22:21:40 +0200 Message-ID: <87h6s4w20b.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 711D3180010 X-Rspam-User: X-Stat-Signature: dygn1i449qizqsd7op7td8sbuig7ztgs X-Rspamd-Server: rspam03 X-HE-Tag: 1684786903-734829 X-HE-Meta: U2FsdGVkX19XgwVVFvYNHvU22X/+zjitrQu/dQ9gqKxIqPLIMQVRSxtkG7EdCUhwFizAit+Viyzfwr8CGANjcgQ9tB+SxV8xPh/T37eWGEoMGj9FcfVdUT1eDTxSds6cMkxcEP9TE7kVJ/UNiwihBfdH3BTUIEviW6WjOrNdqkoH3MBLlUSahLH3BfvRXgQgESkzuw+OrABlQYH/wL0NhLYZbiIAYa55c/vb7HXSYcNjFGbss0Ef2ZILjOmJ30UKt0IKdL81UR3XPWFV62+k/2I/zxp/kYH6Qxu4XI7EA5RTmXIf+WNWTEQuGQafxxhMOZUPUYeovqmp8WSfoGg0z2+713ngERQBPK+cgPmyzdjmaLwq0snAJwAE73DwuQv8GeQUV4dw+lOvfzXCGOyfFE01/TtXj38fsHNnb3HUaX/Gucegk4hXU6pfbolBx2f9H422qCF/NtSFvUTxTHYL3GEM9pbdPfIT3PniH7bfW0cPxi5P181nqGbTvhVbLjpYhUvojbcpmRObAq44yFfn+CcqJQor7nep0GEUAny3bm7h7PgZ2xbGQ3w8FA9cJUdgpmv7MnFsxG8ML7Suf10aUM1bVmyk5qyR3bdGwhbo2OMjyq1CyZhqQbctblG26q2nEvyiO1w+kw6vytUozx2boXYDdNB8UY0/7dV4Nz+o1/b0BpVEka/Qdy51Dyzy2fDoLveMSWukudsAhRvvti1sbKcpH15LKZT44YvuOd39Kk3Zu/TLBnKGi7SGKrb9JPdT8oM82n29RW01vlHr+Y59yFzgRqRYoY+3OnvL0VPsrM0fdeBZzjg1ZiFzJakYXaEc/1oSyBNKtmGTl/W19OPyexNA538OQsEvdjl/WyVBXd1Gh56vmokWADm++gu9fNpl/fLZKmMpLD3AyEwCEXpIIXY8mjqwdzxncbKnoiqrC7fNczS1SYT5PRdaEDdTLrBIa6cvCRElKSIt42BoBCW gBLq5N9Y sOIju6CW4O6IKfHfoNUgHAel1Poa85fBH0wtARCGSkGQCIdpU7hJVJor2n/vWe7Qg7K54yJUGwkKWv+oc/qfIgbZXcyG1hjoOWsJz/ot3oqsJYb4EOsc9V+wL6rEPQB5xfLRnIA2O/MbH37oeaVXPIHn6JdqSP/7eSBlpYO/xaCAw+jw= 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 Mon, May 22 2023 at 22:34, Baoquan He wrote: > On 05/22/23 at 02:02pm, Thomas Gleixner wrote: >> > @@ -1736,6 +1737,14 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) >> > list_replace_init(&purge_vmap_area_list, &local_purge_list); >> > spin_unlock(&purge_vmap_area_lock); >> > >> > + vb = container_of(va, struct vmap_block, va); >> >> This cannot work vmap_area is not embedded in vmap_block. vmap_block::va >> is a pointer. vmap_area does not link back to vmap_block, so there is no >> way to find it based on a vmap_area. > > Oh, the code is buggy. va->flags can tell if it's vmap_block, then we > can deduce the vb pointer. No. It _CANNOT_ work whether you check the flags or not. struct foo { ..... struct bar bar; }; container_of(ptr_to_bar, struct foo, bar) returns the pointer to the struct foo which has struct bar embedded. But struct foo { ..... struct bar *bar; }; cannot do that because ptr_to_bar points to some object which is completely disconnected from struct foo. Care to look at the implementation of container_of()? Here is what it boils down to: void *member_pointer = bar; p = (struct foo *)(member_pointer - offsetof(struct foo, bar); So it uses the pointer to bar and subtracts the offset of bar in struct foo. This obviously can only work when struct bar is embedded in struct foo. Lets assume that *bar is the first member of foo, i.e. offset of *bar in struct foo is 0 p = (struct foo *)(member_pointer - 0); So you end up with p == member_pointer == bar But you won't get there because the static_assert() in container_of() will catch that and the compiler will tell you in colourful ways. Once the vmap area is handed over for cleaning up the vmap block is gone and even if you let it stay around then the vmap area does not have any information where to find the block. You'd need to have a pointer to the vmap block in vmap area or embed vmap area into vmap block. See? Thanks, tglx