--- /dev/null
+From 8c5122e45a10a9262f872b53f151a592e870f905 Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
+Date: Wed, 8 Jun 2016 17:28:29 -0600
+Subject: IB/mlx4: Properly initialize GRH TClass and FlowLabel in AHs
+
+From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
+
+commit 8c5122e45a10a9262f872b53f151a592e870f905 upstream.
+
+When this code was reworked for IBoE support the order of assignments
+for the sl_tclass_flowlabel got flipped around resulting in
+TClass & FlowLabel being permanently set to 0 in the packet headers.
+
+This breaks IB routers that rely on these headers, but only affects
+kernel users - libmlx4 does this properly for user space.
+
+Fixes: fa417f7b520e ("IB/mlx4: Add support for IBoE")
+Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/hw/mlx4/ah.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/mlx4/ah.c
++++ b/drivers/infiniband/hw/mlx4/ah.c
+@@ -46,6 +46,7 @@ static struct ib_ah *create_ib_ah(struct
+
+ ah->av.ib.port_pd = cpu_to_be32(to_mpd(pd)->pdn | (ah_attr->port_num << 24));
+ ah->av.ib.g_slid = ah_attr->src_path_bits;
++ ah->av.ib.sl_tclass_flowlabel = cpu_to_be32(ah_attr->sl << 28);
+ if (ah_attr->ah_flags & IB_AH_GRH) {
+ ah->av.ib.g_slid |= 0x80;
+ ah->av.ib.gid_index = ah_attr->grh.sgid_index;
+@@ -63,7 +64,6 @@ static struct ib_ah *create_ib_ah(struct
+ !(1 << ah->av.ib.stat_rate & dev->caps.stat_rate_support))
+ --ah->av.ib.stat_rate;
+ }
+- ah->av.ib.sl_tclass_flowlabel = cpu_to_be32(ah_attr->sl << 28);
+
+ return &ah->ibah;
+ }
--- /dev/null
+From dcfc47248d3f7d28df6f531e6426b933de94370d Mon Sep 17 00:00:00 2001
+From: Masami Hiramatsu <mhiramat@kernel.org>
+Date: Sat, 11 Jun 2016 23:06:53 +0900
+Subject: kprobes/x86: Clear TF bit in fault on single-stepping
+
+From: Masami Hiramatsu <mhiramat@kernel.org>
+
+commit dcfc47248d3f7d28df6f531e6426b933de94370d upstream.
+
+Fix kprobe_fault_handler() to clear the TF (trap flag) bit of
+the flags register in the case of a fault fixup on single-stepping.
+
+If we put a kprobe on the instruction which caused a
+page fault (e.g. actual mov instructions in copy_user_*),
+that fault happens on the single-stepping buffer. In this
+case, kprobes resets running instance so that the CPU can
+retry execution on the original ip address.
+
+However, current code forgets to reset the TF bit. Since this
+fault happens with TF bit set for enabling single-stepping,
+when it retries, it causes a debug exception and kprobes
+can not handle it because it already reset itself.
+
+On the most of x86-64 platform, it can be easily reproduced
+by using kprobe tracer. E.g.
+
+ # cd /sys/kernel/debug/tracing
+ # echo p copy_user_enhanced_fast_string+5 > kprobe_events
+ # echo 1 > events/kprobes/enable
+
+And you'll see a kernel panic on do_debug(), since the debug
+trap is not handled by kprobes.
+
+To fix this problem, we just need to clear the TF bit when
+resetting running kprobe.
+
+Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
+Reviewed-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
+Acked-by: Steven Rostedt <rostedt@goodmis.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Stephane Eranian <eranian@google.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vince Weaver <vincent.weaver@maine.edu>
+Cc: systemtap@sourceware.org
+Link: http://lkml.kernel.org/r/20160611140648.25885.37482.stgit@devbox
+[ Updated the comments. ]
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/kprobes/core.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/arch/x86/kernel/kprobes/core.c
++++ b/arch/x86/kernel/kprobes/core.c
+@@ -911,7 +911,19 @@ int __kprobes kprobe_fault_handler(struc
+ * normal page fault.
+ */
+ regs->ip = (unsigned long)cur->addr;
++ /*
++ * Trap flag (TF) has been set here because this fault
++ * happened where the single stepping will be done.
++ * So clear it by resetting the current kprobe:
++ */
++ regs->flags &= ~X86_EFLAGS_TF;
++
++ /*
++ * If the TF flag was set before the kprobe hit,
++ * don't touch it:
++ */
+ regs->flags |= kcb->kprobe_old_flags;
++
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ restore_previous_kprobe(kcb);
+ else
--- /dev/null
+From 0422e83d84ae24b933e4b0d4c1e0f0b4ae8a0a3b Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Thu, 26 May 2016 21:08:17 +0100
+Subject: locking/ww_mutex: Report recursive ww_mutex locking early
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 0422e83d84ae24b933e4b0d4c1e0f0b4ae8a0a3b upstream.
+
+Recursive locking for ww_mutexes was originally conceived as an
+exception. However, it is heavily used by the DRM atomic modesetting
+code. Currently, the recursive deadlock is checked after we have queued
+up for a busy-spin and as we never release the lock, we spin until
+kicked, whereupon the deadlock is discovered and reported.
+
+A simple solution for the now common problem is to move the recursive
+deadlock discovery to the first action when taking the ww_mutex.
+
+Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lkml.kernel.org/r/1464293297-19777-1-git-send-email-chris@chris-wilson.co.uk
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/locking/mutex.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/kernel/locking/mutex.c
++++ b/kernel/locking/mutex.c
+@@ -304,9 +304,6 @@ __mutex_lock_check_stamp(struct mutex *l
+ if (!hold_ctx)
+ return 0;
+
+- if (unlikely(ctx == hold_ctx))
+- return -EALREADY;
+-
+ if (ctx->stamp - hold_ctx->stamp <= LONG_MAX &&
+ (ctx->stamp != hold_ctx->stamp || ctx > hold_ctx)) {
+ #ifdef CONFIG_DEBUG_MUTEXES
+@@ -417,6 +414,12 @@ __mutex_lock_common(struct mutex *lock,
+ unsigned long flags;
+ int ret;
+
++ if (use_ww_ctx) {
++ struct ww_mutex *ww = container_of(lock, struct ww_mutex, base);
++ if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
++ return -EALREADY;
++ }
++
+ preempt_disable();
+ mutex_acquire_nest(&lock->dep_map, subclass, 0, nest_lock, ip);
+
--- /dev/null
+From 126e7557328a1cd576be4fca95b133a2695283ff Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j@w1.fi>
+Date: Sun, 19 Jun 2016 23:51:02 +0300
+Subject: mac80211: Fix mesh estab_plinks counting in STA removal case
+
+From: Jouni Malinen <j@w1.fi>
+
+commit 126e7557328a1cd576be4fca95b133a2695283ff upstream.
+
+If a user space program (e.g., wpa_supplicant) deletes a STA entry that
+is currently in NL80211_PLINK_ESTAB state, the number of established
+plinks counter was not decremented and this could result in rejecting
+new plink establishment before really hitting the real maximum plink
+limit. For !user_mpm case, this decrementation is handled by
+mesh_plink_deactive().
+
+Fix this by decrementing estab_plinks on STA deletion
+(mesh_sta_cleanup() gets called from there) so that the counter has a
+correct value and the Beacon frame advertisement in Mesh Configuration
+element shows the proper value for capability to accept additional
+peers.
+
+Signed-off-by: Jouni Malinen <j@w1.fi>
+Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/mesh.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/net/mac80211/mesh.c
++++ b/net/mac80211/mesh.c
+@@ -148,14 +148,17 @@ u32 mesh_accept_plinks_update(struct iee
+ void mesh_sta_cleanup(struct sta_info *sta)
+ {
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+- u32 changed;
++ u32 changed = 0;
+
+ /*
+ * maybe userspace handles peer allocation and peering, but in either
+ * case the beacon is still generated by the kernel and we might need
+ * an update.
+ */
+- changed = mesh_accept_plinks_update(sdata);
++ if (sdata->u.mesh.user_mpm &&
++ sta->mesh->plink_state == NL80211_PLINK_ESTAB)
++ changed |= mesh_plink_dec_estab_count(sdata);
++ changed |= mesh_accept_plinks_update(sdata);
+ if (!sdata->u.mesh.user_mpm) {
+ changed |= mesh_plink_deactivate(sta);
+ del_timer_sync(&sta->plink_timer);
--- /dev/null
+From fe7a7c57629e8dcbc0e297363a9b2366d67a6dc5 Mon Sep 17 00:00:00 2001
+From: Bob Copeland <me@bobcopeland.com>
+Date: Sun, 15 May 2016 13:19:16 -0400
+Subject: mac80211: mesh: flush mesh paths unconditionally
+
+From: Bob Copeland <me@bobcopeland.com>
+
+commit fe7a7c57629e8dcbc0e297363a9b2366d67a6dc5 upstream.
+
+Currently, the mesh paths associated with a nexthop station are cleaned
+up in the following code path:
+
+ __sta_info_destroy_part1
+ synchronize_net()
+ __sta_info_destroy_part2
+ -> cleanup_single_sta
+ -> mesh_sta_cleanup
+ -> mesh_plink_deactivate
+ -> mesh_path_flush_by_nexthop
+
+However, there are a couple of problems here:
+
+1) the paths aren't flushed at all if the MPM is running in userspace
+ (e.g. when using wpa_supplicant or authsae)
+
+2) there is no synchronize_rcu between removing the path and readers
+ accessing the nexthop, which means the following race is possible:
+
+CPU0 CPU1
+~~~~ ~~~~
+ sta_info_destroy_part1()
+ synchronize_net()
+rcu_read_lock()
+mesh_nexthop_resolve()
+ mpath = mesh_path_lookup()
+ [...] -> mesh_path_flush_by_nexthop()
+ sta = rcu_dereference(
+ mpath->next_hop)
+ kfree(sta)
+ access sta <-- CRASH
+
+Fix both of these by unconditionally flushing paths before destroying
+the sta, and by adding a synchronize_net() after path flush to ensure
+no active readers can still dereference the sta.
+
+Fixes this crash:
+
+[ 348.529295] BUG: unable to handle kernel paging request at 00020040
+[ 348.530014] IP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
+[ 348.530014] *pde = 00000000
+[ 348.530014] Oops: 0000 [#1] PREEMPT
+[ 348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ]
+[ 348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G O 4.6.0-rc5-wt=V1 #1
+[ 348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016 11/07/2014
+[ 348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000
+[ 348.530014] EIP: 0060:[<f929245d>] EFLAGS: 00010246 CPU: 0
+[ 348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
+[ 348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008
+[ 348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40
+[ 348.530014] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
+[ 348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690
+[ 348.530014] Stack:
+[ 348.530014] 00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0
+[ 348.530014] f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320
+[ 348.530014] f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1
+[ 348.530014] Call Trace:
+[ 348.530014] [<f9291d80>] mesh_nexthop_lookup+0xbb/0xc8 [mac80211]
+[ 348.530014] [<f9291dc1>] mesh_nexthop_resolve+0x34/0xd8 [mac80211]
+[ 348.530014] [<f9277f6f>] ieee80211_xmit+0x92/0xc1 [mac80211]
+[ 348.530014] [<f9278dd1>] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211]
+[ 348.530014] [<c04df012>] ? sch_direct_xmit+0xd7/0x1b3
+[ 348.530014] [<c022a8c6>] ? __local_bh_enable_ip+0x5d/0x7b
+[ 348.530014] [<f956870c>] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4]
+[ 348.530014] [<f957e036>] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat]
+[ 348.530014] [<c04c6f45>] ? netif_skb_features+0x14d/0x30a
+[ 348.530014] [<f9278e10>] ieee80211_subif_start_xmit+0xa/0xe [mac80211]
+[ 348.530014] [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
+[ 348.530014] [<c04c7261>] ? validate_xmit_skb.isra.120.part.121+0x10/0x253
+[ 348.530014] [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
+[ 348.530014] [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
+[ 348.530014] [<c04c7cfb>] dev_queue_xmit+0xa/0xc
+[ 348.530014] [<f91bfc7a>] batadv_send_skb_packet+0xd6/0xec [batman_adv]
+[ 348.530014] [<f91bfdc4>] batadv_send_unicast_skb+0x15/0x4a [batman_adv]
+[ 348.530014] [<f91b5938>] batadv_dat_send_data+0x27e/0x310 [batman_adv]
+[ 348.530014] [<f91c30b5>] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv]
+[ 348.530014] [<f91b63f3>] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv]
+[ 348.530014] [<f91c0cd9>] batadv_interface_tx+0x206/0x385 [batman_adv]
+[ 348.530014] [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
+[ 348.530014] [<c04c7261>] ? validate_xmit_skb.isra.120.part.121+0x10/0x253
+[ 348.530014] [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
+[ 348.530014] [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
+[ 348.530014] [<f80cbd2a>] ? igb_xmit_frame+0x57/0x72 [igb]
+[ 348.530014] [<c04c7cfb>] dev_queue_xmit+0xa/0xc
+[ 348.530014] [<f843a326>] br_dev_queue_push_xmit+0xeb/0xfb [bridge]
+[ 348.530014] [<f843a35f>] br_forward_finish+0x29/0x74 [bridge]
+[ 348.530014] [<f843a23b>] ? deliver_clone+0x3b/0x3b [bridge]
+[ 348.530014] [<f843a714>] __br_forward+0x89/0xe7 [bridge]
+[ 348.530014] [<f843a336>] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge]
+[ 348.530014] [<f843a234>] deliver_clone+0x34/0x3b [bridge]
+[ 348.530014] [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
+[ 348.530014] [<f843a66d>] br_flood+0x77/0x95 [bridge]
+[ 348.530014] [<f843a809>] br_flood_forward+0x13/0x1a [bridge]
+[ 348.530014] [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
+[ 348.530014] [<f843b877>] br_handle_frame_finish+0x392/0x3db [bridge]
+[ 348.530014] [<c04e9b2b>] ? nf_iterate+0x2b/0x6b
+[ 348.530014] [<f843baa6>] br_handle_frame+0x1e6/0x240 [bridge]
+[ 348.530014] [<f843b4e5>] ? br_handle_local_finish+0x6a/0x6a [bridge]
+[ 348.530014] [<c04c4ba0>] __netif_receive_skb_core+0x43a/0x66b
+[ 348.530014] [<f843b8c0>] ? br_handle_frame_finish+0x3db/0x3db [bridge]
+[ 348.530014] [<c023cea4>] ? resched_curr+0x19/0x37
+[ 348.530014] [<c0240707>] ? check_preempt_wakeup+0xbf/0xfe
+[ 348.530014] [<c0255dec>] ? ktime_get_with_offset+0x5c/0xfc
+[ 348.530014] [<c04c4fc1>] __netif_receive_skb+0x47/0x55
+[ 348.530014] [<c04c57ba>] netif_receive_skb_internal+0x40/0x5a
+[ 348.530014] [<c04c61ef>] napi_gro_receive+0x3a/0x94
+[ 348.530014] [<f80ce8d5>] igb_poll+0x6fd/0x9ad [igb]
+[ 348.530014] [<c0242bd8>] ? swake_up_locked+0x14/0x26
+[ 348.530014] [<c04c5d29>] net_rx_action+0xde/0x250
+[ 348.530014] [<c022a743>] __do_softirq+0x8a/0x163
+[ 348.530014] [<c022a6b9>] ? __hrtimer_tasklet_trampoline+0x19/0x19
+[ 348.530014] [<c021100f>] do_softirq_own_stack+0x26/0x2c
+[ 348.530014] <IRQ>
+[ 348.530014] [<c022a957>] irq_exit+0x31/0x6f
+[ 348.530014] [<c0210eb2>] do_IRQ+0x8d/0xa0
+[ 348.530014] [<c058152c>] common_interrupt+0x2c/0x40
+[ 348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005
+[ 348.530014] EIP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40
+[ 348.530014] CR2: 0000000000020040
+[ 348.530014] ---[ end trace 48556ac26779732e ]---
+[ 348.530014] Kernel panic - not syncing: Fatal exception in interrupt
+[ 348.530014] Kernel Offset: disabled
+
+Reported-by: Fred Veldini <fred.veldini@gmail.com>
+Tested-by: Fred Veldini <fred.veldini@gmail.com>
+Signed-off-by: Bob Copeland <me@bobcopeland.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/mesh.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/net/mac80211/mesh.c
++++ b/net/mac80211/mesh.c
+@@ -161,6 +161,10 @@ void mesh_sta_cleanup(struct sta_info *s
+ del_timer_sync(&sta->plink_timer);
+ }
+
++ /* make sure no readers can access nexthop sta from here on */
++ mesh_path_flush_by_nexthop(sta);
++ synchronize_net();
++
+ if (changed)
+ ieee80211_mbss_info_change_notify(sdata, changed);
+ }
--- /dev/null
+From 62397da50bb20a6b812c949ef465d7e69fe54bb6 Mon Sep 17 00:00:00 2001
+From: Martin Willi <martin@strongswan.org>
+Date: Fri, 13 May 2016 12:41:48 +0200
+Subject: mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNAL
+
+From: Martin Willi <martin@strongswan.org>
+
+commit 62397da50bb20a6b812c949ef465d7e69fe54bb6 upstream.
+
+A wmediumd that does not send this attribute causes a NULL pointer
+dereference, as the attribute is accessed even if it does not exist.
+
+The attribute was required but never checked ever since userspace frame
+forwarding has been introduced. The issue gets more problematic once we
+allow wmediumd registration from user namespaces.
+
+Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx")
+Signed-off-by: Martin Willi <martin@strongswan.org>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/mac80211_hwsim.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/wireless/mac80211_hwsim.c
++++ b/drivers/net/wireless/mac80211_hwsim.c
+@@ -2251,6 +2251,7 @@ static int hwsim_tx_info_frame_received_
+ if (!info->attrs[HWSIM_ATTR_ADDR_TRANSMITTER] ||
+ !info->attrs[HWSIM_ATTR_FLAGS] ||
+ !info->attrs[HWSIM_ATTR_COOKIE] ||
++ !info->attrs[HWSIM_ATTR_SIGNAL] ||
+ !info->attrs[HWSIM_ATTR_TX_INFO])
+ goto out;
+
--- /dev/null
+From d20cb71dbf3487f24549ede1a8e2d67579b4632e Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@ZenIV.linux.org.uk>
+Date: Mon, 20 Jun 2016 13:14:36 -0400
+Subject: make nfs_atomic_open() call d_drop() on all ->open_context() errors.
+
+From: Al Viro <viro@ZenIV.linux.org.uk>
+
+commit d20cb71dbf3487f24549ede1a8e2d67579b4632e upstream.
+
+In "NFSv4: Move dentry instantiation into the NFSv4-specific atomic open code"
+unconditional d_drop() after the ->open_context() had been removed. It had
+been correct for success cases (there ->open_context() itself had been doing
+dcache manipulations), but not for error ones. Only one of those (ENOENT)
+got a compensatory d_drop() added in that commit, but in fact it should've
+been done for all errors. As it is, the case of O_CREAT non-exclusive open
+on a hashed negative dentry racing with e.g. symlink creation from another
+client ended up with ->open_context() getting an error and proceeding to
+call nfs_lookup(). On a hashed dentry, which would've instantly triggered
+BUG_ON() in d_materialise_unique() (or, these days, its equivalent in
+d_splice_alias()).
+
+Tested-by: Oleg Drokin <green@linuxhacker.ru>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/dir.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/nfs/dir.c
++++ b/fs/nfs/dir.c
+@@ -1459,9 +1459,9 @@ int nfs_atomic_open(struct inode *dir, s
+ err = PTR_ERR(inode);
+ trace_nfs_atomic_open_exit(dir, ctx, open_flags, err);
+ put_nfs_open_context(ctx);
++ d_drop(dentry);
+ switch (err) {
+ case -ENOENT:
+- d_drop(dentry);
+ d_add(dentry, NULL);
+ break;
+ case -EISDIR:
--- /dev/null
+From e547f2628327fec6afd2e03b46f113f614cca05b Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <trond.myklebust@primarydata.com>
+Date: Sat, 25 Jun 2016 19:19:28 -0400
+Subject: NFS: Fix another OPEN_DOWNGRADE bug
+
+From: Trond Myklebust <trond.myklebust@primarydata.com>
+
+commit e547f2628327fec6afd2e03b46f113f614cca05b upstream.
+
+Olga Kornievskaia reports that the following test fails to trigger
+an OPEN_DOWNGRADE on the wire, and only triggers the final CLOSE.
+
+ fd0 = open(foo, RDRW) -- should be open on the wire for "both"
+ fd1 = open(foo, RDONLY) -- should be open on the wire for "read"
+ close(fd0) -- should trigger an open_downgrade
+ read(fd1)
+ close(fd1)
+
+The issue is that we're missing a check for whether or not the current
+state transitioned from an O_RDWR state as opposed to having transitioned
+from a combination of O_RDONLY and O_WRONLY.
+
+Reported-by: Olga Kornievskaia <aglo@umich.edu>
+Fixes: cd9288ffaea4 ("NFSv4: Fix another bug in the close/open_downgrade code")
+Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/nfs4proc.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -2583,12 +2583,11 @@ static void nfs4_close_prepare(struct rp
+ call_close |= is_wronly;
+ else if (is_wronly)
+ calldata->arg.fmode |= FMODE_WRITE;
++ if (calldata->arg.fmode != (FMODE_READ|FMODE_WRITE))
++ call_close |= is_rdwr;
+ } else if (is_rdwr)
+ calldata->arg.fmode |= FMODE_READ|FMODE_WRITE;
+
+- if (calldata->arg.fmode == 0)
+- call_close |= is_rdwr;
+-
+ if (!nfs4_valid_open_stateid(state))
+ call_close = 0;
+ spin_unlock(&state->owner->so_lock);
--- /dev/null
+From 8445a87f7092bc8336ea1305be9306f26b846d93 Mon Sep 17 00:00:00 2001
+From: "Guilherme G. Piccoli" <gpiccoli@linux.vnet.ibm.com>
+Date: Mon, 11 Apr 2016 16:17:23 -0300
+Subject: powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism
+
+From: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
+
+commit 8445a87f7092bc8336ea1305be9306f26b846d93 upstream.
+
+Commit 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn")
+changed the pci_dn struct by removing its EEH-related members.
+As part of this clean-up, DDW mechanism was modified to read the device
+configuration address from eeh_dev struct.
+
+As a consequence, now if we disable EEH mechanism on kernel command-line
+for example, the DDW mechanism will fail, generating a kernel oops by
+dereferencing a NULL pointer (which turns to be the eeh_dev pointer).
+
+This patch just changes the configuration address calculation on DDW
+functions to a manual calculation based on pci_dn members instead of
+using eeh_dev-based address.
+
+No functional changes were made. This was tested on pSeries, both
+in PHyp and qemu guest.
+
+Fixes: 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn")
+Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/pseries/iommu.c | 24 ++++++++++++------------
+ 1 file changed, 12 insertions(+), 12 deletions(-)
+
+--- a/arch/powerpc/platforms/pseries/iommu.c
++++ b/arch/powerpc/platforms/pseries/iommu.c
+@@ -826,7 +826,8 @@ machine_arch_initcall(pseries, find_exis
+ static int query_ddw(struct pci_dev *dev, const u32 *ddw_avail,
+ struct ddw_query_response *query)
+ {
+- struct eeh_dev *edev;
++ struct device_node *dn;
++ struct pci_dn *pdn;
+ u32 cfg_addr;
+ u64 buid;
+ int ret;
+@@ -837,11 +838,10 @@ static int query_ddw(struct pci_dev *dev
+ * Retrieve them from the pci device, not the node with the
+ * dma-window property
+ */
+- edev = pci_dev_to_eeh_dev(dev);
+- cfg_addr = edev->config_addr;
+- if (edev->pe_config_addr)
+- cfg_addr = edev->pe_config_addr;
+- buid = edev->phb->buid;
++ dn = pci_device_to_OF_node(dev);
++ pdn = PCI_DN(dn);
++ buid = pdn->phb->buid;
++ cfg_addr = (pdn->busno << 8) | pdn->devfn;
+
+ ret = rtas_call(ddw_avail[0], 3, 5, (u32 *)query,
+ cfg_addr, BUID_HI(buid), BUID_LO(buid));
+@@ -855,7 +855,8 @@ static int create_ddw(struct pci_dev *de
+ struct ddw_create_response *create, int page_shift,
+ int window_shift)
+ {
+- struct eeh_dev *edev;
++ struct device_node *dn;
++ struct pci_dn *pdn;
+ u32 cfg_addr;
+ u64 buid;
+ int ret;
+@@ -866,11 +867,10 @@ static int create_ddw(struct pci_dev *de
+ * Retrieve them from the pci device, not the node with the
+ * dma-window property
+ */
+- edev = pci_dev_to_eeh_dev(dev);
+- cfg_addr = edev->config_addr;
+- if (edev->pe_config_addr)
+- cfg_addr = edev->pe_config_addr;
+- buid = edev->phb->buid;
++ dn = pci_device_to_OF_node(dev);
++ pdn = PCI_DN(dn);
++ buid = pdn->phb->buid;
++ cfg_addr = (pdn->busno << 8) | pdn->devfn;
+
+ do {
+ /* extra outputs are LIOBN and dma-addr (hi, lo) */
--- /dev/null
+From 8a934efe94347eee843aeea65bdec8077a79e259 Mon Sep 17 00:00:00 2001
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Date: Thu, 26 May 2016 09:56:07 +1000
+Subject: powerpc/pseries: Fix PCI config address for DDW
+
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+
+commit 8a934efe94347eee843aeea65bdec8077a79e259 upstream.
+
+In commit 8445a87f7092 "powerpc/iommu: Remove the dependency on EEH
+struct in DDW mechanism", the PE address was replaced with the PCI
+config address in order to remove dependency on EEH. According to PAPR
+spec, firmware (pHyp or QEMU) should accept "xxBBSSxx" format PCI config
+address, not "xxxxBBSS" provided by the patch. Note that "BB" is PCI bus
+number and "SS" is the combination of slot and function number.
+
+This fixes the PCI address passed to DDW RTAS calls.
+
+Fixes: 8445a87f7092 ("powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism")
+Reported-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
+Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Tested-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/pseries/iommu.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/platforms/pseries/iommu.c
++++ b/arch/powerpc/platforms/pseries/iommu.c
+@@ -841,7 +841,7 @@ static int query_ddw(struct pci_dev *dev
+ dn = pci_device_to_OF_node(dev);
+ pdn = PCI_DN(dn);
+ buid = pdn->phb->buid;
+- cfg_addr = (pdn->busno << 8) | pdn->devfn;
++ cfg_addr = ((pdn->busno << 16) | (pdn->devfn << 8));
+
+ ret = rtas_call(ddw_avail[0], 3, 5, (u32 *)query,
+ cfg_addr, BUID_HI(buid), BUID_LO(buid));
+@@ -870,7 +870,7 @@ static int create_ddw(struct pci_dev *de
+ dn = pci_device_to_OF_node(dev);
+ pdn = PCI_DN(dn);
+ buid = pdn->phb->buid;
+- cfg_addr = (pdn->busno << 8) | pdn->devfn;
++ cfg_addr = ((pdn->busno << 16) | (pdn->devfn << 8));
+
+ do {
+ /* extra outputs are LIOBN and dma-addr (hi, lo) */
--- /dev/null
+From 8e96a87c5431c256feb65bcfc5aec92d9f7839b6 Mon Sep 17 00:00:00 2001
+From: Cyril Bur <cyrilbur@gmail.com>
+Date: Fri, 17 Jun 2016 14:58:34 +1000
+Subject: powerpc/tm: Always reclaim in start_thread() for exec() class syscalls
+
+From: Cyril Bur <cyrilbur@gmail.com>
+
+commit 8e96a87c5431c256feb65bcfc5aec92d9f7839b6 upstream.
+
+Userspace can quite legitimately perform an exec() syscall with a
+suspended transaction. exec() does not return to the old process, rather
+it load a new one and starts that, the expectation therefore is that the
+new process starts not in a transaction. Currently exec() is not treated
+any differently to any other syscall which creates problems.
+
+Firstly it could allow a new process to start with a suspended
+transaction for a binary that no longer exists. This means that the
+checkpointed state won't be valid and if the suspended transaction were
+ever to be resumed and subsequently aborted (a possibility which is
+exceedingly likely as exec()ing will likely doom the transaction) the
+new process will jump to invalid state.
+
+Secondly the incorrect attempt to keep the transactional state while
+still zeroing state for the new process creates at least two TM Bad
+Things. The first triggers on the rfid to return to userspace as
+start_thread() has given the new process a 'clean' MSR but the suspend
+will still be set in the hardware MSR. The second TM Bad Thing triggers
+in __switch_to() as the processor is still transactionally suspended but
+__switch_to() wants to zero the TM sprs for the new process.
+
+This is an example of the outcome of calling exec() with a suspended
+transaction. Note the first 700 is likely the first TM bad thing
+decsribed earlier only the kernel can't report it as we've loaded
+userspace registers. c000000000009980 is the rfid in
+fast_exception_return()
+
+ Bad kernel stack pointer 3fffcfa1a370 at c000000000009980
+ Oops: Bad kernel stack pointer, sig: 6 [#1]
+ CPU: 0 PID: 2006 Comm: tm-execed Not tainted
+ NIP: c000000000009980 LR: 0000000000000000 CTR: 0000000000000000
+ REGS: c00000003ffefd40 TRAP: 0700 Not tainted
+ MSR: 8000000300201031 <SF,ME,IR,DR,LE,TM[SE]> CR: 00000000 XER: 00000000
+ CFAR: c0000000000098b4 SOFTE: 0
+ PACATMSCRATCH: b00000010000d033
+ GPR00: 0000000000000000 00003fffcfa1a370 0000000000000000 0000000000000000
+ GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+ GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+ GPR12: 00003fff966611c0 0000000000000000 0000000000000000 0000000000000000
+ NIP [c000000000009980] fast_exception_return+0xb0/0xb8
+ LR [0000000000000000] (null)
+ Call Trace:
+ Instruction dump:
+ f84d0278 e9a100d8 7c7b03a6 e84101a0 7c4ff120 e8410170 7c5a03a6 e8010070
+ e8410080 e8610088 e8810090 e8210078 <4c000024> 48000000 e8610178 88ed023b
+
+ Kernel BUG at c000000000043e80 [verbose debug info unavailable]
+ Unexpected TM Bad Thing exception at c000000000043e80 (msr 0x201033)
+ Oops: Unrecoverable exception, sig: 6 [#2]
+ CPU: 0 PID: 2006 Comm: tm-execed Tainted: G D
+ task: c0000000fbea6d80 ti: c00000003ffec000 task.ti: c0000000fb7ec000
+ NIP: c000000000043e80 LR: c000000000015a24 CTR: 0000000000000000
+ REGS: c00000003ffef7e0 TRAP: 0700 Tainted: G D
+ MSR: 8000000300201033 <SF,ME,IR,DR,RI,LE,TM[SE]> CR: 28002828 XER: 00000000
+ CFAR: c000000000015a20 SOFTE: 0
+ PACATMSCRATCH: b00000010000d033
+ GPR00: 0000000000000000 c00000003ffefa60 c000000000db5500 c0000000fbead000
+ GPR04: 8000000300001033 2222222222222222 2222222222222222 00000000ff160000
+ GPR08: 0000000000000000 800000010000d033 c0000000fb7e3ea0 c00000000fe00004
+ GPR12: 0000000000002200 c00000000fe00000 0000000000000000 0000000000000000
+ GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+ GPR20: 0000000000000000 0000000000000000 c0000000fbea7410 00000000ff160000
+ GPR24: c0000000ffe1f600 c0000000fbea8700 c0000000fbea8700 c0000000fbead000
+ GPR28: c000000000e20198 c0000000fbea6d80 c0000000fbeab680 c0000000fbea6d80
+ NIP [c000000000043e80] tm_restore_sprs+0xc/0x1c
+ LR [c000000000015a24] __switch_to+0x1f4/0x420
+ Call Trace:
+ Instruction dump:
+ 7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0 7c0122a6 f80304b8
+ 4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6> e80304b8 7c0123a6 4e800020
+
+This fixes CVE-2016-5828.
+
+Fixes: bc2a9408fa65 ("powerpc: Hook in new transactional memory code")
+Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/process.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/arch/powerpc/kernel/process.c
++++ b/arch/powerpc/kernel/process.c
+@@ -1237,6 +1237,16 @@ void start_thread(struct pt_regs *regs,
+ current->thread.regs = regs - 1;
+ }
+
++#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
++ /*
++ * Clear any transactional state, we're exec()ing. The cause is
++ * not important as there will never be a recheckpoint so it's not
++ * user visible.
++ */
++ if (MSR_TM_SUSPENDED(mfmsr()))
++ tm_reclaim_current(0);
++#endif
++
+ memset(regs->gpr, 0, sizeof(regs->gpr));
+ regs->ctr = 0;
+ regs->link = 0;
usb-quirks-add-no-lpm-quirk-for-acer-c120-led-projector.patch
usb-musb-stop-bulk-endpoint-while-queue-is-rotated.patch
usb-musb-ensure-rx-reinit-occurs-for-shared_fifo-endpoints.patch
+mac80211-mesh-flush-mesh-paths-unconditionally.patch
+mac80211_hwsim-add-missing-check-for-hwsim_attr_signal.patch
+mac80211-fix-mesh-estab_plinks-counting-in-sta-removal-case.patch
+ib-mlx4-properly-initialize-grh-tclass-and-flowlabel-in-ahs.patch
+powerpc-iommu-remove-the-dependency-on-eeh-struct-in-ddw-mechanism.patch
+powerpc-pseries-fix-pci-config-address-for-ddw.patch
+powerpc-tm-always-reclaim-in-start_thread-for-exec-class-syscalls.patch
+usb-ehci-declare-hostpc-register-as-zero-length-array.patch
+locking-ww_mutex-report-recursive-ww_mutex-locking-early.patch
+x86-build-copy-ldlinux.c32-to-image.iso.patch
+kprobes-x86-clear-tf-bit-in-fault-on-single-stepping.patch
+x86-amd_nb-fix-boot-crash-on-non-amd-systems.patch
+make-nfs_atomic_open-call-d_drop-on-all-open_context-errors.patch
+nfs-fix-another-open_downgrade-bug.patch
--- /dev/null
+From 7e8b3dfef16375dbfeb1f36a83eb9f27117c51fd Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Thu, 23 Jun 2016 14:54:37 -0400
+Subject: USB: EHCI: declare hostpc register as zero-length array
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 7e8b3dfef16375dbfeb1f36a83eb9f27117c51fd upstream.
+
+The HOSTPC extension registers found in some EHCI implementations form
+a variable-length array, with one element for each port. Therefore
+the hostpc field in struct ehci_regs should be declared as a
+zero-length array, not a single-element array.
+
+This fixes a problem reported by UBSAN.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
+Tested-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/usb/ehci_def.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/include/linux/usb/ehci_def.h
++++ b/include/linux/usb/ehci_def.h
+@@ -178,11 +178,11 @@ struct ehci_regs {
+ * PORTSCx
+ */
+ /* HOSTPC: offset 0x84 */
+- u32 hostpc[1]; /* HOSTPC extension */
++ u32 hostpc[0]; /* HOSTPC extension */
+ #define HOSTPC_PHCD (1<<22) /* Phy clock disable */
+ #define HOSTPC_PSPD (3<<25) /* Port speed detection */
+
+- u32 reserved5[16];
++ u32 reserved5[17];
+
+ /* USBMODE_EX: offset 0xc8 */
+ u32 usbmode_ex; /* USB Device mode extension */
--- /dev/null
+From 1ead852dd88779eda12cb09cc894a03d9abfe1ec Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <bp@suse.de>
+Date: Thu, 16 Jun 2016 19:13:49 +0200
+Subject: x86/amd_nb: Fix boot crash on non-AMD systems
+
+From: Borislav Petkov <bp@suse.de>
+
+commit 1ead852dd88779eda12cb09cc894a03d9abfe1ec upstream.
+
+Fix boot crash that triggers if this driver is built into a kernel and
+run on non-AMD systems.
+
+AMD northbridges users call amd_cache_northbridges() and it returns
+a negative value to signal that we weren't able to cache/detect any
+northbridges on the system.
+
+At least, it should do so as all its callers expect it to do so. But it
+does return a negative value only when kmalloc() fails.
+
+Fix it to return -ENODEV if there are no NBs cached as otherwise, amd_nb
+users like amd64_edac, for example, which relies on it to know whether
+it should load or not, gets loaded on systems like Intel Xeons where it
+shouldn't.
+
+Reported-and-tested-by: Tony Battersby <tonyb@cybernetics.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lkml.kernel.org/r/1466097230-5333-2-git-send-email-bp@alien8.de
+Link: https://lkml.kernel.org/r/5761BEB0.9000807@cybernetics.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/amd_nb.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/amd_nb.c
++++ b/arch/x86/kernel/amd_nb.c
+@@ -67,8 +67,8 @@ int amd_cache_northbridges(void)
+ while ((misc = next_northbridge(misc, amd_nb_misc_ids)) != NULL)
+ i++;
+
+- if (i == 0)
+- return 0;
++ if (!i)
++ return -ENODEV;
+
+ nb = kzalloc(i * sizeof(struct amd_northbridge), GFP_KERNEL);
+ if (!nb)
--- /dev/null
+From 9c77679cadb118c0aa99e6f88533d91765a131ba Mon Sep 17 00:00:00 2001
+From: "H. Peter Anvin" <hpa@zytor.com>
+Date: Tue, 5 Apr 2016 17:01:33 -0700
+Subject: x86, build: copy ldlinux.c32 to image.iso
+
+From: H. Peter Anvin <hpa@zytor.com>
+
+commit 9c77679cadb118c0aa99e6f88533d91765a131ba upstream.
+
+For newer versions of Syslinux, we need ldlinux.c32 in addition to
+isolinux.bin to reside on the boot disk, so if the latter is found,
+copy it, too, to the isoimage tree.
+
+Signed-off-by: H. Peter Anvin <hpa@zytor.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/boot/Makefile | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/x86/boot/Makefile
++++ b/arch/x86/boot/Makefile
+@@ -156,6 +156,9 @@ isoimage: $(obj)/bzImage
+ for i in lib lib64 share end ; do \
+ if [ -f /usr/$$i/syslinux/isolinux.bin ] ; then \
+ cp /usr/$$i/syslinux/isolinux.bin $(obj)/isoimage ; \
++ if [ -f /usr/$$i/syslinux/ldlinux.c32 ]; then \
++ cp /usr/$$i/syslinux/ldlinux.c32 $(obj)/isoimage ; \
++ fi ; \
+ break ; \
+ fi ; \
+ if [ $$i = end ] ; then exit 1 ; fi ; \
projects / thirdparty / kernel / stable-queue.git / commitdiff
