From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 4070D22256F for ; Thu, 12 Mar 2026 21:15:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773350125; cv=none; b=kHGDFKxAOaz6pHScd/xsMWUYa+lByabbf/Eha4LNSYnwDeXiY3ZjeAVVOVHZyKJQz4YTuW0ujmYzKtWShnbz7ksTjF5ON+SwT5FSFJNWpD0Bmvx8Bl7WzQZ3xhadUlMHDYYEwiesNZh3DVValW1jazTgG+xBiipEeZtAf43v4GI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773350125; c=relaxed/simple; bh=csK1En/4fONGq/lr85KpbezFYh469Cwgl1uC4F6XmcI=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=aCmz8yxdbSSPzGpT3oN18FI1DLoK43m1o/NZCgm5zjurzSwihzsIM/RyYiDR/tRwI5iJHwe5UXmWrEJseziRWN2zlK+W2XEU0sE+K92YlcMBqgxQ4/aRUfNkCxWaxE9xx6xsKU8DR/i+sZvt3xzLTAEerqGTTQTClQSZw5o5+QA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YvizAiiE; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YvizAiiE" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-483487335c2so13084535e9.2 for ; Thu, 12 Mar 2026 14:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773350121; x=1773954921; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=csK1En/4fONGq/lr85KpbezFYh469Cwgl1uC4F6XmcI=; b=YvizAiiE7BMDvvDS9kvEvRxQyshly8YhYGJUjashU/vS5M65boyn+fjNLMoJpUIexG nVffyLbYkdEW0oLbxaBdJjXDg6RnnQy+sF7OwTSZ6kTv+Oa+M9Z2cKtpyHW2+qYpVusi DzK2AYG45LOahnbHRmAjjsuGhBCFJsy5HQPb0Zl2BB6PZzAbQoJ6yzkHRsBHQ7C5ty9Y 6z/jF4ciQBr0J3IWsUhSrnpb6eSUrwT/EV+xo/Oq9R1mcJsE4HbjO7pHwB6NqS1r/7eH t5dpMddmqY4UFj38bL3RSG5JKP/xvHf9J2LfNuzgI4A/FJGADZEnftI/rh+niNwLLEHv oD4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773350121; x=1773954921; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=csK1En/4fONGq/lr85KpbezFYh469Cwgl1uC4F6XmcI=; b=dodFCcrS/zjSH9E4lom4jGQg7py/vMBInG+/jNJJ0tpHNrhfNOnHEQkKP/eVA+fdiH M89oH+RdqgJ6sNEEoPrema8HbPHx4xTGr2g0TERY5uMfpLLx+JCP5gHGXzXHmSRUDli2 YSN5Bp08CtdPs311/7pjQmG8j1CVDsL039Dkn+YcN/0cMrU82PoMotbJP8bXf/R23yGl PI+UchgZR1yd/KehKjArflw90iQBi+eh0kKuJWqtmMgxv1ZGa1YuuV3RZksGoSn1BUGO LISxki41spnk3y+BDLtKscujUuSx52Odh+SWqWF2XqcsB0eKGYm7SSVniHeHEnRy0LAd ++Ng== X-Forwarded-Encrypted: i=1; AJvYcCXD4moZa+tNSlogsAgAvrscn7OOkQjw/+PEQnIKI2tCCULAx7Iic7T+UqhIMRosC4MwIGHWRPN1yXCCv4I=@vger.kernel.org X-Gm-Message-State: AOJu0Yyakerl0qm3StUOp0GuwkhNHLDoPk4fAcsVzLs0lwIpbyuomR2v aI8XZ2TRtn5UoeOdMuALrGXptCwC2R6hyp8pK7Kj6PnlSi+SGTItVSlI X-Gm-Gg: ATEYQzzTYv6VjICdPvVTT6FW/ic+TVeuXEvbI1+sp9Vj11vclRConmJvdBJsYGcwqvs bLhpv0MvYS9fE023icjDhHMJcTGrsgRH0ACrz4dy3rm9m3m/4V+WX5O5k4NCQkORBIxeX5cTo/n SlB8Y9IZy3U7XxAbg7CvQVPIhyRgnuLZFNS6yvBZCa5DeHzvPqxpPi/sFLmax7YCxEEU3iZn/TB SrsUYQoJj3UIpPjlQQgTQXnNh2ixedpDCUmwoOOZuoiskX4sWoAp1enxn9+f0vb+dnxy3nh1Vqh bH3pX8BJWzM1WkuF00niC2ICC7qm6oUXaQayqktW9WQHtvRCkBIjsZZLhl3iMKPg2xcsdvVh0a+ VeNVVw4iyYnoSK0hRkut/TcS5EYa01Bv3DEcYaywyoIF1ecEzatvFLbqP8u14DSBJjPEZVZU46L m2tiJYxJEHRbGeZt4pdJ69ybGnGw== X-Received: by 2002:a05:600c:3ba4:b0:485:3f72:3230 with SMTP id 5b1f17b1804b1-485566d936dmr13803785e9.15.1773350121216; Thu, 12 Mar 2026 14:15:21 -0700 (PDT) Received: from ?IPv6:::1? ([2a00:23ee:2968:90cb:1c6d:1979:bcad:501a]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4855640d915sm5009175e9.4.2026.03.12.14.15.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 14:15:20 -0700 (PDT) Date: Thu, 12 Mar 2026 21:15:20 +0000 From: Josh Law To: Andrew Morton Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Josh Law Message-ID: In-Reply-To: <43bacae7-3891-417e-9384-20cede8eec6e@gmail.com> References: <20260312181948.20020-1-objecting@objecting.org> <20260312181948.20020-2-objecting@objecting.org> <20260312135514.e4fc0fa4c1f50e6fbda2644c@linux-foundation.org> <43bacae7-3891-417e-9384-20cede8eec6e@gmail.com> Subject: Re: [PATCH v3 1/2] lib/idr: fix infinite loop in idr_get_next() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: 12 Mar 2026 20:57:48 Josh Law : > 12 Mar 2026 20:55:15 Andrew Morton : > >> On Thu, 12 Mar 2026 18:19:47 +0000 Josh Law wrot= e: >> >>> 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 sam= e >>> state forever. >> >> This assumes that the idr_get_next() caller ignores the NULL return and >> just keeps on looping.=C2=A0 Isn't that a caller bug and if so, do we ne= ed >> to defend against it here? > > The risk isn't just a single loop failure; it's that idr_get_next() break= s the 'forward-progress' guarantee of the iterator. > In macros like idr_for_each_entry_continue, if idr_get_next() returns NUL= L without advancing the pointer, the caller is left in a permanent trap. An= y attempt to resume or retry the iteration results in an infinite loop of t= he 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.. This most definitely needs to be merged. V/R