Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753244AbbBXJ5V (ORCPT ); Tue, 24 Feb 2015 04:57:21 -0500 Received: from smtp-out6.electric.net ([192.162.217.183]:59249 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752321AbbBXJ5Q (ORCPT ); Tue, 24 Feb 2015 04:57:16 -0500 From: David Laight To: "'Ingo Molnar'" , Anton Blanchard CC: Don Zickus , "x86@kernel.org" , Russell King , Peter Zijlstra , "peterz@infradead.org" , "hpa@zytor.com" , "linux-kernel@vger.kernel.org" , Steven Rostedt , "Linus Torvalds" , Ingo Molnar , Paul Mackerras , "linux-arm-kernel@lists.infradead.org" , Andrew Morton , "linuxppc-dev@lists.ozlabs.org" , Thomas Gleixner , "sam.bobroff@au1.ibm.com" , Arjan van de Ven Subject: RE: [PATCH 1/7] Add die_spin_lock_{irqsave,irqrestore} Thread-Topic: [PATCH 1/7] Add die_spin_lock_{irqsave,irqrestore} Thread-Index: AQHQT/zfYZ6nTe+cQUyIV0Gup5GyfZz/j0oQ Date: Tue, 24 Feb 2015 09:56:14 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CAE9BD3@AcuExch.aculab.com> References: <1424748634-9153-1-git-send-email-anton@samba.org> <1424748634-9153-2-git-send-email-anton@samba.org> <20150224064107.GB15387@gmail.com> In-Reply-To: <20150224064107.GB15387@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t1O9vTui018517 Content-Length: 801 Lines: 20 From: Ingo Molnar ... > So why not trylock and time out here after a few seconds, > instead of indefinitely supressing some potentially vital > output due to some other CPU crashing/locking with the lock > held? I've used that for status requests that usually lock a table to get a consistent view. If trylock times out assume that the data is actually stable and access it anyway. Remember the pid doing the access and next time it tries to acquire the same lock do a trylock with no timeout. That way if (when) there is a locking fubar (or a driver oops with a lock held) at least some of the relevant status commands will work. David ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?