Drop patch that was included in 3.8-rc7-git2

2 files changed, 0 insertions, 199 deletions

diff --git a/kernel.spec b/kernel.spec
index db4d6429c..7050bbc9a 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -742,8 +742,6 @@ Patch21244: iwlegacy-add-flush-callback.patch
 #rhbz 892811
 Patch21247: ath9k_rx_dma_stop_check.patch
 
-Patch21248: pid-unlock_irq-when-alloc_pid-fails-because-init.patch
-
 #rhbz 910126
 Patch21249: pstore-Create-a-convenient-mount-point-for-pstore.patch
 
@@ -1454,8 +1452,6 @@ ApplyPatch iwlegacy-add-flush-callback.patch
 #rhbz 892811
 ApplyPatch ath9k_rx_dma_stop_check.patch
 
-ApplyPatch pid-unlock_irq-when-alloc_pid-fails-because-init.patch
-
 #rhbz 910126
 ApplyPatch pstore-Create-a-convenient-mount-point-for-pstore.patch
 
diff --git a/pid-unlock_irq-when-alloc_pid-fails-because-init.patch b/pid-unlock_irq-when-alloc_pid-fails-because-init.patch
deleted file mode 100644
index 79062233f..000000000
--- a/pid-unlock_irq-when-alloc_pid-fails-because-init.patch
+++ /dev/null
@@ -1,195 +0,0 @@
-Path: news.gmane.org!not-for-mail
-From: ebiederm@xmission.com (Eric W. Biederman)
-Newsgroups: gmane.linux.kernel
-Subject: Re: Odd ENOMEM being returned in 3.8-rcX
-Date: Fri, 08 Feb 2013 12:13:09 -0800
-Lines: 117
-Approved: news@gmane.org
-Message-ID: <87k3qiwomi.fsf@xmission.com>
-References: <20130207215742.GB31684@hansolo.jdub.homelinux.org>
-	<20130207141502.04625ea0.akpm@linux-foundation.org>
-	<20130208003501.GC31684@hansolo.jdub.homelinux.org>
-	<20130208181949.GD31684@hansolo.jdub.homelinux.org>
-NNTP-Posting-Host: plane.gmane.org
-Mime-Version: 1.0
-Content-Type: text/plain
-X-Trace: ger.gmane.org 1360354410 32723 80.91.229.3 (8 Feb 2013 20:13:30 GMT)
-X-Complaints-To: usenet@ger.gmane.org
-NNTP-Posting-Date: Fri, 8 Feb 2013 20:13:30 +0000 (UTC)
-Cc: Andrew Morton <akpm@linux-foundation.org>,
-	Al Viro <viro@zeniv.linux.org.uk>,
-	Mel Gorman <mgorman@suse.de>, linux-kernel@vger.kernel.org
-To: Josh Boyer <jwboyer@redhat.com>
-Original-X-From: linux-kernel-owner@vger.kernel.org Fri Feb 08 21:13:50 2013
-Return-path: <linux-kernel-owner@vger.kernel.org>
-Envelope-to: glk-linux-kernel-3@plane.gmane.org
-Original-Received: from vger.kernel.org ([209.132.180.67])
-	by plane.gmane.org with esmtp (Exim 4.69)
-	(envelope-from <linux-kernel-owner@vger.kernel.org>)
-	id 1U3uKS-0003Ug-Vg
-	for glk-linux-kernel-3@plane.gmane.org; Fri, 08 Feb 2013 21:13:49 +0100
-Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-	id S932228Ab3BHUNT (ORCPT <rfc822;glk-linux-kernel-3@m.gmane.org>);
-	Fri, 8 Feb 2013 15:13:19 -0500
-Original-Received: from out01.mta.xmission.com ([166.70.13.231]:45242 "EHLO
-	out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
-	with ESMTP id S932068Ab3BHUNS (ORCPT
-	<rfc822;linux-kernel@vger.kernel.org>);
-	Fri, 8 Feb 2013 15:13:18 -0500
-Original-Received: from in02.mta.xmission.com ([166.70.13.52])
-	by out01.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
-	(Exim 4.76)
-	(envelope-from <ebiederm@xmission.com>)
-	id 1U3uJw-0002FX-87; Fri, 08 Feb 2013 13:13:16 -0700
-Original-Received: from c-98-207-153-68.hsd1.ca.comcast.net ([98.207.153.68] helo=eric-ThinkPad-X220.xmission.com)
-	by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
-	(Exim 4.76)
-	(envelope-from <ebiederm@xmission.com>)
-	id 1U3uJt-0002Vi-8d; Fri, 08 Feb 2013 13:13:16 -0700
-In-Reply-To: <20130208181949.GD31684@hansolo.jdub.homelinux.org> (Josh Boyer's
-	message of "Fri, 8 Feb 2013 13:19:49 -0500")
-User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)
-X-XM-AID: U2FsdGVkX19Djtj1/IXFytBzyU3W7XCCOHTPWCA75uo=
-X-SA-Exim-Connect-IP: 98.207.153.68
-X-SA-Exim-Mail-From: ebiederm@xmission.com
-X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sa07.xmission.com
-X-Spam-Level: 
-X-Spam-Status: No, score=-0.6 required=8.0 tests=ALL_TRUSTED,
-	DCC_CHECK_NEGATIVE,FVGT_m_MULTI_ODD,T_TM2_M_HEADER_IN_MSG,T_XMDrugObfuBody_08
-	autolearn=disabled version=3.3.2
-X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-	*  0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG
-	* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
-	*      [sa07 1397; Body=1 Fuz1=1 Fuz2=1]
-	*  0.4 FVGT_m_MULTI_ODD Contains multiple odd letter combinations
-	*  0.0 T_XMDrugObfuBody_08 obfuscated drug references
-X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 
-X-Spam-Combo: ;Josh Boyer <jwboyer@redhat.com>
-X-Spam-Relay-Country: 
-X-Spam-Flag: No
-X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700)
-X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
-Original-Sender: linux-kernel-owner@vger.kernel.org
-Precedence: bulk
-List-ID: <linux-kernel.vger.kernel.org>
-X-Mailing-List: linux-kernel@vger.kernel.org
-Xref: news.gmane.org gmane.linux.kernel:1438656
-Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/1438656>
-
-Josh Boyer <jwboyer@redhat.com> writes:
-
-> On Thu, Feb 07, 2013 at 07:35:01PM -0500, Josh Boyer wrote:
->> On Thu, Feb 07, 2013 at 02:15:02PM -0800, Andrew Morton wrote:
->> > On Thu, 7 Feb 2013 16:57:42 -0500
->> > Josh Boyer <jwboyer@redhat.com> wrote:
->> > 
->> > > Hi All,
->> > > 
->> > > We've hit a weird error in Fedora using the 3.8-rcX kernels.  It seems
->> > > the mock tool is getting back ENOMEM when doing very simple things that
->> > > normally just work.  The 3.7 kernels on the same userspace work just
->> > > fine.  It seems just running 'mock init -v' is enough to cause the
->> > > failure.
->> > 
->> > I assume you're not seeing the "page allocation failure" message and
->> > backtrace.  This means that either
->> 
->> Right.  If I disable our debug options, I see no backtraces at all and
->> the python app still gets ENOMEM returned.  (See below for those
->> interested).
->> 
->> > a) it's a __GFP_NOWARN callsite.  This is rare.  Or
->> > 
->> > b) it's actually a different error but someone went and overwrote a
->> >    callee's return value with -ENOMEM.  We do this a lot and it sucks.
->> 
->> We do it in copy_io :\.
->> 
->> > > At first glance it seems copy_io is failing (possibly because
->> > > get_task_io_context fails), and then the above fallout is printed.  The
->> > > warning seems fairly valid, but I don't think that is the root of the
->> > > problem.
->> > 
->> > yes, get_task_io_context() might be the place.  Tried adding a few
->> > error-path printks in there to see what's happening?
->> 
->> Yeah, that's my next step.  I guess I know what I'll be doing tomorrow.
->> 
->> > I can't see anything around there which leaves interrupts disabled
->> > though.  It's quite likely that there's some code with is forgetting to
->> > reenable interrupts on a rarely-tested error path, and that ENOMEM is
->> > tickling the bug.
->> 
->> Right, agreed.  As I said, I think that is mostly a secondary issue.
->> Hopefully it will be easy to fix once we figure out why we're getting
->> the ENOMEM error.
->> 
->> Python backtrace below.  Seems to be failing on forking a umount command
->> after init'ing the chroot.  I can put the full output somewhere if
->> people are interested.
->
-> OK.  I've bisected this down to:
->
-> 50804fe3737ca6a5942fdc2057a18a8141d00141 is the first bad commit
-> commit 50804fe3737ca6a5942fdc2057a18a8141d00141
-> Author: Eric W. Biederman <ebiederm@xmission.com>
-> Date:   Tue Mar 2 15:41:50 2010 -0800
->
->     pidns: Support unsharing the pid namespace.
->     
->
-> I haven't really gotten much farther than that yet, but the bisect was
-> pretty straight forward.  Eric, is there anything specific I can gather
-> or do to help figure out why that is causing mock to get such a weird
-> error?  I can provide the bisect log if you'd like.
-
-My best guess in some dark corner of mock has untested code to unshare a
-pid namespace, and that corner started doing something now that
-unsharing of the pid namespace actually works.
-
-If mock has called unshare(CLONE_NEWPID). And then forked a process and
-that process exited, and then forked anothe process that second and all
-subsequent fork calls will fail with -ENOMEM (because init has exited in
-the pid namespace).  -ENOMEM will be generated because of a failure of
-alloc_pid.
-
-Looking at that code path a little closer that just about has to be it,
-because I goofed and the error path drops the lock but not irqs.  The
-patch below should fix the nasty warning and confirm where the code is
-failing in copy_process.
-
-An strace to see which syscalls mock is making and with which flags
-would be very interesting.  I am almost certain that there is a
-unshare(CLONE_NEWPID) somewhere in there.  But in a remote corner of
-possibility it could weird clone flags, or something else.
-
-Beyond that I suspect we want to work with the mock folks so they get
-their code to use a pid namespace working the way they intended.
-
-Eric
-
-From: "Eric W. Biederman" <ebiederm@xmission.com>
-Date: Fri, 8 Feb 2013 12:05:54 -0800
-Subject: [PATCH] pid: unlock_irq when alloc_pid fails because init has
- exited.
-
-Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
----
- kernel/pid.c |    2 +-
- 1 files changed, 1 insertions(+), 1 deletions(-)
-
-diff --git a/kernel/pid.c b/kernel/pid.c
-index de9af60..f2c6a68 100644
---- a/kernel/pid.c
-+++ b/kernel/pid.c
-@@ -331,7 +331,7 @@ out:
- 	return pid;
- 
- out_unlock:
--	spin_unlock(&pidmap_lock);
-+	spin_unlock_irq(&pidmap_lock);
- out_free:
- 	while (++i <= ns->level)
- 		free_pidmap(pid->numbers + i);
--- 
-1.7.5.4