From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e23smtp02.au.ibm.com (e23smtp02.au.ibm.com [202.81.31.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 9D9C72C009F for ; Fri, 21 Mar 2014 15:55:09 +1100 (EST) Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 21 Mar 2014 14:55:08 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id EA2EA2BB0054 for ; Fri, 21 Mar 2014 15:55:06 +1100 (EST) Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s2L4sqf48716704 for ; Fri, 21 Mar 2014 15:54:52 +1100 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s2L4t4bF015487 for ; Fri, 21 Mar 2014 15:55:05 +1100 Date: Fri, 21 Mar 2014 10:25:01 +0530 From: Srikar Dronamraju To: Davidlohr Bueso Subject: Re: Tasks stuck in futex code (in 3.14-rc6) Message-ID: <20140321045501.GD30295@linux.vnet.ibm.com> References: <20140319154705.GB8557@laptop.programming.kicks-ass.net> <20140319170829.GD8557@laptop.programming.kicks-ass.net> <20140320053350.GB30295@linux.vnet.ibm.com> <1395295019.2612.11.camel@buesod1.americas.hpqcorp.net> <1395335909.14694.15.camel@buesod1.americas.hpqcorp.net> <1395342510.14694.43.camel@buesod1.americas.hpqcorp.net> <1395346808.14694.62.camel@buesod1.americas.hpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: <1395346808.14694.62.camel@buesod1.americas.hpqcorp.net> Cc: Peter Zijlstra , Linus Torvalds , LKML , Paul Mackerras , Thomas Gleixner , Paul McKenney , ppc-dev , Ingo Molnar Reply-To: Srikar Dronamraju List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > > Ok, so a big reason why this patch doesn't apply cleanly after reverting > is because *most* of the changes were done at the top of the file with > regards to documenting the ordering guarantees, the actual code changes > are quite minimal. > > I reverted commits 99b60ce6 (documentation) and b0c29f79 (the offending > commit), and then I cleanly applied the equivalent ones from v3 of the > series (which was already *tested* and ready for upstream until you > suggested looking into the alternative spinlock approach): > > https://lkml.org/lkml/2013/12/19/624 > https://lkml.org/lkml/2013/12/19/630 I reverted commits 99b60ce6 and b0c29f79. Then applied the patches in the above url. The last one had a reject but it was pretty straightforward to resolve it. After this, specjbb completes. So reverting and applying v3 3/4 and 4/4 patches works for me. -- Thanks and Regards Srikar Dronamraju From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754217AbaCUEzO (ORCPT ); Fri, 21 Mar 2014 00:55:14 -0400 Received: from e23smtp05.au.ibm.com ([202.81.31.147]:55479 "EHLO e23smtp05.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750987AbaCUEzL (ORCPT ); Fri, 21 Mar 2014 00:55:11 -0400 Date: Fri, 21 Mar 2014 10:25:01 +0530 From: Srikar Dronamraju To: Davidlohr Bueso Cc: Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , LKML , ppc-dev , Benjamin Herrenschmidt , Paul Mackerras , Paul McKenney Subject: Re: Tasks stuck in futex code (in 3.14-rc6) Message-ID: <20140321045501.GD30295@linux.vnet.ibm.com> Reply-To: Srikar Dronamraju References: <20140319154705.GB8557@laptop.programming.kicks-ass.net> <20140319170829.GD8557@laptop.programming.kicks-ass.net> <20140320053350.GB30295@linux.vnet.ibm.com> <1395295019.2612.11.camel@buesod1.americas.hpqcorp.net> <1395335909.14694.15.camel@buesod1.americas.hpqcorp.net> <1395342510.14694.43.camel@buesod1.americas.hpqcorp.net> <1395346808.14694.62.camel@buesod1.americas.hpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1395346808.14694.62.camel@buesod1.americas.hpqcorp.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14032104-1396-0000-0000-0000048027AB Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Ok, so a big reason why this patch doesn't apply cleanly after reverting > is because *most* of the changes were done at the top of the file with > regards to documenting the ordering guarantees, the actual code changes > are quite minimal. > > I reverted commits 99b60ce6 (documentation) and b0c29f79 (the offending > commit), and then I cleanly applied the equivalent ones from v3 of the > series (which was already *tested* and ready for upstream until you > suggested looking into the alternative spinlock approach): > > https://lkml.org/lkml/2013/12/19/624 > https://lkml.org/lkml/2013/12/19/630 I reverted commits 99b60ce6 and b0c29f79. Then applied the patches in the above url. The last one had a reject but it was pretty straightforward to resolve it. After this, specjbb completes. So reverting and applying v3 3/4 and 4/4 patches works for me. -- Thanks and Regards Srikar Dronamraju