Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757969AbZKJTuw (ORCPT ); Tue, 10 Nov 2009 14:50:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757920AbZKJTuv (ORCPT ); Tue, 10 Nov 2009 14:50:51 -0500 Received: from hera.kernel.org ([140.211.167.34]:59480 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757914AbZKJTuv (ORCPT ); Tue, 10 Nov 2009 14:50:51 -0500 Message-ID: <4AF9C402.9040800@kernel.org> Date: Wed, 11 Nov 2009 04:50:26 +0900 From: Tejun Heo User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ingo Molnar CC: Linus Torvalds , Linux Kernel , Yinghai Lu Subject: Re: [GIT PULL] percpu fixes for 2.6.32-rc6 References: <4AF90254.40909@kernel.org> <4AF9B1FD.1010408@kernel.org> <4AF9BE3A.40409@kernel.org> <20091110193705.GA9011@elte.hu> In-Reply-To: <20091110193705.GA9011@elte.hu> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1478 Lines: 34 Ingo Molnar wrote: > * Tejun Heo wrote: > >> In this case, as the second function needs to release to free the old >> map, the extra unlock/lock pair is actually necessary. Splitting into >> two functions is fine but I think it would be better to fix it first >> and then split them in following patches so that it can be bisected if >> I screw up while splitting, right? > > i think Linus's point was that this hack was the last straw that broke > the camel's back, and that we are better off with a clean solution > straight away. If you send the clean approach i can help test it on a > good number of boxes. If you're talking about the locking itself, there really is no clean solution at this point. Until vmalloc locking is updated, we'll have to do locking impedance matching in percpu code. I'm still not quite sure whether we really need to update vmalloc code to be irqsafe. 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. Thanks. -- tejun -- 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/