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 84C9BD20691 for ; Wed, 16 Oct 2024 03:16:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDBB46B007B; Tue, 15 Oct 2024 23:16:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D8B3C6B0082; Tue, 15 Oct 2024 23:16:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C52996B0083; Tue, 15 Oct 2024 23:16:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A7D8F6B007B for ; Tue, 15 Oct 2024 23:16:17 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0288080CC7 for ; Wed, 16 Oct 2024 03:16:08 +0000 (UTC) X-FDA: 82678001658.19.F968D5C Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf27.hostedemail.com (Postfix) with ESMTP id F110840006 for ; Wed, 16 Oct 2024 03:16:06 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=glne9Rwf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729048469; a=rsa-sha256; cv=none; b=nC0S/Gj+AEfglFfJjP18qHfz3OoPWxJaYwHa6dlBW81jyEQUQ2T81jSKqR6gKsKhAjbuga YvNw8lmhmOfl+/mAjX8p9yItkunGdefhgOiq8s7+VtcGKnW0DMLZf/MZwvfsjF5K2L2Kl/ eQqWs5D6J6v3U9V/JRjOI4S4+Uas2Cg= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=glne9Rwf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.218.49 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=1729048469; 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=D8p4Z+Br4Ungs7HNIAhMVHw6q2vxa95uXCI26RvCh3E=; b=M1P9TJSmJgY0J6MTUqzOTfRduljxzuz6/HUlZQYRVRh2t+HSdaiitcwPBZ81Cg7LuV45d6 tkJQV3A8UlMm8E1lCpmWFoHeRT34bq5/YCSYdIdf8BfE48d5dSlDjOIPNFMP25YKxo8xhg tfk78I7hfwNMJfFgEsE8L7EzvphVlig= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a99543ab209so933334066b.2 for ; Tue, 15 Oct 2024 20:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729048573; x=1729653373; 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=D8p4Z+Br4Ungs7HNIAhMVHw6q2vxa95uXCI26RvCh3E=; b=glne9RwfQZRVdnTcLg/wJL4e7pCI5+6yproz7ESTIgHZD4juIO8kjEwfQndVCumvaQ bKRFVuurGTp6HGBHsBp3uvkRWw4Lwvb4uR19yZqm/njyPk6tUSLc/02u/OrTuOYnQ88A w1b/F9oL4vxf5prXJTVdKgVCB21iMuJlz9S4Jz6i9/O1Ot2kiraWBVMrX3SyvlrqThtf tVThgZm5BYihR00NgOvv3TPjhoJmUnyMH3mFDn9ul/X9n+T4/eAmVloFV2XZwEZWE82n G8dlgffhgum06EFdaCS6ygE9dPOcjNwuWpMC1vXABaUaO/JwH5YZBrC/jgd5AG3ntob1 DlMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729048573; x=1729653373; 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=D8p4Z+Br4Ungs7HNIAhMVHw6q2vxa95uXCI26RvCh3E=; b=aAyjzlcCaE0gaNy3w/KrjnTpAG3EJCuK5ZU0wehsrqOJHY2kOPXdiWssHOZowB7TgC MB9pX4FWLFWHgE+JlROT8RkvYp8CRC7SHcw/nFaChlnMY9/3XseN66dINMglNsrT8pvK CR93tNVDx5jLYMuWyn9SLFhNjUDiK6JssJEglhzGE4rHFJPlnEl08/7XVelrt34AxtR6 4i6SEwef8XYOI3l+l+K820OwJy/wfUNWcySeK0wDsDOlOzL8sm6dEfofVYCysHc4wow1 jGPmHZSI+hp3ghgMrv2D4CgginUKtSBA8HpGDxxxBBn88JvztqwXGZE9gSkYymIr47Ed /axg== X-Forwarded-Encrypted: i=1; AJvYcCVNt6DWQeYSICGoNj2JQ2E44NMaTHxFyEctck2QfB+tC+W61KndHe9l/ab9EZYXCiZpaBdZIJ5KNA==@kvack.org X-Gm-Message-State: AOJu0Ywyd66yaa0A7nbrYObKq4fZY5y3MIX9QLMp7TTsbOgt1OAM0tSI BhjfsECuh5Y84krWekqmA+ZmmXoPUcvpSnBTHrZA/pdSoY4P4Gye X-Google-Smtp-Source: AGHT+IHFUooePn/XXzAbQXnN/aLDLya3GS6rkCIRGKXGS3PfMjfIjTFY/JFfpwqCsKZiH87tknCaZg== X-Received: by 2002:a17:907:f19d:b0:a99:f283:8147 with SMTP id a640c23a62f3a-a9a34cfa73dmr176083266b.27.1729048573164; Tue, 15 Oct 2024 20:16:13 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9a2974a49asm129603066b.89.2024.10.15.20.16.10 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 15 Oct 2024 20:16:11 -0700 (PDT) Date: Wed, 16 Oct 2024 03:16:09 +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: <20241016031609.3zug7hgkecy26dni@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: F110840006 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: sc3shrf9s4s6jt8itg4hh8sexsdiq767 X-HE-Tag: 1729048566-648661 X-HE-Meta: U2FsdGVkX18LBmHnoXyh8JpSriZOO+ETCPFGGOsxNrOHyoqMnKZ9BIyN9vkIxf4xZt0ekudn1VA0BdqkitRgrFMC1QAbmBvRhFLk6Z2HqG3b8WV7Wg6eFGg8fgVK4LNmSvsV87Emtyva8H6FLmwrpMK7MX4vmWThBw/o9cPiDBUoEFFnrF02hh1phfEzmpLXcNDls2/aKIkpliZLXtbxF3lHen8WPonTERfgpfgsKoM/hbYh8sS+snnEPSncLnhmjr2VWFfSEbYU4aUY3ja0pV2P0R/+tjx0Ga3xxvrWpQphWyFLlt1QZUSh1YSpfo7KbmXLvNDC3hya3t7VcqoAUxgUBKSmcqYXGhxGZutJRqyR6s2VYgILHhbS23ghkVTmFwj+x/nDmkexPSbaQqsKiD/fm7wIA48O6vSFTpEvyDl7kvCOeMkfrzWOLiuygKNr/vQGVTvtbqhx5KvQBDbzT0DAUQfiEvNmTq8AjOWlB3uXDZtp6rG1c1aJf0AtAYtVtx12dKs+1b4Fp+g67bW1618fdaelua6IgyGzVtfWSNHx9z4toQvkDI5W+2ofhTIgY7xmcx9aBEmO8UiVSKRUG3jN6jkbpZbqaRwBk2RywbeYpBTbvE9lYvfh9JMr7UF/M90MOb4p75j+TDi28nzFw7y89oQ8ws3qKO/6MO/f3DGy4on0PRdeQk6Y9kNyGgutAIo7P5nM/J12G7NKF4q44m2wMh2OSFmpb73EeNyjfVGtEwKvByULyEPn4IrO9yhMXLgBhGb9xwjleyc+N48GMQ72lv3w4bbRtMPc9hs3aOd71kR5pFFmTVweqW4Db1lqu/ICHvMOG/YTlZ0r0OusYAlzAY0HMApyFHxgzIGRto9vy6z/+6jmPxOFAcUmPOQZpK71rlnGC7KTgmyvEY5h5EZeCxK9EgKDVMMzFIYbHXRxfI3id5AijcoB1ovpf/DWMA/9oDXkrEiWPPkOu8H eaehlnLf rEzSk7n26iw2BwwisuXBWkSYB5+UgiLDCtzjzJPISr2GghJ5b8+9zsE0vlUi7urdTlbEbOT++P6l0k/6cDNb9s2XY2lIo09tYdzPJqwEpcmVOnTwMvqlwdV/Mn1uPeV7itWd8zgMnoRQGsh/x7ReGhlCQ7D5RkDhOiPAUJ+CxOhKS9fCTtlsZxKwFqFNcJiBSAa1YBYRMhMdqzjMTsNeHvJifDNxJKjqsWQ0D4Jx5CVTZhOsOpy/VuLsQr781b2rUvRK83iw5JnKA4EhJ5LYdh1DrXrkT5wnxI9hn2b1b4NIMyYL+4puI/70QMX4K+Bb85aa6f7x4x/95INTiVc5nl3SE73Ku1SdZ1ZZbxj1N2m2cZHHGTcs/GPoAxnyWiq7rPG9AwZIbkDcD0B+szbvn2WYIdC7AG8vxWsR6qvGBWHYcWCUYPQmwW6tkN8iF7H9786PsN7mDebHUSd6/fLn03bEQYkv6ycfTrlhqV3TsB6pKkfnIgnWvWaq31FiZ+6IB0SdXAPvwqZ09Rx/tqVneUvJHhJYQ0ipyMavSe5l4uOfkEMwx58RSHqKytji1NmRva083c3TKmWeK9UyAyhKkmr1nhRoYJ5qGNTbOfdLzhfcwwZNpZvZp2126+lmd7dhl4wCruMmr0cR2hCJKEGr4cJLbH2lARZSas7ozC+xYqZ6P9LU7WPVZg+zR047l2RS3JiDk03v3lJTvV3wWUKQbwXtSQQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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. > >> >> >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. > Ok, I see your preference. So current behavior of this is not expected, right? mas_set_range(mas, 0, ULONG_MAX) mas_store(mas, NULL) This operation to an empty tree will create a node now. Looks like a problem? >Thanks, >Liam -- Wei Yang Help you, Help me