Message-ID: <428E962F.40600@acm.org>
Date: Fri, 20 May 2005 21:00:15 -0500
From: Corey Minyard <minyard@acm.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Lee Revell <rlrevell@joe-job.com>
Cc: george@mvista.com, Andrew Morton <akpm@osdl.org>,
       lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Fixes for IPMI use of timers
References: <428D2181.2080106@acm.org>  <428E8B68.6040909@mvista.com> <1116639005.14582.7.camel@mindpipe>
In-Reply-To: <1116639005.14582.7.camel@mindpipe>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1090
Lines: 37

Lee Revell wrote:

>On Fri, 2005-05-20 at 18:14 -0700, George Anzinger wrote:
>  
>
>>> 		/* We already have irqsave on, so no need for it
>>>                    here. */
>>>-		read_lock(&xtime_lock);
>>>+		read_lock_irqsave(&xtime_lock, flags);
>>>      
>>>
>>I rather hope this fails to compile :)  xtime_lock is a sequence lock in the 2.6 
>>kernel.
>>
>>    
>>
>>> 		jiffies_now = jiffies;
>>> 		smi_info->si_timer.expires = jiffies_now;
>>> 		smi_info->si_timer.sub_expires = get_arch_cycles(jiffies_now);
>>>+		read_unlock_irqrestore(&xtime_lock, flags);
>>>      
>>>
>
>The old code clearly has an unbalanced lock/unlock, maybe it's
>sufficient to just fix that?
>  
>
Yes, probably just best to fix that up.  When high-res timers make it 
into the kernel, this can be fixed up, this is left over from the 2.4 
high-res timers.

-Corey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/