From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sender-of-o59.zoho.eu (sender-of-o59.zoho.eu [136.143.169.59]) (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 4AE9E3D88EE for ; Thu, 19 Mar 2026 15:15:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.169.59 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773933325; cv=pass; b=Ism66i2Xb8dhFqCiaOe26tFaDwNd+O+YLOqGpW74a3crCWWJLsjAitOO15neThBw/oIKmGRf0FmAziwUo3V4V5v/Lu15cG1ix8QAwLwjv7QdVI1ZD4hhpQuOHkpbFpClN6L32OYiK+kLYBKsqGgx67UFJooC2sE5N403IeoT8wI= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773933325; c=relaxed/simple; bh=pcWAopZm63IguKM/Y8SnrsLFmrIW9vt0coYATUpqY3Q=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=ZSMYYBgbHtIhpcJvt2bi1JrlsA0AcliJ7fmNZAKZSSYvc17dLcmitd9vhFfZ3Osy8Q0ASTZ9DdrF4omreNIgZqhBNr1xp/fs1q2ibH1d2XLj1F3sfIUvr+CtzyPzuR38V1PF+TF6MzhDpe7KOTuxvd21rHlgl1zM+EFq/mbSCDI= 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=iqrviPno; arc=pass smtp.client-ip=136.143.169.59 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="iqrviPno" ARC-Seal: i=1; a=rsa-sha256; t=1773933314; cv=none; d=zohomail.eu; s=zohoarc; b=ZtrelBZLytaEkBwKxhj2hp/rZQbktANf5AeCqbhuoySCn9szhym9SHmQDe5EP+Sbscx8MoqmemJgbzXkC9j9NO1E6DaXCokDFErmI/revDJLcZ7JrBx3kzp4Wnx+m1tSBSZfKcsAKuLT+qaUI4gKeofO0gDcY8VEMFCwBFfwRAk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1773933314; 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=vXP/uguMO0eg7qh86iM+Uyfkm6l3LxRZBwvQRLwG7a8=; b=Wjwk3jIW3S7A4G+bw2LVxNOFdOJPXDDLqK6qLmVibXbIxK4V8Bl9EHFly6fKe5iE601iIjz1+1B/Agu7OQ8MLDlF64JWIuyALRUaURb7VjXTINuhm8j1CfkNMNxLel1WtwY7vHOGWvQG2yFlmNneJPu5SxykfyiEJGiaPgiakus= 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=1773933314; 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=vXP/uguMO0eg7qh86iM+Uyfkm6l3LxRZBwvQRLwG7a8=; b=iqrviPnoHhKEnzYHb7xQWdIp3wAuWIxeKg+I2BAKOsZ7Ovw+LyOmh0QTG2CGuKBk sy6NQwMB2bjex8D3vuhG3pEEUElbpGVLpn16h6qTdgftMHHQI9ym6r+/I1oUR+RDbmA KmXL9YpP4i7WusTZbJAY9b9NrIWvujMAMEuTBvVo= Received: by mx.zoho.eu with SMTPS id 1773933311627796.3944445884487; Thu, 19 Mar 2026 16:15:11 +0100 (CET) Date: Thu, 19 Mar 2026 15:15:09 +0000 From: Josh Law To: David Howells CC: dhowells@redhat.com, Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] lib/assoc_array: fix stale nr_leaves_on_tree after gc User-Agent: Thunderbird for Android In-Reply-To: <4186139.1773929698@warthog.procyon.org.uk> References: <20260318204515.26931-1-objecting@objecting.org> <4186139.1773929698@warthog.procyon.org.uk> Message-ID: <971D421B-D22B-4C0F-AF6C-704CC95A9F02@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 19 March 2026 14:14:58 GMT, David Howells wrote= : >Josh Law wrote: > >> 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 > >This just moves the window=2E The count is then inconsistent before the = new >root becomes visible=2E > >Note that there's no guarantee that nr_leaves_on_tree is stable if you're= not >locking against modification=2E Further, if you look in: > > Documentation/core-api/assoc_array=2Erst > >there's no mention of nr_leaves_on_tree being part of the API=2E Unfortu= nately, >C doesn't allow me to put in a private: marker as C++ does=2E > >Note that neither assoc_array_iterate() nor assoc_array_find() make refer= ence >to the value=2E > >Are you actually seeing a problem stemming from this? > >David > Well, the bug actually is there, and if i made a mistake, this patch shoul= d atleast be hardening level, (As i say, better safe than sorry) V/R Josh Law