From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758393AbZKJVn2 (ORCPT ); Tue, 10 Nov 2009 16:43:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758327AbZKJVn1 (ORCPT ); Tue, 10 Nov 2009 16:43:27 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:48620 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758296AbZKJVn0 (ORCPT ); Tue, 10 Nov 2009 16:43:26 -0500 Date: Tue, 10 Nov 2009 13:42:51 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Tejun Heo cc: Ingo Molnar , Linux Kernel , Yinghai Lu Subject: Re: [GIT PULL] percpu fixes for 2.6.32-rc6 In-Reply-To: <4AF9C402.9040800@kernel.org> Message-ID: References: <4AF90254.40909@kernel.org> <4AF9B1FD.1010408@kernel.org> <4AF9BE3A.40409@kernel.org> <20091110193705.GA9011@elte.hu> <4AF9C402.9040800@kernel.org> User-Agent: Alpine 2.01 (LFD 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 11 Nov 2009, Tejun Heo wrote: > > If you're talking about the three way return value, which I do agree > to be quite ugly, I think it will be a lot safer to have three patches > - one to fix the deadlock, another to fix the return value and the > final one to de-uglify the function, especially as we're pretty late > in the release cycle. I'm certainly ok with doing it in stages if that is how you want to do it. That said, I'm not entirely sure it's _worthwhile_, since the "return 1" case has apparently never ever actually worked. From a bisect standpoint, what's the difference between seeing - oh, now that we made it return the documented code and actually re-try properly when dropping the lock, it turns out that the re-try code was always buggy and we just hadn't noticed before because it didn't trigger or - oh, now that we rewrote the function to be cleaner and do the lock dropping and retry more obviously, it turns out that the retry doesn't actually work and leads to deadlocks. but I don't care deeply. I want the cleanup because I think that the code sucks from a "future proofing" and readability standpoint, but I really don't mind one way or the other whether you want to finally do that one "return 1" correctly for one commit, only to then fix it to not do that three-way test of a single function in the next one. So whatever works - as long as the end result both looks sane and doesn't have the bug we clearly have now. Linus