Index: PATCHES/patches/Revert-cpufreq-pcc-cpufreq-update-default-value-of-c.patch
===================================================================
--- PATCHES/patches/Revert-cpufreq-pcc-cpufreq-update-default-value-of-c.patch	(revision 1047017)
+++ PATCHES/patches/Revert-cpufreq-pcc-cpufreq-update-default-value-of-c.patch	(nonexistent)
@@ -1,75 +0,0 @@
-From da7d3abe1c9e5ebac2cf86f97e9e89888a5e2094 Mon Sep 17 00:00:00 2001
-From: Andreas Herrmann <aherrmann@suse.com>
-Date: Fri, 22 Jul 2016 17:14:11 +0200
-Subject: [PATCH] Revert "cpufreq: pcc-cpufreq: update default value of
- cpuinfo_transition_latency"
-
-This reverts commit 790d849bf811a8ab5d4cd2cce0f6fda92f6aebf2.
-
-Using a v4.7-rc7 kernel on a HP ProLiant triggered following messages
-
- pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz
- cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governor
-
-The last line was shown for each CPU in the system.
-Testing v4.5 (where commit 790d849b was integrated) triggered
-similar messages. Same behaviour on a 2nd HP Proliant system.
-
-So commit 790d849bf (cpufreq: pcc-cpufreq: update default value of
-cpuinfo_transition_latency) causes the system to use performance
-governor which, I guess, was not the intention of the patch.
-
-Enabling debug output in pcc-cpufreq provides following verbose output:
-
- pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz
- pcc_get_offset: for CPU 0: pcc_cpu_data input_offset: 0x44, pcc_cpu_data output_offset: 0x48
- init: policy->max is 2800000, policy->min is 1200000
- get: get_freq for CPU 0
- get: SUCCESS: (virtual) output_offset for cpu 0 is 0xffffc9000d7c0048, contains a value of: 0xff06. Speed is: 168000 MHz
- cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governor
- target: CPU 0 should go to target freq: 2800000 (virtual) input_offset is 0xffffc9000d7c0044
- target: was SUCCESSFUL for cpu 0
-
-I am asking to revert 790d849bf to re-enable usage of ondemand
-governor with pcc-cpufreq.
-
-Fixes: 790d849bf (cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency)
-CC: <stable@vger.kernel.org> # 4.5+
-Signed-off-by: Andreas Herrmann <aherrmann@suse.com>
-Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
----
- Documentation/cpu-freq/pcc-cpufreq.txt | 4 ++--
- drivers/cpufreq/pcc-cpufreq.c          | 2 --
- 2 files changed, 2 insertions(+), 4 deletions(-)
-
-diff --git a/Documentation/cpu-freq/pcc-cpufreq.txt b/Documentation/cpu-freq/pcc-cpufreq.txt
-index 0a94224..9e3c3b3 100644
---- a/Documentation/cpu-freq/pcc-cpufreq.txt
-+++ b/Documentation/cpu-freq/pcc-cpufreq.txt
-@@ -159,8 +159,8 @@ to be strictly associated with a P-state.
- 
- 2.2 cpuinfo_transition_latency:
- -------------------------------
--The cpuinfo_transition_latency field is CPUFREQ_ETERNAL. The PCC specification
--does not include a field to expose this value currently.
-+The cpuinfo_transition_latency field is 0. The PCC specification does
-+not include a field to expose this value currently.
- 
- 2.3 cpuinfo_cur_freq:
- ---------------------
-diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
-index a7ecb9a..3f0ce2a 100644
---- a/drivers/cpufreq/pcc-cpufreq.c
-+++ b/drivers/cpufreq/pcc-cpufreq.c
-@@ -555,8 +555,6 @@ static int pcc_cpufreq_cpu_init(struct cpufreq_policy *policy)
- 	policy->min = policy->cpuinfo.min_freq =
- 		ioread32(&pcch_hdr->minimum_frequency) * 1000;
- 
--	policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
--
- 	pr_debug("init: policy->max is %d, policy->min is %d\n",
- 		policy->max, policy->min);
- out:
--- 
-2.9.2
-
Index: PATCHES/patches/fs-ext4-don-t-call-ext4_should_journal_data-on-the-jour.patch
===================================================================
--- PATCHES/patches/fs-ext4-don-t-call-ext4_should_journal_data-on-the-jour.patch	(revision 1047017)
+++ PATCHES/patches/fs-ext4-don-t-call-ext4_should_journal_data-on-the-jour.patch	(nonexistent)
@@ -1,45 +0,0 @@
-From 6a7fd522a7c94cdef0a3b08acf8e6702056e635c Mon Sep 17 00:00:00 2001
-From: Vegard Nossum <vegard.nossum@oracle.com>
-Date: Mon, 4 Jul 2016 11:03:00 -0400
-Subject: [PATCH] ext4: don't call ext4_should_journal_data() on the journal
- inode
-
-If ext4_fill_super() fails early, it's possible for ext4_evict_inode()
-to call ext4_should_journal_data() before superblock options and flags
-are fully set up.  In that case, the iput() on the journal inode can
-end up causing a BUG().
-
-Work around this problem by reordering the tests so we only call
-ext4_should_journal_data() after we know it's not the journal inode.
-
-Fixes: 2d859db3e4 ("ext4: fix data corruption in inodes with journalled data")
-Fixes: 2b405bfa84 ("ext4: fix data=journal fast mount/umount hang")
-Cc: Jan Kara <jack@suse.cz>
-Cc: stable@vger.kernel.org
-Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
-Signed-off-by: Theodore Ts'o <tytso@mit.edu>
-Reviewed-by: Jan Kara <jack@suse.cz>
----
- fs/ext4/inode.c | 6 +++---
- 1 file changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
-index 321a31c..ea39d19 100644
---- a/fs/ext4/inode.c
-+++ b/fs/ext4/inode.c
-@@ -211,9 +211,9 @@ void ext4_evict_inode(struct inode *inode)
- 		 * Note that directories do not have this problem because they
- 		 * don't use page cache.
- 		 */
--		if (ext4_should_journal_data(inode) &&
--		    (S_ISLNK(inode->i_mode) || S_ISREG(inode->i_mode)) &&
--		    inode->i_ino != EXT4_JOURNAL_INO) {
-+		if (inode->i_ino != EXT4_JOURNAL_INO &&
-+		    ext4_should_journal_data(inode) &&
-+		    (S_ISLNK(inode->i_mode) || S_ISREG(inode->i_mode))) {
- 			journal_t *journal = EXT4_SB(inode->i_sb)->s_journal;
- 			tid_t commit_tid = EXT4_I(inode)->i_datasync_tid;
- 
--- 
-2.9.2
-
Index: PATCHES/patches/fs-ext4-fix-deadlock-during-page-writeback.patch
===================================================================
--- PATCHES/patches/fs-ext4-fix-deadlock-during-page-writeback.patch	(revision 1047017)
+++ PATCHES/patches/fs-ext4-fix-deadlock-during-page-writeback.patch	(nonexistent)
@@ -1,78 +0,0 @@
-From 646caa9c8e196880b41cd3e3d33a2ebc752bdb85 Mon Sep 17 00:00:00 2001
-From: Jan Kara <jack@suse.cz>
-Date: Mon, 4 Jul 2016 10:14:01 -0400
-Subject: [PATCH] ext4: fix deadlock during page writeback
-
-Commit 06bd3c36a733 (ext4: fix data exposure after a crash) uncovered a
-deadlock in ext4_writepages() which was previously much harder to hit.
-After this commit xfstest generic/130 reproduces the deadlock on small
-filesystems.
-
-The problem happens when ext4_do_update_inode() sets LARGE_FILE feature
-and marks current inode handle as synchronous. That subsequently results
-in ext4_journal_stop() called from ext4_writepages() to block waiting for
-transaction commit while still holding page locks, reference to io_end,
-and some prepared bio in mpd structure each of which can possibly block
-transaction commit from completing and thus results in deadlock.
-
-Fix the problem by releasing page locks, io_end reference, and
-submitting prepared bio before calling ext4_journal_stop().
-
-[ Changed to defer the call to ext4_journal_stop() only if the handle
-  is synchronous.  --tytso ]
-
-Reported-and-tested-by: Eryu Guan <eguan@redhat.com>
-Signed-off-by: Theodore Ts'o <tytso@mit.edu>
-CC: stable@vger.kernel.org
-Signed-off-by: Jan Kara <jack@suse.cz>
----
- fs/ext4/inode.c | 29 ++++++++++++++++++++++++++---
- 1 file changed, 26 insertions(+), 3 deletions(-)
-
-diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
-index 44ee5d9..321a31c 100644
---- a/fs/ext4/inode.c
-+++ b/fs/ext4/inode.c
-@@ -2754,13 +2754,36 @@ retry:
- 				done = true;
- 			}
- 		}
--		ext4_journal_stop(handle);
-+		/*
-+		 * Caution: If the handle is synchronous,
-+		 * ext4_journal_stop() can wait for transaction commit
-+		 * to finish which may depend on writeback of pages to
-+		 * complete or on page lock to be released.  In that
-+		 * case, we have to wait until after after we have
-+		 * submitted all the IO, released page locks we hold,
-+		 * and dropped io_end reference (for extent conversion
-+		 * to be able to complete) before stopping the handle.
-+		 */
-+		if (!ext4_handle_valid(handle) || handle->h_sync == 0) {
-+			ext4_journal_stop(handle);
-+			handle = NULL;
-+		}
- 		/* Submit prepared bio */
- 		ext4_io_submit(&mpd.io_submit);
- 		/* Unlock pages we didn't use */
- 		mpage_release_unused_pages(&mpd, give_up_on_write);
--		/* Drop our io_end reference we got from init */
--		ext4_put_io_end(mpd.io_submit.io_end);
-+		/*
-+		 * Drop our io_end reference we got from init. We have
-+		 * to be careful and use deferred io_end finishing if
-+		 * we are still holding the transaction as we can
-+		 * release the last reference to io_end which may end
-+		 * up doing unwritten extent conversion.
-+		 */
-+		if (handle) {
-+			ext4_put_io_end_defer(mpd.io_submit.io_end);
-+			ext4_journal_stop(handle);
-+		} else
-+			ext4_put_io_end(mpd.io_submit.io_end);
- 
- 		if (ret == -ENOSPC && sbi->s_journal) {
- 			/*
--- 
-2.9.2
-
Index: PATCHES/patches/series
===================================================================
--- PATCHES/patches/series	(revision 1047017)
+++ PATCHES/patches/series	(working copy)
@@ -38,15 +38,9 @@
 # slows down boot
 Revert-cpufreq-pcc-Enable-autoload-of-pcc-cpufreq-fo.patch
 
-#
-Revert-cpufreq-pcc-cpufreq-update-default-value-of-c.patch
-
 # breaks nvidia304
 Revert-x86-mm-mtrr-Remove-kernel-internal-MTRR-inter.patch
 
-#
-x86-power-64-Fix-hibernation-return-address-corrupti.patch
-
 ###
 ### Core
 ###
@@ -147,10 +141,6 @@
 fs-aufs-4.7-modular.patch
 fs-aufs-4.7-ver-fix.patch
 
-# ext4
-fs-ext4-don-t-call-ext4_should_journal_data-on-the-jour.patch
-fs-ext4-fix-deadlock-during-page-writeback.patch
-
 ###
 ### FireWire
 ###
Index: PATCHES/patches/x86-power-64-Fix-hibernation-return-address-corrupti.patch
===================================================================
--- PATCHES/patches/x86-power-64-Fix-hibernation-return-address-corrupti.patch	(revision 1047017)
+++ PATCHES/patches/x86-power-64-Fix-hibernation-return-address-corrupti.patch	(nonexistent)
@@ -1,101 +0,0 @@
-From 4ce827b4cc58bec7952591b96cce2b28553e4d5b Mon Sep 17 00:00:00 2001
-From: Josh Poimboeuf <jpoimboe@redhat.com>
-Date: Thu, 28 Jul 2016 23:15:21 +0200
-Subject: [PATCH] x86/power/64: Fix hibernation return address corruption
-
-In kernel bug 150021, a kernel panic was reported when restoring a
-hibernate image.  Only a picture of the oops was reported, so I can't
-paste the whole thing here.  But here are the most interesting parts:
-
-  kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
-  BUG: unable to handle kernel paging request at ffff8804615cfd78
-  ...
-  RIP: ffff8804615cfd78
-  RSP: ffff8804615f0000
-  RBP: ffff8804615cfdc0
-  ...
-  Call Trace:
-   do_signal+0x23
-   exit_to_usermode_loop+0x64
-   ...
-
-The RIP is on the same page as RBP, so it apparently started executing
-on the stack.
-
-The bug was bisected to commit ef0f3ed5a4ac (x86/asm/power: Create
-stack frames in hibernate_asm_64.S), which in retrospect seems quite
-dangerous, since that code saves and restores the stack pointer from a
-global variable ('saved_context').
-
-There are a lot of moving parts in the hibernate save and restore paths,
-so I don't know exactly what caused the panic.  Presumably, a FRAME_END
-was executed without the corresponding FRAME_BEGIN, or vice versa.  That
-would corrupt the return address on the stack and would be consistent
-with the details of the above panic.
-
-[ rjw: One major problem is that by the time the FRAME_BEGIN in
-  restore_registers() is executed, the stack pointer value may not
-  be valid any more.  Namely, the stack area pointed to by it
-  previously may have been overwritten by some image memory contents
-  and that page frame may now be used for whatever different purpose
-  it had been allocated for before hibernation.  In that case, the
-  FRAME_BEGIN will corrupt that memory. ]
-
-Instead of doing the frame pointer save/restore around the bounds of the
-affected functions, just do it around the call to swsusp_save().
-
-That has the same effect of ensuring that if swsusp_save() sleeps, the
-frame pointers will be correct.  It's also a much more obviously safe
-way to do it than the original patch.  And objtool still doesn't report
-any warnings.
-
-Fixes: ef0f3ed5a4ac (x86/asm/power: Create stack frames in hibernate_asm_64.S)
-Link: https://bugzilla.kernel.org/show_bug.cgi?id=150021
-Cc: 4.6+ <stable@vger.kernel.org> # 4.6+
-Reported-by: Andre Reinke <andre.reinke@mailbox.org>
-Tested-by: Andre Reinke <andre.reinke@mailbox.org>
-Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
-Acked-by: Ingo Molnar <mingo@kernel.org>
-Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
----
- arch/x86/power/hibernate_asm_64.S | 4 +---
- 1 file changed, 1 insertion(+), 3 deletions(-)
-
-diff --git a/arch/x86/power/hibernate_asm_64.S b/arch/x86/power/hibernate_asm_64.S
-index 3177c2b..8eee0e9 100644
---- a/arch/x86/power/hibernate_asm_64.S
-+++ b/arch/x86/power/hibernate_asm_64.S
-@@ -24,7 +24,6 @@
- #include <asm/frame.h>
- 
- ENTRY(swsusp_arch_suspend)
--	FRAME_BEGIN
- 	movq	$saved_context, %rax
- 	movq	%rsp, pt_regs_sp(%rax)
- 	movq	%rbp, pt_regs_bp(%rax)
-@@ -48,6 +47,7 @@ ENTRY(swsusp_arch_suspend)
- 	movq	%cr3, %rax
- 	movq	%rax, restore_cr3(%rip)
- 
-+	FRAME_BEGIN
- 	call swsusp_save
- 	FRAME_END
- 	ret
-@@ -104,7 +104,6 @@ ENTRY(core_restore_code)
- 	 /* code below belongs to the image kernel */
- 	.align PAGE_SIZE
- ENTRY(restore_registers)
--	FRAME_BEGIN
- 	/* go back to the original page tables */
- 	movq    %r9, %cr3
- 
-@@ -145,6 +144,5 @@ ENTRY(restore_registers)
- 	/* tell the hibernation core that we've just restored the memory */
- 	movq	%rax, in_suspend(%rip)
- 
--	FRAME_END
- 	ret
- ENDPROC(restore_registers)
--- 
-2.9.2
-
Index: SOURCES/patch-4.7.1.sign
===================================================================
--- SOURCES/patch-4.7.1.sign	(nonexistent)
+++ SOURCES/patch-4.7.1.sign	(working copy)
@@ -0,0 +1,17 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQIcBAABCAAGBQJXssJEAAoJEDjbvchgkmk+uwkQAJgrFlluBUOE6P92Ihb9JFWD
+Wlidr0gOSNf/Uig+xlyXxfbChAMLcIOtkt4vL64MsgD7YfjV8kZQ7DyWJAG5ETWM
+gEuugH0wj1m4FvunV9nx6CncgJwumvzu8UA2jWJLbW0Fcm5FLJwF3x89tGjv88V8
+97wLeIePMnDQZHbm4uryQ1zruPUT56/gtSMIMR8HuTMtus3ZifnK/jLrJW79IVV4
+ygJJDI1yrlka0jjOtwPI0OtxMK/SQJ6UKY0gNI1qiGGX4dWkQIebp8x5wniFxDV8
+dGOXq9esCv/SDIrQXhycfRsz5X1AD48fWPKYwIYeiWXswl7AsWat5CXaLPenGu4j
+1mxv5wRG90pbLuTVws5mg8HCWtzR3n6bvlCCAVQbEDJpOKmTez6RB32njdDc9f+8
+OLp2og/jjo6SeE/Dse5OB1WNamGkBY9wmpuXwbieDyzz5LxRjg6rP+d9EUrYpKah
+aQ06SVh/3yFl9fQVS0YnaX8zXbXHeQgM7Ff2kBKxwNpxDTMhuUGRbWKklFFFEqVh
++4/ylDPo0iRh9tE89H81Jb8ks32xjiFl7afqrvPqVSkxRYsuJvglZSN3aA+jd3pd
+0dnxjNVaNLMOEb/fYgnEA0NAGBKHoC+fQ+yDv+1NoHpQq5rb/iTyiFCx/I/vT87q
+Wt63WX7jhs1gzZRwHl5V
+=YhYZ
+-----END PGP SIGNATURE-----
Index: SOURCES/sha1.lst
===================================================================
--- SOURCES/sha1.lst	(revision 1047017)
+++ SOURCES/sha1.lst	(working copy)
@@ -1,2 +1,3 @@
-6de45352a52a93480e5206706dd5438d19db16ef  linux-4.7.0-mga2.tar.xz
+b79c573e9da6feb4a1257f09f971fce4e9819d1f  linux-4.7.1-mga1.tar.xz
 99551524779bf05382e363f4879101227664dd55  linux-4.7.tar.xz
+1a987f0b7b8dde6b66aedd9de2a2ad2846a05ced  patch-4.7.1.xz
Index: SPECS/kernel.spec
===================================================================
--- SPECS/kernel.spec	(revision 1047017)
+++ SPECS/kernel.spec	(working copy)
@@ -13,12 +13,12 @@
 %define kernelversion	4
 %define patchlevel	7
 # sublevel is now used for -stable patches
-%define sublevel	0
+%define sublevel	1
 # extstable is for extended stable patches
 %define extstable	0
 
 # Package release
-%define mgarel		2
+%define mgarel		1
 
 # kernel Makefile extraversion is substituted by
 # kpatch wich are either 0 (empty), rc (kpatch)
