21 Nov, 2013
26 commits
-
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 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 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 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 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 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 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 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 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 +0200Revert "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 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: feThe 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 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 0636fc507a976cdc40f21bdbcce6f0b98ff1dfe9 upstream.
Signed-off-by: Rui li
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
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_fbAnother 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 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 -
[ 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 -
[ 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 -
[ 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 -
[ 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 -
[ 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
netperfAs 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 -
[ 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 -
[ 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 -
[ 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 -
[ 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 -
[ 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:2This 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 -
[ 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
13 Nov, 2013
14 commits
-
commit 1517a3f21a1dd321f16bcf44204bddff9d21abd0 upstream.
Debugfs was setup in NTB to only have a single debugfs directory. This
resulted in the leaking of debugfs directories and files when multiple
NTB devices were present, due to each device stomping on the variables
containing the previous device's values (thus preventing them from being
freed on cleanup). Correct this by creating a secondary directory of
the PCI BDF for each device present, and nesting the previously existing
information in those directories.Signed-off-by: Jon Mason
Signed-off-by: Greg Kroah-Hartman -
commit b6750cfe0710a14fd147ba27fddbecae8ba88c77 upstream.
Due to ambiguous documentation, the USD/DSD identification is backward
when compared to the setting in BIOS. Correct the bits to match the
BIOS setting.Signed-off-by: Jon Mason
Signed-off-by: Greg Kroah-Hartman -
commit 87034511519815259e37336f52edf06d114d43b6 upstream.
The NTB Xeon hardware has 16 scratch pad registers and 16 back-to-back
scratch pad registers. Correct the #define to represent this and update
the variable names to reflect their usage.Signed-off-by: Jon Mason
Signed-off-by: Greg Kroah-Hartman -
commit 3b12a0d15bd1559e72ad21d9d807fd2a6706f0ab upstream.
If an error is encountered in ntb_device_setup, it is possible that the
spci_cmd isn't populated. Writes to the offset can result in a NULL
pointer dereference. This issue is easily encountered by running in
NTB-RP mode, as it currently is not supported and will generate an
error. To get around this issue, return if an error is encountered
prior to attempting to write to the spci_cmd offset.Signed-off-by: Jon Mason
Signed-off-by: Greg Kroah-Hartman -
commit 05e16745c0c471bba313961b605b6da3b21a853d upstream.
This issue was first pointed out by Jiaxing Wang several months ago, but no
further comments:
https://lkml.org/lkml/2013/6/29/41As we know pread() does not change f_pos, so after pread(), file->f_pos
and m->read_pos become different. And seq_lseek() does not update file->f_pos
if offset equals to m->read_pos, so after pread() and seq_lseek()(lseek to
m->read_pos), then a subsequent read may read from a wrong position, the
following program produces the problem:char str1[32] = { 0 };
char str2[32] = { 0 };
int poffset = 10;
int count = 20;/*open any seq file*/
int fd = open("/proc/modules", O_RDONLY);pread(fd, str1, count, poffset);
printf("pread:%s\n", str1);/*seek to where m->read_pos is*/
lseek(fd, poffset+count, SEEK_SET);/*supposed to read from poffset+count, but this read from position 0*/
read(fd, str2, count);
printf("read:%s\n", str2);out put:
pread:
ck_netbios_ns 12665
read:
nf_conntrack_netbios/proc/modules:
nf_conntrack_netbios_ns 12665 0 - Live 0xffffffffa038b000
nf_conntrack_broadcast 12589 1 nf_conntrack_netbios_ns, Live 0xffffffffa0386000So we always update file->f_pos to offset in seq_lseek() to fix this issue.
Signed-off-by: Jiaxing Wang
Signed-off-by: Gu Zheng
Signed-off-by: Al Viro
Cc: Jonghwan Choi
Signed-off-by: Greg Kroah-Hartman -
commit b0267507dfd0187fb7840a0ec461a510a7f041c5 upstream.
Commit 040a0a37 ("mutex: Add support for wound/wait style locks")
used "!__builtin_constant_p(p == NULL)" but gcc 3.x cannot
handle such expression correctly, leading to boot failure when
built with CONFIG_DEBUG_MUTEXES=y.Fix it by explicitly passing a bool which tells whether p != NULL
or not.[ PeterZ: This is a sad patch, but provided it actually generates
similar code I suppose its the best we can do bar whole
sale deprecating gcc-3. ]Signed-off-by: Tetsuo Handa
Acked-by: Peter Zijlstra
Acked-by: Maarten Lankhorst
Cc: peterz@infradead.org
Cc: imirkin@alum.mit.edu
Cc: daniel.vetter@ffwll.ch
Cc: robdclark@gmail.com
Cc: Linus Torvalds
Cc: Andrew Morton
Link: http://lkml.kernel.org/r/201310171945.AGB17114.FSQVtHOJFOOFML@I-love.SAKURA.ne.jp
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 1fbc0d789d12fec313c91912fc11733fdfbab863 upstream.
Originally I've thought that this is leftover hw state dirt from the
BIOS. But after way too much helpless flailing around on my part I've
noticed that the actual bug is when we change the state of an already
active pipe.For example when we change the fdi lines from 2 to 3 without switching
off outputs in-between we'll never see the crucial on->off transition
in the ->modeset_global_resources hook the current logic relies on.Patch version 2 got this right by instead also checking whether the
pipe is indeed active. But that in turn broke things when pipes have
been turned off through dpms since the bifurcate enabling is done in
the ->crtc_mode_set callback.To address this issues discussed with Ville in the patch review move
the setting of the bifurcate bit into the ->crtc_enable hook. That way
we won't wreak havoc with this state when userspace puts all other
outputs into dpms off state. This also moves us forward with our
overall goal to unify the modeset and dpms on paths (which we need to
have to allow runtime pm in the dpms off state).Unfortunately this requires us to move the bifurcate helpers around a
bit.Also update the commit message, I've misanalyzed the bug rather badly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507
Tested-by: Jan-Michael Brummer
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 645378d85ee524e429aa4cf52806047b56cdc596 upstream.
The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
having LVDS but the hardware is not populated. This patch adds them to
the list of such systems. Patch is against 3.11.4v2: Patch revised to match the D425KT exactly as the D425KTW does have
LVDS. According to Intel's documentation, the D410PTL and D410PLTW
don't.Signed-off-by: Rob Pearce
[danvet: Pimp commit message to my liking and add cc: stable.]
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 4f56d12ebb28fceac4c6e60c8993fbfc122e1399 upstream.
On CTG+ read out the pipe bpp setting from hardware and fill it into
pipe config. Also check it appropriately.v2: Don't do the pipe_bpp extraction inside the PCH only code block on
ILK+.
Avoid the PIPECONF read as we already have read it for the
PIPECONF_EANBLE check.Note: This is already in drm-intel-next-queued as
commit 42571aefafb1d330ef84eb29418832f72e7dfb4c
Author: Ville Syrjälä
Date: Fri Sep 6 23:29:00 2013 +0300drm/i915: Add support for pipe_bpp readout
but is needed for the following bugfix.
Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 7195a50b5c7e00cc3312934fd022c3006b533d12 upstream.
Call intel_ddi_get_config() to get the pipe_bpp settings from
DDI.The sync polarity settings from DDI are irrelevant for CRT
output, so override them with data from the ADPA register.Note: This is already merged in drm-intel-next-queued as
commit 6801c18c0a43386bb44712cbc028a7e05adb9f0d
Author: Ville Syrjälä
Date: Tue Sep 24 14:24:05 2013 +0300drm/i915: Add HSW CRT output readout support
but is required for the following edp bpp bugfix.
v2: Extract intel_crt_get_flags()
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691
Tested-by: Qingshuai Tian
Signed-off-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit d83671126dc8e7c0b56c9970ea5ffd08c3b0c645 upstream.
Prevent driver load problems if the smc is missing.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=63011Signed-off-by: Alex Deucher
Tested-by: Mikko Rapeli
Signed-off-by: Greg Kroah-Hartman -
commit c23632d4e57c0dd20bf50eca08fa0eb8ad3ff680 upstream.
Some rs780 asics seem to be affected as well.
See:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91f3a6aaf280294b07c05dfe606e6c27b7ba3c72Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60791Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.
Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
the 4 bytes beyond the end of its structure with a 32-bit userspace
running on a 64-bit kernel. This is due to the padding gcc inserts as
the drm_mode_get_connector struct includes a u64 and its size is not a
natural multiple of u64s.64-bit kernel:
sizeof(drm_mode_get_connector)=80, alignof=8
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=432-bit userspace:
sizeof(drm_mode_get_connector)=76, alignof=4
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4Fortuituously we can insert explicit padding to the tail of our
structures without breaking ABI.Reported-by: Pavel Roskin
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
