From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sender-of-o58.zoho.eu (sender-of-o58.zoho.eu [136.143.169.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D45C5304BDA for ; Wed, 18 Mar 2026 17:29:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.169.58 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773854958; cv=pass; b=tkhcHpPB/spdx7ZEjGxJySjDO1ySAt+aya4zV7FNz++Y47XuCq4y7FAxfOF0XfiZix4yOJCKheWdb03q2PNmFTixUN3hxtiIjxadkl7An87HeWwRBSt4GB4f5+bU8+ioUnY3/iPXxAaBaT8IbP1E3XNcUfKd8FwJexc8k54eN3k= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773854958; c=relaxed/simple; bh=MzQgORQCweaG7XMZsOqfyqlDP2QfecDaZeU2oHpvA4c=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=jJ8lr1sGHd8kooipS6ysoh4xYlAn2LIdVhEDMeXpkbl0IRd5q5sCaGdBlYh5NvuhmWiaurAYc3Le0eDGRLW/rgo1hAMjB1ni5lEKQ/YTdVLa0CKvSHms4lqV+uT8En9wW5t8Dq+VEptNrgxZ8JaQv3EJBkB9BGa7OSpm/b3SYJs= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org; spf=pass smtp.mailfrom=objecting.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b=Bhoc9pH7; arc=pass smtp.client-ip=136.143.169.58 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=objecting.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b="Bhoc9pH7" ARC-Seal: i=1; a=rsa-sha256; t=1773854952; cv=none; d=zohomail.eu; s=zohoarc; b=Y5Ii2OXB+pna99RCFugPiFbrwwkbugq1TOOohAMS1aiQD9gHCSzFf9dRnFlwwSPsJvXGdC1yAaz4jdRb2GKGPJiE5N2Y6KwJ/A0IqAHfjqEUUXN4z53pJzivfXbdRzFjQlEAf1yQVLauBI6uiiRxQyzYlc5FoiMDpgMPqtzXJ7Q= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1773854952; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=+w+5XAKtfpeD65g0RxkZgSHGqgybEEk3gHX2DNKVZWM=; b=QqzVgIkBb7E7dH9pSJfV01kEFTvgBMXwMHvF8c64BmjVHzJZkuv5N77KJ4Wuqplyvc7Chr3lQ/lFygKP+gTsJQYwXOaqB7Jg0RsslcXzG0qQFvmYHKEmt5ULIQ+VU7gLjDHv2vYufQ30C6nap1KPvysY2aSYWGaSUgJkDJ1SQpA= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=objecting.org; spf=pass smtp.mailfrom=objecting@objecting.org; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1773854952; s=zmail; d=objecting.org; i=objecting@objecting.org; h=Date:Date:From:From:To:To:CC:Subject:Subject:In-Reply-To:References:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc; bh=+w+5XAKtfpeD65g0RxkZgSHGqgybEEk3gHX2DNKVZWM=; b=Bhoc9pH7+ekhihxw6/KnaYx5/y9de6HrhiOm2blluFC4WBEjQEpPyGduX0e3wYCR JV8PU2IjKF6yBVWI7JAA5mqu0uo0LRl5li7wcaQH2mPCTINPGDqYusDh+LTELYsHHWh 1ShHq91oNMO4vLVYOYV/bR9E/75OMaJOIFpVLGEQ= Received: by mx.zoho.eu with SMTPS id 1773854949704966.0933733032067; Wed, 18 Mar 2026 18:29:09 +0100 (CET) Date: Wed, 18 Mar 2026 17:29:10 +0000 From: Josh Law To: Andrew Morton CC: linux-kernel@vger.kernel.org, hlcj1234567@gmail.com Subject: Re: [PATCH] lib/assoc_array: fix stale nr_leaves_on_tree after gc User-Agent: Thunderbird for Android In-Reply-To: <20260318102319.0db807e1dc3e29fd1cde68b1@linux-foundation.org> References: <20260318164959.85841-1-objecting@objecting.org> <20260318102319.0db807e1dc3e29fd1cde68b1@linux-foundation.org> Message-ID: <540EA561-7291-4AAF-8FAD-857793B811D9@objecting.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External On 18 March 2026 17:23:19 GMT, Andrew Morton = wrote: >On Wed, 18 Mar 2026 16:49:59 +0000 Josh Law w= rote: > >> In assoc_array_gc(), assoc_array_apply_edit() publishes the new tree >> root before nr_leaves_on_tree is updated, creating a window where the >> tree is visible with a stale leaf count=2E Move the nr_leaves_on_tree >> assignment before assoc_array_apply_edit() so the count is consistent >> when the new root becomes visible=2E >>=20 >> =2E=2E=2E >> >> --- a/lib/assoc_array=2Ec >> +++ b/lib/assoc_array=2Ec >> @@ -1711,8 +1711,8 @@ int assoc_array_gc(struct assoc_array *array, >> =20 >> gc_complete: >> edit->set[0]=2Eto =3D new_root; >> - assoc_array_apply_edit(edit); >> array->nr_leaves_on_tree =3D nr_leaves_on_tree; >> + assoc_array_apply_edit(edit); >> return 0; > >But assoc_array_apply_edit() alters array->nr_leaves_on_tree and now we >immediately overwrite that alteration? Hi Andrew, It probably doesn't overwrite it in this specific case=2E In assoc_array_gc(), the edit script is zero-initialized, meaning edit->ad= just_count_on is NULL=2E Because of this (and since array->root isn't NULL)= , assoc_array_apply_edit() safely skips the block that modifies nr_leaves_o= n_tree=2E Since apply_edit() doesn't touch the count here, the explicit assignment r= ight after is necessary to record the newly calculated post-GC count=2E V/R Josh Law