OSDN Git Service
Bin Liu [Thu, 26 May 2016 16:43:45 +0000 (11:43 -0500)]
usb: gadget: fix spinlock dead lock in gadgetfs
commit
d246dcb2331c5783743720e6510892eb1d2801d9 upstream.
[ 40.467381] =============================================
[ 40.473013] [ INFO: possible recursive locking detected ]
[ 40.478651]
4.6.0-08691-g7f3db9a #37 Not tainted
[ 40.483466] ---------------------------------------------
[ 40.489098] usb/733 is trying to acquire lock:
[ 40.493734] (&(&dev->lock)->rlock){-.....}, at: [<
bf129288>] ep0_complete+0x18/0xdc [gadgetfs]
[ 40.502882]
[ 40.502882] but task is already holding lock:
[ 40.508967] (&(&dev->lock)->rlock){-.....}, at: [<
bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
[ 40.517811]
[ 40.517811] other info that might help us debug this:
[ 40.524623] Possible unsafe locking scenario:
[ 40.524623]
[ 40.530798] CPU0
[ 40.533346] ----
[ 40.535894] lock(&(&dev->lock)->rlock);
[ 40.540088] lock(&(&dev->lock)->rlock);
[ 40.544284]
[ 40.544284] *** DEADLOCK ***
[ 40.544284]
[ 40.550461] May be due to missing lock nesting notation
[ 40.550461]
[ 40.557544] 2 locks held by usb/733:
[ 40.561271] #0: (&f->f_pos_lock){+.+.+.}, at: [<
c02a6114>] __fdget_pos+0x40/0x48
[ 40.569219] #1: (&(&dev->lock)->rlock){-.....}, at: [<
bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
[ 40.578523]
[ 40.578523] stack backtrace:
[ 40.583075] CPU: 0 PID: 733 Comm: usb Not tainted
4.6.0-08691-g7f3db9a #37
[ 40.590246] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 40.596625] [<
c010ffbc>] (unwind_backtrace) from [<
c010c1bc>] (show_stack+0x10/0x14)
[ 40.604718] [<
c010c1bc>] (show_stack) from [<
c04207fc>] (dump_stack+0xb0/0xe4)
[ 40.612267] [<
c04207fc>] (dump_stack) from [<
c01886ec>] (__lock_acquire+0xf68/0x1994)
[ 40.620440] [<
c01886ec>] (__lock_acquire) from [<
c0189528>] (lock_acquire+0xd8/0x238)
[ 40.628621] [<
c0189528>] (lock_acquire) from [<
c06ad6b4>] (_raw_spin_lock_irqsave+0x38/0x4c)
[ 40.637440] [<
c06ad6b4>] (_raw_spin_lock_irqsave) from [<
bf129288>] (ep0_complete+0x18/0xdc [gadgetfs])
[ 40.647339] [<
bf129288>] (ep0_complete [gadgetfs]) from [<
bf10a728>] (musb_g_giveback+0x118/0x1b0 [musb_hdrc])
[ 40.657842] [<
bf10a728>] (musb_g_giveback [musb_hdrc]) from [<
bf108768>] (musb_g_ep0_queue+0x16c/0x188 [musb_hdrc])
[ 40.668772] [<
bf108768>] (musb_g_ep0_queue [musb_hdrc]) from [<
bf12a944>] (ep0_read+0x544/0x5e0 [gadgetfs])
[ 40.678963] [<
bf12a944>] (ep0_read [gadgetfs]) from [<
c0284470>] (__vfs_read+0x20/0x110)
[ 40.687414] [<
c0284470>] (__vfs_read) from [<
c0285324>] (vfs_read+0x88/0x114)
[ 40.694864] [<
c0285324>] (vfs_read) from [<
c0286150>] (SyS_read+0x44/0x9c)
[ 40.702051] [<
c0286150>] (SyS_read) from [<
c0107820>] (ret_fast_syscall+0x0/0x1c)
This is caused by the spinlock bug in ep0_read().
Fix the two other deadlock sources in gadgetfs_setup() too.
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sudip Mukherjee [Mon, 30 May 2016 13:46:33 +0000 (19:16 +0530)]
USB: mos7720: delete parport
commit
dcb21ad4385731b7fc3ef39d255685f2f63c8c5d upstream.
parport subsystem has introduced parport_del_port() to delete a port
when it is going away. Without parport_del_port() the registered port
will not be unregistered.
To reproduce and verify the error:
Command to be used is : ls /sys/bus/parport/devices
1) without the device attached there is no output as there is no
registered parport.
2) Attach the device, and the command will show "parport0".
3) Remove the device and the command still shows "parport0".
4) Attach the device again and we get "parport1".
With the patch applied:
1) without the device attached there is no output as there is no
registered parport.
2) Attach the device, and the command will show "parport0".
3) Remove the device and there is no output as "parport0" is now
removed.
4) Attach device again to get "parport0" again.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Nyman [Wed, 1 Jun 2016 15:09:08 +0000 (18:09 +0300)]
xhci: Fix handling timeouted commands on hosts in weird states.
commit
3425aa03f484d45dc21e0e791c2f6c74ea656421 upstream.
If commands timeout we mark them for abortion, then stop the command
ring, and turn the commands to no-ops and finally restart the command
ring.
If the host is working properly the no-op commands will finish and
pending completions are called.
If we notice the host is failing, driver clears the command ring and
completes, deletes and frees all pending commands.
There are two separate cases reported where host is believed to work
properly but is not. In the first case we successfully stop the ring
but no abort or stop command ring event is ever sent and host locks up.
The second case is if a host is removed, command times out and driver
believes the ring is stopped, and assumes it will be restarted, but
actually ends up timing out on the same command forever.
If one of the pending commands has the xhci->mutex held it will block
xhci_stop() in the remove codepath which otherwise would cleanup pending
commands.
Add a check that clears all pending commands in case host is removed,
or we are stuck timing out on the same command. Also restart the
command timeout timer when stopping the command ring to ensure we
recive an ring stop/abort event.
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Wed, 1 Jun 2016 19:01:29 +0000 (21:01 +0200)]
USB: xhci: Add broken streams quirk for Frescologic device id 1009
commit
d95815ba6a0f287213118c136e64d8c56daeaeab upstream.
I got one of these cards for testing uas with, it seems that with streams
it dma-s all over the place, corrupting memory. On my first tests it
managed to dma over the BIOS of the motherboard somehow and completely
bricked it.
Tests on another motherboard show that it does work with streams disabled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Petazzoni [Wed, 1 Jun 2016 15:09:09 +0000 (18:09 +0300)]
usb: xhci-plat: properly handle probe deferral for devm_clk_get()
commit
de95c40d5beaa47f6dc8fe9ac4159b4672b51523 upstream.
On some platforms, the clocks might be registered by a platform
driver. When this is the case, the clock platform driver may very well
be probed after xhci-plat, in which case the first probe() invocation
of xhci-plat will receive -EPROBE_DEFER as the return value of
devm_clk_get().
The current code handles that as a normal error, and simply assumes
that this means that the system doesn't have a clock for the XHCI
controller, and continues probing without calling
clk_prepare_enable(). Unfortunately, this doesn't work on systems
where the XHCI controller does have a clock, but that clock is
provided by another platform driver. In order to fix this situation,
we handle the -EPROBE_DEFER error condition specially, and abort the
XHCI controller probe(). It will be retried later automatically, the
clock will be available, devm_clk_get() will succeed, and the probe()
will continue with the clock prepared and enabled as expected.
In practice, such issue is seen on the ARM64 Marvell 7K/8K platform,
where the clocks are registered by a platform driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gabriel Krisman Bertazi [Wed, 1 Jun 2016 15:09:07 +0000 (18:09 +0300)]
xhci: Cleanup only when releasing primary hcd
commit
27a41a83ec54d0edfcaf079310244e7f013a7701 upstream.
Under stress occasions some TI devices might not return early when
reading the status register during the quirk invocation of xhci_irq made
by usb_hcd_pci_remove. This means that instead of returning, we end up
handling this interruption in the middle of a shutdown. Since
xhci->event_ring has already been freed in xhci_mem_cleanup, we end up
accessing freed memory, causing the Oops below.
commit
8c24d6d7b09d ("usb: xhci: stop everything on the first call to
xhci_stop") is the one that changed the instant in which we clean up the
event queue when stopping a device. Before, we didn't call
xhci_mem_cleanup at the first time xhci_stop is executed (for the shared
HCD), instead, we only did it after the invocation for the primary HCD,
much later at the removal path. The code flow for this oops looks like
this:
xhci_pci_remove()
usb_remove_hcd(xhci->shared)
xhci_stop(xhci->shared)
xhci_halt()
xhci_mem_cleanup(xhci); // Free the event_queue
usb_hcd_pci_remove(primary)
xhci_irq() // Access the event_queue if STS_EINT is set. Crash.
xhci_stop()
xhci_halt()
// return early
The fix modifies xhci_stop to only cleanup the xhci data when releasing
the primary HCD. This way, we still have the event_queue configured
when invoking xhci_irq. We still halt the device on the first call to
xhci_stop, though.
I could reproduce this issue several times on the mainline kernel by
doing a bind-unbind stress test with a specific storage gadget attached.
I also ran the same test over-night with my patch applied and didn't
observe the issue anymore.
[ 113.334124] Unable to handle kernel paging request for data at address 0x00000028
[ 113.335514] Faulting instruction address: 0xd00000000d4f767c
[ 113.336839] Oops: Kernel access of bad area, sig: 11 [#1]
[ 113.338214] SMP NR_CPUS=1024 NUMA PowerNV
[
c000000efe47ba90]
c000000000720850 usb_hcd_irq+0x50/0x80
[
c000000efe47bac0]
c00000000073d328 usb_hcd_pci_remove+0x68/0x1f0
[
c000000efe47bb00]
d00000000daf0128 xhci_pci_remove+0x78/0xb0
[xhci_pci]
[
c000000efe47bb30]
c00000000055cf70 pci_device_remove+0x70/0x110
[
c000000efe47bb70]
c00000000061c6bc __device_release_driver+0xbc/0x190
[
c000000efe47bba0]
c00000000061c7d0 device_release_driver+0x40/0x70
[
c000000efe47bbd0]
c000000000619510 unbind_store+0x120/0x150
[
c000000efe47bc20]
c0000000006183c4 drv_attr_store+0x64/0xa0
[
c000000efe47bc60]
c00000000039f1d0 sysfs_kf_write+0x80/0xb0
[
c000000efe47bca0]
c00000000039e14c kernfs_fop_write+0x18c/0x1f0
[
c000000efe47bcf0]
c0000000002e962c __vfs_write+0x6c/0x190
[
c000000efe47bd90]
c0000000002eab40 vfs_write+0xc0/0x200
[
c000000efe47bde0]
c0000000002ec85c SyS_write+0x6c/0x110
[
c000000efe47be30]
c000000000009260 system_call+0x38/0x108
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: joel@jms.id.au
Reviewed-by: Roger Quadros <rogerq@ti.com>
Tested-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bin Liu [Tue, 31 May 2016 15:05:25 +0000 (10:05 -0500)]
usb: musb: host: correct cppi dma channel for isoch transfer
commit
04471eb8c3158c0ad9df4b24da845a63b2e8f23a upstream.
Incorrect cppi dma channel is referenced in musb_rx_dma_iso_cppi41(),
which causes kernel NULL pointer reference oops later when calling
cppi41_dma_channel_program().
Fixes:
069a3fd (usb: musb: Remove ifdefs for musb_host_rx in musb_host.c
part1)
Reported-by: Matwey V. Kornilov <matwey@sai.msu.ru>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrew Goodbody [Tue, 31 May 2016 15:05:26 +0000 (10:05 -0500)]
usb: musb: Ensure rx reinit occurs for shared_fifo endpoints
commit
f3eec0cf784e0d6c47822ca6b66df3d5812af7e6 upstream.
shared_fifo endpoints would only get a previous tx state cleared
out, the rx state was only cleared for non shared_fifo endpoints
Change this so that the rx state is cleared for all endpoints.
This addresses an issue that resulted in rx packets being dropped
silently.
Signed-off-by: Andrew Goodbody <andrew.goodbody@cambrionix.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrew Goodbody [Tue, 31 May 2016 15:05:27 +0000 (10:05 -0500)]
usb: musb: Stop bulk endpoint while queue is rotated
commit
7b2c17f829545df27a910e8d82e133c21c9a8c9c upstream.
Ensure that the endpoint is stopped by clearing REQPKT before
clearing DATAERR_NAKTIMEOUT before rotating the queue on the
dedicated bulk endpoint.
This addresses an issue where a race could result in the endpoint
receiving data before it was reprogrammed resulting in a warning
about such data from musb_rx_reinit before it was thrown away.
The data thrown away was a valid packet that had been correctly
ACKed which meant the host and device got out of sync.
Signed-off-by: Andrew Goodbody <andrew.goodbody@cambrionix.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bin Liu [Tue, 31 May 2016 15:05:24 +0000 (10:05 -0500)]
usb: musb: only restore devctl when session was set in backup
commit
84ac5d1140f716a616522f952734e850448d2556 upstream.
If the session bit was not set in the backup of devctl register,
restoring devctl would clear the session bit. Therefor, only restore
devctl register when the session bit was set in the backup.
This solves the device enumeration failure in otg mode exposed by commit
56f487c (PM / Runtime: Update last_busy in rpm_resume).
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Thu, 19 May 2016 15:12:20 +0000 (17:12 +0200)]
usb: quirks: Add no-lpm quirk for Acer C120 LED Projector
commit
32cb0b37098f4beeff5ad9e325f11b42a6ede56c upstream.
The Acer C120 LED Projector is a USB-3 connected pico projector which
takes both its power and video data from USB-3.
In combination with some hubs this device does not play well with
lpm, so disable lpm for it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Thu, 19 May 2016 15:12:19 +0000 (17:12 +0200)]
usb: quirks: Fix sorting
commit
81099f97bd31e25ff2719a435b1860fc3876122f upstream.
Properly sort all the entries by vendor id.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Tue, 31 May 2016 07:18:03 +0000 (09:18 +0200)]
USB: uas: Fix slave queue_depth not being set
commit
593224ea77b1ca842f45cf76f4deeef44dfbacd1 upstream.
Commit
198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level")
removed the scsi_change_queue_depth() call from uas_slave_configure()
assuming that the slave would inherit the host's queue_depth, which
that commit sets to the same value.
This is incorrect, without the scsi_change_queue_depth() call the slave's
queue_depth defaults to 1, introducing a performance regression.
This commit restores the call, fixing the performance regression.
Fixes:
198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level")
Reported-by: Tom Yan <tom.ty89@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Krause [Wed, 22 Jun 2016 18:29:37 +0000 (20:29 +0200)]
crypto: user - re-add size check for CRYPTO_MSG_GETALG
commit
055ddaace03580455a7b7dbea8e93d62acee61fc upstream.
Commit
9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG")
accidentally removed the minimum size check for CRYPTO_MSG_GETALG
netlink messages. This allows userland to send a truncated
CRYPTO_MSG_GETALG message as short as a netlink header only making
crypto_report() operate on uninitialized memory by accessing data
beyond the end of the netlink message.
Fix this be re-adding the minimum required size of CRYPTO_MSG_GETALG
messages to the crypto_msg_min[] array.
Fixes:
9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG")
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Wed, 8 Jun 2016 12:56:39 +0000 (14:56 +0200)]
crypto: ux500 - memmove the right size
commit
19ced623db2fe91604d69f7d86b03144c5107739 upstream.
The hash buffer is really HASH_BLOCK_SIZE bytes, someone
must have thought that memmove takes n*u32 words by mistake.
Tests work as good/bad as before after this patch.
Cc: Joakim Bech <joakim.bech@linaro.org>
Reported-by: David Binderman <linuxdev.baldrick@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anton Blanchard [Fri, 10 Jun 2016 06:47:03 +0000 (16:47 +1000)]
crypto: vmx - Increase priority of aes-cbc cipher
commit
12d3f49e1ffbbf8cbbb60acae5a21103c5c841ac upstream.
All of the VMX AES ciphers (AES, AES-CBC and AES-CTR) are set at
priority 1000. Unfortunately this means we never use AES-CBC and
AES-CTR, because the base AES-CBC cipher that is implemented on
top of AES inherits its priority.
To fix this, AES-CBC and AES-CTR have to be a higher priority. Set
them to 2000.
Testing on a POWER8 with:
cryptsetup benchmark --cipher aes --key-size 256
Shows decryption speed increase from 402.4 MB/s to 3069.2 MB/s,
over 7x faster. Thanks to Mike Strosaker for helping me debug
this issue.
Fixes:
8c755ace357c ("crypto: vmx - Adding CBC routines for VMX module")
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Basil Gunn [Thu, 16 Jun 2016 16:42:30 +0000 (09:42 -0700)]
AX.25: Close socket connection on session completion
[ Upstream commit
4a7d99ea1b27734558feb6833f180cd38a159940 ]
A socket connection made in ax.25 is not closed when session is
completed. The heartbeat timer is stopped prematurely and this is
where the socket gets closed. Allow heatbeat timer to run to close
socket. Symptom occurs in kernels >= 4.2.0
Originally sent 6/15/2016. Resend with distribution list matching
scripts/maintainer.pl output.
Signed-off-by: Basil Gunn <basil@pacabunga.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Borkmann [Fri, 19 Feb 2016 22:05:25 +0000 (23:05 +0100)]
bpf: try harder on clones when writing into skb
[ Upstream commit
3697649ff29e0f647565eed04b27a7779c646a22 ]
When we're dealing with clones and the area is not writeable, try
harder and get a copy via pskb_expand_head(). Replace also other
occurences in tc actions with the new skb_try_make_writable().
Reported-by: Ashhad Sheikh <ashhadsheikh394@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Feng Tang [Fri, 24 Jun 2016 07:26:05 +0000 (15:26 +0800)]
net: alx: Work around the DMA RX overflow issue
[ Upstream commit
881d0327db37ad917a367c77aff1afa1ee41e0a9 ]
Note: This is a verified backported patch for stable 4.4 kernel, and it
could also be applied to 4.3/4.2/4.1/3.18/3.16
There is a problem with alx devices, that the network link will be
lost in 1-5 minutes after the device is up.
>From debugging without datasheet, we found the error always
happen when the DMA RX address is set to 0x....fc0, which is very
likely to be a HW/silicon problem.
This patch will apply rx skb with 64 bytes longer space, and if the
allocated skb has a 0x...fc0 address, it will use skb_resever(skb, 64)
to advance the address, so that the RX overflow can be avoided.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70761
Signed-off-by: Feng Tang <feng.tang@intel.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Tested-by: Ole Lukoie <olelukoie@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Ferre [Thu, 10 Mar 2016 15:44:32 +0000 (16:44 +0100)]
net: macb: fix default configuration for GMAC on AT91
[ Upstream commit
6bdaa5e9ed39b3b3328f35d218e8ad5a99cfc4d2 ]
On AT91 SoCs, the User Register (USRIO) exposes a switch to configure the
"Reduced" or "Traditional" version of the Media Independent Interface
(RMII vs. MII or RGMII vs. GMII).
As on the older EMAC version, on GMAC, this switch is set by default to the
non-reduced type of interface, so use the existing capability and extend it to
GMII as well. We then keep the current logic in the macb_init() function.
The capabilities of sama5d2, sama5d4 and sama5d3 GEM interface are updated in
the macb_config structure to be able to properly enable them with a traditional
interface (GMII or MII).
Reported-by: Romain HENRIET <romain.henriet@l-acoustics.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[cyrille.pitchen@atmel.com: backported to 4.4.y]
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Barroso [Tue, 28 Jun 2016 08:16:43 +0000 (11:16 +0300)]
neigh: Explicitly declare RCU-bh read side critical section in neigh_xmit()
[ Upstream commit
b560f03ddfb072bca65e9440ff0dc4f9b1d1f056 ]
neigh_xmit() expects to be called inside an RCU-bh read side critical
section, and while one of its two current callers gets this right, the
other one doesn't.
More specifically, neigh_xmit() has two callers, mpls_forward() and
mpls_output(), and while both callers call neigh_xmit() under
rcu_read_lock(), this provides sufficient protection for neigh_xmit()
only in the case of mpls_forward(), as that is always called from
softirq context and therefore doesn't need explicit BH protection,
while mpls_output() can be called from process context with softirqs
enabled.
When mpls_output() is called from process context, with softirqs
enabled, we can be preempted by a softirq at any time, and RCU-bh
considers the completion of a softirq as signaling the end of any
pending read-side critical sections, so if we do get a softirq
while we are in the part of neigh_xmit() that expects to be run inside
an RCU-bh read side critical section, we can end up with an unexpected
RCU grace period running right in the middle of that critical section,
making things go boom.
This patch fixes this impedance mismatch in the callee, by making
neigh_xmit() always take rcu_read_{,un}lock_bh() around the code that
expects to be treated as an RCU-bh read side critical section, as this
seems a safer option than fixing it in the callers.
Fixes:
4fd3d7d9e868f ("neigh: Add helper function neigh_xmit")
Signed-off-by: David Barroso <dbarroso@fastly.com>
Signed-off-by: Lennert Buytenhek <lbuytenhek@fastly.com>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: Robert Shearman <rshearma@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Borkmann [Mon, 27 Jun 2016 19:38:11 +0000 (21:38 +0200)]
bpf, perf: delay release of BPF prog after grace period
[ Upstream commit
ceb56070359b7329b5678b5d95a376fcb24767be ]
Commit
dead9f29ddcc ("perf: Fix race in BPF program unregister") moved
destruction of BPF program from free_event_rcu() callback to __free_event(),
which is problematic if used with tail calls: if prog A is attached as
trace event directly, but at the same time present in a tail call map used
by another trace event program elsewhere, then we need to delay destruction
via RCU grace period since it can still be in use by the program doing the
tail call (the prog first needs to be dropped from the tail call map, then
trace event with prog A attached destroyed, so we get immediate destruction).
Fixes:
dead9f29ddcc ("perf: Fix race in BPF program unregister")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Cc: Jann Horn <jann@thejh.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Willem de Bruijn [Fri, 24 Jun 2016 20:02:35 +0000 (16:02 -0400)]
sock_diag: do not broadcast raw socket destruction
[ Upstream commit
9a0fee2b552b1235fb1706ae1fc664ae74573be8 ]
Diag intends to broadcast tcp_sk and udp_sk socket destruction.
Testing sk->sk_protocol for IPPROTO_TCP/IPPROTO_UDP alone is not
sufficient for this. Raw sockets can have the same type.
Add a test for sk->sk_type.
Fixes:
eb4cb008529c ("sock_diag: define destruction multicast groups")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
daniel [Fri, 24 Jun 2016 10:35:18 +0000 (12:35 +0200)]
Bridge: Fix ipv6 mc snooping if bridge has no ipv6 address
[ Upstream commit
0888d5f3c0f183ea6177355752ada433d370ac89 ]
The bridge is falsly dropping ipv6 mulitcast packets if there is:
1. No ipv6 address assigned on the brigde.
2. No external mld querier present.
3. The internal querier enabled.
When the bridge fails to build mld queries, because it has no
ipv6 address, it slilently returns, but keeps the local querier enabled.
This specific case causes confusing packet loss.
Ipv6 multicast snooping can only work if:
a) An external querier is present
OR
b) The bridge has an ipv6 address an is capable of sending own queries
Otherwise it has to forward/flood the ipv6 multicast traffic,
because snooping cannot work.
This patch fixes the issue by adding a flag to the bridge struct that
indicates that there is currently no ipv6 address assinged to the bridge
and returns a false state for the local querier in
__br_multicast_querier_exists().
Special thanks to Linus Lüssing.
Fixes:
d1d81d4c3dd8 ("bridge: check return value of ipv6_dev_get_saddr()")
Signed-off-by: Daniel Danzberger <daniel@dd-wrt.com>
Acked-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Goff [Thu, 23 Jun 2016 20:11:57 +0000 (16:11 -0400)]
ipmr/ip6mr: Initialize the last assert time of mfc entries.
[ Upstream commit
70a0dec45174c976c64b4c8c1d0898581f759948 ]
This fixes wrong-interface signaling on 32-bit platforms for entries
created when jiffies > 2^31 + MFC_ASSERT_THRESH.
Signed-off-by: Tom Goff <thomas.goff@ll.mit.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Mon, 20 Jun 2016 22:00:43 +0000 (15:00 -0700)]
netem: fix a use after free
[ Upstream commit
21de12ee5568fd1aec47890c72967abf791ac80a ]
If the packet was dropped by lower qdisc, then we must not
access it later.
Save qdisc_pkt_len(skb) in a temp variable.
Fixes:
2ccccf5fb43f ("net_sched: update hierarchical backlog too")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: WANG Cong <xiyou.wangcong@gmail.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Herbert Xu [Sat, 18 Jun 2016 05:03:36 +0000 (13:03 +0800)]
esp: Fix ESN generation under UDP encapsulation
[ Upstream commit
962fcef33b03395051367181a0549d29d109d9a4 ]
Blair Steven noticed that ESN in conjunction with UDP encapsulation
is broken because we set the temporary ESP header to the wrong spot.
This patch fixes this by first of all using the right spot, i.e.,
4 bytes off the real ESP header, and then saving this information
so that after encryption we can restore it properly.
Fixes:
7021b2e1cddd ("esp4: Switch to new AEAD interface")
Reported-by: Blair Steven <Blair.Steven@alliedtelesis.co.nz>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simon Horman [Thu, 16 Jun 2016 08:06:19 +0000 (17:06 +0900)]
sit: correct IP protocol used in ipip6_err
[ Upstream commit
d5d8760b78d0cfafe292f965f599988138b06a70 ]
Since
32b8a8e59c9c ("sit: add IPv4 over IPv4 support")
ipip6_err() may be called for packets whose IP protocol is
IPPROTO_IPIP as well as those whose IP protocol is IPPROTO_IPV6.
In the case of IPPROTO_IPIP packets the correct protocol value is not
passed to ipv4_update_pmtu() or ipv4_redirect().
This patch resolves this problem by using the IP protocol of the packet
rather than a hard-coded value. This appears to be consistent
with the usage of the protocol of a packet by icmp_socket_deliver()
the caller of ipip6_err().
I was able to exercise the redirect case by using a setup where an ICMP
redirect was received for the destination of the encapsulated packet.
However, it appears that although incorrect the protocol field is not used
in this case and thus no problem manifests. On inspection it does not
appear that a problem will manifest in the fragmentation needed/update pmtu
case either.
In short I believe this is a cosmetic fix. None the less, the use of
IPPROTO_IPV6 seems wrong and confusing.
Reviewed-by: Dinan Gunawardena <dinan.gunawardena@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason A. Donenfeld [Wed, 15 Jun 2016 09:14:53 +0000 (11:14 +0200)]
net: Don't forget pr_fmt on net_dbg_ratelimited for CONFIG_DYNAMIC_DEBUG
[ Upstream commit
daddef76c3deaaa7922f9d7b18edbf0a061215c3 ]
The implementation of net_dbg_ratelimited in the CONFIG_DYNAMIC_DEBUG
case was added with
2c94b5373 ("net: Implement net_dbg_ratelimited() for
CONFIG_DYNAMIC_DEBUG case"). The implementation strategy was to take the
usual definition of the dynamic_pr_debug macro, but alter it by adding a
call to "net_ratelimit()" in the if statement. This is, in fact, the
correct approach.
However, while doing this, the author of the commit forgot to surround
fmt by pr_fmt, resulting in unprefixed log messages appearing in the
console. So, this commit adds back the pr_fmt(fmt) invocation, making
net_dbg_ratelimited properly consistent across DEBUG, no DEBUG, and
DYNAMIC_DEBUG cases, and bringing parity with the behavior of
dynamic_pr_debug as well.
Fixes:
2c94b5373 ("net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Tim Bingham <tbingham@akamai.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Mon, 13 Jun 2016 03:01:25 +0000 (20:01 -0700)]
net_sched: fix pfifo_head_drop behavior vs backlog
[ Upstream commit
6c0d54f1897d229748d4f41ef919078db6db2123 ]
When the qdisc is full, we drop a packet at the head of the queue,
queue the current skb and return NET_XMIT_CN
Now we track backlog on upper qdiscs, we need to call
qdisc_tree_reduce_backlog(), even if the qlen did not change.
Fixes:
2ccccf5fb43f ("net_sched: update hierarchical backlog too")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: WANG Cong <xiyou.wangcong@gmail.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 24 Jun 2016 17:18:38 +0000 (10:18 -0700)]
Linux 4.4.14
Florian Westphal [Fri, 1 Apr 2016 13:37:59 +0000 (15:37 +0200)]
netfilter: x_tables: introduce and use xt_copy_counters_from_user
commit
d7591f0c41ce3e67600a982bab6989ef0f07b3ce upstream.
The three variants use same copy&pasted code, condense this into a
helper and use that.
Make sure info.name is 0-terminated.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:34 +0000 (14:17 +0200)]
netfilter: x_tables: do compat validation via translate_table
commit
09d9686047dbbe1cf4faa558d3ecc4aae2046054 upstream.
This looks like refactoring, but its also a bug fix.
Problem is that the compat path (32bit iptables, 64bit kernel) lacks a few
sanity tests that are done in the normal path.
For example, we do not check for underflows and the base chain policies.
While its possible to also add such checks to the compat path, its more
copy&pastry, for instance we cannot reuse check_underflow() helper as
e->target_offset differs in the compat case.
Other problem is that it makes auditing for validation errors harder; two
places need to be checked and kept in sync.
At a high level 32 bit compat works like this:
1- initial pass over blob:
validate match/entry offsets, bounds checking
lookup all matches and targets
do bookkeeping wrt. size delta of 32/64bit structures
assign match/target.u.kernel pointer (points at kernel
implementation, needed to access ->compatsize etc.)
2- allocate memory according to the total bookkeeping size to
contain the translated ruleset
3- second pass over original blob:
for each entry, copy the 32bit representation to the newly allocated
memory. This also does any special match translations (e.g.
adjust 32bit to 64bit longs, etc).
4- check if ruleset is free of loops (chase all jumps)
5-first pass over translated blob:
call the checkentry function of all matches and targets.
The alternative implemented by this patch is to drop steps 3&4 from the
compat process, the translation is changed into an intermediate step
rather than a full 1:1 translate_table replacement.
In the 2nd pass (step #3), change the 64bit ruleset back to a kernel
representation, i.e. put() the kernel pointer and restore ->u.user.name .
This gets us a 64bit ruleset that is in the format generated by a 64bit
iptables userspace -- we can then use translate_table() to get the
'native' sanity checks.
This has two drawbacks:
1. we re-validate all the match and target entry structure sizes even
though compat translation is supposed to never generate bogus offsets.
2. we put and then re-lookup each match and target.
THe upside is that we get all sanity tests and ruleset validations
provided by the normal path and can remove some duplicated compat code.
iptables-restore time of autogenerated ruleset with 300k chains of form
-A CHAIN0001 -m limit --limit 1/s -j CHAIN0002
-A CHAIN0002 -m limit --limit 1/s -j CHAIN0003
shows no noticeable differences in restore times:
old: 0m30.796s
new: 0m31.521s
64bit: 0m25.674s
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:33 +0000 (14:17 +0200)]
netfilter: x_tables: xt_compat_match_from_user doesn't need a retval
commit
0188346f21e6546498c2a0f84888797ad4063fc5 upstream.
Always returned 0.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:31 +0000 (14:17 +0200)]
netfilter: ip6_tables: simplify translate_compat_table args
commit
329a0807124f12fe1c8032f95d8a8eb47047fb0e upstream.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:30 +0000 (14:17 +0200)]
netfilter: ip_tables: simplify translate_compat_table args
commit
7d3f843eed29222254c9feab481f55175a1afcc9 upstream.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:32 +0000 (14:17 +0200)]
netfilter: arp_tables: simplify translate_compat_table args
commit
8dddd32756f6fe8e4e82a63361119b7e2384e02f upstream.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Wed, 1 Jun 2016 00:04:44 +0000 (02:04 +0200)]
netfilter: x_tables: don't reject valid target size on some architectures
commit
7b7eba0f3515fca3296b8881d583f7c1042f5226 upstream.
Quoting John Stultz:
In updating a 32bit arm device from 4.6 to Linus' current HEAD, I
noticed I was having some trouble with networking, and realized that
/proc/net/ip_tables_names was suddenly empty.
Digging through the registration process, it seems we're catching on the:
if (strcmp(t->u.user.name, XT_STANDARD_TARGET) == 0 &&
target_offset + sizeof(struct xt_standard_target) != next_offset)
return -EINVAL;
Where next_offset seems to be 4 bytes larger then the
offset + standard_target struct size.
next_offset needs to be aligned via XT_ALIGN (so we can access all members
of ip(6)t_entry struct).
This problem didn't show up on i686 as it only needs 4-byte alignment for
u64, but iptables userspace on other 32bit arches does insert extra padding.
Reported-by: John Stultz <john.stultz@linaro.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Fixes:
7ed2abddd20cf ("netfilter: x_tables: check standard target size too")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:29 +0000 (14:17 +0200)]
netfilter: x_tables: validate all offsets and sizes in a rule
commit
13631bfc604161a9d69cd68991dff8603edd66f9 upstream.
Validate that all matches (if any) add up to the beginning of
the target and that each match covers at least the base structure size.
The compat path should be able to safely re-use the function
as the structures only differ in alignment; added a
BUILD_BUG_ON just in case we have an arch that adds padding as well.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:28 +0000 (14:17 +0200)]
netfilter: x_tables: check for bogus target offset
commit
ce683e5f9d045e5d67d1312a42b359cb2ab2a13c upstream.
We're currently asserting that targetoff + targetsize <= nextoff.
Extend it to also check that targetoff is >= sizeof(xt_entry).
Since this is generic code, add an argument pointing to the start of the
match/target, we can then derive the base structure size from the delta.
We also need the e->elems pointer in a followup change to validate matches.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:27 +0000 (14:17 +0200)]
netfilter: x_tables: check standard target size too
commit
7ed2abddd20cf8f6bd27f65bd218f26fa5bf7f44 upstream.
We have targets and standard targets -- the latter carries a verdict.
The ip/ip6tables validation functions will access t->verdict for the
standard targets to fetch the jump offset or verdict for chainloop
detection, but this happens before the targets get checked/validated.
Thus we also need to check for verdict presence here, else t->verdict
can point right after a blob.
Spotted with UBSAN while testing malformed blobs.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:26 +0000 (14:17 +0200)]
netfilter: x_tables: add compat version of xt_check_entry_offsets
commit
fc1221b3a163d1386d1052184202d5dc50d302d1 upstream.
32bit rulesets have different layout and alignment requirements, so once
more integrity checks get added to xt_check_entry_offsets it will reject
well-formed 32bit rulesets.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:25 +0000 (14:17 +0200)]
netfilter: x_tables: assert minimum target size
commit
a08e4e190b866579896c09af59b3bdca821da2cd upstream.
The target size includes the size of the xt_entry_target struct.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:24 +0000 (14:17 +0200)]
netfilter: x_tables: kill check_entry helper
commit
aa412ba225dd3bc36d404c28cdc3d674850d80d0 upstream.
Once we add more sanity testing to xt_check_entry_offsets it
becomes relvant if we're expecting a 32bit 'config_compat' blob
or a normal one.
Since we already have a lot of similar-named functions (check_entry,
compat_check_entry, find_and_check_entry, etc.) and the current
incarnation is short just fold its contents into the callers.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:23 +0000 (14:17 +0200)]
netfilter: x_tables: add and use xt_check_entry_offsets
commit
7d35812c3214afa5b37a675113555259cfd67b98 upstream.
Currently arp/ip and ip6tables each implement a short helper to check that
the target offset is large enough to hold one xt_entry_target struct and
that t->u.target_size fits within the current rule.
Unfortunately these checks are not sufficient.
To avoid adding new tests to all of ip/ip6/arptables move the current
checks into a helper, then extend this helper in followup patches.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:22 +0000 (14:17 +0200)]
netfilter: x_tables: validate targets of jumps
commit
36472341017529e2b12573093cc0f68719300997 upstream.
When we see a jump also check that the offset gets us to beginning of
a rule (an ipt_entry).
The extra overhead is negible, even with absurd cases.
300k custom rules, 300k jumps to 'next' user chain:
[ plus one jump from INPUT to first userchain ]:
Before:
real 0m24.874s
user 0m7.532s
sys 0m16.076s
After:
real 0m27.464s
user 0m7.436s
sys 0m18.840s
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 1 Apr 2016 12:17:21 +0000 (14:17 +0200)]
netfilter: x_tables: don't move to non-existent next rule
commit
f24e230d257af1ad7476c6e81a8dc3127a74204e upstream.
Ben Hawkes says:
In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it
is possible for a user-supplied ipt_entry structure to have a large
next_offset field. This field is not bounds checked prior to writing a
counter value at the supplied offset.
Base chains enforce absolute verdict.
User defined chains are supposed to end with an unconditional return,
xtables userspace adds them automatically.
But if such return is missing we will move to non-existent next rule.
Reported-by: Ben Hawkes <hawkes@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maarten Lankhorst [Wed, 4 May 2016 12:38:26 +0000 (14:38 +0200)]
drm/core: Do not preserve framebuffer on rmfb, v4.
commit
f2d580b9a8149735cbc4b59c4a8df60173658140 upstream.
It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.
drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.
Changes since v1:
- Add comment.
Changes since v2:
- Add fastpath for refcount = 1. (danvet)
Changes since v3:
- Rebased.
- Restore lastclose framebuffer removal too.
Fixes:
13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_rmfb_basic
References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Thomas Hellstrom <thellstrom@vmware.com> #v3
Tested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/6c63ca37-0e7e-ac7f-a6d2-c7822e3d611f@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tadeusz Struk [Fri, 29 Apr 2016 17:43:40 +0000 (10:43 -0700)]
crypto: qat - fix adf_ctl_drv.c:undefined reference to adf_init_pf_wq
commit
6dc5df71ee5c8b44607928bfe27be50314dcf848 upstream.
Fix undefined reference issue reported by kbuild test robot.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Tue, 22 Mar 2016 17:02:52 +0000 (18:02 +0100)]
netfilter: x_tables: fix unconditional helper
commit
54d83fc74aa9ec72794373cb47432c5f7fb1a309 upstream.
Ben Hawkes says:
In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it
is possible for a user-supplied ipt_entry structure to have a large
next_offset field. This field is not bounds checked prior to writing a
counter value at the supplied offset.
Problem is that mark_source_chains should not have been called --
the rule doesn't have a next entry, so its supposed to return
an absolute verdict of either ACCEPT or DROP.
However, the function conditional() doesn't work as the name implies.
It only checks that the rule is using wildcard address matching.
However, an unconditional rule must also not be using any matches
(no -m args).
The underflow validator only checked the addresses, therefore
passing the 'unconditional absolute verdict' test, while
mark_source_chains also tested for presence of matches, and thus
proceeeded to the next (not-existent) rule.
Unify this so that all the callers have same idea of 'unconditional rule'.
Reported-by: Ben Hawkes <hawkes@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Tue, 22 Mar 2016 17:02:50 +0000 (18:02 +0100)]
netfilter: x_tables: make sure e->next_offset covers remaining blob size
commit
6e94e0cfb0887e4013b3b930fa6ab1fe6bb6ba91 upstream.
Otherwise this function may read data beyond the ruleset blob.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Tue, 22 Mar 2016 17:02:49 +0000 (18:02 +0100)]
netfilter: x_tables: validate e->target_offset early
commit
bdf533de6968e9686df777dc178486f600c6e617 upstream.
We should check that e->target_offset is sane before
mark_source_chains gets called since it will fetch the target entry
for loop detection.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ralf Baechle [Thu, 4 Feb 2016 00:24:40 +0000 (01:24 +0100)]
MIPS: Fix 64k page support for 32 bit kernels.
commit
d7de413475f443957a0c1d256e405d19b3a2cb22 upstream.
TASK_SIZE was defined as 0x7fff8000UL which for 64k pages is not a
multiple of the page size. Somewhere further down the math fails
such that executing an ELF binary fails.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Tested-by: Joshua Henderson <joshua.henderson@microchip.com>
Cc: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Sun, 29 May 2016 03:41:12 +0000 (20:41 -0700)]
sparc64: Fix return from trap window fill crashes.
[ Upstream commit
7cafc0b8bf130f038b0ec2dcdd6a9de6dc59b65a ]
We must handle data access exception as well as memory address unaligned
exceptions from return from trap window fill faults, not just normal
TLB misses.
Otherwise we can get an OOPS that looks like this:
ld-linux.so.2(36808): Kernel bad sw trap 5 [#1]
CPU: 1 PID: 36808 Comm: ld-linux.so.2 Not tainted 4.6.0 #34
task:
fff8000303be5c60 ti:
fff8000301344000 task.ti:
fff8000301344000
TSTATE:
0000004410001601 TPC:
0000000000a1a784 TNPC:
0000000000a1a788 Y:
00000002 Not tainted
TPC: <do_sparc64_fault+0x5c4/0x700>
g0:
fff8000024fc8248 g1:
0000000000db04dc g2:
0000000000000000 g3:
0000000000000001
g4:
fff8000303be5c60 g5:
fff800030e672000 g6:
fff8000301344000 g7:
0000000000000001
o0:
0000000000b95ee8 o1:
000000000000012b o2:
0000000000000000 o3:
0000000200b9b358
o4:
0000000000000000 o5:
fff8000301344040 sp:
fff80003013475c1 ret_pc:
0000000000a1a77c
RPC: <do_sparc64_fault+0x5bc/0x700>
l0:
00000000000007ff l1:
0000000000000000 l2:
000000000000005f l3:
0000000000000000
l4:
fff8000301347e98 l5:
fff8000024ff3060 l6:
0000000000000000 l7:
0000000000000000
i0:
fff8000301347f60 i1:
0000000000102400 i2:
0000000000000000 i3:
0000000000000000
i4:
0000000000000000 i5:
0000000000000000 i6:
fff80003013476a1 i7:
0000000000404d4c
I7: <user_rtt_fill_fixup+0x6c/0x7c>
Call Trace:
[
0000000000404d4c] user_rtt_fill_fixup+0x6c/0x7c
The window trap handlers are slightly clever, the trap table entries for them are
composed of two pieces of code. First comes the code that actually performs
the window fill or spill trap handling, and then there are three instructions at
the end which are for exception processing.
The userland register window fill handler is:
add %sp, STACK_BIAS + 0x00, %g1; \
ldxa [%g1 + %g0] ASI, %l0; \
mov 0x08, %g2; \
mov 0x10, %g3; \
ldxa [%g1 + %g2] ASI, %l1; \
mov 0x18, %g5; \
ldxa [%g1 + %g3] ASI, %l2; \
ldxa [%g1 + %g5] ASI, %l3; \
add %g1, 0x20, %g1; \
ldxa [%g1 + %g0] ASI, %l4; \
ldxa [%g1 + %g2] ASI, %l5; \
ldxa [%g1 + %g3] ASI, %l6; \
ldxa [%g1 + %g5] ASI, %l7; \
add %g1, 0x20, %g1; \
ldxa [%g1 + %g0] ASI, %i0; \
ldxa [%g1 + %g2] ASI, %i1; \
ldxa [%g1 + %g3] ASI, %i2; \
ldxa [%g1 + %g5] ASI, %i3; \
add %g1, 0x20, %g1; \
ldxa [%g1 + %g0] ASI, %i4; \
ldxa [%g1 + %g2] ASI, %i5; \
ldxa [%g1 + %g3] ASI, %i6; \
ldxa [%g1 + %g5] ASI, %i7; \
restored; \
retry; nop; nop; nop; nop; \
b,a,pt %xcc, fill_fixup_dax; \
b,a,pt %xcc, fill_fixup_mna; \
b,a,pt %xcc, fill_fixup;
And the way this works is that if any of those memory accesses
generate an exception, the exception handler can revector to one of
those final three branch instructions depending upon which kind of
exception the memory access took. In this way, the fault handler
doesn't have to know if it was a spill or a fill that it's handling
the fault for. It just always branches to the last instruction in
the parent trap's handler.
For example, for a regular fault, the code goes:
winfix_trampoline:
rdpr %tpc, %g3
or %g3, 0x7c, %g3
wrpr %g3, %tnpc
done
All window trap handlers are 0x80 aligned, so if we "or" 0x7c into the
trap time program counter, we'll get that final instruction in the
trap handler.
On return from trap, we have to pull the register window in but we do
this by hand instead of just executing a "restore" instruction for
several reasons. The largest being that from Niagara and onward we
simply don't have enough levels in the trap stack to fully resolve all
possible exception cases of a window fault when we are already at
trap level 1 (which we enter to get ready to return from the original
trap).
This is executed inline via the FILL_*_RTRAP handlers. rtrap_64.S's
code branches directly to these to do the window fill by hand if
necessary. Now if you look at them, we'll see at the end:
ba,a,pt %xcc, user_rtt_fill_fixup;
ba,a,pt %xcc, user_rtt_fill_fixup;
ba,a,pt %xcc, user_rtt_fill_fixup;
And oops, all three cases are handled like a fault.
This doesn't work because each of these trap types (data access
exception, memory address unaligned, and faults) store their auxiliary
info in different registers to pass on to the C handler which does the
real work.
So in the case where the stack was unaligned, the unaligned trap
handler sets up the arg registers one way, and then we branched to
the fault handler which expects them setup another way.
So the FAULT_TYPE_* value ends up basically being garbage, and
randomly would generate the backtrace seen above.
Reported-by: Nick Alcock <nix@esperi.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Sun, 29 May 2016 04:21:31 +0000 (21:21 -0700)]
sparc: Harden signal return frame checks.
[ Upstream commit
d11c2a0de2824395656cf8ed15811580c9dd38aa ]
All signal frames must be at least 16-byte aligned, because that is
the alignment we explicitly create when we build signal return stack
frames.
All stack pointers must be at least 8-byte aligned.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Wed, 25 May 2016 19:51:20 +0000 (12:51 -0700)]
sparc64: Take ctx_alloc_lock properly in hugetlb_setup().
[ Upstream commit
9ea46abe22550e3366ff7cee2f8391b35b12f730 ]
On cheetahplus chips we take the ctx_alloc_lock in order to
modify the TLB lookup parameters for the indexed TLBs, which
are stored in the context register.
This is called with interrupts disabled, however ctx_alloc_lock
is an IRQ safe lock, therefore we must take acquire/release it
properly with spin_{lock,unlock}_irq().
Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nitin Gupta [Wed, 30 Mar 2016 18:17:13 +0000 (11:17 -0700)]
sparc64: Reduce TLB flushes during hugepte changes
[ Upstream commit
24e49ee3d76b70853a96520e46b8837e5eae65b2 ]
During hugepage map/unmap, TSB and TLB flushes are currently
issued at every PAGE_SIZE'd boundary which is unnecessary.
We now issue the flush at REAL_HPAGE_SIZE boundaries only.
Without this patch workloads which unmap a large hugepage
backed VMA region get CPU lockups due to excessive TLB
flush calls.
Orabug:
22365539,
22643230,
22995196
Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Babu Moger [Thu, 24 Mar 2016 20:02:22 +0000 (13:02 -0700)]
sparc/PCI: Fix for panic while enabling SR-IOV
[ Upstream commit
d0c31e02005764dae0aab130a57e9794d06b824d ]
We noticed this panic while enabling SR-IOV in sparc.
mlx4_core: Mellanox ConnectX core driver v2.2-1 (Jan 1 2015)
mlx4_core: Initializing 0007:01:00.0
mlx4_core 0007:01:00.0: Enabling SR-IOV with 5 VFs
mlx4_core: Initializing 0007:01:00.1
Unable to handle kernel NULL pointer dereference
insmod(10010): Oops [#1]
CPU: 391 PID: 10010 Comm: insmod Not tainted
4.1.12-32.el6uek.kdump2.sparc64 #1
TPC: <dma_supported+0x20/0x80>
I7: <__mlx4_init_one+0x324/0x500 [mlx4_core]>
Call Trace:
[
00000000104c5ea4] __mlx4_init_one+0x324/0x500 [mlx4_core]
[
00000000104c613c] mlx4_init_one+0xbc/0x120 [mlx4_core]
[
0000000000725f14] local_pci_probe+0x34/0xa0
[
0000000000726028] pci_call_probe+0xa8/0xe0
[
0000000000726310] pci_device_probe+0x50/0x80
[
000000000079f700] really_probe+0x140/0x420
[
000000000079fa24] driver_probe_device+0x44/0xa0
[
000000000079fb5c] __device_attach+0x3c/0x60
[
000000000079d85c] bus_for_each_drv+0x5c/0xa0
[
000000000079f588] device_attach+0x88/0xc0
[
000000000071acd0] pci_bus_add_device+0x30/0x80
[
0000000000736090] virtfn_add.clone.1+0x210/0x360
[
00000000007364a4] sriov_enable+0x2c4/0x520
[
000000000073672c] pci_enable_sriov+0x2c/0x40
[
00000000104c2d58] mlx4_enable_sriov+0xf8/0x180 [mlx4_core]
[
00000000104c49ac] mlx4_load_one+0x42c/0xd40 [mlx4_core]
Disabling lock debugging due to kernel taint
Caller[
00000000104c5ea4]: __mlx4_init_one+0x324/0x500 [mlx4_core]
Caller[
00000000104c613c]: mlx4_init_one+0xbc/0x120 [mlx4_core]
Caller[
0000000000725f14]: local_pci_probe+0x34/0xa0
Caller[
0000000000726028]: pci_call_probe+0xa8/0xe0
Caller[
0000000000726310]: pci_device_probe+0x50/0x80
Caller[
000000000079f700]: really_probe+0x140/0x420
Caller[
000000000079fa24]: driver_probe_device+0x44/0xa0
Caller[
000000000079fb5c]: __device_attach+0x3c/0x60
Caller[
000000000079d85c]: bus_for_each_drv+0x5c/0xa0
Caller[
000000000079f588]: device_attach+0x88/0xc0
Caller[
000000000071acd0]: pci_bus_add_device+0x30/0x80
Caller[
0000000000736090]: virtfn_add.clone.1+0x210/0x360
Caller[
00000000007364a4]: sriov_enable+0x2c4/0x520
Caller[
000000000073672c]: pci_enable_sriov+0x2c/0x40
Caller[
00000000104c2d58]: mlx4_enable_sriov+0xf8/0x180 [mlx4_core]
Caller[
00000000104c49ac]: mlx4_load_one+0x42c/0xd40 [mlx4_core]
Caller[
00000000104c5f90]: __mlx4_init_one+0x410/0x500 [mlx4_core]
Caller[
00000000104c613c]: mlx4_init_one+0xbc/0x120 [mlx4_core]
Caller[
0000000000725f14]: local_pci_probe+0x34/0xa0
Caller[
0000000000726028]: pci_call_probe+0xa8/0xe0
Caller[
0000000000726310]: pci_device_probe+0x50/0x80
Caller[
000000000079f700]: really_probe+0x140/0x420
Caller[
000000000079fa24]: driver_probe_device+0x44/0xa0
Caller[
000000000079fb08]: __driver_attach+0x88/0xa0
Caller[
000000000079d90c]: bus_for_each_dev+0x6c/0xa0
Caller[
000000000079f29c]: driver_attach+0x1c/0x40
Caller[
000000000079e35c]: bus_add_driver+0x17c/0x220
Caller[
00000000007a02d4]: driver_register+0x74/0x120
Caller[
00000000007263fc]: __pci_register_driver+0x3c/0x60
Caller[
00000000104f62bc]: mlx4_init+0x60/0xcc [mlx4_core]
Kernel panic - not syncing: Fatal exception
Press Stop-A (L1-A) to return to the boot prom
---[ end Kernel panic - not syncing: Fatal exception
Details:
Here is the call sequence
virtfn_add->__mlx4_init_one->dma_set_mask->dma_supported
The panic happened at line 760(file arch/sparc/kernel/iommu.c)
758 int dma_supported(struct device *dev, u64 device_mask)
759 {
760 struct iommu *iommu = dev->archdata.iommu;
761 u64 dma_addr_mask = iommu->dma_addr_mask;
762
763 if (device_mask >= (1UL << 32UL))
764 return 0;
765
766 if ((device_mask & dma_addr_mask) == dma_addr_mask)
767 return 1;
768
769 #ifdef CONFIG_PCI
770 if (dev_is_pci(dev))
771 return pci64_dma_supported(to_pci_dev(dev), device_mask);
772 #endif
773
774 return 0;
775 }
776 EXPORT_SYMBOL(dma_supported);
Same panic happened with Intel ixgbe driver also.
SR-IOV code looks for arch specific data while enabling
VFs. When VF device is added, driver probe function makes set
of calls to initialize the pci device. Because the VF device is
added different way than the normal PF device(which happens via
of_create_pci_dev for sparc), some of the arch specific initialization
does not happen for VF device. That causes panic when archdata is
accessed.
To fix this, I have used already defined weak function
pcibios_setup_device to copy archdata from PF to VF.
Also verified the fix.
Signed-off-by: Babu Moger <babu.moger@oracle.com>
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Tue, 1 Mar 2016 05:25:32 +0000 (00:25 -0500)]
sparc64: Fix sparc64_set_context stack handling.
[ Upstream commit
397d1533b6cce0ccb5379542e2e6d079f6936c46 ]
Like a signal return, we should use synchronize_user_stack() rather
than flush_user_windows().
Reported-by: Ilya Malakhov <ilmalakhovthefirst@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nitin Gupta [Wed, 6 Jan 2016 06:35:35 +0000 (22:35 -0800)]
sparc64: Fix numa node distance initialization
[ Upstream commit
36beca6571c941b28b0798667608239731f9bc3a ]
Orabug:
22495713
Currently, NUMA node distance matrix is initialized only
when a machine descriptor (MD) exists. However, sun4u
machines (e.g. Sun Blade 2500) do not have an MD and thus
distance values were left uninitialized. The initialization
is now moved such that it happens on both sun4u and sun4v.
Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com>
Tested-by: Mikael Pettersson <mikpelinux@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Wed, 27 Apr 2016 21:27:37 +0000 (17:27 -0400)]
sparc64: Fix bootup regressions on some Kconfig combinations.
[ Upstream commit
49fa5230462f9f2c4e97c81356473a6bdf06c422 ]
The system call tracing bug fix mentioned in the Fixes tag
below increased the amount of assembler code in the sequence
of assembler files included by head_64.S
This caused to total set of code to exceed 0x4000 bytes in
size, which overflows the expression in head_64.S that works
to place swapper_tsb at address 0x408000.
When this is violated, the TSB is not properly aligned, and
also the trap table is not aligned properly either. All of
this together results in failed boots.
So, do two things:
1) Simplify some code by using ba,a instead of ba/nop to get
those bytes back.
2) Add a linker script assertion to make sure that if this
happens again the build will fail.
Fixes:
1a40b95374f6 ("sparc: Fix system call tracing register handling.")
Reported-by: Meelis Roos <mroos@linux.ee>
Reported-by: Joerg Abraham <joerg.abraham@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mike Frysinger [Mon, 18 Jan 2016 11:32:30 +0000 (06:32 -0500)]
sparc: Fix system call tracing register handling.
[ Upstream commit
1a40b95374f680625318ab61d81958e949e0afe3 ]
A system call trace trigger on entry allows the tracing
process to inspect and potentially change the traced
process's registers.
Account for that by reloading the %g1 (syscall number)
and %i0-%i5 (syscall argument) values. We need to be
careful to revalidate the range of %g1, and reload the
system call table entry it corresponds to into %l7.
Reported-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tested-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Wed, 8 Jun 2016 01:26:55 +0000 (21:26 -0400)]
fix d_walk()/non-delayed __d_free() race
commit
3d56c25e3bb0726a5c5e16fc2d9e38f8ed763085 upstream.
Ascend-to-parent logics in d_walk() depends on all encountered child
dentries not getting freed without an RCU delay. Unfortunately, in
quite a few cases it is not true, with hard-to-hit oopsable race as
the result.
Fortunately, the fix is simiple; right now the rule is "if it ever
been hashed, freeing must be delayed" and changing it to "if it
ever had a parent, freeing must be delayed" closes that hole and
covers all cases the old rule used to cover. Moreover, pipes and
sockets remain _not_ covered, so we do not introduce RCU delay in
the cases which are the reason for having that delay conditional
in the first place.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jann Horn [Wed, 1 Jun 2016 09:55:07 +0000 (11:55 +0200)]
sched: panic on corrupted stack end
commit
29d6455178a09e1dc340380c582b13356227e8df upstream.
Until now, hitting this BUG_ON caused a recursive oops (because oops
handling involves do_exit(), which calls into the scheduler, which in
turn raises an oops), which caused stuff below the stack to be
overwritten until a panic happened (e.g. via an oops in interrupt
context, caused by the overwritten CPU index in the thread_info).
Just panic directly.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jann Horn [Wed, 1 Jun 2016 09:55:05 +0000 (11:55 +0200)]
proc: prevent stacking filesystems on top
commit
e54ad7f1ee263ffa5a2de9c609d58dfa27b21cd9 upstream.
This prevents stacking filesystems (ecryptfs and overlayfs) from using
procfs as lower filesystem. There is too much magic going on inside
procfs, and there is no good reason to stack stuff on top of procfs.
(For example, procfs does access checks in VFS open handlers, and
ecryptfs by design calls open handlers from a kernel thread that doesn't
drop privileges or so.)
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Lutomirski [Tue, 24 May 2016 22:54:04 +0000 (15:54 -0700)]
x86/entry/traps: Don't force in_interrupt() to return true in IST handlers
commit
aaee8c3c5cce2d9107310dd9f3026b4f901d441c upstream.
Forcing in_interrupt() to return true if we're not in a bona fide
interrupt confuses the softirq code. This fixes warnings like:
NOHZ: local_softirq_pending 282
... which can happen when running things like selftests/x86.
This will change perf's static percpu buffer usage in IST context.
I think this is okay, and it's changing the behavior to match
historical (pre-4.0) behavior.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes:
959274753857 ("x86, traps: Track entry into and exit from IST context")
Link: http://lkml.kernel.org/r/cdc215f94d118d691d73df35275022331156fb45.1464130360.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prasun Maiti [Mon, 6 Jun 2016 14:34:19 +0000 (20:04 +0530)]
wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel
commit
3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724 upstream.
iwpriv app uses iw_point structure to send data to Kernel. The iw_point
structure holds a pointer. For compatibility Kernel converts the pointer
as required for WEXT IOCTLs (SIOCIWFIRST to SIOCIWLAST). Some drivers
may use iw_handler_def.private_args to populate iwpriv commands instead
of iw_handler_def.private. For those case, the IOCTLs from
SIOCIWFIRSTPRIV to SIOCIWLASTPRIV will follow the path ndo_do_ioctl().
Accordingly when the filled up iw_point structure comes from 32 bit
iwpriv to 64 bit Kernel, Kernel will not convert the pointer and sends
it to driver. So, the driver may get the invalid data.
The pointer conversion for the IOCTLs (SIOCIWFIRSTPRIV to
SIOCIWLASTPRIV), which follow the path ndo_do_ioctl(), is mandatory.
This patch adds pointer conversion from 32 bit to 64 bit and vice versa,
if the ioctl comes from 32 bit iwpriv to 64 bit Kernel.
Signed-off-by: Prasun Maiti <prasunmaiti87@gmail.com>
Signed-off-by: Ujjal Roy <royujjal@gmail.com>
Tested-by: Dibyajyoti Ghosh <dibyajyotig@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jann Horn [Wed, 1 Jun 2016 09:55:06 +0000 (11:55 +0200)]
ecryptfs: forbid opening files without mmap handler
commit
2f36db71009304b3f0b95afacd8eba1f9f046b87 upstream.
This prevents users from triggering a stack overflow through a recursive
invocation of pagefault handling that involves mapping procfs files into
virtual memory.
Signed-off-by: Jann Horn <jannh@google.com>
Acked-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Fri, 3 Jun 2016 21:55:44 +0000 (14:55 -0700)]
memcg: add RCU locking around css_for_each_descendant_pre() in memcg_offline_kmem()
commit
3a06bb78ceeceacc86a1e31133a7944013f9775b upstream.
memcg_offline_kmem() may be called from memcg_free_kmem() after a css
init failure. memcg_free_kmem() is a ->css_free callback which is
called without cgroup_mutex and memcg_offline_kmem() ends up using
css_for_each_descendant_pre() without any locking. Fix it by adding rcu
read locking around it.
mkdir: cannot create directory `65530': No space left on device
===============================
[ INFO: suspicious RCU usage. ]
4.6.0-work+ #321 Not tainted
-------------------------------
kernel/cgroup.c:4008 cgroup_mutex or RCU read lock required!
[ 527.243970] other info that might help us debug this:
[ 527.244715]
rcu_scheduler_active = 1, debug_locks = 0
2 locks held by kworker/0:5/1664:
#0: ("cgroup_destroy"){.+.+..}, at: [<
ffffffff81060ab5>] process_one_work+0x165/0x4a0
#1: ((&css->destroy_work)#3){+.+...}, at: [<
ffffffff81060ab5>] process_one_work+0x165/0x4a0
[ 527.248098] stack backtrace:
CPU: 0 PID: 1664 Comm: kworker/0:5 Not tainted 4.6.0-work+ #321
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
Workqueue: cgroup_destroy css_free_work_fn
Call Trace:
dump_stack+0x68/0xa1
lockdep_rcu_suspicious+0xd7/0x110
css_next_descendant_pre+0x7d/0xb0
memcg_offline_kmem.part.44+0x4a/0xc0
mem_cgroup_css_free+0x1ec/0x200
css_free_work_fn+0x49/0x5e0
process_one_work+0x1c5/0x4a0
worker_thread+0x49/0x490
kthread+0xea/0x100
ret_from_fork+0x1f/0x40
Link: http://lkml.kernel.org/r/20160526203018.GG23194@mtj.duckdns.org
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Sat, 4 Jun 2016 15:21:33 +0000 (17:21 +0200)]
parisc: Fix pagefault crash in unaligned __get_user() call
commit
8b78f260887df532da529f225c49195d18fef36b upstream.
One of the debian buildd servers had this crash in the syslog without
any other information:
Unaligned handler failed, ret = -2
clock_adjtime (pid 22578): Unaligned data reference (code 28)
CPU: 1 PID: 22578 Comm: clock_adjtime Tainted: G E 4.5.0-2-parisc64-smp #1 Debian 4.5.4-1
task:
000000007d9960f8 ti:
00000001bde7c000 task.ti:
00000001bde7c000
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW:
00001000000001001111100000001111 Tainted: G E
r00-03
000000ff0804f80f 00000001bde7c2b0 00000000402d2be8 00000001bde7c2b0
r04-07
00000000409e1fd0 00000000fa6f7fff 00000001bde7c148 00000000fa6f7fff
r08-11
0000000000000000 00000000ffffffff 00000000fac9bb7b 000000000002b4d4
r12-15
000000000015241c 000000000015242c 000000000000002d 00000000fac9bb7b
r16-19
0000000000028800 0000000000000001 0000000000000070 00000001bde7c218
r20-23
0000000000000000 00000001bde7c210 0000000000000002 0000000000000000
r24-27
0000000000000000 0000000000000000 00000001bde7c148 00000000409e1fd0
r28-31
0000000000000001 00000001bde7c320 00000001bde7c350 00000001bde7c218
sr00-03
0000000001200000 0000000001200000 0000000000000000 0000000001200000
sr04-07
0000000000000000 0000000000000000 0000000000000000 0000000000000000
IASQ:
0000000000000000 0000000000000000 IAOQ:
00000000402d2e84 00000000402d2e88
IIR:
0ca0d089 ISR:
0000000001200000 IOR:
00000000fa6f7fff
CPU: 1 CR30:
00000001bde7c000 CR31:
ffffffffffffffff
ORIG_R28:
00000002369fe628
IAOQ[0]: compat_get_timex+0x2dc/0x3c0
IAOQ[1]: compat_get_timex+0x2e0/0x3c0
RP(r2): compat_get_timex+0x40/0x3c0
Backtrace:
[<
00000000402d4608>] compat_SyS_clock_adjtime+0x40/0xc0
[<
0000000040205024>] syscall_exit+0x0/0x14
This means the userspace program clock_adjtime called the clock_adjtime()
syscall and then crashed inside the compat_get_timex() function.
Syscalls should never crash programs, but instead return EFAULT.
The IIR register contains the executed instruction, which disassebles
into "ldw 0(sr3,r5),r9".
This load-word instruction is part of __get_user() which tried to read the word
at %r5/IOR (0xfa6f7fff). This means the unaligned handler jumped in. The
unaligned handler is able to emulate all ldw instructions, but it fails if it
fails to read the source e.g. because of page fault.
The following program reproduces the problem:
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>
#include <sys/mman.h>
int main(void) {
/* allocate 8k */
char *ptr = mmap(NULL, 2*4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
/* free second half (upper 4k) and make it invalid. */
munmap(ptr+4096, 4096);
/* syscall where first int is unaligned and clobbers into invalid memory region */
/* syscall should return EFAULT */
return syscall(__NR_clock_adjtime, 0, ptr+4095);
}
To fix this issue we simply need to check if the faulting instruction address
is in the exception fixup table when the unaligned handler failed. If it
is, call the fixup routine instead of crashing.
While looking at the unaligned handler I found another issue as well: The
target register should not be modified if the handler was unsuccessful.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hongkun.cao [Sat, 21 May 2016 07:23:39 +0000 (15:23 +0800)]
pinctrl: mediatek: fix dual-edge code defect
commit
5edf673d07fdcb6498be24914f3f38f8d8843199 upstream.
When a dual-edge irq is triggered, an incorrect irq will be reported on
condition that the external signal is not stable and this incorrect irq
has been registered.
Correct the register offset.
Signed-off-by: Hongkun Cao <hongkun.cao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Huth [Tue, 31 May 2016 05:51:17 +0000 (07:51 +0200)]
powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call
commit
7cc851039d643a2ee7df4d18177150f2c3a484f5 upstream.
If we do not provide the PVR for POWER8NVL, a guest on this system
currently ends up in PowerISA 2.06 compatibility mode on KVM, since QEMU
does not provide a generic PowerISA 2.07 mode yet. So some new
instructions from POWER8 (like "mtvsrd") get disabled for the guest,
resulting in crashes when using code compiled explicitly for
POWER8 (e.g. with the "-mcpu=power8" option of GCC).
Fixes:
ddee09c099c3 ("powerpc: Add PVR for POWER8NVL processor")
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Huth [Thu, 12 May 2016 11:29:11 +0000 (13:29 +0200)]
powerpc: Use privileged SPR number for MMCR2
commit
8dd75ccb571f3c92c48014b3dabd3d51a115ab41 upstream.
We are already using the privileged versions of MMCR0, MMCR1
and MMCRA in the kernel, so for MMCR2, we should better use
the privileged versions, too, to be consistent.
Fixes:
240686c13687 ("powerpc: Initialise PMU related regs on Power8")
Suggested-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Huth [Thu, 12 May 2016 11:26:44 +0000 (13:26 +0200)]
powerpc: Fix definition of SIAR and SDAR registers
commit
d23fac2b27d94aeb7b65536a50d32bfdc21fe01e upstream.
The SIAR and SDAR registers are available twice, one time as SPRs
780 / 781 (unprivileged, but read-only), and one time as the SPRs
796 / 797 (privileged, but read and write). The Linux kernel code
currently uses the unprivileged SPRs - while this is OK for reading,
writing to that register of course does not work.
Since the KVM code tries to write to this register, too (see the mtspr
in book3s_hv_rmhandlers.S), the contents of this register sometimes get
lost for the guests, e.g. during migration of a VM.
To fix this issue, simply switch to the privileged SPR numbers instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell Currey [Thu, 7 Apr 2016 06:28:26 +0000 (16:28 +1000)]
powerpc/pseries/eeh: Handle RTAS delay requests in configure_bridge
commit
871e178e0f2c4fa788f694721a10b4758d494ce1 upstream.
In the "ibm,configure-pe" and "ibm,configure-bridge" RTAS calls, the
spec states that values of 9900-9905 can be returned, indicating that
software should delay for 10^x (where x is the last digit, i.e. 990x)
milliseconds and attempt the call again. Currently, the kernel doesn't
know about this, and respecting it fixes some PCI failures when the
hypervisor is busy.
The delay is capped at 0.2 seconds.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Tue, 7 Jun 2016 16:55:15 +0000 (17:55 +0100)]
arm64: mm: always take dirty state from new pte in ptep_set_access_flags
commit
0106d456c4cb1770253fefc0ab23c9ca760b43f7 upstream.
Commit
66dbd6e61a52 ("arm64: Implement ptep_set_access_flags() for
hardware AF/DBM") ensured that pte flags are updated atomically in the
face of potential concurrent, hardware-assisted updates. However, Alex
reports that:
| This patch breaks swapping for me.
| In the broken case, you'll see either systemd cpu time spike (because
| it's stuck in a page fault loop) or the system hang (because the
| application owning the screen is stuck in a page fault loop).
It turns out that this is because the 'dirty' argument to
ptep_set_access_flags is always 0 for read faults, and so we can't use
it to set PTE_RDONLY. The failing sequence is:
1. We put down a PTE_WRITE | PTE_DIRTY | PTE_AF pte
2. Memory pressure -> pte_mkold(pte) -> clear PTE_AF
3. A read faults due to the missing access flag
4. ptep_set_access_flags is called with dirty = 0, due to the read fault
5. pte is then made PTE_WRITE | PTE_DIRTY | PTE_AF | PTE_RDONLY (!)
6. A write faults, but pte_write is true so we get stuck
The solution is to check the new page table entry (as would be done by
the generic, non-atomic definition of ptep_set_access_flags that just
calls set_pte_at) to establish the dirty state.
Fixes:
66dbd6e61a52 ("arm64: Implement ptep_set_access_flags() for hardware AF/DBM")
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Alexander Graf <agraf@suse.de>
Tested-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Catalin Marinas [Tue, 31 May 2016 14:55:03 +0000 (15:55 +0100)]
arm64: Provide "model name" in /proc/cpuinfo for PER_LINUX32 tasks
commit
e47b020a323d1b2a7b1e9aac86e99eae19463630 upstream.
This patch brings the PER_LINUX32 /proc/cpuinfo format more in line with
the 32-bit ARM one by providing an additional line:
model name : ARMv8 Processor rev X (v8l)
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Lendacky [Fri, 20 May 2016 22:33:03 +0000 (17:33 -0500)]
crypto: ccp - Fix AES XTS error for request sizes above 4096
commit
ab6a11a7c8ef47f996974dd3c648c2c0b1a36ab1 upstream.
The ccp-crypto module for AES XTS support has a bug that can allow requests
greater than 4096 bytes in size to be passed to the CCP hardware. The CCP
hardware does not support request sizes larger than 4096, resulting in
incorrect output. The request should actually be handled by the fallback
mechanism instantiated by the ccp-crypto module.
Add a check to insure the request size is less than or equal to the maximum
supported size and use the fallback mechanism if it is not.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Wed, 18 May 2016 14:55:56 +0000 (16:55 +0200)]
crypto: public_key: select CRYPTO_AKCIPHER
commit
bad6a185b4d6f81d0ed2b6e4c16307969f160b95 upstream.
In some rare randconfig builds, we can end up with
ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER disabled,
which fails to link because of the reference to crypto_alloc_akcipher:
crypto/built-in.o: In function `public_key_verify_signature':
:(.text+0x110e4): undefined reference to `crypto_alloc_akcipher'
This adds a Kconfig 'select' statement to ensure the dependency
is always there.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Thu, 2 Jun 2016 08:00:28 +0000 (09:00 +0100)]
irqchip/gic-v3: Fix ICC_SGI1R_EL1.INTID decoding mask
commit
dd5f1b049dc139876801db3cdd0f20d21fd428cc upstream.
The INTID mask is wrong, and is made a signed value, which has
nteresting effects in the KVM emulation. Let's sanitize it.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Holzheu [Thu, 12 May 2016 16:10:48 +0000 (18:10 +0200)]
s390/bpf: reduce maximum program size to 64 KB
commit
0fa963553a5c28d8f8aabd8878326d3f782045fc upstream.
The s390 BFP compiler currently uses relative branch instructions
that only support jumps up to 64 KB. Examples are "j", "jnz", "cgrj",
etc. Currently the maximum size of s390 BPF programs is set
to 0x7ffff. If branches over 64 KB are generated the, kernel can
crash due to incorrect code.
So fix this an reduce the maximum size to 64 KB. Programs larger than
that will be interpreted.
Fixes:
ce2b6ad9c185 ("s390/bpf: increase BPF_SIZE_MAX")
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Holzheu [Wed, 11 May 2016 19:13:13 +0000 (21:13 +0200)]
s390/bpf: fix recache skb->data/hlen for skb_vlan_push/pop
commit
6edf0aa4f8bbdfbb4d6d786892fa02728d05dc36 upstream.
In case of usage of skb_vlan_push/pop, in the prologue we store
the SKB pointer on the stack and restore it after BPF_JMP_CALL
to skb_vlan_push/pop.
Unfortunately currently there are two bugs in the code:
1) The wrong stack slot (offset 170 instead of 176) is used
2) The wrong register (W1 instead of B1) is saved
So fix this and use correct stack slot and register.
Fixes:
9db7f2b81880 ("s390/bpf: recache skb->data/hlen for skb_vlan_push/pop")
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Dooks [Tue, 7 Jun 2016 16:22:17 +0000 (17:22 +0100)]
gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings
commit
b66b2a0adf0e48973b582e055758b9907a7eee7c upstream.
The bcm_kona_gpio_reset() calls bcm_kona_gpio_write_lock_regs()
with what looks like the wrong parameter. The write_lock_regs
function takes a pointer to the registers, not the bcm_kona_gpio
structure.
Fix the warning, and probably bug by changing the function to
pass reg_base instead of kona_gpio, fixing the following warning:
drivers/gpio/gpio-bcm-kona.c:550:47: warning: incorrect type in argument 1
(different address spaces)
expected void [noderef] <asn:2>*reg_base
got struct bcm_kona_gpio *kona_gpio
warning: incorrect type in argument 1 (different address spaces)
expected void [noderef] <asn:2>*reg_base
got struct bcm_kona_gpio *kona_gpio
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Mon, 30 May 2016 22:14:56 +0000 (23:14 +0100)]
ARM: fix PTRACE_SETVFPREGS on SMP systems
commit
e2dfb4b880146bfd4b6aa8e138c0205407cebbaf upstream.
PTRACE_SETVFPREGS fails to properly mark the VFP register set to be
reloaded, because it undoes one of the effects of vfp_flush_hwstate().
Specifically vfp_flush_hwstate() sets thread->vfpstate.hard.cpu to
an invalid CPU number, but vfp_set() overwrites this with the original
CPU number, thereby rendering the hardware state as apparently "valid",
even though the software state is more recent.
Fix this by reverting the previous change.
Fixes:
8130b9d7b9d8 ("ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers")
Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Torsten Hilbrich [Tue, 7 Jun 2016 11:14:21 +0000 (13:14 +0200)]
ALSA: hda/realtek: Add T560 docking unit fixup
commit
dab38e43b298501a4e8807b56117c029e2e98383 upstream.
Tested with Lenovo Ultradock. Fixes the non-working headphone jack on
the docking unit.
Signed-off-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
Tested-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kailang Yang [Mon, 30 May 2016 08:44:20 +0000 (16:44 +0800)]
ALSA: hda/realtek - Add support for new codecs ALC700/ALC701/ALC703
commit
6fbae35a3170c3e2b1b9d7b9cc943cbe48771362 upstream.
Support new codecs for ALC700/ALC701/ALC703.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kailang Yang [Mon, 30 May 2016 07:58:28 +0000 (15:58 +0800)]
ALSA: hda/realtek - ALC256 speaker noise issue
commit
e69e7e03ed225abf3e1c43545aa3bcb68dc81d5f upstream.
That is some different register for ALC255 and ALC256.
ALC256 can't fit with some ALC255 register.
This issue is cause from LDO output voltage control.
This patch is updated the right LDO register value.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AceLan Kao [Fri, 3 Jun 2016 06:45:25 +0000 (14:45 +0800)]
ALSA: hda - Fix headset mic detection problem for Dell machine
commit
f90d83b301701026b2e4c437a3613f377f63290e upstream.
Add the pin configuration value of this machine into the pin_quirk
table to make DELL1_MIC_NO_PRESENCE apply to this machine.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vinod Koul [Thu, 9 Jun 2016 06:02:14 +0000 (11:32 +0530)]
ALSA: hda - Add PCI ID for Kabylake
commit
35639a0e98391036a4c7f23253c321d6621a8897 upstream.
Kabylake shows up as PCI ID 0xa171. And Kabylake-LP as 0x9d71.
Since these are similar to Skylake add these to SKL_PLUS macro
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paolo Bonzini [Wed, 1 Jun 2016 12:09:21 +0000 (14:09 +0200)]
KVM: irqfd: fix NULL pointer dereference in kvm_irq_map_gsi
commit
c622a3c21ede892e370b56e1ceb9eb28f8bbda6b upstream.
Found by syzkaller:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000120
IP: [<
ffffffffa0797202>] kvm_irq_map_gsi+0x12/0x90 [kvm]
PGD
6f80b067 PUD
b6535067 PMD 0
Oops: 0000 [#1] SMP
CPU: 3 PID: 4988 Comm: a.out Not tainted 4.4.9-300.fc23.x86_64 #1
[...]
Call Trace:
[<
ffffffffa0795f62>] irqfd_update+0x32/0xc0 [kvm]
[<
ffffffffa0796c7c>] kvm_irqfd+0x3dc/0x5b0 [kvm]
[<
ffffffffa07943f4>] kvm_vm_ioctl+0x164/0x6f0 [kvm]
[<
ffffffff81241648>] do_vfs_ioctl+0x298/0x480
[<
ffffffff812418a9>] SyS_ioctl+0x79/0x90
[<
ffffffff817a1062>] tracesys_phase2+0x84/0x89
Code: b5 71 a7 e0 5b 41 5c 41 5d 5d f3 c3 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 8b 8f 10 2e 00 00 31 c0 48 89 e5 <39> 91 20 01 00 00 76 6a 48 63 d2 48 8b 94 d1 28 01 00 00 48 85
RIP [<
ffffffffa0797202>] kvm_irq_map_gsi+0x12/0x90 [kvm]
RSP <
ffff8800926cbca8>
CR2:
0000000000000120
Testcase:
#include <unistd.h>
#include <sys/syscall.h>
#include <string.h>
#include <stdint.h>
#include <linux/kvm.h>
#include <fcntl.h>
#include <sys/ioctl.h>
long r[26];
int main()
{
memset(r, -1, sizeof(r));
r[2] = open("/dev/kvm", 0);
r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
struct kvm_irqfd ifd;
ifd.fd = syscall(SYS_eventfd2, 5, 0);
ifd.gsi = 3;
ifd.flags = 2;
ifd.resamplefd = ifd.fd;
r[25] = ioctl(r[3], KVM_IRQFD, &ifd);
return 0;
}
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paolo Bonzini [Wed, 1 Jun 2016 12:09:23 +0000 (14:09 +0200)]
KVM: x86: fix OOPS after invalid KVM_SET_DEBUGREGS
commit
d14bdb553f9196169f003058ae1cdabe514470e6 upstream.
MOV to DR6 or DR7 causes a #GP if an attempt is made to write a 1 to
any of bits 63:32. However, this is not detected at KVM_SET_DEBUGREGS
time, and the next KVM_RUN oopses:
general protection fault: 0000 [#1] SMP
CPU: 2 PID: 14987 Comm: a.out Not tainted 4.4.9-300.fc23.x86_64 #1
Hardware name: LENOVO
2325F51/
2325F51, BIOS G2ET32WW (1.12 ) 05/30/2012
[...]
Call Trace:
[<
ffffffffa072c93d>] kvm_arch_vcpu_ioctl_run+0x141d/0x14e0 [kvm]
[<
ffffffffa071405d>] kvm_vcpu_ioctl+0x33d/0x620 [kvm]
[<
ffffffff81241648>] do_vfs_ioctl+0x298/0x480
[<
ffffffff812418a9>] SyS_ioctl+0x79/0x90
[<
ffffffff817a0f2e>] entry_SYSCALL_64_fastpath+0x12/0x71
Code: 55 83 ff 07 48 89 e5 77 27 89 ff ff 24 fd 90 87 80 81 0f 23 fe 5d c3 0f 23 c6 5d c3 0f 23 ce 5d c3 0f 23 d6 5d c3 0f 23 de 5d c3 <0f> 23 f6 5d c3 0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
RIP [<
ffffffff810639eb>] native_set_debugreg+0x2b/0x40
RSP <
ffff88005836bd50>
Testcase (beautified/reduced from syzkaller output):
#include <unistd.h>
#include <sys/syscall.h>
#include <string.h>
#include <stdint.h>
#include <linux/kvm.h>
#include <fcntl.h>
#include <sys/ioctl.h>
long r[8];
int main()
{
struct kvm_debugregs dr = { 0 };
r[2] = open("/dev/kvm", O_RDONLY);
r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7);
memcpy(&dr,
"\x5d\x6a\x6b\xe8\x57\x3b\x4b\x7e\xcf\x0d\xa1\x72"
"\xa3\x4a\x29\x0c\xfc\x6d\x44\x00\xa7\x52\xc7\xd8"
"\x00\xdb\x89\x9d\x78\xb5\x54\x6b\x6b\x13\x1c\xe9"
"\x5e\xd3\x0e\x40\x6f\xb4\x66\xf7\x5b\xe3\x36\xcb",
48);
r[7] = ioctl(r[4], KVM_SET_DEBUGREGS, &dr);
r[6] = ioctl(r[4], KVM_RUN, 0);
}
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Wragg [Fri, 3 Jun 2016 22:58:15 +0000 (18:58 -0400)]
vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices
[ Upstream commit
7e059158d57b79159eaf1f504825d19866ef2c42 ]
Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could
transmit vxlan packets of any size, constrained only by the ability to
send out the resulting packets. 4.3 introduced netdevs corresponding
to tunnel vports. These netdevs have an MTU, which limits the size of
a packet that can be successfully encapsulated. The default MTU
values are low (1500 or less), which is awkwardly small in the context
of physical networks supporting jumbo frames, and leads to a
conspicuous change in behaviour for userspace.
Instead, set the MTU on openvswitch-created netdevs to be the relevant
maximum (i.e. the maximum IP packet size minus any relevant overhead),
effectively restoring the behaviour prior to 4.3.
Signed-off-by: David Wragg <david@weave.works>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Wragg [Fri, 3 Jun 2016 22:58:14 +0000 (18:58 -0400)]
geneve: Relax MTU constraints
[ Upstream commit
55e5bfb53cff286c1c1ff49f51325dc15c7fea63 ]
Allow the MTU of geneve devices to be set to large values, in order to
exploit underlying networks with larger frame sizes.
GENEVE does not have a fixed encapsulation overhead (an openvswitch
rule can add variable length options), so there is no relevant maximum
MTU to enforce. A maximum of IP_MAX_MTU is used instead.
Encapsulated packets that are too big for the underlying network will
get dropped on the floor.
Signed-off-by: David Wragg <david@weave.works>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Wragg [Fri, 3 Jun 2016 22:58:13 +0000 (18:58 -0400)]
vxlan: Relax MTU constraints
[ Upstream commit
72564b59ffc438ea103b0727a921aaddce766728 ]
Allow the MTU of vxlan devices without an underlying device to be set
to larger values (up to a maximum based on IP packet limits and vxlan
overhead).
Previously, their MTUs could not be set to higher than the
conventional ethernet value of 1500. This is a very arbitrary value
in the context of vxlan, and prevented vxlan devices from being able
to take advantage of jumbo frames etc.
The default MTU remains 1500, for compatibility.
Signed-off-by: David Wragg <david@weave.works>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jakub Sitnicki [Wed, 8 Jun 2016 13:13:34 +0000 (15:13 +0200)]
ipv6: Skip XFRM lookup if dst_entry in socket cache is valid
[ Upstream commit
00bc0ef5880dc7b82f9c320dead4afaad48e47be ]
At present we perform an xfrm_lookup() for each UDPv6 message we
send. The lookup involves querying the flow cache (flow_cache_lookup)
and, in case of a cache miss, creating an XFRM bundle.
If we miss the flow cache, we can end up creating a new bundle and
deriving the path MTU (xfrm_init_pmtu) from on an already transformed
dst_entry, which we pass from the socket cache (sk->sk_dst_cache) down
to xfrm_lookup(). This can happen only if we're caching the dst_entry
in the socket, that is when we're using a connected UDP socket.
To put it another way, the path MTU shrinks each time we miss the flow
cache, which later on leads to incorrectly fragmented payload. It can
be observed with ESPv6 in transport mode:
1) Set up a transformation and lower the MTU to trigger fragmentation
# ip xfrm policy add dir out src ::1 dst ::1 \
tmpl src ::1 dst ::1 proto esp spi 1
# ip xfrm state add src ::1 dst ::1 \
proto esp spi 1 enc 'aes' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
# ip link set dev lo mtu 1500
2) Monitor the packet flow and set up an UDP sink
# tcpdump -ni lo -ttt &
# socat udp6-listen:12345,fork /dev/null &
3) Send a datagram that needs fragmentation with a connected socket
# perl -e 'print "@" x 1470 | socat - udp6:[::1]:12345
2016/06/07 18:52:52 socat[724] E read(3, 0x555bb3d5ba00, 8192): Protocol error
00:00:00.000000 IP6 ::1 > ::1: frag (0|1448) ESP(spi=0x00000001,seq=0x2), length 1448
00:00:00.000014 IP6 ::1 > ::1: frag (1448|32)
00:00:00.000050 IP6 ::1 > ::1: ESP(spi=0x00000001,seq=0x3), length 1272
(^ ICMPv6 Parameter Problem)
00:00:00.000022 IP6 ::1 > ::1: ESP(spi=0x00000001,seq=0x5), length 136
4) Compare it to a non-connected socket
# perl -e 'print "@" x 1500' | socat - udp6-sendto:[::1]:12345
00:00:40.535488 IP6 ::1 > ::1: frag (0|1448) ESP(spi=0x00000001,seq=0x6), length 1448
00:00:00.000010 IP6 ::1 > ::1: frag (1448|64)
What happens in step (3) is:
1) when connecting the socket in __ip6_datagram_connect(), we
perform an XFRM lookup, miss the flow cache, create an XFRM
bundle, and cache the destination,
2) afterwards, when sending the datagram, we perform an XFRM lookup,
again, miss the flow cache (due to mismatch of flowi6_iif and
flowi6_oif, which is an issue of its own), and recreate an XFRM
bundle based on the cached (and already transformed) destination.
To prevent the recreation of an XFRM bundle, avoid an XFRM lookup
altogether whenever we already have a destination entry cached in the
socket. This prevents the path MTU shrinkage and brings us on par with
UDPv4.
The fix also benefits connected PINGv6 sockets, another user of
ip6_sk_dst_lookup_flow(), who also suffer messages being transformed
twice.
Joint work with Hannes Frederic Sowa.
Reported-by: Jan Tluka <jtluka@redhat.com>
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Wed, 8 Jun 2016 10:59:17 +0000 (12:59 +0200)]
l2tp: fix configuration passed to setup_udp_tunnel_sock()
[ Upstream commit
a5c5e2da8551eb69e5d5d09d51d526140b5db9fb ]
Unused fields of udp_cfg must be all zeros. Otherwise
setup_udp_tunnel_sock() fills ->gro_receive and ->gro_complete
callbacks with garbage, eventually resulting in panic when used by
udp_gro_receive().
[ 72.694123] BUG: unable to handle kernel paging request at
ffff880033f87d78
[ 72.695518] IP: [<
ffff880033f87d78>] 0xffff880033f87d78
[ 72.696530] PGD
26e2067 PUD
26e3067 PMD
342ed063 PTE
8000000033f87163
[ 72.696530] Oops: 0011 [#1] SMP KASAN
[ 72.696530] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pptp gre pppox ppp_generic slhc crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel evdev aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper serio_raw acpi_cpufreq button proc\
essor ext4 crc16 jbd2 mbcache virtio_blk virtio_net virtio_pci virtio_ring virtio
[ 72.696530] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.7.0-rc1 #1
[ 72.696530] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[ 72.696530] task:
ffff880035b59700 ti:
ffff880035b70000 task.ti:
ffff880035b70000
[ 72.696530] RIP: 0010:[<
ffff880033f87d78>] [<
ffff880033f87d78>] 0xffff880033f87d78
[ 72.696530] RSP: 0018:
ffff880035f87bc0 EFLAGS:
00010246
[ 72.696530] RAX:
ffffed000698f996 RBX:
ffff88003326b840 RCX:
ffffffff814cc823
[ 72.696530] RDX:
ffff88003326b840 RSI:
ffff880033e48038 RDI:
ffff880034c7c780
[ 72.696530] RBP:
ffff880035f87c18 R08:
000000000000a506 R09:
0000000000000000
[ 72.696530] R10:
ffff880035f87b38 R11:
ffff880034b9344d R12:
00000000ebfea715
[ 72.696530] R13:
0000000000000000 R14:
ffff880034c7c780 R15:
0000000000000000
[ 72.696530] FS:
0000000000000000(0000) GS:
ffff880035f80000(0000) knlGS:
0000000000000000
[ 72.696530] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 72.696530] CR2:
ffff880033f87d78 CR3:
0000000033c98000 CR4:
00000000000406a0
[ 72.696530] Stack:
[ 72.696530]
ffffffff814cc834 ffff880034b93468 0000001481416818 ffff88003326b874
[ 72.696530]
ffff880034c7ccb0 ffff880033e48038 ffff88003326b840 ffff880034b93462
[ 72.696530]
ffff88003326b88a ffff88003326b88c ffff880034b93468 ffff880035f87c70
[ 72.696530] Call Trace:
[ 72.696530] <IRQ>
[ 72.696530] [<
ffffffff814cc834>] ? udp_gro_receive+0x1c6/0x1f9
[ 72.696530] [<
ffffffff814ccb1c>] udp4_gro_receive+0x2b5/0x310
[ 72.696530] [<
ffffffff814d989b>] inet_gro_receive+0x4a3/0x4cd
[ 72.696530] [<
ffffffff81431b32>] dev_gro_receive+0x584/0x7a3
[ 72.696530] [<
ffffffff810adf7a>] ? __lock_is_held+0x29/0x64
[ 72.696530] [<
ffffffff814321f7>] napi_gro_receive+0x124/0x21d
[ 72.696530] [<
ffffffffa000b145>] virtnet_receive+0x8df/0x8f6 [virtio_net]
[ 72.696530] [<
ffffffffa000b27e>] virtnet_poll+0x1d/0x8d [virtio_net]
[ 72.696530] [<
ffffffff81431350>] net_rx_action+0x15b/0x3b9
[ 72.696530] [<
ffffffff815893d6>] __do_softirq+0x216/0x546
[ 72.696530] [<
ffffffff81062392>] irq_exit+0x49/0xb6
[ 72.696530] [<
ffffffff81588e9a>] do_IRQ+0xe2/0xfa
[ 72.696530] [<
ffffffff81587a49>] common_interrupt+0x89/0x89
[ 72.696530] <EOI>
[ 72.696530] [<
ffffffff810b05df>] ? trace_hardirqs_on_caller+0x229/0x270
[ 72.696530] [<
ffffffff8102b3c7>] ? default_idle+0x1c/0x2d
[ 72.696530] [<
ffffffff8102b3c5>] ? default_idle+0x1a/0x2d
[ 72.696530] [<
ffffffff8102bb8c>] arch_cpu_idle+0xa/0xc
[ 72.696530] [<
ffffffff810a6c39>] default_idle_call+0x1a/0x1c
[ 72.696530] [<
ffffffff810a6d96>] cpu_startup_entry+0x15b/0x20f
[ 72.696530] [<
ffffffff81039a81>] start_secondary+0x12c/0x133
[ 72.696530] Code: ff ff ff ff ff ff ff ff ff ff 7f ff ff ff ff ff ff ff 7f 00 7e f8 33 00 88 ff ff 6d 61 58 81 ff ff ff ff 5e de 0a 81 ff ff ff ff <00> 5c e2 34 00 88 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 72.696530] RIP [<
ffff880033f87d78>] 0xffff880033f87d78
[ 72.696530] RSP <
ffff880035f87bc0>
[ 72.696530] CR2:
ffff880033f87d78
[ 72.696530] ---[ end trace
ad7758b9a1dccf99 ]---
[ 72.696530] Kernel panic - not syncing: Fatal exception in interrupt
[ 72.696530] Kernel Offset: disabled
[ 72.696530] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
v2: use empty initialiser instead of "{ NULL }" to avoid relying on
first field's type.
Fixes:
38fd2af24fcf ("udp: Add socket based GRO and config")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Toshiaki Makita [Tue, 7 Jun 2016 10:14:17 +0000 (19:14 +0900)]
bridge: Don't insert unnecessary local fdb entry on changing mac address
[ Upstream commit
0b148def403153a4d1565f1640356cb78ce5109f ]
The missing br_vlan_should_use() test caused creation of an unneeded
local fdb entry on changing mac address of a bridge device when there is
a vlan which is configured on a bridge port but not on the bridge
device.
Fixes:
2594e9064a57 ("bridge: vlan: add per-vlan struct and move to rhashtables")
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yuchung Cheng [Mon, 6 Jun 2016 22:07:18 +0000 (15:07 -0700)]
tcp: record TLP and ER timer stats in v6 stats
[ Upstream commit
ce3cf4ec0305919fc69a972f6c2b2efd35d36abc ]
The v6 tcp stats scan do not provide TLP and ER timer information
correctly like the v4 version . This patch fixes that.
Fixes:
6ba8a3b19e76 ("tcp: Tail loss probe (TLP)")
Fixes:
eed530b6c676 ("tcp: early retransmit")
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chen Haiquan [Fri, 27 May 2016 02:49:11 +0000 (10:49 +0800)]
vxlan: Accept user specified MTU value when create new vxlan link
[ Upstream commit
ce577668a426c6a9e2470a09dcd07fbd6e45272a ]
When create a new vxlan link, example:
ip link add vtap mtu 1440 type vxlan vni 1 dev eth0
The argument "mtu" has no effect, because it is not set to conf->mtu. The
default value is used in vxlan_dev_configure function.
This problem was introduced by commit
0dfbdf4102b9 (vxlan: Factor out device
configuration).
Fixes:
0dfbdf4102b9 (vxlan: Factor out device configuration)
Signed-off-by: Chen Haiquan <oc@yunify.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ivan Vecera [Wed, 25 May 2016 19:21:52 +0000 (21:21 +0200)]
team: don't call netdev_change_features under team->lock
[ Upstream commit
f6988cb63a4e698d8a62a1d085d263d1fcc351ea ]
The team_device_event() notifier calls team_compute_features() to fix
vlan_features under team->lock to protect team->port_list. The problem is
that subsequent __team_compute_features() calls netdev_change_features()
to propagate vlan_features to upper vlan devices while team->lock is still
taken. This can lead to deadlock when NETIF_F_LRO is modified on lower
devices or team device itself.
Example:
The team0 as active backup with eth0 and eth1 NICs. Both eth0 & eth1 are
LRO capable and LRO is enabled. Thus LRO is also enabled on team0.
The command 'ethtool -K team0 lro off' now hangs due to this deadlock:
dev_ethtool()
-> ethtool_set_features()
-> __netdev_update_features(team)
-> netdev_sync_lower_features()
-> netdev_update_features(lower_1)
-> __netdev_update_features(lower_1)
-> netdev_features_change(lower_1)
-> call_netdevice_notifiers(...)
-> team_device_event(lower_1)
-> team_compute_features(team) [TAKES team->lock]
-> netdev_change_features(team)
-> __netdev_update_features(team)
-> netdev_sync_lower_features()
-> netdev_update_features(lower_2)
-> __netdev_update_features(lower_2)
-> netdev_features_change(lower_2)
-> call_netdevice_notifiers(...)
-> team_device_event(lower_2)
-> team_compute_features(team) [DEADLOCK]
The bug is present in team from the beginning but it appeared after the commit
fd867d5 (net/core: generic support for disabling netdev features down stack)
that adds synchronization of features with lower devices.
Fixes:
fd867d5 (net/core: generic support for disabling netdev features down stack)
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>