From: Josh Law <hlcj1234567@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Josh Law <objecting@objecting.org>
Subject: Re: [PATCH v3 1/2] lib/idr: fix infinite loop in idr_get_next()
Date: Thu, 12 Mar 2026 20:57:46 +0000 [thread overview]
Message-ID: <43bacae7-3891-417e-9384-20cede8eec6e@gmail.com> (raw)
In-Reply-To: <20260312135514.e4fc0fa4c1f50e6fbda2644c@linux-foundation.org>
12 Mar 2026 20:55:15 Andrew Morton <akpm@linux-foundation.org>:
> On Thu, 12 Mar 2026 18:19:47 +0000 Josh Law <hlcj1234567@gmail.com> wrote:
>
>> In idr_get_next(), if the returned id from idr_get_next_ul() is greater
>> than INT_MAX, the function issues a warning and returns NULL without
>> updating the *nextid pointer. This causes a soft lockup for any caller
>> iterating over an IDR (e.g. via idr_for_each_entry) because they will
>> receive NULL, fail to advance their index, and repeatedly query the same
>> state forever.
>
> This assumes that the idr_get_next() caller ignores the NULL return and
> just keeps on looping. Isn't that a caller bug and if so, do we need
> to defend against it here?
The risk isn't just a single loop failure; it's that idr_get_next() breaks the 'forward-progress' guarantee of the iterator.
In macros like idr_for_each_entry_continue, if idr_get_next() returns NULL without advancing the pointer, the caller is left in a permanent trap. Any attempt to resume or retry the iteration results in an infinite loop of the same warning because the index is never incremented past the problematic ID.
Advancing the pointer ensures the infrastructure is robust against these 'soft lockups', even if the caller's error handling is imperfect..
next prev parent reply other threads:[~2026-03-12 20:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 18:19 [PATCH v3 0/2] lib/idr: Fixes for infinite loop and memory leak Josh Law
2026-03-12 18:19 ` [PATCH v3 1/2] lib/idr: fix infinite loop in idr_get_next() Josh Law
2026-03-12 20:55 ` Andrew Morton
2026-03-12 20:57 ` Josh Law [this message]
2026-03-12 21:15 ` Josh Law
2026-03-12 18:19 ` [PATCH v3 2/2] lib/idr: fix memory leak in ida_alloc_range() error path Josh Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43bacae7-3891-417e-9384-20cede8eec6e@gmail.com \
--to=hlcj1234567@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=objecting@objecting.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox