From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f73.google.com (mail-ej1-f73.google.com [209.85.218.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A0C493033F8 for ; Mon, 9 Feb 2026 08:23:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770625381; cv=none; b=cyejho5w8lSdljE3/oMCrvGjK4enQzS7vFpLk8JJpzSfXnY5S7P7lOpNrkKDgUXKDziVRDY8bHA8Y1g0cX5t1N9TCKjA5BKTNL6x/w3lAhinZhxRMyCy2h3MLwridIMc9UxfqqGPP7/AxR0eR7MTEWypDw3r74R4ujEEF3y66Ys= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770625381; c=relaxed/simple; bh=u9KFcok8VmsR9j/4O5Pg7VJFj1YapmytJK90G5hcIXU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Content-Type; b=mXzO7Pf/QZ0sfdyM/aencfPr+pxXwM9K0aEXw8vZxWywvHwqjvs24PYyslX4ztqtoHkGedRfnDoesZ32GhtPweDgsFiwhwQ4bFlE0slsXdQOoZBWb0sKO0s9JWpe/Wu2GsCVWNKuu6JSIiCY7F2bYYQdft3SApEwrYgiC+/ygB4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=UWRR6fLP; arc=none smtp.client-ip=209.85.218.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="UWRR6fLP" Received: by mail-ej1-f73.google.com with SMTP id a640c23a62f3a-b8704795d25so231455166b.2 for ; Mon, 09 Feb 2026 00:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770625379; x=1771230179; darn=vger.kernel.org; h=to:from:subject:message-id:references:mime-version:in-reply-to:date :from:to:cc:subject:date:message-id:reply-to; bh=1z62XI4JGEoZVPtufxwSYx1SFhBLLihIdxzj7l54Q9E=; b=UWRR6fLPL8ivWWL+GF0AcC+Ts7QGJ4u5me2VQaCPxrF98uTukQE/7ofm2dH1NsuQcA G1quuKCCvbtl9/CDIEjqURCjKKYJb4Ea9PIoWrZFwS483qYOvOBobn+DfFPakn2NNoop ru/3MKu4uDqARuekesXzWEmzoPmEAxLTuCKfgGW9mhd9LXKxwpNdII47zxifhOtIaBsr tRrFTV2XTSs0qte3jgNyQCn8FYVD2MBads0ZL/4yL2yGYaReH2xaaTjhrO+qRhGhWLzP 3Kori3cl/uA3uTvIYbMKgkIRq3sl8sTLTRyGioMjS7PCwNKYRstgcnhwRgiOKdfhqSSE +06A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770625379; x=1771230179; h=to:from:subject:message-id:references:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1z62XI4JGEoZVPtufxwSYx1SFhBLLihIdxzj7l54Q9E=; b=eyjZFSMQ7pgy9tnulBQExL1hy4VhzbOg+dd8VSQCkNlnb7OVWIBqPEe3+pm79fVtww lwHbKDnn594y1ORuJjOtDi7aWBOLpqaTLMOskIKVcAXD68gPmxsjbJrxD7/9n2YnK3dv YdMJmRKsYZA8HGknwTznTBP0kjV9v4nXvBffxYRIeunSjsuhxe+ay3uMS6Pj1gTSkqHJ 0XDTScq3Mfg+eMNGdYMFhjaP1JnTcVIAtBQ1ztOgSFMJ2FG+5s4VqBw2Xm+UIW7bfO5O IxifKHQIgmNqMo1pCkGL8xkJgVz5OPVL98b8e7ssa3aa6z54W0b0E8/TwE98nVWZvqnm 96KA== X-Forwarded-Encrypted: i=1; AJvYcCVZWtCKaoiDNMYFAZ9L43DhnEzHEem2A7/rH7O89ZSCGftp3oyZm4z2RofD91X0Ut2BPHxDPQg11zwZwZM=@vger.kernel.org X-Gm-Message-State: AOJu0YwPOmS17MMTiXwZ6uvxLDQ+GdyRnvJIUfzVoxq520ANzXcSMGKi T6pLCuWhBH4Eukgs5L6dvvn3QWG3/+vUAfU5p2IVMO1MFgAh0fReuWjqHRPKFf6QlX+U14OqPfb AUcnbcmev2l8Ve6C2rQ== X-Received: from ejbri1.prod.google.com ([2002:a17:906:d7c1:b0:b8e:b016:f0a]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a17:907:a0d:b0:b86:f495:5e4c with SMTP id a640c23a62f3a-b8edf3749a6mr545462266b.55.1770625378829; Mon, 09 Feb 2026 00:22:58 -0800 (PST) Date: Mon, 9 Feb 2026 08:22:57 +0000 In-Reply-To: <6agwmmfv26g2ljxv2cvd5sbskkjgurnu2mhbsg5ssxkdikxpdp@xehzjz57omb7> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260118-mas-next-doc-v1-1-827d9f4924ce@google.com> <6fgs2mcvwlitkjza5d7cpu3mk34sqqn53vqazkicyge4gtqt7f@5dvqmpubypip> <6agwmmfv26g2ljxv2cvd5sbskkjgurnu2mhbsg5ssxkdikxpdp@xehzjz57omb7> Message-ID: Subject: Re: [PATCH] maple_tree: update mas_next[_range] docs From: Alice Ryhl To: "Liam R. Howlett" , Andrew Morton , Andrew Ballance , maple-tree@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" On Sat, Feb 07, 2026 at 08:16:56AM +0000, Liam R. Howlett wrote: > * Alice Ryhl [260204 15:29]: > > On Mon, Jan 26, 2026 at 03:20:17PM -0500, Liam R. Howlett wrote: > > > * Alice Ryhl [260121 04:56]: > > > > On Tue, Jan 20, 2026 at 12:54:47PM -0500, Liam R. Howlett wrote: > > > > > * Alice Ryhl [260118 06:00]: > > > > > > If you read the docs, it sounds like the difference between these > > > > > > functions is whether mas->index and mas->last are updated. However, if > > > > > > you read the implementation, you will instead find that the difference > > > > > > is whether NULL entries are skipped. > > > > > > > > > > This is not the intent. > > > > > > > > > > mas_ should return special values including the XA_ZERO_ENTRY. > > > > > > > > > > mas_next() should get the next non-NULL value. > > > > > > > > > > mas_next_range() should advance the maple state to the next range, > > > > > regardless of what is in the range (NULL, special, or a regular entry). > > > > > > > > > > Both should update the mas->index and mas->last values, if it moves > > > > > (ie, no error state is encountered). > > > > > > > > I guess I'm a bit confused about the difference between XA_ZERO_ENTRY > > > > and returning NULL. Isn't the case where we return NULL when a slot has > > > > been reserved but not inserted yet? > > > > > > mas_ will return the special entries. > > > > > > mtree_ will return NULL on special entries. I think this is just > > > mtree_load(). > > > > > > If you want to use your own locking and use mas_, then you can filter > > > out the special entries yourself. > > > > > > If you want to use the normal api, then the special entries are filtered > > > for you. > > > > > > This way you can mix/match the apis but the noral api still remains > > > simple to use - even if there are advanced users that mixed in. > > > > > > The idea is that if you're using the advanced interface and storing > > > special entries, then you probably want to do something different on > > > those entries - at least sometimes. > > > > > > > > > > > Like the docs, you use "get" vs "advance" wording here, but I don't > > > > think there's any difference behavior-wise? Is one intended? > > > > > > On return type, no, there isn't a difference. The difference is where > > > the mas points in the end (mas->offset, mas->index, mas->last). > > > > > > If a NULL is encountered bu mas_next(), then we proceed to the next slot > > > (which must have a value, if there is a next slot). So, mas_next() will > > > always return the next entry until there is not a next entry - then it > > > returns NULL. Note that mas_next() takes an 'end' value where we'll > > > stop advancing slots regardless if there are values. > > > > > > If a NULL is encountered by mas_next_range(), then we return the NULL. > > > So, in this way, we can move to the next range even if it's NULL. > > > > > > I hope this makes the difference more clear? > > > > Yes. > > > > But I guess the docs should still need to be updated? Right now, both of > > them say "Can return the zero entry.", but one of them can't because it > > skips them. > > Neither of the ones you are updating should skip the zero entry as they > are both the advanced interface. What do you call the entries that mas_next() skips? You know, the ones where it would otherwise return NULL. Alice