commit e0cd0574e82d995e12328d07678558d5e6736be7 Author: Greg Kroah-Hartman Date: Wed Nov 20 12:31:48 2013 -0800 Linux 3.11.9 commit 56a766f0fe6e932dc2ecd6aac2e33861027d31c2 Author: Dan Carpenter Date: Fri Aug 23 06:54:44 2013 -0300 media: sh_vou: almost forever loop in sh_vou_try_fmt_vid_out() commit 47c32ec9392a1fc7dec9d7cfde084e1432fcee82 upstream. The "i < " part of the "i < ARRAY_SIZE()" condition was missing. Signed-off-by: Dan Carpenter [g.liakhovetski@gmx.de: remove unrelated superfluous braces] Signed-off-by: Guennadi Liakhovetski Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 1e7c2cd28dc4ea3a86266fcfd07700e3911716a5 Author: Xenia Ragiadakou Date: Sat Aug 31 18:09:12 2013 +0300 usbcore: set lpm_capable field for LPM capable root hubs commit 9df89d85b407690afa46ddfbccc80bec6869971d upstream. This patch sets the lpm_capable field for root hubs with LPM capabilities. Signed-off-by: Xenia Ragiadakou Reported-by: Martin MOKREJS Suggested-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit a35bbad6526cf3de01a4344b3c36d5e1e292bbd1 Author: Krzysztof Mazur Date: Thu Aug 22 14:49:39 2013 +0200 usb: fail on usb_hub_create_port_device() errors commit e58547eb9561a8a72d46e2d411090a614d33ac0e upstream. Ignoring usb_hub_create_port_device() errors cause later NULL pointer deference when uninitialized hub->ports[i] entries are dereferenced after port memory allocation error. Signed-off-by: Krzysztof Mazur Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit b2c2f76356a3acca905be36a07b43b9f586abdcc Author: Krzysztof Mazur Date: Thu Aug 22 14:49:38 2013 +0200 usb: fix cleanup after failure in hub_configure() commit d0308d4b6b02597f39fc31a9bddf7bb3faad5622 upstream. If the hub_configure() fails after setting the hdev->maxchild the hub->ports might be NULL or point to uninitialized kzallocated memory causing NULL pointer dereference in hub_quiesce() during cleanup. Now after such error the hdev->maxchild is set to 0 to avoid cleanup of uninitialized ports. Signed-off-by: Krzysztof Mazur Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit c03642ee7ef2fda996cbf699a6363b2cd7d8b48b Author: Johan Hovold Date: Mon Sep 23 16:27:32 2013 +0200 backlight: atmel-pwm-bl: fix deferred probe from __init commit 9d3fde86b15303decea632c929fbf1f3ae4501f2 upstream. Move probe out of __init section and don't use platform_driver_probe which cannot be used with deferred probing. Since commit e9354576 ("gpiolib: Defer failed gpio requests by default") this driver might return -EPROBE_DEFER if a gpio_request fails. Cc: Richard Purdie Cc: Jingoo Han Cc: Jean-Christophe Plagniol-Villard Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit be85221c4bab7fa3d930d13683b9edacc24392f3 Author: Johan Hovold Date: Tue Oct 22 18:32:39 2013 +0200 misc: atmel_pwm: add deferred-probing support commit 5c6d6fd1564138ad048564e48639f842714a90c6 upstream. Two drivers (atmel-pwm-bl and leds-atmel-pwm) currently depend on the atmel_pwm driver to have bound to any pwm-device before their devices are probed. Support deferred probing of such devices by making sure to return -EPROBE_DEFER from pwm_channel_alloc when no pwm-device has yet been bound. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit b53ef1347bffe6f9fd40816387d2519c56c27d87 Author: Matti Gottlieb Date: Sun Sep 22 08:23:23 2013 +0300 iwlwifi: pcie: add new SKUs for 7000 & 3160 NIC series commit b49926629fb5c324bb1ed3960fb0d7905a4a8562 upstream. Add some new PCI IDs to the table for 7000 & 3160 series Cc: stable@vger.kernel.org Signed-off-by: Matti Gottlieb Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 57b0a9d310c0b1373fbbeee2aa0caec12cd74c5e Author: Peter Zijlstra Date: Mon Oct 28 13:55:29 2013 +0100 perf: Fix perf ring buffer memory ordering commit bf378d341e4873ed928dc3c636252e6895a21f50 upstream. The PPC64 people noticed a missing memory barrier and crufty old comments in the perf ring buffer code. So update all the comments and add the missing barrier. When the architecture implements local_t using atomic_long_t there will be double barriers issued; but short of introducing more conditional barrier primitives this is the best we can do. Reported-by: Victor Kaplansky Tested-by: Victor Kaplansky Signed-off-by: Peter Zijlstra Cc: Mathieu Desnoyers Cc: michael@ellerman.id.au Cc: Paul McKenney Cc: Michael Neuling Cc: Frederic Weisbecker Cc: anton@samba.org Cc: benh@kernel.crashing.org Link: http://lkml.kernel.org/r/20131025173749.GG19466@laptop.lan Signed-off-by: Ingo Molnar Cc: Michael Neuling Signed-off-by: Greg Kroah-Hartman commit 747b00783906993edb8289641d92663e87b3a3f3 Author: Jani Nikula Date: Mon Oct 21 10:52:07 2013 +0300 drm/i915/dp: workaround BIOS eDP bpp clamping issue commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf upstream. This isn't a real fix to the problem, but rather a stopgap measure while trying to find a proper solution. There are several laptops out there that fail to light up the eDP panel in UEFI boot mode. They seem to be mostly IVB machines, including but apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot. The difference between UEFI and CSM is that the BIOS provides a different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and 1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz link, and for reasons yet unknown fail to light up the panel. Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with 2.7 GHz link, the eDP panel lights up. So essentially this is a link speed issue, and *not* a bpp clamping issue. The bug raised its head since commit 657445fe8660100ad174600ebfa61536392b7624 Author: Daniel Vetter Date: Sat May 4 10:09:18 2013 +0200 Revert "drm/i915: revert eDP bpp clamping code changes" which started clamping bpp *before* computing the link requirements, and thus affecting the required bandwidth. Clamping after the computations kept the link at 2.7 GHz. Even though the BIOS tells us to use 18 bpp through the VBT, it happily boots up at 24 bpp and 2.7 GHz itself! Use this information to selectively ignore the VBT provided value. We can't ignore the VBT eDP bpp altogether, as there are other laptops that do require the clamping to be used due to EDID reporting higher bpp than the panel can support. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950 Tested-by: Ulf Winkelvos Tested-by: jkp Signed-off-by: Jani Nikula Signed-off-by: Daniel Vetter [Jani: stable 3.11 backport] Signed-off-by: Greg Kroah-Hartman commit 33e3df4431c556fab571411bf46a7cac1c6426e5 Author: Steven Rostedt Date: Wed Oct 9 22:23:23 2013 -0400 tracing: Fix potential out-of-bounds in trace_get_user() commit 057db8488b53d5e4faa0cedb2f39d4ae75dfbdbb upstream. Andrey reported the following report: ERROR: AddressSanitizer: heap-buffer-overflow on address ffff8800359c99f3 ffff8800359c99f3 is located 0 bytes to the right of 243-byte region [ffff8800359c9900, ffff8800359c99f3) Accessed by thread T13003: #0 ffffffff810dd2da (asan_report_error+0x32a/0x440) #1 ffffffff810dc6b0 (asan_check_region+0x30/0x40) #2 ffffffff810dd4d3 (__tsan_write1+0x13/0x20) #3 ffffffff811cd19e (ftrace_regex_release+0x1be/0x260) #4 ffffffff812a1065 (__fput+0x155/0x360) #5 ffffffff812a12de (____fput+0x1e/0x30) #6 ffffffff8111708d (task_work_run+0x10d/0x140) #7 ffffffff810ea043 (do_exit+0x433/0x11f0) #8 ffffffff810eaee4 (do_group_exit+0x84/0x130) #9 ffffffff810eafb1 (SyS_exit_group+0x21/0x30) #10 ffffffff81928782 (system_call_fastpath+0x16/0x1b) Allocated by thread T5167: #0 ffffffff810dc778 (asan_slab_alloc+0x48/0xc0) #1 ffffffff8128337c (__kmalloc+0xbc/0x500) #2 ffffffff811d9d54 (trace_parser_get_init+0x34/0x90) #3 ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0) #4 ffffffff811cda7d (ftrace_filter_open+0x2d/0x40) #5 ffffffff8129b4ff (do_dentry_open+0x32f/0x430) #6 ffffffff8129b668 (finish_open+0x68/0xa0) #7 ffffffff812b66ac (do_last+0xb8c/0x1710) #8 ffffffff812b7350 (path_openat+0x120/0xb50) #9 ffffffff812b8884 (do_filp_open+0x54/0xb0) #10 ffffffff8129d36c (do_sys_open+0x1ac/0x2c0) #11 ffffffff8129d4b7 (SyS_open+0x37/0x50) #12 ffffffff81928782 (system_call_fastpath+0x16/0x1b) Shadow bytes around the buggy address: ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>ffff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap redzone: fa Heap kmalloc redzone: fb Freed heap region: fd Shadow gap: fe The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;' Although the crash happened in ftrace_regex_open() the real bug occurred in trace_get_user() where there's an incrementation to parser->idx without a check against the size. The way it is triggered is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop that reads the last character stores it and then breaks out because there is no more characters. Then the last character is read to determine what to do next, and the index is incremented without checking size. Then the caller of trace_get_user() usually nulls out the last character with a zero, but since the index is equal to the size, it writes a nul character after the allocated space, which can corrupt memory. Luckily, only root user has write access to this file. Link: http://lkml.kernel.org/r/20131009222323.04fd1a0d@gandalf.local.home Reported-by: Andrey Konovalov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 0e5f1191f16f22168597a72f134817bd452311cd Author: Anssi Hannula Date: Sat Oct 5 02:25:38 2013 +0300 ALSA: hda - hdmi: Fix reported channel map on common default layouts commit 56cac413dd6d43af8355f5d1f90a199b540f73fc upstream. hdmi_setup_fake_chmap() is supposed to set the reported channel map when the channel map is not specified by the user. However, the function indexes channel_allocations[] with a wrong value and extracts the wrong nibble from hdmi_channel_mapping[], causing wrong channel maps to be shown. Fix those issues. Tested on Intel HDMI to correctly generate various channel maps, for example 3,4,14,15,7,8,5,6 (instead of incorrect 3,4,8,7,5,6,14,0) for standard 7.1 channel audio. (Note that the side and rear channels are reported as RL/RR and RLC/RRC, respectively, as per the CEA-861 standard, instead of the more traditional SL/SR and RL/RR.) Note that this only fixes the layouts that only contain traditional 7.1 speakers (2.0, 2.1, 4.0, 5.1, 7.1, etc.). E.g. the rear center of 6.1 is still being shown wrongly due to an issue with from_cea_slot() which will be fixed in a later patch. Signed-off-by: Anssi Hannula Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 01535e4b7b56616692ff1f80f1b2fc79f8d1cbec Author: Rui li Date: Fri Oct 25 10:57:21 2013 +0800 USB: add new zte 3g-dongle's pid to option.c commit 0636fc507a976cdc40f21bdbcce6f0b98ff1dfe9 upstream. Signed-off-by: Rui li Cc: stable Signed-off-by: Greg Kroah-Hartman commit e55433c7d7bbbf07dd93dcd4d778adbeffbb579d Author: Gerd Hoffmann Date: Wed Oct 2 13:55:10 2013 +0200 hyperv-fb: add pci stub commit 7ad9684721606efbfb9b347346816e1e6baff8bb upstream. This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer driver will bind to the pci device then, so linux kernel and userspace know there is a proper kernel driver for the device active. lspci shows this for example: [root@dhcp231 ~]# lspci -vs8 00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual VGA (prog-if 00 [VGA controller]) Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at f8000000 (32-bit, non-prefetchable) [size=64M] Expansion ROM at [disabled] Kernel driver in use: hyperv_fb Another effect is that the xorg vesa driver will not attach to the device and thus the Xorg server will automatically use the fbdev driver instead. Signed-off-by: Gerd Hoffmann Acked-by: Haiyang Zhang Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit 583d15959df1bfc179a83b1b53a49ab72455e128 Author: Srinivas Pandruvada Date: Tue Sep 24 11:05:16 2013 -0700 Thermal: x86_pkg_temp: change spin lock commit 7bed1b3caaedd5918f0820b29f3b7a2ddc812922 upstream. x86_pkg_temp receives thermal notifications via a callback from a therm_throt driver, where thermal interrupts are processed. This callback is pkg_temp_thermal_platform_thermal_notify. Here to avoid multiple interrupts from cores in a package, we disable the source and also set a variable to avoid scheduling delayed work function. This variable is protected via spin_lock_irqsave. On one buggy platform, we still receiving interrupts even if the source is disabled. This can cause deadlock/lockdep warning, when interrupt is generated while under spinlock in work function. Change spin_lock to spin_lock_irqsave and spin_unlock to spin_unlock_irqrestore as the data it is trying to protect can also be modified in a notification call called from interrupt handler. Signed-off-by: Srinivas Pandruvada Signed-off-by: Zhang Rui Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit edd644711b563f7c5732c1c05afa0a280c85b547 Author: David Vrabel Date: Mon Oct 7 13:55:19 2013 +0100 xen-netback: transition to CLOSED when removing a VIF [ Upstream commit dc62ccaccfb139d9b04bbc5a2688a4402adbfab3 ] If a guest is destroyed without transitioning its frontend to CLOSED, the domain becomes a zombie as netback was not grant unmapping the shared rings. When removing a VIF, transition the backend to CLOSED so the VIF is disconnected if necessary (which will unmap the shared rings etc). This fixes a regression introduced by 279f438e36c0a70b23b86d2090aeec50155034a9 (xen-netback: Don't destroy the netdev until the vif is shut down). Signed-off-by: David Vrabel Cc: Ian Campbell Cc: Wei Liu Cc: Paul Durrant Acked-by: Wei Liu Reviewed-by: Paul Durrant Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5fe14179931a43c9ed41228f6ccbd6be699c4a4e Author: Paul Durrant Date: Thu Sep 26 12:09:52 2013 +0100 xen-netback: Handle backend state transitions in a more robust way [ Upstream commit ea732dff5cfa10789007bf4a5b935388a0bb2a8f ] When the frontend state changes netback now specifies its desired state to a new function, set_backend_state(), which transitions through any necessary intermediate states. This fixes an issue observed with some old Windows frontend drivers where they failed to transition through the Closing state and netback would not behave correctly. Signed-off-by: Paul Durrant Cc: Ian Campbell Cc: Wei Liu Cc: David Vrabel Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4e9728a21f389cbba3bd5403126ed66757f4db1e Author: Hannes Frederic Sowa Date: Thu Oct 24 10:14:27 2013 +0200 ipv6: reset dst.expires value when clearing expire flag [ Upstream commit 01ba16d6ec85a1ec4669c75513a76b61ec53ee50 ] On receiving a packet too big icmp error we update the expire value by calling rt6_update_expires. This function uses dst_set_expires which is implemented that it can only reduce the expiration value of the dst entry. If we insert new routing non-expiry information into the ipv6 fib where we already have a matching rt6_info we only clear the RTF_EXPIRES flag in rt6i_flags and leave the dst.expires value as is. When new mtu information arrives for that cached dst_entry we again call dst_set_expires. This time it won't update the dst.expire value because we left the dst.expire value intact from the last update. So dst_set_expires won't touch dst.expires. Fix this by resetting dst.expires when clearing the RTF_EXPIRE flag. dst_set_expires checks for a zero expiration and updates the dst.expires. In the past this (not updating dst.expires) was necessary because dst.expire was placed in a union with the dst_entry *from reference and rt6_clean_expires did assign NULL to it. This split happend in ecd9883724b78cc72ed92c98bcb1a46c764fff21 ("ipv6: fix race condition regarding dst->expires and dst->from"). Reported-by: Steinar H. Gunderson Reported-by: Valentijn Sessink Cc: YOSHIFUJI Hideaki Acked-by: Eric Dumazet Tested-by: Valentijn Sessink Signed-off-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1731edcbfebcba8d348320af86250d377920887a Author: Hannes Frederic Sowa Date: Thu Oct 24 07:48:24 2013 +0200 ipv6: ip6_dst_check needs to check for expired dst_entries [ Upstream commit e3bc10bd95d7fcc3f2ac690c6ff22833ea6781d6 ] On receiving a packet too big icmp error we check if our current cached dst_entry in the socket is still valid. This validation check did not care about the expiration of the (cached) route. The error path I traced down: The socket receives a packet too big mtu notification. It still has a valid dst_entry and thus issues the ip6_rt_pmtu_update on this dst_entry, setting RTF_EXPIRE and updates the dst.expiration value (which could fail because of not up-to-date expiration values, see previous patch). In some seldom cases we race with a) the ip6_fib gc or b) another routing lookup which would result in a recreation of the cached rt6_info from its parent non-cached rt6_info. While copying the rt6_info we reinitialize the metrics store by copying it over from the parent thus invalidating the just installed pmtu update (both dsts use the same key to the inetpeer storage). The dst_entry with the just invalidated metrics data would just get its RTF_EXPIRES flag cleared and would continue to stay valid for the socket. We should have not issued the pmtu update on the already expired dst_entry in the first placed. By checking the expiration on the dst entry and doing a relookup in case it is out of date we close the race because we would install a new rt6_info into the fib before we issue the pmtu update, thus closing this race. Not reliably updating the dst.expire value was fixed by the patch "ipv6: reset dst.expires value when clearing expire flag". Reported-by: Steinar H. Gunderson Reported-by: Valentijn Sessink Cc: YOSHIFUJI Hideaki Signed-off-by: Hannes Frederic Sowa Reviewed-by: Eric Dumazet Tested-by: Valentijn Sessink Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2ce4f6032a861ee486fcedff2332566e29ccdf63 Author: Eric Dumazet Date: Fri Oct 25 17:26:17 2013 -0700 tcp: gso: fix truesize tracking [ Upstream commit 0d08c42cf9a71530fef5ebcfe368f38f2dd0476f ] commit 6ff50cd55545 ("tcp: gso: do not generate out of order packets") had an heuristic that can trigger a warning in skb_try_coalesce(), because skb->truesize of the gso segments were exactly set to mss. This breaks the requirement that skb->truesize >= skb->len + truesizeof(struct sk_buff); It can trivially be reproduced by : ifconfig lo mtu 1500 ethtool -K lo tso off netperf As the skbs are looped into the TCP networking stack, skb_try_coalesce() warns us of these skb under-estimating their truesize. Signed-off-by: Eric Dumazet Reported-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 16eb6273adfced2e67e54373d87b48fbeb28ee0c Author: Ben Hutchings Date: Sun Oct 27 21:02:39 2013 +0000 cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures [ Upstream commit 262e827fe745642589450ae241b7afd3912c3f25 ] The length calculation here is now invalid on 32-bit architectures, since sk_buff::tail is a pointer and sk_buff::transport_header is an integer offset: drivers/net/ethernet/chelsio/cxgb3/sge.c: In function 'write_ofld_wr': drivers/net/ethernet/chelsio/cxgb3/sge.c:1603:9: warning: passing argument 4 of 'make_sgl' makes integer from pointer without a cast [enabled by default] adap->pdev); ^ drivers/net/ethernet/chelsio/cxgb3/sge.c:964:28: note: expected 'unsigned int' but argument is of type 'sk_buff_data_t' static inline unsigned int make_sgl(const struct sk_buff *skb, ^ Use the appropriate skb accessor functions. Compile-tested only. Signed-off-by: Ben Hutchings Fixes: 1a37e412a022 ('net: Use 16bits for *_headers fields of struct skbuff') Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6f54c27651df94b564dec0d66954ed190c8ef811 Author: Wei Liu Date: Mon Oct 28 12:07:57 2013 +0000 xen-netback: use jiffies_64 value to calculate credit timeout [ Upstream commit 059dfa6a93b779516321e5112db9d7621b1367ba ] time_after_eq() only works if the delta is < MAX_ULONG/2. For a 32bit Dom0, if netfront sends packets at a very low rate, the time between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2 and the test for timer_after_eq() will be incorrect. Credit will not be replenished and the guest may become unable to send packets (e.g., if prior to the long gap, all credit was exhausted). Use jiffies_64 variant to mitigate this problem for 32bit Dom0. Suggested-by: Jan Beulich Signed-off-by: Wei Liu Reviewed-by: David Vrabel Cc: Ian Campbell Cc: Jason Luan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1527a1e413876f0b237bd97d15ed9b930e65d6e4 Author: Jason Wang Date: Tue Oct 29 15:11:07 2013 +0800 virtio-net: correctly handle cpu hotplug notifier during resuming [ Upstream commit ec9debbd9a88d8ea86c488d6ffcac419ee7d46d9 ] commit 3ab098df35f8b98b6553edc2e40234af512ba877 (virtio-net: don't respond to cpu hotplug notifier if we're not ready) tries to bypass the cpu hotplug notifier by checking the config_enable and does nothing is it was false. So it need to try to hold the config_lock mutex which may happen in atomic environment which leads the following warnings: [ 622.944441] CPU0 attaching NULL sched-domain. [ 622.944446] CPU1 attaching NULL sched-domain. [ 622.944485] CPU0 attaching NULL sched-domain. [ 622.950795] BUG: sleeping function called from invalid context at kernel/mutex.c:616 [ 622.950796] in_atomic(): 1, irqs_disabled(): 1, pid: 10, name: migration/1 [ 622.950796] no locks held by migration/1/10. [ 622.950798] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.12.0-rc5-wl-01249-gb91e82d #317 [ 622.950799] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 622.950802] 0000000000000000 ffff88001d42dba0 ffffffff81a32f22 ffff88001bfb9c70 [ 622.950803] ffff88001d42dbb0 ffffffff810edb02 ffff88001d42dc38 ffffffff81a396ed [ 622.950805] 0000000000000046 ffff88001d42dbe8 ffffffff810e861d 0000000000000000 [ 622.950805] Call Trace: [ 622.950810] [] dump_stack+0x54/0x74 [ 622.950815] [] __might_sleep+0x112/0x114 [ 622.950817] [] mutex_lock_nested+0x3c/0x3c6 [ 622.950818] [] ? up+0x39/0x3e [ 622.950821] [] ? acpi_os_signal_semaphore+0x21/0x2d [ 622.950824] [] ? acpi_ut_release_mutex+0x5e/0x62 [ 622.950828] [] virtnet_cpu_callback+0x33/0x87 [ 622.950830] [] notifier_call_chain+0x3c/0x5e [ 622.950832] [] __raw_notifier_call_chain+0xe/0x10 [ 622.950835] [] __cpu_notify+0x20/0x37 [ 622.950836] [] cpu_notify+0x13/0x15 [ 622.950838] [] take_cpu_down+0x27/0x3a [ 622.950841] [] stop_machine_cpu_stop+0x93/0xf1 [ 622.950842] [] cpu_stopper_thread+0xa0/0x12f [ 622.950844] [] ? cpu_stopper_thread+0x12f/0x12f [ 622.950847] [] ? lock_release_holdtime.part.7+0xa3/0xa8 [ 622.950848] [] ? cpu_stop_should_run+0x3f/0x47 [ 622.950850] [] smpboot_thread_fn+0x1c5/0x1e3 [ 622.950852] [] ? lg_global_unlock+0x67/0x67 [ 622.950854] [] kthread+0xd8/0xe0 [ 622.950857] [] ? wait_for_common+0x12f/0x164 [ 622.950859] [] ? kthread_create_on_node+0x124/0x124 [ 622.950861] [] ret_from_fork+0x7c/0xb0 [ 622.950862] [] ? kthread_create_on_node+0x124/0x124 [ 622.950876] smpboot: CPU 1 is now offline [ 623.194556] SMP alternatives: lockdep: fixing up alternatives [ 623.194559] smpboot: Booting Node 0 Processor 1 APIC 0x1 ... A correct fix is to unregister the hotcpu notifier during restore and register a new one in resume. Reported-by: Fengguang Wu Tested-by: Fengguang Wu Cc: Wanlong Gao Cc: Rusty Russell Cc: Michael S. Tsirkin Signed-off-by: Jason Wang Acked-by: Michael S. Tsirkin Reviewed-by: Wanlong Gao Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6047108c443aa6dc359e205ad028e7533a605b43 Author: Jason Wang Date: Fri Nov 1 15:01:10 2013 +0800 net: flow_dissector: fail on evil iph->ihl [ Upstream commit 6f092343855a71e03b8d209815d8c45bf3a27fcd ] We don't validate iph->ihl which may lead a dead loop if we meet a IPIP skb whose iph->ihl is zero. Fix this by failing immediately when iph->ihl is evil (less than 5). This issue were introduced by commit ec5efe7946280d1e84603389a1030ccec0a767ae (rps: support IPIP encapsulation). Signed-off-by: Jason Wang Cc: Eric Dumazet Cc: Petr Matousek Cc: Michael S. Tsirkin Cc: Daniel Borkmann Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e697716658d52d072707f0aade1ccf8742c5fa60 Author: Daniel Borkmann Date: Thu Oct 31 09:13:32 2013 +0100 net: sctp: do not trigger BUG_ON in sctp_cmd_delete_tcb [ Upstream commit 7926c1d5be0b7cbe5b8d5c788d7d39237e7b212c ] Introduced in f9e42b853523 ("net: sctp: sideeffect: throw BUG if primary_path is NULL"), we intended to find a buggy assoc that's part of the assoc hash table with a primary_path that is NULL. However, we better remove the BUG_ON for now and find a more suitable place to assert for these things as Mark reports that this also triggers the bug when duplication cookie processing happens, and the assoc is not part of the hash table (so all good in this case). Such a situation can for example easily be reproduced by: tc qdisc add dev eth0 root handle 1: prio bands 2 priomap 1 1 1 1 1 1 tc qdisc add dev eth0 parent 1:2 handle 20: netem loss 20% tc filter add dev eth0 protocol ip parent 1: prio 2 u32 match ip \ protocol 132 0xff match u8 0x0b 0xff at 32 flowid 1:2 This drops 20% of COOKIE-ACK packets. After some follow-up discussion with Vlad we came to the conclusion that for now we should still better remove this BUG_ON() assertion, and come up with two follow-ups later on, that is, i) find a more suitable place for this assertion, and possibly ii) have a special allocator/initializer for such kind of temporary assocs. Reported-by: Mark Thomas Signed-off-by: Vlad Yasevich Signed-off-by: Daniel Borkmann Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 51ce60929df54a8daa310091743458c95d95633f Author: Jack Morgenstein Date: Sun Nov 3 10:04:07 2013 +0200 net/mlx4_core: Fix call to __mlx4_unregister_mac [ Upstream commit c32b7dfbb1dfb3f0a68f250deff65103c8bb704a ] In function mlx4_master_deactivate_admin_state() __mlx4_unregister_mac was called using the MAC index. It should be called with the value of the MAC itself. Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman