From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757802AbYG1Txq (ORCPT ); Mon, 28 Jul 2008 15:53:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752611AbYG1Txi (ORCPT ); Mon, 28 Jul 2008 15:53:38 -0400 Received: from one.firstfloor.org ([213.235.205.2]:37743 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752332AbYG1Txh (ORCPT ); Mon, 28 Jul 2008 15:53:37 -0400 Date: Mon, 28 Jul 2008 21:53:24 +0200 From: Andi Kleen To: Thomas Gleixner Cc: Andi Kleen , Linus Torvalds , Andrew Morton , LKML , Ingo Molnar , Dhaval Giani , Venkatesch Pallipadi , Len Brown Subject: Re: [PATCH] ACPI/CPUIDLE: prevent setting pm_idle to NULL Message-ID: <20080728195324.GE30344@one.firstfloor.org> References: <20080728174644.GC30344@one.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > The problem here is that the acpi/cpuidle code can be in a state where > the _save/old variables _ARE_ NULL because they had not been > initialized with the original pm_idle before the module is removed or > the cst state changes. So all we have to do is to prevent pm_idle to > be set to NULL. It still seems wrong to me to fall back to the cpuidle idle function instead of the earlier idle function just because cpuidle was loaded in a weird way. But yes mwait_idle could be set up later after the saving state. I suggested default_idle because it is safe, but yes it is probably not the optimal choice. Perhaps to solve this cleanly we really need to go to a hierarchy of idle functions registered with priority instead of this fragile pointer saving/restoring. -Andi