From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265343AbUEZHrY (ORCPT ); Wed, 26 May 2004 03:47:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265344AbUEZHrY (ORCPT ); Wed, 26 May 2004 03:47:24 -0400 Received: from dragnfire.mtl.istop.com ([66.11.160.179]:23277 "EHLO dsl.commfireservices.com") by vger.kernel.org with ESMTP id S265343AbUEZHrX (ORCPT ); Wed, 26 May 2004 03:47:23 -0400 Date: Wed, 26 May 2004 03:48:31 -0400 (EDT) From: Zwane Mwaikambo To: Keith Owens Cc: Andrew Morton , Linux Kernel Subject: Re: [PATCH][2.6-mm] i386: enable interrupts on contention in spin_lock_irq In-Reply-To: <14280.1085556586@kao2.melbourne.sgi.com> Message-ID: References: <14280.1085556586@kao2.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 26 May 2004, Keith Owens wrote: > Your patch opens a window where data that was protected by the disabled > interrupt on entry becomes unprotected while waiting for the lock and > can therefore change. > > It could be that I am worrying unnecessarily, after all any code that > calls spin_lock_irq() with interrupts already disabled is probably > wrong to start off with. But it does need to be considered as a > possible failure mode. Granted there might be code like that, i'll throw in some debugging code locally to test for such a condition. It wouldn't necessarily be a bug but a very uncool way of obfuscating the locking. Thanks, Zwane