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 E5F27C5B552 for ; Wed, 4 Jun 2025 04:33:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 615516B0582; Wed, 4 Jun 2025 00:33:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C5FA6B0583; Wed, 4 Jun 2025 00:33:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BBE76B0584; Wed, 4 Jun 2025 00:33:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2BD226B0582 for ; Wed, 4 Jun 2025 00:33:43 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8FB26C01C1 for ; Wed, 4 Jun 2025 04:33:42 +0000 (UTC) X-FDA: 83516449884.12.04CE6EB Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf12.hostedemail.com (Postfix) with ESMTP id C06EB40005 for ; Wed, 4 Jun 2025 04:33:40 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=k4r5apP8; spf=pass (imf12.hostedemail.com: domain of akpm@linux-foundation.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749011621; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jYI7/eFIpyCLrWIf8IBDx5vnqMPpaySlYSgtOjWpfbM=; b=solOTtULqVYZfAr15KSypCM1vV83R6lh2qrsh5lxbnVeUHMEWIrKH6txF4UAFTRhlDieNN o+odnGzJU9ff1AYtQJhY1/lb5bbqFMZuvuFJ5NUPab9D2HUBFB7f2IJ0rMo7Bd3gtdgVRi c6hc4tqVzwjVtnBGPrbYxY/BOyHYrmo= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=k4r5apP8; spf=pass (imf12.hostedemail.com: domain of akpm@linux-foundation.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749011621; a=rsa-sha256; cv=none; b=bqQkHn6ckqjZXUElJDwX7mSuvBrPArYk2lbapspwfcI3u5/V2RUUs8l6SRI6oJn2nWNWMD eh45GZqqk24KC5WLBaEekxwBxMm3M0kmR/eU4GVUrwUsOyQOz5wvcB0U8PDURJXQ/QuyRo FvaB2vTn8yJEki0tWaJO2WnHaWJg+8I= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 5BEBE4A5F0; Wed, 4 Jun 2025 04:33:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD94FC4CEE7; Wed, 4 Jun 2025 04:33:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1749011619; bh=9NeDDdxV0q4sXEFhvG5y3MBDGxM6rM76CNHh5/RF2/c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=k4r5apP8Gx8lEe5htLA+PcDXUKwh7TZpQZgx5DX5ZFjAb+lHsV+QQC/pZDznExcu4 tgEPBts+Tx2ZiHI3hZe0BW0QYQB6Q8KEZnGyfZ+lLO4l2QDJ4bWLQ4B2xUIi6J88pD cOyBO/+8jH2lK3ig/zy2cKtbEg2B0MinQpkPGiB8= Date: Tue, 3 Jun 2025 21:33:38 -0700 From: Andrew Morton To: Dev Jain Cc: willy@infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, david@redhat.com, anshuman.khandual@arm.com, ryan.roberts@arm.com, ziy@nvidia.com, aneesh.kumar@kernel.org Subject: Re: [PATCH v2] xarray: Add a BUG_ON() to ensure caller is not sibling Message-Id: <20250603213338.7d80bbe0e021052c20e1c5f5@linux-foundation.org> In-Reply-To: <20250604041533.91198-1-dev.jain@arm.com> References: <20250604041533.91198-1-dev.jain@arm.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: C06EB40005 X-Stat-Signature: z91zpwc463abxmenm56bydef6rxdf1uy X-Rspam-User: X-HE-Tag: 1749011620-894759 X-HE-Meta: U2FsdGVkX18sNF45wlvK0h+nC0SVPzvz9giaorby8iK6do1QmihHJnmPsfxWfu9VIDqT462LtTkID8dPI8oKqVf02/GNk39LyFEmIABWcA1U1yegwKf9Ti4+RsjC1neqnQsjd1uYN029G8nDmlhkXAwh0hV8++zMKwvVqpjlYO41V96rt5gJXFkSC4T3G3h++4qxPY6M3TWnm1BwvvUG21t+0W8YPk8g5raF6Yi3QHbN0ID5vc0y2UlXrqXd89G0Zbw0rYEz9nI3iiEUFDr8A2jkQFJ+Uqi66DMlmrNVJLoBN2TauWhQST0f/mQV5qO9VcY877/REQAvJYPizGu/0tG0ZREDGzuf6VGYa69uQr9SWy8Pfl/VRxk31kSqFhlhs6MQOVYL1mu7DUeoTFPmUswz4KwGNM9TC6Ff0YWvsveYUQFB0VNhjXsRmclSjQMRdfgAQKradTM8HVMDgdPvOTUqwEAPJxctzf74mk7oAnmggBQwGm9ZVqz02rgsn+pIigxtvZo88QKeT3h+B0Xa0Qmfl7/bFYkfnQJRoM6beOMKtdc4DrEt3O74YoeXUkUU3styDRSh4gFXY/+xFrFP6e6BGiy9YvOJG9OtPZWQVBQu8me277F0b7HFNy5xsehh3zNd7Ce2WegLMiupuUCllUjUCv5qQ9KGCXvShn9DqpzjlBS16WAFlvgaUSPQf9zjFINrqdVsamEZYCIovoGvznPJ4c9WdCyFp8ZCgBr6Y5a1naEnYYoOED5RRnW2hJaMNobLVd31uUTzxhJSUetTBOeuOvFSFjFut7P2iTrRgOnQabloZW0Hd4IAj8uKLX/kMoL4KsKzOg2Jpm2DrcHRYTcSQY8P8dYKGxYpBVs5F+C9hkYKJLLE5d6i5oGodBZPxi+4fWB8T4ZuIso3t8YufyS94iDl82t9uuK28+vCKlBByiLurektfaOyUamKpLNtnPyMVpIQpncKI1pWSTG z3T0mlq/ FcfTXHgE1N0TZYUJi1OiEvidFjds46VTISxYHzVf+MM6hRIZ6p/UslDYck1V3eY/CP7kFeFvn5TU01bC199biMdS8VMJD5jXrteWLH1VozMuHe26wwXh13RpP35lfRp9if5pTg6mAOEw252qYteHNuitbLPKqzRb4sePkdMQxSwAwrEMB4ZsEbTv1PqO3XzDYfjZIJgW6BLaud2QBt+JVRDiW/fkCccSQtYmv4HTK1WfkxT2yMuXlXc1VBLLVPeKgnDE+y8oRd64voqY59M/uF+oWv4DqEH/SvbxEl41220PnQkRdKz2ip6mthn02mzyrR0UdwR2zqcUUdCqdI0Y86Br2EWdlFCwV3cMjXk0FezsCCj+FwOXxXiLtrtzACn4OPzP5Zdq3FP22fVA= 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: List-Subscribe: List-Unsubscribe: On Wed, 4 Jun 2025 09:45:33 +0530 Dev Jain wrote: > Suppose xas is pointing somewhere near the end of the multi-entry batch. > Then it may happen that the computed slot already falls beyond the batch, > thus breaking the loop due to !xa_is_sibling(), and computing the wrong > order. For example, suppose we have a shift-6 node having an order-9 > entry => 8 - 1 = 7 siblings, so assume the slots are at offset 0 till 7 in > this node. If xas->xa_offset is 6, then the code will compute order as > 1 + xas->xa_node->shift = 7. Therefore, the order computation must start > from the beginning of the multi-slot entries, that is, the non-sibling > entry. Thus ensure that the caller is aware of this by triggering a BUG > when the entry is a sibling entry. Why check this thing in particular? There are a zillion things we could check... > Note that this BUG_ON() is only > active while running selftests, so there is no overhead in a running > kernel. hm, how do we know this? Now and in the future? xa_get_order() and xas_get_order() have callers all over the place.