aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-01-28Merge branch 'lan78xx-fixes'David S. Miller1-44/+88
Woojung Huh says: ==================== lan78xx: update and fixes lan78xx: change to use updated phy-ignore-interrupts lan78xx: Add to handle mux control per chip id lan78xx: throttle TX path at slower than SuperSpeed USB ==================== Signed-off-by: David S. Miller <[email protected]>
2016-01-28lan78xx: throttle TX path at slower than SuperSpeed USB[email protected]1-1/+3
Throttle TX path only at slower than SuperSpeed USB. SuperSpeed USB has enough bandwidth to maintain GigE. Signed-off-by: Woojung Huh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28lan78xx: Add to handle mux control per chip id[email protected]1-27/+71
Depends on chip, some EEPROM pins are muxed with LED function. Disable & restore LED function to access EEPROM. Signed-off-by: Woojung Huh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28lan78xx: change to use updated phy-ignore-interrupts[email protected]1-16/+14
Update lan78xx to use patch of commit 4f2aaf7dd95b ("Merge branch 'fix-phy-ignore-interrupts'"). Signed-off-by: Woojung Huh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28tcp: beware of alignments in tcp_get_info()Eric Dumazet1-4/+8
With some combinations of user provided flags in netlink command, it is possible to call tcp_get_info() with a buffer that is not 8-bytes aligned. It does matter on some arches, so we need to use put_unaligned() to store the u64 fields. Current iproute2 package does not trigger this particular issue. Fixes: 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info") Fixes: 977cb0ecf82e ("tcp: add pacing_rate information into tcp_info") Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-29ALSA: hda - Add new GPU codec ID 0x10de0083 to snd-hdaAaron Plattner1-0/+1
Vendor ID 0x10de0083 is used by a yet-to-be-named GPU chip. This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is appropriate here. Signed-off-by: Aaron Plattner <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-01-28Revert "Staging: panel: usleep_range is preferred over udelay"Sudip Mukherjee1-19/+15
This reverts commit ebd43516d3879f882a403836bba8bc5791f26a28. We should not be sleeping inside spin_lock. Fixes: ebd43516d387 ("Staging: panel: usleep_range is preferred over udelay") Cc: Sirnam Swetha <[email protected]> Signed-off-by: Sudip Mukherjee <[email protected]> Reported-by: Huang, Ying <[email protected]> Tested-by: Huang, Ying <[email protected]> Cc: stable <[email protected]> # 4.4 Signed-off-by: Greg Kroah-Hartman <[email protected]>
2016-01-28Merge tag 'trace-v4.5-rc1' of ↵Linus Torvalds3-3/+2
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull minor tracing fixes from Steven Rostedt: "This includes three minor fixes, mostly due to cut-and-paste issues. The first is a cut and paste issue that changed the amount of stack to skip when tracing a stack dump from 0 to 6, which basically made the stack disappear for small stack traces. The second fix is just removing an unused field in a struct that is no longer used, and currently just wastes space. The third is another cut-and-paste fix that had a tracepoint recording the wrong field (it was recording the previous field a second time)" * tag 'trace-v4.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing/dma-buf/fence: Fix timeline str value on fence_annotate_wait_on ftrace: Remove unused nr_trampolines var tracing: Fix stacktrace skip depth in trace_buffer_unlock_commit_regs()
2016-01-28switchdev: Require RTNL mutex to be held when sending FDB notificationsIdo Schimmel5-15/+14
When switchdev drivers process FDB notifications from the underlying device they resolve the netdev to which the entry points to and notify the bridge using the switchdev notifier. However, since the RTNL mutex is not held there is nothing preventing the netdev from disappearing in the middle, which will cause br_switchdev_event() to dereference a non-existing netdev. Make switchdev drivers hold the lock at the beginning of the notification processing session and release it once it ends, after notifying the bridge. Also, remove switchdev_mutex and fdb_lock, as they are no longer needed when RTNL mutex is held. Fixes: 03bf0c281234 ("switchdev: introduce switchdev notifier") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28xen-netfront: request Tx response events more oftenMalcolm Crossley1-12/+3
Trying to batch Tx response events results in poor performance because this delays freeing the transmitted skbs. Instead use the standard RING_FINAL_CHECK_FOR_RESPONSES() macro to be notified once the next Tx response is placed on the ring. Signed-off-by: Malcolm Crossley <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28net: mv643xx_eth: fix packet corruption with TSO and tiny unaligned packets.Nicolas Schichan1-2/+2
The code in txq_put_data() would use txq->tx_curr_desc to index the tso_hdrs/tso_hdrs_dma buffers, for less than 8 bytes unaligned fragments, which is already moved to the next descriptor at the beginning of the function. If that fragment was the last of the the skb, the next skb would use that same space to place the ip headers, overwritting that small fragment data. Fixes: 91986fd3d335 (net: mv643xx_eth: Ensure proper data alignment in TSO TX path) Signed-off-by: Nicolas Schichan <[email protected]> Reviewed-by: Philipp Kirchhofer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28of: of_mdio: Ensure mdio device is a PHYAndrew Lunn1-1/+9
of_phy_find_device() is used to find the phy device associated with a device node. It is expected the node is for a PHY device, but in fact it could of been probed as a generic MDIO device. Ensure the device is a PHY before returning it. Fixes: a9049e0c513c ("mdio: Add support for mdio drivers.") Reported-by: Aaro Koskinen <[email protected]> Reported-by: Olof Johansson <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Tested-by: Aaro Koskinen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28Merge tag 'mac80211-for-davem-2016-01-26' of ↵David S. Miller13-64/+85
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== Here's a first set of fixes for the 4.5-rc cycle: * make regulatory messages much less verbose by default * various remain-on-channel fixes * scheduled scanning fixes with hardware restart * a PS-Poll handling fix; was broken just recently * bugfix to avoid buffering non-bufferable MMPDUs * world regulatory domain data fix * a fix for scanning causing other work to get stuck * hwsim: revert an older problematic patch that caused some userspace tools to have issues - not that big a deal as it's a debug only driver though ==================== Signed-off-by: David S. Miller <[email protected]>
2016-01-29Merge branch 'drm-rockchip-next-fixes-2016-01-22' of ↵Dave Airlie9-30/+73
https://github.com/markyzq/kernel-drm-rockchip into drm-fixes Here are some fixes for drm/rockchip, these fixes base on drm-next. These fixes works on my popmetal(rk3288) board. About patch: drm/atomic-helper: Export framebuffer_changed() Daniel Vetter ack for merging it through rockchip git trees, so framebuffer_changed() can be reused by drm/rockchip. All others looks good, so I'd like you can land them. * 'drm-rockchip-next-fixes-2016-01-22' of https://github.com/markyzq/kernel-drm-rockchip: drm/rockchip: respect CONFIG_DRM_FBDEV_EMULATION drm/rockchip: fix wrong pitch/size using on gem drm/rockchip: explain why we can't wait_for_vblanks drm/rockchip: don't wait for vblank if fb hasn't changed drm/atomic-helper: Export framebuffer_changed() drm/rockchip/dsi: fix handling mipi_dsi_pixel_format_to_bpp result drm/rockchip: vop: fix mask when updating interrupts drm/rockchip: cleanup unnecessary export symbol drm/rockchip: Don't build rockchip_drm_vop as modules
2016-01-29drm/vmwgfx: respect 'nomodeset'Rob Clark1-0/+7
Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]>. Cc: [email protected] Signed-off-by: Dave Airlie <[email protected]>
2016-01-28net: Fix dependencies for !HAS_IOMEM archsRichard Weinberger2-0/+2
Not every arch has io memory. So, unbreak the build by fixing the dependencies. Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28tcp: fix tcp_mark_head_lost to check skb len before fragmentingNeal Cardwell1-5/+5
This commit fixes a corner case in tcp_mark_head_lost() which was causing the WARN_ON(len > skb->len) in tcp_fragment() to fire. tcp_mark_head_lost() was assuming that if a packet has tcp_skb_pcount(skb) of N, then it's safe to fragment off a prefix of M*mss bytes, for any M < N. But with the tricky way TCP pcounts are maintained, this is not always true. For example, suppose the sender sends 4 1-byte packets and have the last 3 packet sacked. It will merge the last 3 packets in the write queue into an skb with pcount = 3 and len = 3 bytes. If another recovery happens after a sack reneging event, tcp_mark_head_lost() may attempt to split the skb assuming it has more than 2*MSS bytes. This sounds very counterintuitive, but as the commit description for the related commit c0638c247f55 ("tcp: don't fragment SACKed skbs in tcp_mark_head_lost()") notes, this is because tcp_shifted_skb() coalesces adjacent regions of SACKed skbs, and when doing this it preserves the sum of their packet counts in order to reflect the real-world dynamics on the wire. The c0638c247f55 commit tried to avoid problems by not fragmenting SACKed skbs, since SACKed skbs are where the non-proportionality between pcount and skb->len/mss is known to be possible. However, that commit did not handle the case where during a reneging event one of these weird SACKed skbs becomes an un-SACKed skb, which tcp_mark_head_lost() can then try to fragment. The fix is to simply mark the entire skb lost when this happens. This makes the recovery slightly more aggressive in such corner cases before we detect reordering. But once we detect reordering this code path is by-passed because FACK is disabled. Signed-off-by: Neal Cardwell <[email protected]> Signed-off-by: Yuchung Cheng <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-29Merge tag 'drm-vc4-fixes-2015-01-19' of http://github.com/anholt/linux into ↵Dave Airlie1-10/+7
drm-fixes This pull request just includes the !CONFIG_PM_SLEEP build fix for vc4. * tag 'drm-vc4-fixes-2015-01-19' of http://github.com/anholt/linux: drm/vc4: Remove broken attempt at GPU reset using genpd.
2016-01-29Merge branch 'drm-etnaviv-fixes' of git://git.pengutronix.de/git/lst/linux ↵Dave Airlie11-87/+255
into drm-fixes A bunch of etnaviv fixes for 4.5-rc. Most of them are fixing things in code paths that will only be hit if something goes wrong, which have been unearthed by more extensive testing. The only thing that doesn't really qualify as fixes is an UAPI extension that userspace wants to rely on being present, so I want to fast-track this into 4.5 before etnaviv ends up in a released kernel. * 'drm-etnaviv-fixes' of git://git.pengutronix.de/git/lst/linux: drm/etnaviv: call correct function when trying to vmap a DMABUF drm/etnaviv: rename etnaviv_gem_vaddr to etnaviv_gem_vmap drm/etnaviv: fix get pages error path in etnaviv_gem_vaddr drm/etnaviv: fix memory leak in IOMMU init path drm/etnaviv: add further minor features and varyings count drm/etnaviv: add helper for comparing model/revision IDs drm/etnaviv: add helper to extract bitfields drm/etnaviv: use defined constants for the chip model drm/etnaviv: update common and state_hi xml.h files drm/etnaviv: ignore VG GPUs with FE2.0 drm/etnaviv: fix failure path if model is zero drm/etnaviv: hold object lock while getting pages for coredump drm/etnaviv: remove owner assignment from platform_driver
2016-01-28inet: frag: Always orphan skbs inside ip_defrag()Joe Stringer2-2/+1
Later parts of the stack (including fragmentation) expect that there is never a socket attached to frag in a frag_list, however this invariant was not enforced on all defrag paths. This could lead to the BUG_ON(skb->sk) during ip_do_fragment(), as per the call stack at the end of this commit message. While the call could be added to openvswitch to fix this particular error, the head and tail of the frags list are already orphaned indirectly inside ip_defrag(), so it seems like the remaining fragments should all be orphaned in all circumstances. kernel BUG at net/ipv4/ip_output.c:586! [...] Call Trace: <IRQ> [<ffffffffa0205270>] ? do_output.isra.29+0x1b0/0x1b0 [openvswitch] [<ffffffffa02167a7>] ovs_fragment+0xcc/0x214 [openvswitch] [<ffffffff81667830>] ? dst_discard_out+0x20/0x20 [<ffffffff81667810>] ? dst_ifdown+0x80/0x80 [<ffffffffa0212072>] ? find_bucket.isra.2+0x62/0x70 [openvswitch] [<ffffffff810e0ba5>] ? mod_timer_pending+0x65/0x210 [<ffffffff810b732b>] ? __lock_acquire+0x3db/0x1b90 [<ffffffffa03205a2>] ? nf_conntrack_in+0x252/0x500 [nf_conntrack] [<ffffffff810b63c4>] ? __lock_is_held+0x54/0x70 [<ffffffffa02051a3>] do_output.isra.29+0xe3/0x1b0 [openvswitch] [<ffffffffa0206411>] do_execute_actions+0xe11/0x11f0 [openvswitch] [<ffffffff810b63c4>] ? __lock_is_held+0x54/0x70 [<ffffffffa0206822>] ovs_execute_actions+0x32/0xd0 [openvswitch] [<ffffffffa020b505>] ovs_dp_process_packet+0x85/0x140 [openvswitch] [<ffffffff810b63c4>] ? __lock_is_held+0x54/0x70 [<ffffffffa02068a2>] ovs_execute_actions+0xb2/0xd0 [openvswitch] [<ffffffffa020b505>] ovs_dp_process_packet+0x85/0x140 [openvswitch] [<ffffffffa0215019>] ? ovs_ct_get_labels+0x49/0x80 [openvswitch] [<ffffffffa0213a1d>] ovs_vport_receive+0x5d/0xa0 [openvswitch] [<ffffffff810b732b>] ? __lock_acquire+0x3db/0x1b90 [<ffffffff810b732b>] ? __lock_acquire+0x3db/0x1b90 [<ffffffff810b732b>] ? __lock_acquire+0x3db/0x1b90 [<ffffffffa0214895>] ? internal_dev_xmit+0x5/0x140 [openvswitch] [<ffffffffa02148fc>] internal_dev_xmit+0x6c/0x140 [openvswitch] [<ffffffffa0214895>] ? internal_dev_xmit+0x5/0x140 [openvswitch] [<ffffffff81660299>] dev_hard_start_xmit+0x2b9/0x5e0 [<ffffffff8165fc21>] ? netif_skb_features+0xd1/0x1f0 [<ffffffff81660f20>] __dev_queue_xmit+0x800/0x930 [<ffffffff81660770>] ? __dev_queue_xmit+0x50/0x930 [<ffffffff810b53f1>] ? mark_held_locks+0x71/0x90 [<ffffffff81669876>] ? neigh_resolve_output+0x106/0x220 [<ffffffff81661060>] dev_queue_xmit+0x10/0x20 [<ffffffff816698e8>] neigh_resolve_output+0x178/0x220 [<ffffffff816a8e6f>] ? ip_finish_output2+0x1ff/0x590 [<ffffffff816a8e6f>] ip_finish_output2+0x1ff/0x590 [<ffffffff816a8cee>] ? ip_finish_output2+0x7e/0x590 [<ffffffff816a9a31>] ip_do_fragment+0x831/0x8a0 [<ffffffff816a8c70>] ? ip_copy_metadata+0x1b0/0x1b0 [<ffffffff816a9ae3>] ip_fragment.constprop.49+0x43/0x80 [<ffffffff816a9c9c>] ip_finish_output+0x17c/0x340 [<ffffffff8169a6f4>] ? nf_hook_slow+0xe4/0x190 [<ffffffff816ab4c0>] ip_output+0x70/0x110 [<ffffffff816a9b20>] ? ip_fragment.constprop.49+0x80/0x80 [<ffffffff816aa9f9>] ip_local_out+0x39/0x70 [<ffffffff816abf89>] ip_send_skb+0x19/0x40 [<ffffffff816abfe3>] ip_push_pending_frames+0x33/0x40 [<ffffffff816df21a>] icmp_push_reply+0xea/0x120 [<ffffffff816df93d>] icmp_reply.constprop.23+0x1ed/0x230 [<ffffffff816df9ce>] icmp_echo.part.21+0x4e/0x50 [<ffffffff810b63c4>] ? __lock_is_held+0x54/0x70 [<ffffffff810d5f9e>] ? rcu_read_lock_held+0x5e/0x70 [<ffffffff816dfa06>] icmp_echo+0x36/0x70 [<ffffffff816e0d11>] icmp_rcv+0x271/0x450 [<ffffffff816a4ca7>] ip_local_deliver_finish+0x127/0x3a0 [<ffffffff816a4bc1>] ? ip_local_deliver_finish+0x41/0x3a0 [<ffffffff816a5160>] ip_local_deliver+0x60/0xd0 [<ffffffff816a4b80>] ? ip_rcv_finish+0x560/0x560 [<ffffffff816a46fd>] ip_rcv_finish+0xdd/0x560 [<ffffffff816a5453>] ip_rcv+0x283/0x3e0 [<ffffffff810b6302>] ? match_held_lock+0x192/0x200 [<ffffffff816a4620>] ? inet_del_offload+0x40/0x40 [<ffffffff8165d062>] __netif_receive_skb_core+0x392/0xae0 [<ffffffff8165e68e>] ? process_backlog+0x8e/0x230 [<ffffffff810b53f1>] ? mark_held_locks+0x71/0x90 [<ffffffff8165d7c8>] __netif_receive_skb+0x18/0x60 [<ffffffff8165e678>] process_backlog+0x78/0x230 [<ffffffff8165e6dd>] ? process_backlog+0xdd/0x230 [<ffffffff8165e355>] net_rx_action+0x155/0x400 [<ffffffff8106b48c>] __do_softirq+0xcc/0x420 [<ffffffff816a8e87>] ? ip_finish_output2+0x217/0x590 [<ffffffff8178e78c>] do_softirq_own_stack+0x1c/0x30 <EOI> [<ffffffff8106b88e>] do_softirq+0x4e/0x60 [<ffffffff8106b948>] __local_bh_enable_ip+0xa8/0xb0 [<ffffffff816a8eb0>] ip_finish_output2+0x240/0x590 [<ffffffff816a9a31>] ? ip_do_fragment+0x831/0x8a0 [<ffffffff816a9a31>] ip_do_fragment+0x831/0x8a0 [<ffffffff816a8c70>] ? ip_copy_metadata+0x1b0/0x1b0 [<ffffffff816a9ae3>] ip_fragment.constprop.49+0x43/0x80 [<ffffffff816a9c9c>] ip_finish_output+0x17c/0x340 [<ffffffff8169a6f4>] ? nf_hook_slow+0xe4/0x190 [<ffffffff816ab4c0>] ip_output+0x70/0x110 [<ffffffff816a9b20>] ? ip_fragment.constprop.49+0x80/0x80 [<ffffffff816aa9f9>] ip_local_out+0x39/0x70 [<ffffffff816abf89>] ip_send_skb+0x19/0x40 [<ffffffff816abfe3>] ip_push_pending_frames+0x33/0x40 [<ffffffff816d55d3>] raw_sendmsg+0x7d3/0xc30 [<ffffffff810b732b>] ? __lock_acquire+0x3db/0x1b90 [<ffffffff816e7557>] ? inet_sendmsg+0xc7/0x1d0 [<ffffffff810b63c4>] ? __lock_is_held+0x54/0x70 [<ffffffff816e759a>] inet_sendmsg+0x10a/0x1d0 [<ffffffff816e7495>] ? inet_sendmsg+0x5/0x1d0 [<ffffffff8163e398>] sock_sendmsg+0x38/0x50 [<ffffffff8163ec5f>] ___sys_sendmsg+0x25f/0x270 [<ffffffff811aadad>] ? handle_mm_fault+0x8dd/0x1320 [<ffffffff8178c147>] ? _raw_spin_unlock+0x27/0x40 [<ffffffff810529b2>] ? __do_page_fault+0x1e2/0x460 [<ffffffff81204886>] ? __fget_light+0x66/0x90 [<ffffffff8163f8e2>] __sys_sendmsg+0x42/0x80 [<ffffffff8163f932>] SyS_sendmsg+0x12/0x20 [<ffffffff8178cb17>] entry_SYSCALL_64_fastpath+0x12/0x6f Code: 00 00 44 89 e0 e9 7c fb ff ff 4c 89 ff e8 e7 e7 ff ff 41 8b 9d 80 00 00 00 2b 5d d4 89 d8 c1 f8 03 0f b7 c0 e9 33 ff ff f 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 RIP [<ffffffff816a9a92>] ip_do_fragment+0x892/0x8a0 RSP <ffff88006d603170> Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action") Signed-off-by: Joe Stringer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-29Merge branch 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie21-101/+192
into drm-fixes Misc radeon and amdgpu fixes: - SMU firmware loading fix for Stoney - DP audio fixes for DCE4.1 - Don't expose fbdev device if no connectors - fix page table LRU list update handling * 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux: drm/amdgpu: only move pt bos in LRU list on success drm/radeon: fix DP audio support for APU with DCE4.1 display engine drm/radeon: Add a common function for DFS handling drm/radeon: cleaned up VCO output settings for DP audio drm/amd/powerplay: Update SMU firmware loading for Stoney drm/amdgpu: don't init fbdev if we don't have any connectors drm/radeon: only init fbdev if we have connectors drm/radeon: Ensure radeon bo is unreserved in radeon_gem_va_ioctl drm/amdgpu: fix next_rptr handling for debugfs drm/radeon: properly byte swap vce firmware setup drm/amdgpu: add a message to indicate when powerplay is enabled (v2) drm/amdgpu: fix amdgpu_bo_pin_restricted VRAM placing v2 drm/amd/amdgpu: Improve amdgpu_dpm* macros to avoid unexpected result (v2) drm/amdgpu: Allow the driver to load if amdgpu.powerplay=1 on asics without powerplay support drm/amdgpu: Use drm_calloc_large for VM page_tables array drm/amdgpu: Add some tweaks to gfx 8 soft reset drm/amdgpu: fix tonga smu resume
2016-01-28Merge branch 'sctp-transport-races'David S. Miller5-30/+24
Xin Long says: ==================== fix the transport dead race check by using atomic_add_unless on refcnt sctp: fix the transport dead race check by using atomic_add_unless on refcnt sctp: hold transport before we access t->asoc in sctp proc sctp: remove the dead field of sctp_transport ==================== Signed-off-by: David S. Miller <[email protected]>
2016-01-28sctp: remove the dead field of sctp_transportXin Long4-21/+2
After we use refcnt to check if transport is alive, the dead can be removed from sctp_transport. The traversal of transport_addr_list in procfs dump is using list_for_each_entry_rcu, no need to check if it has been freed. sctp_generate_t3_rtx_event and sctp_generate_heartbeat_event is protected by sock lock, it's not necessary to check dead, either. also, the timers are cancelled when sctp_transport_free() is called, that it doesn't wait for refcnt to reach 0 to cancel them. Signed-off-by: Xin Long <[email protected]> Signed-off-by: Marcelo Ricardo Leitner <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28sctp: hold transport before we access t->asoc in sctp procXin Long1-0/+8
Previously, before rhashtable, /proc assoc listing was done by read-locking the entire hash entry and dumping all assocs at once, so we were sure that the assoc wasn't freed because it wouldn't be possible to remove it from the hash meanwhile. Now we use rhashtable to list transports, and dump entries one by one. That is, now we have to check if the assoc is still a good one, as the transport we got may be being freed. Signed-off-by: Xin Long <[email protected]> Reviewed-by: Marcelo Ricardo Leitner <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28sctp: fix the transport dead race check by using atomic_add_unless on refcntXin Long3-9/+14
Now when __sctp_lookup_association is running in BH, it will try to check if t->dead is set, but meanwhile other CPUs may be freeing this transport and this assoc and if it happens that __sctp_lookup_association checked t->dead a bit too early, it may think that the association is still good while it was already freed. So we fix this race by using atomic_add_unless in sctp_transport_hold. After we get one transport from hashtable, we will hold it only when this transport's refcnt is not 0, so that we can make sure t->asoc cannot be freed before we hold the asoc again. Note that sctp association is not freed using RCU so we can't use atomic_add_unless() with it as it may just be too late for that either. Fixes: 4f0087812648 ("sctp: apply rhashtable api to send/recv path") Reported-by: Vlad Yasevich <[email protected]> Signed-off-by: Xin Long <[email protected]> Signed-off-by: Marcelo Ricardo Leitner <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28Merge branch 'mlxsw-fixes'David S. Miller4-40/+293
Jiri Pirko says: ==================== mlxsw: driver fixes Couple of various mlxsw driver fixes. ==================== Signed-off-by: David S. Miller <[email protected]>
2016-01-28mlxsw: reg: Use correct offset in field definitonIdo Schimmel1-3/+3
The rx_lane, tx_lane and module fields in the PMLP register don't have an additional offset besides the base one (0x04), so set it to 0x00. Fixes: 4ec14b7634b2 ("mlxsw: Add interface to access registers and process events") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28mlxsw: spectrum: Compare local ports instead of pointersIdo Schimmel1-2/+4
When dumping the FDB we can't compare the actual pointers of the ports structs, as it's possible the struct represents a vPort instead of the underlying physical port. Solve this by comparing the local port number instead, as it's shared between the physical ports and all the vPorts on top of him. Fixes: 54a732018d8e ("mlxsw: spectrum: Adjust switchdev ops for VLAN devices") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28mlxsw: spectrum: Dump LAG FDB records only onceIdo Schimmel1-2/+10
LAG FDB records can only point to LAG devices or VLAN devices configured on top of them. Therefore, when dumping the FDB we shouldn't associate these records with the underlying physical ports. Fixes: 8a1ab5d76639 ("mlxsw: spectrum: Implement FDB add/remove/dump for LAG") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28mlxsw: spectrum: Use correct netdev when notifying bridgeIdo Schimmel1-2/+4
LAG FDB entries pointing to VLAN devices should be reported to the bridge with the matching VLAN device and not the underlying LAG device. Fixes: aac78a440887 ("mlxsw: spectrum: Adjust FDB notifications for VLAN devices") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28mlxsw: spectrum: Don't report VLAN for 802.1D FDB entriesIdo Schimmel1-15/+16
When dumping the hardware FDB we should report entries pointing to VLAN devices with VLAN 0, as packets coming into the bridge are untagged. Likewise, pass FDB_{ADD,DEL} notifications with VLAN 0 for these devices. Fixes: 54a732018d8e ("mlxsw: spectrum: Adjust switchdev ops for VLAN devices") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28mlxsw: spectrum: Notify bridge's FDB only based on learning_syncIdo Schimmel1-8/+6
When we disable learning on bridge port we should still update the software bridge's FDB when entry pointing to this bridge port is aged-out. We can otherwise have an inconsistency between software and hardware tables. Fixes: 8a1ab5d76639 ("mlxsw: spectrum: Implement FDB add/remove/dump for LAG") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28mlxsw: spectrum: Disable learning according to STP stateIdo Schimmel1-1/+1
When port is put into LISTENING state it shouldn't populate the FDB, so set the port's STP state in hardware to DISCARDING instead of LEARNING. It will therefore keep listening to BPDU packets, but discard other non-control packets and won't perform any learning. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28mlxsw: spectrum: Don't forward packets when STP state is DISABLEDIdo Schimmel1-1/+1
When STP state is set to DISABLED the port is assumed to be inactive, but currently we forward packets ingressing through it. Instead, set the port's STP state in hardware to DISCARDING, which means it doesn't forward packets or perform any learning, but it does trap control packets. However, these packets will be dropped by bridge code, which results in the expected behavior. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28mlxsw: spectrum: Flush FDB when leaving bridgeIdo Schimmel1-8/+129
As explained in previous commit, we should always take care of flushing the FDB in the driver and not rely on bridge code. We need to distinguish between two cases with regards to LAG: 1) Port is leaving LAG while LAG is bridged (or VLAN devices on top of it). In this case don't flush the FDB entries pointing to the LAG ID, as this will affect other ports still member in the LAG. Only flush the FDB when the last port in the LAG is leaving the bridge. 2) LAG device is leaving the bridge. In this case the CHANGEUPPER event is simply propagated to each member port, so make each port flush the FDB in its turn. Note that emptying a bridged LAG from ports creates an inconsistency between hardware and software. A user who later (< ageing_time) re-populates the LAG won't have any FDB entries pointing to the LAG ID in hardware, but they will be present in the software bridge's FDB. Currently there is no good solution to this problem, but this will be addressed by us in the future. In order to optimize the flushing process, flush by port or LAG ID if there are no VLAN interfaces on top of the port. Otherwise, flush using (Port / LAG ID, FID=VID} for each of the lower 4K FIDs. In the case of VLAN device simply flush using {Port / LAG ID, vFID} with the vFID to which the VLAN device is mapped to. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28mlxsw: reg: Add the Switch Filtering DB Flush registerIdo Schimmel1-0/+88
When removing a net device from a bridge we should flush the FDB entries associated with this net device. Up until now, we relied upon bridge code to do that for us, but it is possible for user to prevent hardware from syncing with the software bridge (learning_sync=0), so we need to flush overselves. Add the Switch Filtering DB Flush (SFDF) register that is used to flush FDB entries according to different parameters (per-port, per-FID etc). Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28mlxsw: spectrum: Handle port leaving LAG while bridgedIdo Schimmel3-3/+36
It is possible for a user to remove a port from a LAG device, while the LAG device or VLAN devices on top of it are bridged. In these cases, bridge's teardown sequence is never issued, so we need to take care of it ourselves. When LAG's unlinking event is received by port netdev: 1) Traverse its vPorts list and make those member in a bridge leave it. They will be deleted later by LAG code. 2) Make the port netdev itself leave its bridge if member in one. Fixes: 0d65fc13042f ("mlxsw: spectrum: Implement LAG port join/leave") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-28perf: Fix race in perf_event_exit_task_context()Peter Zijlstra1-21/+29
There is a race between perf_event_exit_task_context() and orphans_remove_work() which results in a use-after-free. We mark ctx->task with TASK_TOMBSTONE to indicate a context is 'dead', under ctx->lock. After which point event_function_call() on any event of that context will NOP A concurrent orphans_remove_work() will only hold ctx->mutex for the list iteration and not serialize against this. Therefore its possible that orphans_remove_work()'s perf_remove_from_context() call will fail, but we'll continue to free the event, with the result of free'd memory still being on lists and everything. Once perf_event_exit_task_context() gets around to acquiring ctx->mutex it too will iterate the event list, encounter the already free'd event and proceed to free it _again_. This fails with the WARN in free_event(). Plug the race by having perf_event_exit_task_context() hold ctx::mutex over the whole tear-down, thereby 'naturally' serializing against all other sites, including the orphan work. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-01-28perf: Fix orphan holePeter Zijlstra1-2/+2
We should set event->owner before we install the event, otherwise there is a hole where the target task can fork() and we'll not inherit the event because it thinks the event is orphaned. Signed-off-by: Peter Zijlstra <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-01-28drm/amdgpu: only move pt bos in LRU list on successNicolai Hähnle1-2/+2
This fixes a race condition in the error case: since the pt bos have not necessarily been reserved in case of an error, we could move a pt bo that is currently in the middle of being evicted/moved by another process, which then resulted in a BUG_ON in ttm_bo_add_to_lru. Reviewed-by: Christian König <[email protected]> Signed-off-by: Nicolai Hähnle <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2016-01-28Merge tag 'usb-serial-4.5-rc2' of ↵Greg Kroah-Hartman6-3/+49
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for v4.5-rc2 Here are two fixes of crashes in the visor driver that could be triggered using bad (malicious) descriptors, a fix for two memory leaks in the new mxu11x0 driver, and an interface-blacklist fix for the option driver. Included are also some new device ids. Signed-off-by: Johan Hovold <[email protected]>
2016-01-28powerpc/mm: Fixup _HPAGE_CHG_MASKAneesh Kumar K.V1-1/+3
This was wrongly updated by commit 7aa9a23c69ea ("powerpc, thp: remove infrastructure for handling splitting PMDs") during the last merge window. Fix it up. This could lead to incorrect behaviour in THP and/or mprotect(), at a minimum. Fixes: 7aa9a23c69ea ("powerpc, thp: remove infrastructure for handling splitting PMDs") Signed-off-by: Aneesh Kumar K.V <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2016-01-28powerpc/perf: Remove PPMU_HAS_SSLOT flag for Power8Madhavan Srinivasan1-1/+1
Commit 7a7868326d77 ("powerpc/perf: Add an explict flag indicating presence of SLOT field") introduced the PPMU_HAS_SSLOT flag to remove the assumption that MMCRA[SLOT] was present when PPMU_ALT_SIPR was not set. That commit's changelog also mentions that Power8 does not support MMCRA[SLOT]. However when the Power8 PMU support was merged, it errnoeously included the PPMU_HAS_SSLOT flag. So remove PPMU_HAS_SSLOT from the Power8 flags. mpe: On systems where MMCRA[SLOT] exists, the field occupies bits 37:39 (IBM numbering). On Power8 bit 37 is reserved, and 38:39 overlap with the high bits of the Threshold Event Counter Mantissa. I am not aware of any published events which use the threshold counting mechanism, which would cause the mantissa bits to be set. So in practice this bug is unlikely to trigger. Fixes: e05b9b9e5c10 ("powerpc/perf: Power8 PMU support") Signed-off-by: Madhavan Srinivasan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2016-01-28ALSA: dummy: Disable switching timer backend via sysfsTakashi Iwai1-1/+1
ALSA dummy driver can switch the timer backend between system timer and hrtimer via its hrtimer module option. This can be also switched dynamically via sysfs, but it may lead to a memory corruption when switching is done while a PCM stream is running; the stream instance for the newly switched timer method tries to access the memory that was allocated by another timer method although the sizes differ. As the simplest fix, this patch just disables the switch via sysfs by dropping the writable bit. BugLink: http://lkml.kernel.org/r/CACT4Y+ZGEeEBntHW5WHn2GoeE0G_kRrCmUh6=dWyy-wfzvuJLg@mail.gmail.com Reported-by: Dmitry Vyukov <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-01-28ALSA: timer: fix SND_PCM_TIMER Kconfig textRandy Dunlap1-3/+3
Fix spelling and typos for SND_PCM_TIMER. Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-01-27hwmon: (fam15h_power) Add bit masking for tdp_limitGioh Kim1-1/+9
Add bit masking to read ApmTdpLimit precisely Signed-off-by: Gioh Kim <[email protected]> Acked-by: Borislav Petkov <[email protected]> Acked-by: Huang Rui <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2016-01-27NFS: Cleanup - rename NFS_LAYOUT_RETURN_BEFORE_CLOSETrond Myklebust4-9/+9
NFS_LAYOUT_RETURN_BEFORE_CLOSE is being used to signal that a layoutreturn is needed, either due to a layout recall or to a layout error. Rename it to NFS_LAYOUT_RETURN_REQUESTED in order to clarify its purpose. Signed-off-by: Trond Myklebust <[email protected]>
2016-01-28Merge tag 'seccomp-4.5-rc2' of ↵James Morris1-11/+11
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into for-linus
2016-01-28KEYS: Only apply KEY_FLAG_KEEP to a key if a parent keyring has it setDavid Howells1-1/+2
KEY_FLAG_KEEP should only be applied to a key if the keyring it is being linked into has KEY_FLAG_KEEP set. To this end, partially revert the following patch: commit 1d6d167c2efcfe9539d9cffb1a1be9c92e39c2c0 Author: Mimi Zohar <[email protected]> Date: Thu Jan 7 07:46:36 2016 -0500 KEYS: refcount bug fix to undo the change that made it unconditional (Mimi got it right the first time). Without undoing this change, it becomes impossible to delete, revoke or invalidate keys added to keyrings through __key_instantiate_and_link() where the keyring has itself been linked to. To test this, run the following command sequence: keyctl newring foo @s keyctl add user a a %:foo keyctl unlink %user:a %:foo keyctl clear %:foo With the commit mentioned above the third and fourth commands fail with EPERM when they should succeed. Reported-by: Stephen Gallager <[email protected]> Signed-off-by: David Howells <[email protected]> Acked-by: Mimi Zohar <[email protected]> cc: Mimi Zohar <[email protected]> cc: [email protected] cc: [email protected] Signed-off-by: James Morris <[email protected]>
2016-01-27cpufreq: cpufreq-dt: avoid uninitialized variable warnings:Arnd Bergmann1-8/+7
gcc warns quite a bit about values returned from allocate_resources() in cpufreq-dt.c: cpufreq-dt.c: In function 'cpufreq_init': cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here cpufreq-dt.c: In function 'dt_cpufreq_probe': cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here The problem is that it's slightly hard for gcc to follow return codes across PTR_ERR() calls. This patch uses explicit assignments to the "ret" variable to make it easier for gcc to verify that the code is actually correct, without the need to add a bogus initialization. Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.