Linux 3.5-rc4

5 files changed, 9 insertions, 366 deletions

diff --git a/arm-omap-3.5-fixes.patch b/arm-omap-3.5-fixes.patch
deleted file mode 100644
index f88f1de78..000000000
--- a/arm-omap-3.5-fixes.patch
+++ /dev/null
@@ -1,24 +0,0 @@
---- linux-3.5.0-0.rc2.git0.1.fc17.armv7hl/arch/arm/mach-omap2/dsp.c.orig	2012-06-10 05:54:50.000000000 -0400
-+++ linux-3.5.0-0.rc2.git0.1.fc17.armv7hl/arch/arm/mach-omap2/dsp.c	2012-06-10 05:55:38.000000000 -0400
-@@ -20,6 +20,7 @@
- 
- #include <linux/module.h>
- #include <linux/platform_device.h>
-+#include <asm/memblock.h>
- #include "cm2xxx_3xxx.h"
- #include "prm2xxx_3xxx.h"
- #ifdef CONFIG_BRIDGE_DVFS
---- linux-3.5.0-0.rc2.git0.1.fc17.armv7hl/arch/arm/mach-omap2/board-flash.c.orig	2012-06-11 02:30:19.000000000 -0400
-+++ linux-3.5.0-0.rc2.git0.1.fc17.armv7hl/arch/arm/mach-omap2/board-flash.c	2012-06-11 02:31:05.000000000 -0400
-@@ -97,11 +97,6 @@
- 
- 	gpmc_onenand_init(&board_onenand_data);
- }
--#else
--void
--__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
--{
--}
- #endif /* CONFIG_MTD_ONENAND_OMAP2 || CONFIG_MTD_ONENAND_OMAP2_MODULE */
- 
- #if defined(CONFIG_MTD_NAND_OMAP2) || \
diff --git a/hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch b/hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch
deleted file mode 100644
index 3e0b4a5c7..000000000
--- a/hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch
+++ /dev/null
@@ -1,100 +0,0 @@
-Path: news.gmane.org!not-for-mail
-From: Matthew Garrett <mjg@redhat.com>
-Newsgroups: gmane.linux.kernel,gmane.linux.file-systems
-Subject: [PATCH V2] hfsplus: Fix bless ioctl when used with hardlinks
-Date: Mon, 16 Apr 2012 16:57:18 -0400
-Lines: 45
-Approved: news@gmane.org
-Message-ID: <1334609838-14831-1-git-send-email-mjg@redhat.com>
-NNTP-Posting-Host: plane.gmane.org
-X-Trace: dough.gmane.org 1334609870 7622 80.91.229.3 (16 Apr 2012 20:57:50 GMT)
-X-Complaints-To: usenet@dough.gmane.org
-NNTP-Posting-Date: Mon, 16 Apr 2012 20:57:50 +0000 (UTC)
-Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
-	Matthew Garrett <mjg@redhat.com>
-To: hch@infradead.org
-Original-X-From: linux-kernel-owner@vger.kernel.org Mon Apr 16 22:57:49 2012
-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 1SJszc-0006G8-Gd
-	for glk-linux-kernel-3@plane.gmane.org; Mon, 16 Apr 2012 22:57:48 +0200
-Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-	id S1755330Ab2DPU5g (ORCPT <rfc822;glk-linux-kernel-3@m.gmane.org>);
-	Mon, 16 Apr 2012 16:57:36 -0400
-Original-Received: from mx1.redhat.com ([209.132.183.28]:44295 "EHLO mx1.redhat.com"
-	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
-	id S1752969Ab2DPU5e (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
-	Mon, 16 Apr 2012 16:57:34 -0400
-Original-Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
-	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3GKvQoA029518
-	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
-	Mon, 16 Apr 2012 16:57:26 -0400
-Original-Received: from cavan.codon.org.uk (ovpn-113-122.phx2.redhat.com [10.3.113.122])
-	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3GKvP1p017146
-	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
-	Mon, 16 Apr 2012 16:57:26 -0400
-Original-Received: from nat-pool-rdu.redhat.com ([66.187.233.202] helo=x220.boston.devel.redhat.com)
-	by cavan.codon.org.uk with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
-	(Exim 4.72)
-	(envelope-from <mjg@redhat.com>)
-	id 1SJszC-0003jY-P9; Mon, 16 Apr 2012 21:57:23 +0100
-X-SA-Do-Not-Run: Yes
-X-SA-Exim-Connect-IP: 66.187.233.202
-X-SA-Exim-Mail-From: mjg@redhat.com
-X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false
-X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
-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:1282933 gmane.linux.file-systems:63394
-Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/1282933>
-
-HFS+ doesn't really implement hard links - instead, hardlinks are indicated
-by a magic file type which refers to an indirect node in a hidden
-directory. The spec indicates that stat() should return the inode number
-of the indirect node, but it turns out that this doesn't satisfy the
-firmware when it's looking for a bootloader - it wants the catalog ID of
-the hardlink file instead. Fix up this case.
-
-Signed-off-by: Matthew Garrett <mjg@redhat.com>
----
-
-V2 cleans up the casting.
-
- fs/hfsplus/ioctl.c |    9 +++++++--
- 1 file changed, 7 insertions(+), 2 deletions(-)
-
-diff --git a/fs/hfsplus/ioctl.c b/fs/hfsplus/ioctl.c
-index c640ba5..09addc8 100644
---- a/fs/hfsplus/ioctl.c
-+++ b/fs/hfsplus/ioctl.c
-@@ -31,6 +31,7 @@ static int hfsplus_ioctl_bless(struct file *file, int __user *user_flags)
- 	struct hfsplus_sb_info *sbi = HFSPLUS_SB(inode->i_sb);
- 	struct hfsplus_vh *vh = sbi->s_vhdr;
- 	struct hfsplus_vh *bvh = sbi->s_backup_vhdr;
-+	u32 cnid = (unsigned long)dentry->d_fsdata;
- 
- 	if (!capable(CAP_SYS_ADMIN))
- 		return -EPERM;
-@@ -41,8 +42,12 @@ static int hfsplus_ioctl_bless(struct file *file, int __user *user_flags)
- 	vh->finder_info[0] = bvh->finder_info[0] =
- 		cpu_to_be32(parent_ino(dentry));
- 
--	/* Bootloader */
--	vh->finder_info[1] = bvh->finder_info[1] = cpu_to_be32(inode->i_ino);
-+	/*
-+	 * Bootloader. Just using the inode here breaks in the case of
-+	 * hard links - the firmware wants the ID of the hard link file,
-+	 * but the inode points at the indirect inode
-+	 */
-+	vh->finder_info[1] = bvh->finder_info[1] = cpu_to_be32(cnid);
- 
- 	/* Per spec, the OS X system folder - same as finder_info[0] here */
- 	vh->finder_info[5] = bvh->finder_info[5] =
--- 
-1.7.10
-
diff --git a/kernel.spec b/kernel.spec
index 8b2384b93..54febf470 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -62,7 +62,7 @@ Summary: The Linux kernel
 # For non-released -rc kernels, this will be appended after the rcX and
 # gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
 #
-%global baserelease 4
+%global baserelease 1
 %global fedora_build %{baserelease}
 
 # base_sublevel is the kernel version we're starting with and patching
@@ -93,7 +93,7 @@ Summary: The Linux kernel
 # The next upstream release sublevel (base_sublevel+1)
 %define upstream_sublevel %(echo $((%{base_sublevel} + 1)))
 # The rc snapshot level
-%define rcrev 3
+%define rcrev 4
 # The git snapshot level
 %define gitrev 0
 # Set rpm version accordingly
@@ -717,7 +717,6 @@ Patch20000: uprobes-3.5-tip.patch
 
 # ARM
 # OMAP
-Patch21000: arm-omap-3.5-fixes.patch
 
 # ARM tegra
 Patch21004: arm-tegra-nvec-kconfig.patch
@@ -730,8 +729,6 @@ Patch21010: highbank-export-clock-functions.patch
 
 Patch21094: power-x86-destdir.patch
 
-Patch21098: hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch
-
 #rhbz 754518
 Patch21235: scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch
 
@@ -742,9 +739,6 @@ Patch22000: weird-root-dentry-name-debug.patch
 #selinux ptrace child permissions
 Patch22001: selinux-apply-different-permission-to-ptrace-child.patch
 
-#rhbz 829016
-Patch22022: thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-PAE.patch
-
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -1303,7 +1297,6 @@ ApplyPatch taint-vbox.patch
 #
 # ARM
 #
-ApplyPatch arm-omap-3.5-fixes.patch
 ApplyPatch arm-tegra-nvec-kconfig.patch
 ApplyPatch arm-tegra-usb-no-reset-linux33.patch
 ApplyPatch arm-tegra-sdhci-module-fix.patch
@@ -1419,8 +1412,6 @@ ApplyPatch uprobes-3.5-tip.patch
 
 ApplyPatch power-x86-destdir.patch
 
-ApplyPatch hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch
-
 #rhbz 754518
 ApplyPatch scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch
 
@@ -1434,8 +1425,6 @@ ApplyPatch selinux-apply-different-permission-to-ptrace-child.patch
 #Highbank clock functions
 ApplyPatch highbank-export-clock-functions.patch 
 
-ApplyPatch thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-PAE.patch
-
 # END OF PATCH APPLICATIONS
 
 %endif
@@ -2286,6 +2275,12 @@ fi
 #                 ||----w |
 #                 ||     ||
 %changelog
+* Mon Jun 25 2012 Justin M. Forbes <jforbes@redhat.com> - 3.5.0-0.rc4.git0.1
+- Disable debugging options.
+
+* Mon Jun 25 2012 Justin M. Forbes <jforbes@redhat.com>
+- Linux 3.5-rc4
+
 * Fri Jun 22 2012 Josh Boyer <jwboyer@redhat.com>
 - Add uprobe backports from -tip from Anton Arapov
 
diff --git a/sources b/sources
index 85301cb7c..3ba359fa5 100644
--- a/sources
+++ b/sources
@@ -1,2 +1,2 @@
 967f72983655e2479f951195953e8480  linux-3.4.tar.xz
-45159d08e4a0cdeda609e1a33492b98a  patch-3.5-rc3.xz
+29606cb3e7c174ac128ac39c00813c20  patch-3.5-rc4.xz
diff --git a/thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-PAE.patch b/thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-PAE.patch
deleted file mode 100644
index a91e9bbe4..000000000
--- a/thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-PAE.patch
+++ /dev/null
@@ -1,228 +0,0 @@
-                                                                                                                                                                                                                                                               
-Delivered-To: jwboyer@gmail.com

-Received: by 10.229.175.203 with SMTP id bb11csp66243qcb;

-        Fri, 8 Jun 2012 15:08:27 -0700 (PDT)

-Received: by 10.68.222.133 with SMTP id qm5mr23412736pbc.113.1339193307132;

-        Fri, 08 Jun 2012 15:08:27 -0700 (PDT)

-Return-Path: <stable-owner@vger.kernel.org>

-Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])

-        by mx.google.com with ESMTP id ku9si12482578pbc.355.2012.06.08.15.08.24;

-        Fri, 08 Jun 2012 15:08:25 -0700 (PDT)

-Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;

-Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mail=stable-owner@vger.kernel.org

-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand

-	id S964992Ab2FHWIW (ORCPT <rfc822;bigsmallbd@gmail.com> + 21 others);

-	Fri, 8 Jun 2012 18:08:22 -0400

-Received: from mail-bk0-f74.google.com ([209.85.214.74]:41783 "EHLO

-	mail-bk0-f74.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org

-	with ESMTP id S964922Ab2FHWIV (ORCPT

-	<rfc822;stable@vger.kernel.org>); Fri, 8 Jun 2012 18:08:21 -0400

-Received: by bkty5 with SMTP id y5so128736bkt.1

-        for <stable@vger.kernel.org>; Fri, 08 Jun 2012 15:08:20 -0700 (PDT)

-X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

-        d=google.com; s=20120113;

-        h=subject:to:cc:from:date:message-id:x-gm-message-state;

-        bh=RSdNZSZcXg/enKaYIM+JR4+Bd890ieO+blY9bsk9giI=;

-        b=NwTZEmRSdqDAiTV/EW91GXpM/yrRd7CNzfPif0JcF0iFgxGAo4lB7W1I05vmrnPcCQ

-         Va+P6xXLWle2rAVQLsPooKdtb3u2wnNRDEGvBPZl2alje+qzhKGlQcVgnI5+KCM6GaS+

-         YWoE+2gv5UFmF6JlelThyecGTyZ0D93K5aVYewSxg0H7KZ6BgvMnB/qJKFdScatv1uDH

-         g39MFwJzmD+DmNMn149jeUWYOLLTeMZJkymtJCLgxS8eJzQxXA0nes2Wz/pXCBdxXF2z

-         mft6LyzKtoEUDeTtalgm9zxkT4XJ+6bsAMEXBFgkcyNq0Ic8P79AP0ynlET2L/Ql3ARP

-         C5Sg==

-Received: by 10.14.101.2 with SMTP id a2mr2823176eeg.6.1339193299969;

-        Fri, 08 Jun 2012 15:08:19 -0700 (PDT)

-Received: from hpza10.eem.corp.google.com ([74.125.121.33])

-        by gmr-mx.google.com with ESMTPS id d52si7345113eei.1.2012.06.08.15.08.19

-        (version=TLSv1/SSLv3 cipher=AES128-SHA);

-        Fri, 08 Jun 2012 15:08:19 -0700 (PDT)

-Received: from akpm.mtv.corp.google.com (akpm.mtv.corp.google.com [172.18.96.75])

-	by hpza10.eem.corp.google.com (Postfix) with ESMTP id 9D09620004E;

-	Fri,  8 Jun 2012 15:08:19 -0700 (PDT)

-Received: from localhost.localdomain (localhost [127.0.0.1])

-	by akpm.mtv.corp.google.com (Postfix) with ESMTP id D5FACA0329;

-	Fri,  8 Jun 2012 15:08:18 -0700 (PDT)

-Subject: + thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-pae.patch added to -mm tree

-To:	mm-commits@vger.kernel.org

-Cc:	aarcange@redhat.com, hughd@google.com, jbeulich@suse.com,

-	jrnieder@gmail.com, kosaki.motohiro@gmail.com, lwoodman@redhat.com,

-	mgorman@suse.de, pmatouse@redhat.com, riel@redhat.com,

-	stable@vger.kernel.org, uobergfe@redhat.com

-From:	akpm@linux-foundation.org

-Date:	Fri, 08 Jun 2012 15:08:18 -0700

-Message-Id: <20120608220818.D5FACA0329@akpm.mtv.corp.google.com>

-X-Gm-Message-State: ALoCoQnqC0C+2OVVfC5Yi43jUu5vH03b/RBncPoI4SpE4HFSgaRrM+gM2J8rR6MMoba3nM/OmDAU

-Sender:	stable-owner@vger.kernel.org

-Precedence: bulk

-List-ID: <stable.vger.kernel.org>

-X-Mailing-List:	stable@vger.kernel.org

-

-

-The patch titled

-     Subject: thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE

-has been added to the -mm tree.  Its filename is

-     thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-pae.patch

-

-Before you just go and hit "reply", please:

-   a) Consider who else should be cc'ed

-   b) Prefer to cc a suitable mailing list as well

-   c) Ideally: find the original patch on the mailing list and do a

-      reply-to-all to that, adding suitable additional cc's

-

-*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

-The -mm tree is included into linux-next and is updated

-there every 3-4 working days

-

-------------------------------------------------------

-From: Andrea Arcangeli <aarcange@redhat.com>

-Subject: thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE

-

-In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding the

-mmap_sem for reading, cmpxchg8b cannot be used to read pmd contents under

-Xen.

-

-So instead of dealing only with "consistent" pmdvals in

-pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually

-simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals

-where the low 32bit and high 32bit could be inconsistent (to avoid having

-to use cmpxchg8b).

-

-The only guarantee we get from pmd_read_atomic is that if the low part of

-the pmd was found null, the high part will be null too (so the pmd will be

-considered unstable).  And if the low part of the pmd is found "stable"

-later, then it means the whole pmd was read atomically (because after a

-pmd is stable, neither MADV_DONTNEED nor page faults can alter it anymore,

-and we read the high part after the low part).

-

-In the 32bit PAE x86 case, it is enough to read the low part of the pmdval

-atomically to declare the pmd as "stable" and that's true for THP and no

-THP, furthermore in the THP case we also have a barrier() that will

-prevent any inconsistent pmdvals to be cached by a later re-read of the

-*pmd.

-

-Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>

-Cc: Jonathan Nieder <jrnieder@gmail.com>

-Cc: Ulrich Obergfell <uobergfe@redhat.com>

-Cc: Mel Gorman <mgorman@suse.de>

-Cc: Hugh Dickins <hughd@google.com>

-Cc: Larry Woodman <lwoodman@redhat.com>

-Cc: Petr Matousek <pmatouse@redhat.com>

-Cc: Rik van Riel <riel@redhat.com>

-Cc: Jan Beulich <jbeulich@suse.com>

-Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>

-Cc: <stable@vger.kernel.org>

-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

----

-

- arch/x86/include/asm/pgtable-3level.h |   30 +++++++++++++-----------

- include/asm-generic/pgtable.h         |   10 ++++++++

- 2 files changed, 27 insertions(+), 13 deletions(-)

-

-diff -puN arch/x86/include/asm/pgtable-3level.h~thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-pae arch/x86/include/asm/pgtable-3level.h

---- a/arch/x86/include/asm/pgtable-3level.h~thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-pae

-+++ a/arch/x86/include/asm/pgtable-3level.h

-@@ -47,16 +47,26 @@ static inline void native_set_pte(pte_t 

-  * they can run pmd_offset_map_lock or pmd_trans_huge or other pmd

-  * operations.

-  *

-- * Without THP if the mmap_sem is hold for reading, the

-- * pmd can only transition from null to not null while pmd_read_atomic runs.

-- * So there's no need of literally reading it atomically.

-+ * Without THP if the mmap_sem is hold for reading, the pmd can only

-+ * transition from null to not null while pmd_read_atomic runs. So

-+ * we can always return atomic pmd values with this function.

-  *

-  * With THP if the mmap_sem is hold for reading, the pmd can become

-- * THP or null or point to a pte (and in turn become "stable") at any

-- * time under pmd_read_atomic, so it's mandatory to read it atomically

-- * with cmpxchg8b.

-+ * trans_huge or none or point to a pte (and in turn become "stable")

-+ * at any time under pmd_read_atomic. We could read it really

-+ * atomically here with a atomic64_read for the THP enabled case (and

-+ * it would be a whole lot simpler), but to avoid using cmpxchg8b we

-+ * only return an atomic pmdval if the low part of the pmdval is later

-+ * found stable (i.e. pointing to a pte). And we're returning a none

-+ * pmdval if the low part of the pmd is none. In some cases the high

-+ * and low part of the pmdval returned may not be consistent if THP is

-+ * enabled (the low part may point to previously mapped hugepage,

-+ * while the high part may point to a more recently mapped hugepage),

-+ * but pmd_none_or_trans_huge_or_clear_bad() only needs the low part

-+ * of the pmd to be read atomically to decide if the pmd is unstable

-+ * or not, with the only exception of when the low part of the pmd is

-+ * zero in which case we return a none pmd.

-  */

--#ifndef CONFIG_TRANSPARENT_HUGEPAGE

- static inline pmd_t pmd_read_atomic(pmd_t *pmdp)

- {

- 	pmdval_t ret;

-@@ -74,12 +84,6 @@ static inline pmd_t pmd_read_atomic(pmd_

- 

- 	return (pmd_t) { ret };

- }

--#else /* CONFIG_TRANSPARENT_HUGEPAGE */

--static inline pmd_t pmd_read_atomic(pmd_t *pmdp)

--{

--	return (pmd_t) { atomic64_read((atomic64_t *)pmdp) };

--}

--#endif /* CONFIG_TRANSPARENT_HUGEPAGE */

- 

- static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)

- {

-diff -puN include/asm-generic/pgtable.h~thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-pae include/asm-generic/pgtable.h

---- a/include/asm-generic/pgtable.h~thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-pae

-+++ a/include/asm-generic/pgtable.h

-@@ -484,6 +484,16 @@ static inline int pmd_none_or_trans_huge

- 	/*

- 	 * The barrier will stabilize the pmdval in a register or on

- 	 * the stack so that it will stop changing under the code.

-+	 *

-+	 * When CONFIG_TRANSPARENT_HUGEPAGE=y on x86 32bit PAE,

-+	 * pmd_read_atomic is allowed to return a not atomic pmdval

-+	 * (for example pointing to an hugepage that has never been

-+	 * mapped in the pmd). The below checks will only care about

-+	 * the low part of the pmd with 32bit PAE x86 anyway, with the

-+	 * exception of pmd_none(). So the important thing is that if

-+	 * the low part of the pmd is found null, the high part will

-+	 * be also null or the pmd_none() check below would be

-+	 * confused.

- 	 */

- #ifdef CONFIG_TRANSPARENT_HUGEPAGE

- 	barrier();

-_

-Subject: Subject: thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE

-

-Patches currently in -mm which might be from aarcange@redhat.com are

-

-origin.patch

-linux-next.patch

-mm-fix-slab-page-_count-corruption-when-using-slub.patch

-thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-pae.patch

-hugetlb-rename-max_hstate-to-hugetlb_max_hstate.patch

-hugetlbfs-dont-use-err_ptr-with-vm_fault-values.patch

-hugetlbfs-add-an-inline-helper-for-finding-hstate-index.patch

-hugetlbfs-add-an-inline-helper-for-finding-hstate-index-fix.patch

-hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages.patch

-hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages-fix.patch

-hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages-fix-fix.patch

-hugetlb-avoid-taking-i_mmap_mutex-in-unmap_single_vma-for-hugetlb.patch

-hugetlb-simplify-migrate_huge_page.patch

-hugetlb-simplify-migrate_huge_page-fix.patch

-memcg-add-hugetlb-extension.patch

-memcg-add-hugetlb-extension-fix.patch

-memcg-add-hugetlb-extension-fix-fix.patch

-hugetlb-add-charge-uncharge-calls-for-hugetlb-alloc-free.patch

-memcg-track-resource-index-in-cftype-private.patch

-hugetlbfs-add-memcg-control-files-for-hugetlbfs.patch

-hugetlbfs-add-memcg-control-files-for-hugetlbfs-use-scnprintf-instead-of-sprintf.patch

-hugetlbfs-add-memcg-control-files-for-hugetlbfs-use-scnprintf-instead-of-sprintf-fix.patch

-hugetlbfs-add-a-list-for-tracking-in-use-hugetlb-pages.patch

-memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal.patch

-memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal-fix.patch

-memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal-fix-fix.patch

-hugetlb-migrate-memcg-info-from-oldpage-to-new-page-during-migration.patch

-memcg-add-memory-controller-documentation-for-hugetlb-management.patch

-

---

-To unsubscribe from this list: send the line "unsubscribe stable" in

-the body of a message to majordomo@vger.kernel.org

-More majordomo info at  http://vger.kernel.org/majordomo-info.html