Linux 3.5-rc4

This commit is contained in:
Justin M. Forbes 2012-06-25 12:16:21 -05:00
parent e8d34e0ae5
commit 0350197e2d
5 changed files with 9 additions and 366 deletions

View File

@ -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) || \

View File

@ -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

View File

@ -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

View File

@ -1,2 +1,2 @@
967f72983655e2479f951195953e8480 linux-3.4.tar.xz
45159d08e4a0cdeda609e1a33492b98a patch-3.5-rc3.xz
29606cb3e7c174ac128ac39c00813c20 patch-3.5-rc4.xz

View File

@ -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