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 6BD8FD20693 for ; Wed, 16 Oct 2024 03:24:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0EF66B007B; Tue, 15 Oct 2024 23:24:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBE276B0082; Tue, 15 Oct 2024 23:24:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A862E6B0083; Tue, 15 Oct 2024 23:24:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8B2C76B007B for ; Tue, 15 Oct 2024 23:24:30 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C981DC1955 for ; Wed, 16 Oct 2024 03:24:19 +0000 (UTC) X-FDA: 82678022406.26.36AD3A6 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf28.hostedemail.com (Postfix) with ESMTP id 15C62C0007 for ; Wed, 16 Oct 2024 03:24:19 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="ZYrwu/Vs"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729048962; a=rsa-sha256; cv=none; b=1iIp/9azg3GvdkYoB/r4Tcg3eXehJ3dNlqXSYejM8xPVFFneFi9148cXWi8KTU7+CjP6MB 3D9SB36ftjuZxs1PtC2UoczhslWoXEI81ZI5mzxZ06dKN4Cyvr0BPDMpUyUVl/3k/DXsfP YtWytkUOJuBOvlIP1ffKkFUYnsOlfjQ= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="ZYrwu/Vs"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729048962; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8tELUSzMWUOpAB8jOTRO2YAemySUYu8k/Lm6xY5dF1A=; b=RSUdOXzGmLCwrK0MhAxigqwsj41BVWXB1JR9cjrh1zVqHc761fiCqUuTEZvZuK6+Mgp7dv ckWumSn9eUJg6nhgbL4wKWghRf/6az5rYlqeYOOulxA6DtwsBSCS+NdjzNvKjYb9YHkWbh tYUXYKsEvshM9q3C+WhVtV3BhTxLW34= Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-37d4ac91d97so5165405f8f.2 for ; Tue, 15 Oct 2024 20:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729049066; x=1729653866; darn=kvack.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=8tELUSzMWUOpAB8jOTRO2YAemySUYu8k/Lm6xY5dF1A=; b=ZYrwu/VsF2fvig5fKZz967uJevn/rhxGfJw6V/F4YIkifEpjx/FXpdIwyiHwclRHBO ZK186SnT2erMeCMVsiA1Rdd4g22Vo0ChtJQyAECXYUY+uBubaFoRsbggjRKfHQ8DtBDf +bW9Y7Pqeo4FhzAY1ggiL+fxQd/XHCz957V5q4G0aVUX7XkGyIXM3fdmvpI+umpOLVqH 1ikw1gHJTpPjFvfShrEFBqJQUhpcDyAhEEjEAFVZccdaOIbdtfOITGe+HUIreIvQ/1vZ ilzmpSeACON/uhXzuJljzq+1W6JPc9ZYFyoL7e3crrNF6/pD14NPMZEveilrQJruG9NC 1rcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729049066; x=1729653866; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:to:from:date:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=8tELUSzMWUOpAB8jOTRO2YAemySUYu8k/Lm6xY5dF1A=; b=aGHtd863gM3tZKyG/BdpysHXlDhDZv5LylP5gzJm/iG4ByWEGaZiXP/hadzt3zpR5Z ixqnye2T7fzHlygfG2YGuNLYfa67tSMAR2seXx5AWxD36TM2SeqnCzVq9vkqSxwNNhAX itl8qi56flalL4eJevx72M0vYxAFNxwLTUnV+5TyYfqgmg0vpPY9TLrqDSJjN63YvwzJ bcvlQue6DRZ7b/c7AA4AwuiDL4OBqEbZ+3B9WLFiVpZA1vdpbZOlwWWQUmpf59bJg/tk GJN/xa+sGA5kAEvvcMy3XFx9+OzY6aEpyqkxgLQpfiRAy/z8dk49BLtwO3DMUi/xOf6b YA5g== X-Forwarded-Encrypted: i=1; AJvYcCXja5+ckCTg7eXugV4rieNlvSZmjTo2/xvBLxDKOUXF2PGrv7jgNok71C44+8Uaag4iYndv/uzgaw==@kvack.org X-Gm-Message-State: AOJu0YzfdN/9NXDE8G3D6AMnVHqJmLugu9qkzNsQRhfFSAUSWknPvumC WNlsxbQjDDalKT9Rgykg27s7RDV6W6AUda3Wadodb5U7HOuNS7hD X-Google-Smtp-Source: AGHT+IFZlYugadrO0iayZtHQwwFfpbfjOuK7kKyV+a8hCKuBO6Hw0qvaIEik/7tpm3X16aqMlx/mIw== X-Received: by 2002:a5d:4587:0:b0:374:c3e4:d6b1 with SMTP id ffacd0b85a97d-37d600d2f9bmr11684373f8f.44.1729049066240; Tue, 15 Oct 2024 20:24:26 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9a29850ecfsm130112666b.187.2024.10.15.20.24.23 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 15 Oct 2024 20:24:24 -0700 (PDT) Date: Wed, 16 Oct 2024 03:24:23 +0000 From: Wei Yang To: "Liam R. Howlett" , Wei Yang , akpm@linux-foundation.org, maple-tree@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH 0/2] fix mas_new_root() Message-ID: <20241016032423.sigxswziwqpj44vl@master> Reply-To: Wei Yang References: <20241015233909.23592-1-richard.weiyang@gmail.com> <20241016021830.6pfc2z3f62qh4xuf@master> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Queue-Id: 15C62C0007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 9n3jk6k1s1yj917yphrf8wg9hmrtb6bz X-HE-Tag: 1729049059-889519 X-HE-Meta: U2FsdGVkX18UWlCK/OAYFnCo+aCB05LCP8+NTnyLNxdixQtFADGAkCDJa1IcbVy31UCLZYW2OTmDMgsaKNE8BghYBkp5R3yPYgq02gVAHz0YcERguocl4dd7h38CkohD0CIcTiXZR2dRz+BcnfbMUyebhYRvwfE1FxFQGWw+mlDAZcVU1Rii5UigVpvzj6t3mm1BUidwUWS2PQmYHNGGzTiGIM5uoMLjv4FNnGxfvdE5EOwvmMONzfn+Yj77FXi5gr75Jj57yzSAwdAGOMHTsxc5BVz8LiUwjk3uf3WAKfm1ybUnuom+0j3JR6QhK9Fq1I9dPCSmR+IU727Npfc5QJSLghbmJO3P7LSuXZrlvlNTkkY86yAJA4KfrW1mostvvULBSCWvGxHRUQjWFw1sEt2hXMZ+7qmrfkpnLrVH7nO157PJTe9BWGu1M8eh8eE5LXkg5Xs6dmPM6AiOr1TRJpjw6Ty+/TPPn1ojY8zqqJAniQb1rhjdSRdJeEY6kp9cojgTUxLv7mF5/wHA0hQf1LVbigNfErSCSlahFL9SwvlhYC2kr4An7+1zbREBnOiiWHOjTlYZln9DDjTnIjE/Fjs9pEAwJnuorrIcxIG7p9x5aqh9/0Fo2AF+uF+91dP0tKTghru6k92HHkN/RzRCbW5pJcGOSMBX1sXRQ8mUlHn6rk7hJBqha1bRZ0gHfcAREDhY+05gqzMVihN90NRqMx0Z4CHjfHOKT56fbR3y7bRDLj7k8kqsLUW8I+0/TP5hzhAUDTAn7cB/P01OTCpWCD5XP8TQ50v0Jhk2PXYDqJphZgxcYHcrMEdv7tEm3UotlqwR29nKMbC1iuMQwtsM8MPYpSEg3m80bMj41AqKNc5eTyq3df9S6x9xE5Ve4nfaa2KUWixEU4AzptWMiQzj+TRpiAiHQ6UTSxHAxSrcAm63x21wE9emyVGzcrQ3q2xjArkrBPz4tHbQLRh/jqz ObrkBgbJ GSKXMu7pxcB3sCF/o9tShtus4c3nFe366znPG/2FdZH7FwH1ZpXobt+OJtsmYmFXUnW65qv2St0OUTtjPT0OylAsnw6W2+ZUbQEjjluCFIZBdsog2r6gJJ8a51Bi1PQyXd1YQST8FDCKpMVednDfGAwaNDuVXb7QqqEJIuQjXbmG5RguqJOn4kUdj/9D2VSdZ1Pj7KE4jqvfQ3sGyLcUr/7xgFYScXIm7i/seSyCvJ09M11OpnYWOol/H8Whchc0WwfeAIiml+DPsUsFVnMvgflmPcrdZjB9INktuQrObRYI58iJnPBjel1qUZlSAM4P+Znrr4iIfyMmlxvWKrmvM6pp6MGeme3GpEBzqrnOa6InpUutIhHSxI1wFOWkdbxjas9ihGiEUIs+cRukunHiypC08qmicaDjXrhfhwZwiV0OJoXX+TKnX8NcuBKJEZGyw+ZGDovzsd3aYVpJHFsZuAUOSWgm9OawcxyVVjQ84SKX/yc3Gs3UzQC22d73v/QZDraIZIp6A0LkpPtPmyYkIDa9ziYhqj1bK7i+ULRA8jDTcuPbi7S1fEgpRJjEh2fru6+bek55DB51ods6V9yO8bzTcHsui7zPRC6jLtKw+eWW1uqg8uPlGukZZwlOPD/ShhFFBs5dWmGn3idohPXqMDp9ObHWS93Jvj5KcHg+Q/MIYVhymNyqOi7bFY1weC78KqVn0rVO2R9gtXc9Cn6SM/EQ0Ng== 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 Tue, Oct 15, 2024 at 10:32:41PM -0400, Liam R. Howlett wrote: >* Wei Yang [241015 22:18]: >> On Tue, Oct 15, 2024 at 09:25:19PM -0400, Liam R. Howlett wrote: >> >* Liam R. Howlett [241015 20:42]: >> >> * Wei Yang [241015 19:39]: >> >> > When overwriting the whole range with NULL, current behavior is not correct. >> >> > >> >> >> >> This is really strange. You have changed the code to be wrong then >> >> removed it.. The second patch removes what you changed in the first. >> >> >> >> It doesn't look right today but what you have done is also not right. >> > >> >Looking at this again, the code that you have changed is correct. >> > >> >I actually think the bug is the other way around. If we are >> >represnenting 0 - ULONG_MAX => NULL, then it's an empty tree and we >> >don't need a node to store that, and shouldn't. >> > >> >It's also not really a bug, but a missed optimisation. The ranges are >> >stored correctly, we just use too much memory in one case. >> > >> >The dump isn't clear, but since we merge NULL entries, if there is a 0-0 >> >-> NULL and 1-ULONG_MAX => NULL, then they will be one and the same. >> >You could change the dump code as part of your fix. >> > >> >It's like the init of a tree (tree->ma_root = NULL). >> >> Agree with your above statement, this depends how we want to handle this. The >> change here is to make the behavior consistent. >> >> Want to confirm with you: the fix in this patch is fine with your, right? > >No, it's not fine. You are removing an optimisation. The issue is the >other side of things where a node is used to store a single range from 0 >to ULONX_MAX pointing to NULL in a 256B node. > >And, potentially, the debug dump of the tree should be more clear. > >> >> > >> >Please don't submit multiple patches to fix the same thing like this, it >> >makes it look like you are trying to pad your patch count. I'm guessing >> >you did this to keep them logically separate, but when you completely >> >drop the entire block of code that was changed in the second patch it >> >becomes a bit much (and hard to follow, I was trying to figure out what >> >branch you were working off because it didn't look like the patch would >> >apply to my branch). >> >> Sure, will merge it. > >Merge changes like this in the future, but the second patch in this >series is wrong. > >> >> > >> >Please submit a testcase with any suspected bugs. If it is not possible >> >to do the fix first, then do them at the same time. I often write the >> >fix for a bug, then recreate the bug in a testcase and ensure that it >> >fails without my fix. >> > >> >> Since user won't detect the difference, so a case to see whether the root is a >> node looks good to you? > >Write a test to find out if the resulting 0 - ULONG_MAX store of NULL >results in a node. If it is in a node, then the test should fail. > Want to confirm: Store [0, ULONG_MAX] of NULL should result an empty tree or an single entry represent [0, 0] as current mas_new_root()? >> >> >I am not sure the fixes tag is correct in the patch either, since so >> >much has changed around this. You could test the older code to see once >> >you write a testcase. But the bug is using a node to store 0-ULONG_MAX >> >=> NULL. >> > >> >> So I should drop the fix tag? > >Yes, it's not a bug/problem - it's just inefficient use of space when >someone tries to store 0 - ULONG_MAX, so there really isn't a reason to >backport. > >Thanks, >Liam -- Wei Yang Help you, Help me