From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f43.google.com (mail-dl1-f43.google.com [74.125.82.43]) (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 0D05F3D6497 for ; Thu, 5 Mar 2026 16:53:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772729614; cv=none; b=RXXS1NXnycZvsYY0v89NVMl9ENSFizhtc5Z86DWH/kpk4kVZSa8kATNlnU+6sLznB3WDTSK1t7wGxx3ZWXPOQJqe6gJV8+iXaj7vIF22+BtHYAndLhoer5B8wqZ/1FINVmC9/vMH6T1EXN0TUkkJMdbJHBvDEJdmvnvmV6e63zk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772729614; c=relaxed/simple; bh=ccrLeopJHqSj9fB/czJzBK7R6oyenuY1PQJemNMRKAc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZNVwY/oU0LwBtoryCF9exsO3/AUXDcCrb5LX8xRNf9eakFWqdfCicWTjSHE/ZLyEksrpNGNTgAedUj+dewCuJa9Y/xwGxr4kRVDZ8ghSWy18KCXyKV0dLLzJb5+3jDVdABdP0DY+c36DBXtApa6lXUMvlIUxfleoQQ53/hDJySM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dUKc1siy; arc=none smtp.client-ip=74.125.82.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net 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="dUKc1siy" Received: by mail-dl1-f43.google.com with SMTP id a92af1059eb24-1270adc5121so10318781c88.0 for ; Thu, 05 Mar 2026 08:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772729612; x=1773334412; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=HxhcSN+e9I7LXlQzxczwKkXMqtF+5L91CEl0/9U5qGw=; b=dUKc1siy91t0MKbm0Kkqo/XmASe5vCXaaW82TaPSMF8XXeZVOuBOi6jgtyMy8at51i E4Wnoj8zBGDS/Vjx0LaQqulB2Rkjkpa0f4gajq3O1tL7lWAjrdMDZtJLV/oBm7mCIBcx JEc2p2i5VKMIvxb7dwTymoawOCSbR94lowu3qLnvVKNZGnRdWk/FC3nNOVJvk71TLrRG liaYEay48TJtK7OqUXGjXgImuMm0bUFvIirBIWwW9rGa1O3mF1ZV6poBbugM3Ttrva9s X7eYMv2GucleHXvokA8wViA9KhwAVtcuOD3HFTVa31QpgE4pO7ENPaIyL0wYW25BkNAW LIfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772729612; x=1773334412; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=HxhcSN+e9I7LXlQzxczwKkXMqtF+5L91CEl0/9U5qGw=; b=e+CbJUz5BBPEe6lOFwgnTHnk+3EJV3/IaU2PCu32bsTT9R/fegkIvfUk6t/H3WH4kR BWi3oFJiG8x5vwHyrKDB+B/cYaKZOroRNcnqwyeidaOh4hdpUF2XUdOmWpeJoKx181su d3cO07bdfCAJGvnn8Jpo5QiBEPZls6r8OAq/5FpEPcSnW9J19qBKoUlhw9J3kCDyqBiZ Ad0n5iXWyOcWRbeHSgXj+rFrqYLnO110tLnscFqihdgwEnLSvXNK95nbTmk336qBtW6x X+Udgh7L9ouafQv5BeFnBZVoDkra8bjI7c4LwU7jl3UcnH8EeTGKFjpfRCTwXVUVKhmI nVdQ== X-Forwarded-Encrypted: i=1; AJvYcCUqU87HNRtm1AHb9xNbb1XCKRzxvFb05jCKYsu+FWxgWhnSLmLwJQtmF196i1E4Etr9tcvlsQx0OvJXIMU=@vger.kernel.org X-Gm-Message-State: AOJu0YwcnUjn+TmNI4gZ0HFzfLg38O2hsNGjp0u41BcCA43sie+I8GfN su7N2iDO4+4xfhgBjcmCBJ5kwOIb/AhInyBiyLSdp9SNGgEEsshJH/tb X-Gm-Gg: ATEYQzwLQlAK9GTXNdPNv8JvTT9CBfIu+JtLh+PvN+BvmGBRDN1wp+//eSeJziAtHFy zgeQwmMD4p0x4unCUWPZkkXtETJ88Fs56iPhGH93yLs46iZVI4XzdAUu/CpToJG+3owVzokWmDL BtCWMUJZ/IjaZTHPt9s6SDZxgO7s2T1hs1geKIfVAx/reQToguOX6yceWKNRjRg0b/8r3p9CGsc 3Xq1uVDTb5s+LvVOccgDZLiuEQjL6dpPK72CsERJ4wT2MeSCgyzd1syiFauBRAbl3ZL6CgUEuWg /5MCFbowxXqOBxqsc27izGyxLk+d76ZXIgSlWxNpK4YAA6K6iL1/fFKsfSgb+GJt7pRTgfjUCUd LFGd1RIy7PafQJtMnUz3HshbYVO8wnjw6RuPufyIgM23L9Toxyg72mmnA7El79bf+28ovSRA6ts yDNa56XEu72kDmSx8dQfH0yL0J290EE2SsjQtCzFJMaPLD6wk= X-Received: by 2002:a05:7022:6628:b0:128:ba6e:f87b with SMTP id a92af1059eb24-128c119417fmr206466c88.36.1772729612112; Thu, 05 Mar 2026 08:53:32 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:da43:aeff:fecc:bfd5]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-127899df36asm21429300c88.4.2026.03.05.08.53.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2026 08:53:31 -0800 (PST) Sender: Guenter Roeck Date: Thu, 5 Mar 2026 08:53:30 -0800 From: Guenter Roeck To: Aboorva Devarajan Cc: rafael@kernel.org, christian.loehle@arm.com, daniel.lezcano@linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/4] cpuidle: Skip governor when only one idle state is available Message-ID: <37ab17cd-0488-44bd-9e03-1ba3c0757e8f@roeck-us.net> References: <20260216185005.1131593-1-aboorvad@linux.ibm.com> <20260216185005.1131593-2-aboorvad@linux.ibm.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260216185005.1131593-2-aboorvad@linux.ibm.com> Hi, On Tue, Feb 17, 2026 at 12:20:02AM +0530, Aboorva Devarajan wrote: > On certain platforms (PowerNV systems without a power-mgt DT node), > cpuidle may register only a single idle state. In cases where that > single state is a polling state (state 0), the ladder governor may > incorrectly treat state 1 as the first usable state and pass an > out-of-bounds index. This can lead to a NULL enter callback being > invoked, ultimately resulting in a system crash. > > [ 13.342636] cpuidle-powernv : Only Snooze is available > [ 13.351854] Faulting instruction address: 0x00000000 > [ 13.376489] NIP [0000000000000000] 0x0 > [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 > > Fix this by adding a bail-out in cpuidle_select() that returns state 0 > directly when state_count <= 1, bypassing the governor and keeping the > tick running. > > Fixes: dc2251bf98c6 ("cpuidle: Eliminate the CPUIDLE_DRIVER_STATE_START symbol") > Signed-off-by: Aboorva Devarajan > --- > drivers/cpuidle/cpuidle.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c > index c7876e9e024f..65fbb8e807b9 100644 > --- a/drivers/cpuidle/cpuidle.c > +++ b/drivers/cpuidle/cpuidle.c > @@ -359,6 +359,16 @@ noinstr int cpuidle_enter_state(struct cpuidle_device *dev, > int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev, > bool *stop_tick) > { > + /* > + * If there is only a single idle state (or none), there is nothing > + * meaningful for the governor to choose. Skip the governor and > + * always use state 0 with the tick running. > + */ > + if (drv->state_count <= 1) { > + *stop_tick = false; > + return 0; > + } > + An experimental AI review agent provided the following feedback: Does this unconditionally keep the tick running on systems that only have a single non-polling idle state (like basic ARM systems that only support WFI)? Before this patch, governors like menu would check CPUIDLE_FLAG_POLLING before deciding to keep the tick running. Could this change effectively disable NO_HZ_IDLE on these systems, causing higher power consumption? I don't know scheduling well enough to understand if this is a real problem, but I thought it is worth mentioning it. Please let me know if the problem is real or not so I can feed it back into the agent. Thanks, Guenter