From: Greg Kroah-Hartman Date: Fri, 27 Jun 2014 21:47:26 +0000 (-0700) Subject: 3.4-stable patches X-Git-Tag: v3.4.96~53 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=01e02d845e1f9a61f5d3dfeb7a7402f32216b226;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-stable patches added patches: ext4-fix-wrong-assert-in-ext4_mb_normalize_request.patch hid-core-fix-validation-of-report-id-0.patch matroxfb-perform-a-dummy-read-of-m_status.patch mm-fix-sleeping-function-warning-from-__put_anon_vma.patch mm-memory-failure.c-don-t-let-collect_procs-skip-over-processes-for-mf_action_required.patch mm-memory-failure.c-failure-send-right-signal-code-to-correct-thread.patch mm-vmscan-clear-kswapd-s-special-reclaim-powers-before-exiting.patch s390-lowcore-reserve-96-bytes-for-irb-in-lowcore.patch --- diff --git a/queue-3.4/ext4-fix-wrong-assert-in-ext4_mb_normalize_request.patch b/queue-3.4/ext4-fix-wrong-assert-in-ext4_mb_normalize_request.patch new file mode 100644 index 00000000000..492fa8ab326 --- /dev/null +++ b/queue-3.4/ext4-fix-wrong-assert-in-ext4_mb_normalize_request.patch @@ -0,0 +1,32 @@ +From b5b60778558cafad17bbcbf63e0310bd3c68eb17 Mon Sep 17 00:00:00 2001 +From: Maurizio Lombardi +Date: Tue, 27 May 2014 12:48:56 -0400 +Subject: ext4: fix wrong assert in ext4_mb_normalize_request() + +From: Maurizio Lombardi + +commit b5b60778558cafad17bbcbf63e0310bd3c68eb17 upstream. + +The variable "size" is expressed as number of blocks and not as +number of clusters, this could trigger a kernel panic when using +ext4 with the size of a cluster different from the size of a block. + +Signed-off-by: Maurizio Lombardi +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/mballoc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -3015,7 +3015,7 @@ ext4_mb_normalize_request(struct ext4_al + } + BUG_ON(start + size <= ac->ac_o_ex.fe_logical && + start > ac->ac_o_ex.fe_logical); +- BUG_ON(size <= 0 || size > EXT4_CLUSTERS_PER_GROUP(ac->ac_sb)); ++ BUG_ON(size <= 0 || size > EXT4_BLOCKS_PER_GROUP(ac->ac_sb)); + + /* now prepare goal request */ + diff --git a/queue-3.4/hid-core-fix-validation-of-report-id-0.patch b/queue-3.4/hid-core-fix-validation-of-report-id-0.patch new file mode 100644 index 00000000000..1e45b7fd203 --- /dev/null +++ b/queue-3.4/hid-core-fix-validation-of-report-id-0.patch @@ -0,0 +1,54 @@ +From 1b15d2e5b8077670b1e6a33250a0d9577efff4a5 Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Thu, 17 Apr 2014 13:22:09 -0700 +Subject: HID: core: fix validation of report id 0 + +From: Kees Cook + +commit 1b15d2e5b8077670b1e6a33250a0d9577efff4a5 upstream. + +Some drivers use the first HID report in the list instead of using an +index. In these cases, validation uses ID 0, which was supposed to mean +"first known report". This fixes the problem, which was causing at least +the lgff family of devices to stop working since hid_validate_values +was being called with ID 0, but the devices used single numbered IDs +for their reports: + +0x05, 0x01, /* Usage Page (Desktop), */ +0x09, 0x05, /* Usage (Gamepad), */ +0xA1, 0x01, /* Collection (Application), */ +0xA1, 0x02, /* Collection (Logical), */ +0x85, 0x01, /* Report ID (1), */ +... + +Reported-by: Simon Wood +Signed-off-by: Kees Cook +Reviewed-by: Benjamin Tissoires +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/hid-core.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/drivers/hid/hid-core.c ++++ b/drivers/hid/hid-core.c +@@ -861,7 +861,17 @@ struct hid_report *hid_validate_values(s + * ->numbered being checked, which may not always be the case when + * drivers go to access report values. + */ +- report = hid->report_enum[type].report_id_hash[id]; ++ if (id == 0) { ++ /* ++ * Validating on id 0 means we should examine the first ++ * report in the list. ++ */ ++ report = list_entry( ++ hid->report_enum[type].report_list.next, ++ struct hid_report, list); ++ } else { ++ report = hid->report_enum[type].report_id_hash[id]; ++ } + if (!report) { + hid_err(hid, "missing %s %u\n", hid_report_names[type], id); + return NULL; diff --git a/queue-3.4/matroxfb-perform-a-dummy-read-of-m_status.patch b/queue-3.4/matroxfb-perform-a-dummy-read-of-m_status.patch new file mode 100644 index 00000000000..71410d5a95d --- /dev/null +++ b/queue-3.4/matroxfb-perform-a-dummy-read-of-m_status.patch @@ -0,0 +1,40 @@ +From 972754cfaee94d6e25acf94a497bc0a864d91b7e Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Thu, 15 May 2014 06:58:24 -0400 +Subject: matroxfb: perform a dummy read of M_STATUS + +From: Mikulas Patocka + +commit 972754cfaee94d6e25acf94a497bc0a864d91b7e upstream. + +I had occasional screen corruption with the matrox framebuffer driver and +I found out that the reason for the corruption is that the hardware +blitter accesses the videoram while it is being written to. + +The matrox driver has a macro WaitTillIdle() that should wait until the +blitter is idle, but it sometimes doesn't work. I added a dummy read +mga_inl(M_STATUS) to WaitTillIdle() to fix the problem. The dummy read +will flush the write buffer in the PCI chipset, and the next read of +M_STATUS will return the hardware status. + +Since applying this patch, I had no screen corruption at all. + +Signed-off-by: Mikulas Patocka +Signed-off-by: Tomi Valkeinen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/video/matrox/matroxfb_base.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/video/matrox/matroxfb_base.h ++++ b/drivers/video/matrox/matroxfb_base.h +@@ -698,7 +698,7 @@ void matroxfb_unregister_driver(struct m + + #define mga_fifo(n) do {} while ((mga_inl(M_FIFOSTATUS) & 0xFF) < (n)) + +-#define WaitTillIdle() do {} while (mga_inl(M_STATUS) & 0x10000) ++#define WaitTillIdle() do { mga_inl(M_STATUS); do {} while (mga_inl(M_STATUS) & 0x10000); } while (0) + + /* code speedup */ + #ifdef CONFIG_FB_MATROX_MILLENIUM diff --git a/queue-3.4/mm-fix-sleeping-function-warning-from-__put_anon_vma.patch b/queue-3.4/mm-fix-sleeping-function-warning-from-__put_anon_vma.patch new file mode 100644 index 00000000000..7035fa8d812 --- /dev/null +++ b/queue-3.4/mm-fix-sleeping-function-warning-from-__put_anon_vma.patch @@ -0,0 +1,66 @@ +From 7f39dda9d86fb4f4f17af0de170decf125726f8c Mon Sep 17 00:00:00 2001 +From: Hugh Dickins +Date: Wed, 4 Jun 2014 16:05:33 -0700 +Subject: mm: fix sleeping function warning from __put_anon_vma + +From: Hugh Dickins + +commit 7f39dda9d86fb4f4f17af0de170decf125726f8c upstream. + +Trinity reports BUG: + + sleeping function called from invalid context at kernel/locking/rwsem.c:47 + in_atomic(): 0, irqs_disabled(): 0, pid: 5787, name: trinity-c27 + +__might_sleep < down_write < __put_anon_vma < page_get_anon_vma < +migrate_pages < compact_zone < compact_zone_order < try_to_compact_pages .. + +Right, since conversion to mutex then rwsem, we should not put_anon_vma() +from inside an rcu_read_lock()ed section: fix the two places that did so. +And add might_sleep() to anon_vma_free(), as suggested by Peter Zijlstra. + +Fixes: 88c22088bf23 ("mm: optimize page_lock_anon_vma() fast-path") +Reported-by: Dave Jones +Signed-off-by: Hugh Dickins +Cc: Peter Zijlstra +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/rmap.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/mm/rmap.c ++++ b/mm/rmap.c +@@ -103,6 +103,7 @@ static inline void anon_vma_free(struct + * LOCK should suffice since the actual taking of the lock must + * happen _before_ what follows. + */ ++ might_sleep(); + if (mutex_is_locked(&anon_vma->root->mutex)) { + anon_vma_lock(anon_vma); + anon_vma_unlock(anon_vma); +@@ -476,8 +477,9 @@ struct anon_vma *page_get_anon_vma(struc + * above cannot corrupt). + */ + if (!page_mapped(page)) { ++ rcu_read_unlock(); + put_anon_vma(anon_vma); +- anon_vma = NULL; ++ return NULL; + } + out: + rcu_read_unlock(); +@@ -527,9 +529,9 @@ struct anon_vma *page_lock_anon_vma(stru + } + + if (!page_mapped(page)) { ++ rcu_read_unlock(); + put_anon_vma(anon_vma); +- anon_vma = NULL; +- goto out; ++ return NULL; + } + + /* we pinned the anon_vma, its safe to sleep */ diff --git a/queue-3.4/mm-memory-failure.c-don-t-let-collect_procs-skip-over-processes-for-mf_action_required.patch b/queue-3.4/mm-memory-failure.c-don-t-let-collect_procs-skip-over-processes-for-mf_action_required.patch new file mode 100644 index 00000000000..fe0403cb87a --- /dev/null +++ b/queue-3.4/mm-memory-failure.c-don-t-let-collect_procs-skip-over-processes-for-mf_action_required.patch @@ -0,0 +1,123 @@ +From 74614de17db6fb472370c426d4f934d8d616edf2 Mon Sep 17 00:00:00 2001 +From: Tony Luck +Date: Wed, 4 Jun 2014 16:11:01 -0700 +Subject: mm/memory-failure.c: don't let collect_procs() skip over processes for MF_ACTION_REQUIRED + +From: Tony Luck + +commit 74614de17db6fb472370c426d4f934d8d616edf2 upstream. + +When Linux sees an "action optional" machine check (where h/w has reported +an error that is not in the current execution path) we generally do not +want to signal a process, since most processes do not have a SIGBUS +handler - we'd just prematurely terminate the process for a problem that +they might never actually see. + +task_early_kill() decides whether to consider a process - and it checks +whether this specific process has been marked for early signals with +"prctl", or if the system administrator has requested early signals for +all processes using /proc/sys/vm/memory_failure_early_kill. + +But for MF_ACTION_REQUIRED case we must not defer. The error is in the +execution path of the current thread so we must send the SIGBUS +immediatley. + +Fix by passing a flag argument through collect_procs*() to +task_early_kill() so it knows whether we can defer or must take action. + +Signed-off-by: Tony Luck +Signed-off-by: Naoya Horiguchi +Cc: Andi Kleen +Cc: Borislav Petkov +Cc: Chen Gong +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memory-failure.c | 21 ++++++++++++--------- + 1 file changed, 12 insertions(+), 9 deletions(-) + +--- a/mm/memory-failure.c ++++ b/mm/memory-failure.c +@@ -382,10 +382,12 @@ static void kill_procs(struct list_head + } + } + +-static int task_early_kill(struct task_struct *tsk) ++static int task_early_kill(struct task_struct *tsk, int force_early) + { + if (!tsk->mm) + return 0; ++ if (force_early) ++ return 1; + if (tsk->flags & PF_MCE_PROCESS) + return !!(tsk->flags & PF_MCE_EARLY); + return sysctl_memory_failure_early_kill; +@@ -395,7 +397,7 @@ static int task_early_kill(struct task_s + * Collect processes when the error hit an anonymous page. + */ + static void collect_procs_anon(struct page *page, struct list_head *to_kill, +- struct to_kill **tkc) ++ struct to_kill **tkc, int force_early) + { + struct vm_area_struct *vma; + struct task_struct *tsk; +@@ -409,7 +411,7 @@ static void collect_procs_anon(struct pa + for_each_process (tsk) { + struct anon_vma_chain *vmac; + +- if (!task_early_kill(tsk)) ++ if (!task_early_kill(tsk, force_early)) + continue; + list_for_each_entry(vmac, &av->head, same_anon_vma) { + vma = vmac->vma; +@@ -427,7 +429,7 @@ static void collect_procs_anon(struct pa + * Collect processes when the error hit a file mapped page. + */ + static void collect_procs_file(struct page *page, struct list_head *to_kill, +- struct to_kill **tkc) ++ struct to_kill **tkc, int force_early) + { + struct vm_area_struct *vma; + struct task_struct *tsk; +@@ -439,7 +441,7 @@ static void collect_procs_file(struct pa + for_each_process(tsk) { + pgoff_t pgoff = page->index << (PAGE_CACHE_SHIFT - PAGE_SHIFT); + +- if (!task_early_kill(tsk)) ++ if (!task_early_kill(tsk, force_early)) + continue; + + vma_prio_tree_foreach(vma, &iter, &mapping->i_mmap, pgoff, +@@ -465,7 +467,8 @@ static void collect_procs_file(struct pa + * First preallocate one tokill structure outside the spin locks, + * so that we can kill at least one process reasonably reliable. + */ +-static void collect_procs(struct page *page, struct list_head *tokill) ++static void collect_procs(struct page *page, struct list_head *tokill, ++ int force_early) + { + struct to_kill *tk; + +@@ -476,9 +479,9 @@ static void collect_procs(struct page *p + if (!tk) + return; + if (PageAnon(page)) +- collect_procs_anon(page, tokill, &tk); ++ collect_procs_anon(page, tokill, &tk, force_early); + else +- collect_procs_file(page, tokill, &tk); ++ collect_procs_file(page, tokill, &tk, force_early); + kfree(tk); + } + +@@ -948,7 +951,7 @@ static int hwpoison_user_mappings(struct + * there's nothing that can be done. + */ + if (kill) +- collect_procs(ppage, &tokill); ++ collect_procs(ppage, &tokill, flags & MF_ACTION_REQUIRED); + + if (hpage != ppage) + lock_page(ppage); diff --git a/queue-3.4/mm-memory-failure.c-failure-send-right-signal-code-to-correct-thread.patch b/queue-3.4/mm-memory-failure.c-failure-send-right-signal-code-to-correct-thread.patch new file mode 100644 index 00000000000..aea244f7fdd --- /dev/null +++ b/queue-3.4/mm-memory-failure.c-failure-send-right-signal-code-to-correct-thread.patch @@ -0,0 +1,53 @@ +From a70ffcac741d31a406c1d2b832ae43d658e7e1cf Mon Sep 17 00:00:00 2001 +From: Tony Luck +Date: Wed, 4 Jun 2014 16:10:59 -0700 +Subject: mm/memory-failure.c-failure: send right signal code to correct thread + +From: Tony Luck + +commit a70ffcac741d31a406c1d2b832ae43d658e7e1cf upstream. + +When a thread in a multi-threaded application hits a machine check because +of an uncorrectable error in memory - we want to send the SIGBUS with +si.si_code = BUS_MCEERR_AR to that thread. Currently we fail to do that +if the active thread is not the primary thread in the process. +collect_procs() just finds primary threads and this test: + + if ((flags & MF_ACTION_REQUIRED) && t == current) { + +will see that the thread we found isn't the current thread and so send a +si.si_code = BUS_MCEERR_AO to the primary (and nothing to the active +thread at this time). + +We can fix this by checking whether "current" shares the same mm with the +process that collect_procs() said owned the page. If so, we send the +SIGBUS to current (with code BUS_MCEERR_AR). + +Signed-off-by: Tony Luck +Signed-off-by: Naoya Horiguchi +Reported-by: Otto Bruggeman +Cc: Andi Kleen +Cc: Borislav Petkov +Cc: Chen Gong +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memory-failure.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/mm/memory-failure.c ++++ b/mm/memory-failure.c +@@ -208,9 +208,9 @@ static int kill_proc(struct task_struct + #endif + si.si_addr_lsb = compound_trans_order(compound_head(page)) + PAGE_SHIFT; + +- if ((flags & MF_ACTION_REQUIRED) && t == current) { ++ if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) { + si.si_code = BUS_MCEERR_AR; +- ret = force_sig_info(SIGBUS, &si, t); ++ ret = force_sig_info(SIGBUS, &si, current); + } else { + /* + * Don't use force here, it's convenient if the signal diff --git a/queue-3.4/mm-vmscan-clear-kswapd-s-special-reclaim-powers-before-exiting.patch b/queue-3.4/mm-vmscan-clear-kswapd-s-special-reclaim-powers-before-exiting.patch new file mode 100644 index 00000000000..50b9e8ea7ae --- /dev/null +++ b/queue-3.4/mm-vmscan-clear-kswapd-s-special-reclaim-powers-before-exiting.patch @@ -0,0 +1,94 @@ +From 71abdc15adf8c702a1dd535f8e30df50758848d2 Mon Sep 17 00:00:00 2001 +From: Johannes Weiner +Date: Fri, 6 Jun 2014 14:35:35 -0700 +Subject: mm: vmscan: clear kswapd's special reclaim powers before exiting + +From: Johannes Weiner + +commit 71abdc15adf8c702a1dd535f8e30df50758848d2 upstream. + +When kswapd exits, it can end up taking locks that were previously held +by allocating tasks while they waited for reclaim. Lockdep currently +warns about this: + +On Wed, May 28, 2014 at 06:06:34PM +0800, Gu Zheng wrote: +> inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. +> kswapd2/1151 [HC0[0]:SC0[0]:HE1:SE1] takes: +> (&sig->group_rwsem){+++++?}, at: exit_signals+0x24/0x130 +> {RECLAIM_FS-ON-W} state was registered at: +> mark_held_locks+0xb9/0x140 +> lockdep_trace_alloc+0x7a/0xe0 +> kmem_cache_alloc_trace+0x37/0x240 +> flex_array_alloc+0x99/0x1a0 +> cgroup_attach_task+0x63/0x430 +> attach_task_by_pid+0x210/0x280 +> cgroup_procs_write+0x16/0x20 +> cgroup_file_write+0x120/0x2c0 +> vfs_write+0xc0/0x1f0 +> SyS_write+0x4c/0xa0 +> tracesys+0xdd/0xe2 +> irq event stamp: 49 +> hardirqs last enabled at (49): _raw_spin_unlock_irqrestore+0x36/0x70 +> hardirqs last disabled at (48): _raw_spin_lock_irqsave+0x2b/0xa0 +> softirqs last enabled at (0): copy_process.part.24+0x627/0x15f0 +> softirqs last disabled at (0): (null) +> +> other info that might help us debug this: +> Possible unsafe locking scenario: +> +> CPU0 +> ---- +> lock(&sig->group_rwsem); +> +> lock(&sig->group_rwsem); +> +> *** DEADLOCK *** +> +> no locks held by kswapd2/1151. +> +> stack backtrace: +> CPU: 30 PID: 1151 Comm: kswapd2 Not tainted 3.10.39+ #4 +> Call Trace: +> dump_stack+0x19/0x1b +> print_usage_bug+0x1f7/0x208 +> mark_lock+0x21d/0x2a0 +> __lock_acquire+0x52a/0xb60 +> lock_acquire+0xa2/0x140 +> down_read+0x51/0xa0 +> exit_signals+0x24/0x130 +> do_exit+0xb5/0xa50 +> kthread+0xdb/0x100 +> ret_from_fork+0x7c/0xb0 + +This is because the kswapd thread is still marked as a reclaimer at the +time of exit. But because it is exiting, nobody is actually waiting on +it to make reclaim progress anymore, and it's nothing but a regular +thread at this point. Be tidy and strip it of all its powers +(PF_MEMALLOC, PF_SWAPWRITE, PF_KSWAPD, and the lockdep reclaim state) +before returning from the thread function. + +Signed-off-by: Johannes Weiner +Reported-by: Gu Zheng +Cc: Yasuaki Ishimatsu +Cc: Tang Chen +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/vmscan.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/mm/vmscan.c ++++ b/mm/vmscan.c +@@ -3138,7 +3138,10 @@ static int kswapd(void *p) + } + } + ++ tsk->flags &= ~(PF_MEMALLOC | PF_SWAPWRITE | PF_KSWAPD); + current->reclaim_state = NULL; ++ lockdep_clear_current_reclaim_state(); ++ + return 0; + } + diff --git a/queue-3.4/s390-lowcore-reserve-96-bytes-for-irb-in-lowcore.patch b/queue-3.4/s390-lowcore-reserve-96-bytes-for-irb-in-lowcore.patch new file mode 100644 index 00000000000..4b2f08c0eef --- /dev/null +++ b/queue-3.4/s390-lowcore-reserve-96-bytes-for-irb-in-lowcore.patch @@ -0,0 +1,63 @@ +From 993072ee67aa179c48c85eb19869804e68887d86 Mon Sep 17 00:00:00 2001 +From: Christian Borntraeger +Date: Mon, 26 May 2014 21:55:08 +0200 +Subject: s390/lowcore: reserve 96 bytes for IRB in lowcore + +From: Christian Borntraeger + +commit 993072ee67aa179c48c85eb19869804e68887d86 upstream. + +The IRB might be 96 bytes if the extended-I/O-measurement facility is +used. This feature is currently not used by Linux, but struct irb +already has the emw defined. So let's make the irb in lowcore match the +size of the internal data structure to be future proof. +We also have to add a pad, to correctly align the paste. + +The bigger irb field also circumvents a bug in some QEMU versions that +always write the emw field on test subchannel and therefore destroy the +paste definitions of this CPU. Running under these QEMU version broke +some timing functions in the VDSO and all users of these functions, +e.g. some JREs. + +Signed-off-by: Christian Borntraeger +Signed-off-by: Martin Schwidefsky +Cc: Heiko Carstens +Cc: Sebastian Ott +Cc: Cornelia Huck +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/include/asm/lowcore.h | 11 ++++++----- + 1 file changed, 6 insertions(+), 5 deletions(-) + +--- a/arch/s390/include/asm/lowcore.h ++++ b/arch/s390/include/asm/lowcore.h +@@ -142,9 +142,9 @@ struct _lowcore { + __u8 pad_0x02fc[0x0300-0x02fc]; /* 0x02fc */ + + /* Interrupt response block */ +- __u8 irb[64]; /* 0x0300 */ ++ __u8 irb[96]; /* 0x0300 */ + +- __u8 pad_0x0340[0x0e00-0x0340]; /* 0x0340 */ ++ __u8 pad_0x0360[0x0e00-0x0360]; /* 0x0360 */ + + /* + * 0xe00 contains the address of the IPL Parameter Information +@@ -288,12 +288,13 @@ struct _lowcore { + __u8 pad_0x03a0[0x0400-0x03a0]; /* 0x03a0 */ + + /* Interrupt response block. */ +- __u8 irb[64]; /* 0x0400 */ ++ __u8 irb[96]; /* 0x0400 */ ++ __u8 pad_0x0460[0x0480-0x0460]; /* 0x0460 */ + + /* Per cpu primary space access list */ +- __u32 paste[16]; /* 0x0440 */ ++ __u32 paste[16]; /* 0x0480 */ + +- __u8 pad_0x0480[0x0e00-0x0480]; /* 0x0480 */ ++ __u8 pad_0x04c0[0x0e00-0x04c0]; /* 0x04c0 */ + + /* + * 0xe00 contains the address of the IPL Parameter Information diff --git a/queue-3.4/series b/queue-3.4/series index 80b5e9b497b..f2818fc4ec8 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -7,3 +7,11 @@ usb-gadget-rename-config_usb_gadget_pxa25x.patch usb-dwc3-gadget-clear-stall-when-disabling-endpoint.patch usb-ehci-avoid-bios-handover-on-the-hasee-e200.patch usb-option-fix-runtime-pm-handling.patch +mm-memory-failure.c-failure-send-right-signal-code-to-correct-thread.patch +mm-memory-failure.c-don-t-let-collect_procs-skip-over-processes-for-mf_action_required.patch +mm-fix-sleeping-function-warning-from-__put_anon_vma.patch +hid-core-fix-validation-of-report-id-0.patch +mm-vmscan-clear-kswapd-s-special-reclaim-powers-before-exiting.patch +s390-lowcore-reserve-96-bytes-for-irb-in-lowcore.patch +ext4-fix-wrong-assert-in-ext4_mb_normalize_request.patch +matroxfb-perform-a-dummy-read-of-m_status.patch