From 0350197e2d226fc12ff8e0030d499470c9d5b027 Mon Sep 17 00:00:00 2001 From: "Justin M. Forbes" Date: Mon, 25 Jun 2012 12:16:21 -0500 Subject: [PATCH] Linux 3.5-rc4 --- arm-omap-3.5-fixes.patch | 24 -- ...bless-ioctl-when-used-with-hardlinks.patch | 100 -------- kernel.spec | 21 +- sources | 2 +- ...ead-in-pmd_read_atomic-for-32bit-PAE.patch | 228 ------------------ 5 files changed, 9 insertions(+), 366 deletions(-) delete mode 100644 arm-omap-3.5-fixes.patch delete mode 100644 hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch delete mode 100644 thp-avoid-atomic64_read-in-pmd_read_atomic-for-32bit-PAE.patch 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 - #include -+#include - #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 -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 -To: hch@infradead.org -Original-X-From: linux-kernel-owner@vger.kernel.org Mon Apr 16 22:57:49 2012 -Return-path: -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 ) - 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 ); - 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 ); - 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 ) - 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: -X-Mailing-List: linux-kernel@vger.kernel.org -Xref: news.gmane.org gmane.linux.kernel:1282933 gmane.linux.file-systems:63394 -Archived-At: - -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 ---- - -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 - 3.5.0-0.rc4.git0.1 +- Disable debugging options. + +* Mon Jun 25 2012 Justin M. Forbes +- Linux 3.5-rc4 + * Fri Jun 22 2012 Josh Boyer - 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: -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 + 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 - ); Fri, 8 Jun 2012 18:08:21 -0400 -Received: by bkty5 with SMTP id y5so128736bkt.1 - for ; 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: -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 -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 -Cc: Jonathan Nieder -Cc: Ulrich Obergfell -Cc: Mel Gorman -Cc: Hugh Dickins -Cc: Larry Woodman -Cc: Petr Matousek -Cc: Rik van Riel -Cc: Jan Beulich -Cc: KOSAKI Motohiro -Cc: -Signed-off-by: Andrew Morton ---- - - 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