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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4ACDFC7EE29 for ; Mon, 22 May 2023 20:22:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TTD7oX2BSrfF5JVR0og/AfOhx4N7dJQjPCTJpxPAziw=; b=NfmFG88O99u82Z 8+511yYWqUrYiE6CktaYfzMhAR+D5t09y0Dn1k6P7fkFFeyE3Xli1qGgGKzFHpoVMpTcaj6DI3oE0 KHPgnSmRabIoKR1ofusthKrrFflBxbZE/arP5m47ZBuzoR0+P03ev8/v9emGlYIF3cRDf3WZFZBz7 fBb5pB6Px0m7lHLqEp0f9NjddNtgw/rHjIydDkCdKcD62uMqgSNdrDRjzhsRGZGlt0f09IC4f4OeC kxF5SS8AFrzPjUeR6iDG0NydyxSBkqXVrEeD7gERu78dZ0ra+lcwStdqaWwoFoXxOv2E2HQpe3iUc KgPLhuxo4MutHxjvRagA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q1C2R-007tXI-24; Mon, 22 May 2023 20:21:51 +0000 Received: from galois.linutronix.de ([2a0a:51c0:0:12e:550::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q1C2O-007tVA-1L for linux-arm-kernel@lists.infradead.org; Mon, 22 May 2023 20:21:49 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230522_132148_618166_29FA7EBD X-CRM114-Status: GOOD ( 18.57 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel