Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752892Ab0KZWyP (ORCPT ); Fri, 26 Nov 2010 17:54:15 -0500 Received: from caramon.arm.linux.org.uk ([78.32.30.218]:53802 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752221Ab0KZWyP (ORCPT ); Fri, 26 Nov 2010 17:54:15 -0500 Date: Fri, 26 Nov 2010 22:53:39 +0000 From: Russell King - ARM Linux To: Ohad Ben-Cohen Cc: Olof Johansson , Hari Kanigeri , Suman Anna , Benoit Cousson , Arnd Bergmann , Tony Lindgren , Greg KH , linux-kernel@vger.kernel.org, Grant Likely , Kevin Hilman , akpm@linux-foundation.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 1/4] drivers: hwspinlock: add generic framework Message-ID: <20101126225339.GA26864@n2100.arm.linux.org.uk> References: <1290526740-27624-1-git-send-email-ohad@wizery.com> <1290526740-27624-2-git-send-email-ohad@wizery.com> <20101126045912.GC6598@lixom.net> <20101126091832.GE9310@n2100.arm.linux.org.uk> <20101126104548.GG9310@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1399 Lines: 29 On Sat, Nov 27, 2010 at 12:18:55AM +0200, Ohad Ben-Cohen wrote: > But then there's the other (quite reasonable) claim that says we > shouldn't crash the machine because of a non fatal bug: if a crappy > driver messes up, the user (not the developer) will most probably > prefer the machine to keep running with degraded functionality rather > than boot. There's also the quite reasonable expectation that we shouldn't corrupt user data. With locking interfaces, if someone abuses them and they fail to work, then the risk is data corruption due to races. The safe thing in that case is to panic - terminate that thread before it does anything unsafe, thereby preventing data corruption. Yes, it may mean that something becomes unavailable, but that's better than corrupting data. Take a look at the kernel's own spinlock implementation. Do we do lots of checks in there for things like someone passing a NULL pointer to the spinlock, or do we get an oops instead? Also look at the list implementation. Do we check for NULL pointers there, or do we get an oops instead? Same for mutex. The same goes for lots of other infrastructure interfaces. -- 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/