Linux 3.5-rc4
This commit is contained in:
Justin M. Forbes
parent
e8d34e0ae5
commit
0350197e2d
@ -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) || \
|
||||
@ -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
|
||||
|
||||
21
kernel.spec
21
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
|
||||
|
||||
|
||||
2
sources
2
sources
@ -1,2 +1,2 @@
|
||||
967f72983655e2479f951195953e8480 linux-3.4.tar.xz
|
||||
45159d08e4a0cdeda609e1a33492b98a patch-3.5-rc3.xz
|
||||
29606cb3e7c174ac128ac39c00813c20 patch-3.5-rc4.xz
|
||||
|
||||
@ -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
|
||||
Loading…
Reference in New Issue
Block a user