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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1692C433FE for ; Thu, 21 Apr 2022 16:41:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 3D80B4B274; Thu, 21 Apr 2022 12:41:04 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-SCpMFYY4Et; Thu, 21 Apr 2022 12:41:03 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2B01A4B236; Thu, 21 Apr 2022 12:41:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8C0754B1D7 for ; Thu, 21 Apr 2022 12:41:02 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4bvb0RXyY2m for ; Thu, 21 Apr 2022 12:41:01 -0400 (EDT) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 7F1284B1D0 for ; Thu, 21 Apr 2022 12:41:01 -0400 (EDT) Received: by mail-il1-f173.google.com with SMTP id f5so3402622ilj.13 for ; Thu, 21 Apr 2022 09:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zJ2PGSI6AkHDlxF/GNqF8HmtNwa9bQE1NjwYidDeeG4=; b=pb+EWMdmgz1SYFX5XMH36PJu8yBtqr0Vp8AGddG8kaiOE9UKasHUfSsrOs+kJgSuXR OKFrxOBeYXDavmOeFnwrkdLL4nrogRXknJiEortPNN9IvfWb8G+Nd6qlAWgieJnihyTv bdZgytwpwpts9HrOXNDERUlnemXOUdayTIjMlMen7VrjysCHLtHhwnpMsskmUJnPLeru DTDn/wXdO8zWEHnAZtRNNPaB46buoPfiZ5vWQle6tdzev3eBZl4u/WHtpRquc/yNM/gE VyGcIVWlh+r6XYvo4+irYPo8nPKy9YfO/PULBFjDZMDLESvIdrXpn77TvcarqOxmgu2u ZWZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zJ2PGSI6AkHDlxF/GNqF8HmtNwa9bQE1NjwYidDeeG4=; b=M9e/s5e07eqH2NfHtRC560Ay+SyL/8HKEeLYRagMhg/a4GB4yYLhEyKEWx7Fsg8rOi ImVkm69ltMqXQ9kCYBErY3AE7ET8nDFOzuuwFVobVBrBCNu77vaIeO8DORd5OzH38YIP ZCn8pSCaqOivLlFza81JKQEu/V++sOSK9KuDCIgJHhTxpPOHBpYsop5njHK3VLi8iuD1 aH8ROuIGUyT5mD6gGkNcJd4q+In6q+S7YfSS0HHjxinwFdVvFUEfIAV3+NAnIG2kT2Qa fk9kqxcBG3yRXRU+3v7JA7w1pTplivRyllzOc67Srg+/mHRCe9SpR72tR8ef15+Cnm4b hDog== X-Gm-Message-State: AOAM533hpYpTo2OkAysLIdX4ZhjQhtkuSwP3eSh7PxjybEDWtiS0LjqY tTD8uz+AIC3s6VVmao/i5+5o0w== X-Google-Smtp-Source: ABdhPJznCuS8lVwwartmfDZ1hMkeoqvEWgOgvlXvcS6SugJ8SjoFWUQHCgUp+HIoFk3yQVSQ1VLNBA== X-Received: by 2002:a92:6c08:0:b0:2c6:123f:48c9 with SMTP id h8-20020a926c08000000b002c6123f48c9mr301117ilc.22.1650559260642; Thu, 21 Apr 2022 09:41:00 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id j12-20020a6b310c000000b0065744ce0180sm117650ioa.8.2022.04.21.09.40.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 09:40:59 -0700 (PDT) Date: Thu, 21 Apr 2022 16:40:56 +0000 From: Oliver Upton To: Quentin Perret Subject: Re: [RFC PATCH 09/17] KVM: arm64: Tear down unlinked page tables in parallel walk Message-ID: References: <20220415215901.1737897-1-oupton@google.com> <20220415215901.1737897-10-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , Ben Gardon , David Matlack , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, Apr 21, 2022 at 01:21:54PM +0000, Quentin Perret wrote: > Hi Oliver, > > On Friday 15 Apr 2022 at 21:58:53 (+0000), Oliver Upton wrote: > > Breaking a table pte is insufficient to guarantee ownership of an > > unlinked subtree. Parallel software walkers could be traversing > > substructures and changing their mappings. > > > > Recurse through the unlinked subtree and lock all descendent ptes > > to take ownership of the subtree. Since the ptes are actually being > > evicted, return table ptes back to the table walker to ensure child > > tables are also traversed. Note that this is done both in both the > > pre-order and leaf visitors as the underlying pte remains volatile until > > it is unlinked. > > Still trying to get the full picture of the series so bear with me. IIUC > the case you're dealing with here is when we're coallescing a table into > a block with concurrent walkers making changes in the sub-tree. I > believe this should happen when turning dirty logging off? Yup, I think that's the only time we wind up collapsing tables. > Why do we need to recursively lock the entire sub-tree at all in this > case? As long as the table is turned into a locked invalid PTE, what > concurrent walkers are doing in the sub-tree should be irrelevant no? > None of the changes they do will be made visible to the hardware anyway. > So as long as the sub-tree isn't freed under their feet (which should be > the point of the RCU protection) this should be all fine? Is there a > case where this is not actually true? The problem arises when you're trying to actually free an unlinked subtree. All bets are off until the next RCU grace period. What would stop another software walker from installing a table to a PTE that I've already visited? I think we'd wind up leaking a table page in this case as the walker doing the table collapse assumes it has successfully freed everything underneath. The other option would be to not touch the subtree at all until the rcu callback, as at that point software will not tweak the tables any more. No need for atomics/spinning and can just do a boring traversal. Of course, I lazily avoided this option because it would be a bit more code but isn't too awfully complicated. Does this paint a better picture, or have I only managed to confuse even more? :) -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 4F700C433EF for ; Thu, 21 Apr 2022 16:42:10 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=83H1Ge0T/WLkJRncP+Nn0Ef2w6me4T83wmsaqMbNiPk=; b=Id8U2N4hq6JgWa qw+UJhK3mC7oXgI2rwa1UqW3Nwgg/vAAI6l9ff+WnDHwppef4s486cXsa94D0zfdHQyVY//a4ZB/S mAxmU7WuHjjPO94WVyVb6Sr0UOPo5W7el1MlsQvIlgm3Nt6C69wQjwztPj+8hHTWTKZ34Ke/hfjnZ 3V2ee3PIzIOn1K9LvNDZPE1aPPbqEKHDU9qYGVJ+Xzb7D3aBWqTQzUOsSSJ/x21RnH7NrsMit24K+ i0qlhy0sTUpMgRS4kJgnqd5XU/YIXelFhCeRpdYA0STmyZ1hOaByf0CuHJHW6BEDBGVaQ7R4HpXLh qQDphrVhmnMYw0J7PY5w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhZrf-00EHKV-60; Thu, 21 Apr 2022 16:41:07 +0000 Received: from mail-il1-x12a.google.com ([2607:f8b0:4864:20::12a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhZrc-00EHJF-2Q for linux-arm-kernel@lists.infradead.org; Thu, 21 Apr 2022 16:41:05 +0000 Received: by mail-il1-x12a.google.com with SMTP id d4so3412295iln.6 for ; Thu, 21 Apr 2022 09:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zJ2PGSI6AkHDlxF/GNqF8HmtNwa9bQE1NjwYidDeeG4=; b=pb+EWMdmgz1SYFX5XMH36PJu8yBtqr0Vp8AGddG8kaiOE9UKasHUfSsrOs+kJgSuXR OKFrxOBeYXDavmOeFnwrkdLL4nrogRXknJiEortPNN9IvfWb8G+Nd6qlAWgieJnihyTv bdZgytwpwpts9HrOXNDERUlnemXOUdayTIjMlMen7VrjysCHLtHhwnpMsskmUJnPLeru DTDn/wXdO8zWEHnAZtRNNPaB46buoPfiZ5vWQle6tdzev3eBZl4u/WHtpRquc/yNM/gE VyGcIVWlh+r6XYvo4+irYPo8nPKy9YfO/PULBFjDZMDLESvIdrXpn77TvcarqOxmgu2u ZWZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zJ2PGSI6AkHDlxF/GNqF8HmtNwa9bQE1NjwYidDeeG4=; b=N8OIzCR/qy4VVlexBXm5A+HQuYsFfBZBha0pbkX9oCWb8LeMyfPlSRECqtqmehwa51 G5D/APbhG+m4urpg524wil3B6Xon8GMtqRV4/qAZWIqXz5AE3i9ZRshQzPAG023e40Pq 6+xQ+diHDyxVbZbhw8obUNb6dNuGl7Ky3LdhzO4lqhdZG1BweAC/7guRSXnc3wzRWCI5 zh7EnicKXEn3ZqqAQVAqdyc0+AQl4U87mTh4l09z7UXacHuMMMK7eegjI2Nd5A5kPodq 7jg/fv3V/CiT0CFH3wE7jNHxyXI1bJ9bIw+fcJMNfioxYKaTPT3k2Io22P7TufMkZs1w TPAw== X-Gm-Message-State: AOAM531mwT7ZrN7up8gBBiWc/DvqOxsj6d5zi38CAVFNW9bl8aVn9Edy ZBqQUgCg4TzNoZw2zTHeGNfldw== X-Google-Smtp-Source: ABdhPJznCuS8lVwwartmfDZ1hMkeoqvEWgOgvlXvcS6SugJ8SjoFWUQHCgUp+HIoFk3yQVSQ1VLNBA== X-Received: by 2002:a92:6c08:0:b0:2c6:123f:48c9 with SMTP id h8-20020a926c08000000b002c6123f48c9mr301117ilc.22.1650559260642; Thu, 21 Apr 2022 09:41:00 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id j12-20020a6b310c000000b0065744ce0180sm117650ioa.8.2022.04.21.09.40.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 09:40:59 -0700 (PDT) Date: Thu, 21 Apr 2022 16:40:56 +0000 From: Oliver Upton To: Quentin Perret Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , Ben Gardon , Peter Shier , David Matlack , Paolo Bonzini , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 09/17] KVM: arm64: Tear down unlinked page tables in parallel walk Message-ID: References: <20220415215901.1737897-1-oupton@google.com> <20220415215901.1737897-10-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220421_094104_148099_CC9E7E33 X-CRM114-Status: GOOD ( 27.64 ) 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 Thu, Apr 21, 2022 at 01:21:54PM +0000, Quentin Perret wrote: > Hi Oliver, > > On Friday 15 Apr 2022 at 21:58:53 (+0000), Oliver Upton wrote: > > Breaking a table pte is insufficient to guarantee ownership of an > > unlinked subtree. Parallel software walkers could be traversing > > substructures and changing their mappings. > > > > Recurse through the unlinked subtree and lock all descendent ptes > > to take ownership of the subtree. Since the ptes are actually being > > evicted, return table ptes back to the table walker to ensure child > > tables are also traversed. Note that this is done both in both the > > pre-order and leaf visitors as the underlying pte remains volatile until > > it is unlinked. > > Still trying to get the full picture of the series so bear with me. IIUC > the case you're dealing with here is when we're coallescing a table into > a block with concurrent walkers making changes in the sub-tree. I > believe this should happen when turning dirty logging off? Yup, I think that's the only time we wind up collapsing tables. > Why do we need to recursively lock the entire sub-tree at all in this > case? As long as the table is turned into a locked invalid PTE, what > concurrent walkers are doing in the sub-tree should be irrelevant no? > None of the changes they do will be made visible to the hardware anyway. > So as long as the sub-tree isn't freed under their feet (which should be > the point of the RCU protection) this should be all fine? Is there a > case where this is not actually true? The problem arises when you're trying to actually free an unlinked subtree. All bets are off until the next RCU grace period. What would stop another software walker from installing a table to a PTE that I've already visited? I think we'd wind up leaking a table page in this case as the walker doing the table collapse assumes it has successfully freed everything underneath. The other option would be to not touch the subtree at all until the rcu callback, as at that point software will not tweak the tables any more. No need for atomics/spinning and can just do a boring traversal. Of course, I lazily avoided this option because it would be a bit more code but isn't too awfully complicated. Does this paint a better picture, or have I only managed to confuse even more? :) -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D5DEC433F5 for ; Thu, 21 Apr 2022 16:41:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231772AbiDUQnw (ORCPT ); Thu, 21 Apr 2022 12:43:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231175AbiDUQnv (ORCPT ); Thu, 21 Apr 2022 12:43:51 -0400 Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BCC140E59 for ; Thu, 21 Apr 2022 09:41:01 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id k12so3417500ilv.3 for ; Thu, 21 Apr 2022 09:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zJ2PGSI6AkHDlxF/GNqF8HmtNwa9bQE1NjwYidDeeG4=; b=pb+EWMdmgz1SYFX5XMH36PJu8yBtqr0Vp8AGddG8kaiOE9UKasHUfSsrOs+kJgSuXR OKFrxOBeYXDavmOeFnwrkdLL4nrogRXknJiEortPNN9IvfWb8G+Nd6qlAWgieJnihyTv bdZgytwpwpts9HrOXNDERUlnemXOUdayTIjMlMen7VrjysCHLtHhwnpMsskmUJnPLeru DTDn/wXdO8zWEHnAZtRNNPaB46buoPfiZ5vWQle6tdzev3eBZl4u/WHtpRquc/yNM/gE VyGcIVWlh+r6XYvo4+irYPo8nPKy9YfO/PULBFjDZMDLESvIdrXpn77TvcarqOxmgu2u ZWZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zJ2PGSI6AkHDlxF/GNqF8HmtNwa9bQE1NjwYidDeeG4=; b=iWStDk7brpaLh+IEy0cOrtIcfT6QVIx1iL9t6DDX6BLG7qTU+zxjm5f7gBIXdrt070 /wu7q6kSS/eLJkLepz6lC2gu2PTIbwaDd7r01jYTX6Lf2S+6vEfqyq4ScB135j6TUNC/ CLNQIBhBbE8F6tx7kx1QGQ9yO6wmtpYy6AJknpKCIJadbWmT6ZORfMUCjitw8TeqEU0i RijxWiZtryiosdvP4loghqQJyiOBDJ01SKaEiV9Ccesix2/C+VIj/NkFs2LjDJy3WC4n rY73YrSY5j1eSXoaquVt1EEYIq3y2fY8rMGx10QBrlzZ1Hd9uwwxHWZcDxbFmdxuI1AO f6bQ== X-Gm-Message-State: AOAM532n/8bVOLVNzRHuPuFUEkYn3KKUiCgNBAiI5EEZhz1I3NumIFVj bPMxkpOwdxwq5kI9ZR4oyKaSUQ== X-Google-Smtp-Source: ABdhPJznCuS8lVwwartmfDZ1hMkeoqvEWgOgvlXvcS6SugJ8SjoFWUQHCgUp+HIoFk3yQVSQ1VLNBA== X-Received: by 2002:a92:6c08:0:b0:2c6:123f:48c9 with SMTP id h8-20020a926c08000000b002c6123f48c9mr301117ilc.22.1650559260642; Thu, 21 Apr 2022 09:41:00 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id j12-20020a6b310c000000b0065744ce0180sm117650ioa.8.2022.04.21.09.40.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 09:40:59 -0700 (PDT) Date: Thu, 21 Apr 2022 16:40:56 +0000 From: Oliver Upton To: Quentin Perret Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , Ben Gardon , Peter Shier , David Matlack , Paolo Bonzini , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 09/17] KVM: arm64: Tear down unlinked page tables in parallel walk Message-ID: References: <20220415215901.1737897-1-oupton@google.com> <20220415215901.1737897-10-oupton@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, Apr 21, 2022 at 01:21:54PM +0000, Quentin Perret wrote: > Hi Oliver, > > On Friday 15 Apr 2022 at 21:58:53 (+0000), Oliver Upton wrote: > > Breaking a table pte is insufficient to guarantee ownership of an > > unlinked subtree. Parallel software walkers could be traversing > > substructures and changing their mappings. > > > > Recurse through the unlinked subtree and lock all descendent ptes > > to take ownership of the subtree. Since the ptes are actually being > > evicted, return table ptes back to the table walker to ensure child > > tables are also traversed. Note that this is done both in both the > > pre-order and leaf visitors as the underlying pte remains volatile until > > it is unlinked. > > Still trying to get the full picture of the series so bear with me. IIUC > the case you're dealing with here is when we're coallescing a table into > a block with concurrent walkers making changes in the sub-tree. I > believe this should happen when turning dirty logging off? Yup, I think that's the only time we wind up collapsing tables. > Why do we need to recursively lock the entire sub-tree at all in this > case? As long as the table is turned into a locked invalid PTE, what > concurrent walkers are doing in the sub-tree should be irrelevant no? > None of the changes they do will be made visible to the hardware anyway. > So as long as the sub-tree isn't freed under their feet (which should be > the point of the RCU protection) this should be all fine? Is there a > case where this is not actually true? The problem arises when you're trying to actually free an unlinked subtree. All bets are off until the next RCU grace period. What would stop another software walker from installing a table to a PTE that I've already visited? I think we'd wind up leaking a table page in this case as the walker doing the table collapse assumes it has successfully freed everything underneath. The other option would be to not touch the subtree at all until the rcu callback, as at that point software will not tweak the tables any more. No need for atomics/spinning and can just do a boring traversal. Of course, I lazily avoided this option because it would be a bit more code but isn't too awfully complicated. Does this paint a better picture, or have I only managed to confuse even more? :) -- Thanks, Oliver