From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f74.google.com (mail-ej1-f74.google.com [209.85.218.74]) (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 DD1A52D879A for ; Wed, 4 Feb 2026 15:29:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770218944; cv=none; b=kH5TDFkjKAeIaRVuatQnlRwvXoY4tjGjgpjeuOTesXWehYHmPVtv1F0XANtRTSLPknd/esrqOKuoWefkpoek4O4sqIbZ9EYgmCMm6pvUXMXexplAGVuePtKlTBLOCyCU0ZSKWscSZ27tESPHOJDEu5jE2ZT9A9SiXjNxbOXDYxY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770218944; c=relaxed/simple; bh=FeJZKPBo6GSSPhNo82We+82hISPu/AYf+mF/4/9VD6U=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Content-Type; b=cYhEjDnMrG2zrVW5SVSemGiWR1vKqz0fbkI9JHRgXgXV/fZjf4EfhPeSeTU8kgLmTwO66XDjzFqDWcSR3QxsrcbG8BQbTUztZjroDan6NBIrVkvP5kGXV6Uh94ywaaky6haWdblec3t2sqidf3A+nJrw87uDFzW7xrcCLenLM0k= 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=BgtmbMl2; arc=none smtp.client-ip=209.85.218.74 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="BgtmbMl2" Received: by mail-ej1-f74.google.com with SMTP id a640c23a62f3a-b874c325d10so825172266b.1 for ; Wed, 04 Feb 2026 07:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770218942; x=1770823742; 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=comgElPe5TTFNgd95XxdbOyr6d3AFR078228Bo4y0I4=; b=BgtmbMl2HMlU6IQ1Bo+Yn56eZrct5dK/1dpjqp03WSfh5p/vylTDpHsV8ueS+FsYXu +/CR7QIlxn+hpoSgsFPPSkuM/LHmOZYiDZfT+7yZaqA0ou2/eMlnp2ZSqbplHFw1J90Q er9gBXMA0oywa3EDP1GIOsPYVJvWr0su3SIHw5J4M03rmB8BR87fdqhB7ngGCDcKYoOp hc8d9tnKqIr0p36dno+2XphBgaIsKDc6HocPfDnjg+MJAuOfd41IoQKPIR8CoQe37NjU q6VOS9aPjZ9yHEJATcds3luRJsb4bnFnLrfAgvUfPOZ845R7G7tBy+n1HTMkieNCv2av o4FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770218942; x=1770823742; 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=comgElPe5TTFNgd95XxdbOyr6d3AFR078228Bo4y0I4=; b=irZqJe1WGbPngnuNwmb38ys/j99dFRta5yEEjjZYqs+aMH7/ApLKxj9Z0NOicVzP8s DWXaDFUhp1a44jri62ppM/8UZqs+2d+V1H33dO1wKE12Mty35hVW8AaG1l9QyH/OF0hI H+xJto3CQmrIKc/U3Zcoib6IOr24+7vadGZZQ7yZA1u4CG6DJ1EhsYN44L/1aoqf8W/4 lKDTbniCgqc+SQyFqUK+svukw6Zv291RgZqS4H5dEIbE0ergp93wUHfRqtTpfp8yHj/U P8Zoxizi4UGAVm0wkPyB969uYZ1Q8wGZktUnRAhSLhPgXWYmgvyA+hAsBN8gLrmJQtsU 3DFw== X-Forwarded-Encrypted: i=1; AJvYcCXxOXy9wcHc7sQlkJLswIj0wLQ7+shylAnugWzJ/vDsVfDRhSYCllUiEg363Es5rLXVRrxYlvsZjcaq1LM=@vger.kernel.org X-Gm-Message-State: AOJu0YzCjvBrfKf87EE7tiWFk+KTIM+GBKuKl36zYPweSey8mFUuWgsR Sk7OQ6mDp0FPwqKFrFHXAM0Yy/lGMPBUOmmY85Q5CEvF6IDy69MW0rQU1/15ZfqvjUiSTj7Cmvy +3hmw6eg4A8M2s9OZ3A== X-Received: from ejew27.prod.google.com ([2002:a17:906:185b:b0:b7a:5a7c:9bd0]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a17:907:72c7:b0:b88:7093:3ca3 with SMTP id a640c23a62f3a-b8e9f04ca7dmr253684366b.23.1770218942193; Wed, 04 Feb 2026 07:29:02 -0800 (PST) Date: Wed, 4 Feb 2026 15:29:01 +0000 In-Reply-To: <6fgs2mcvwlitkjza5d7cpu3mk34sqqn53vqazkicyge4gtqt7f@5dvqmpubypip> 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> 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 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. Alice