OSDN Git Service
Roger Quadros [Mon, 9 Dec 2013 01:39:02 +0000 (18:39 -0700)]
ARM: OMAP3: hwmod data: Don't prevent RESET of USB Host module
commit
7f4d3641e2548d1ac5dee837ff434df668a2810c upstream.
Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.
RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM
Fixes:
de231388cb80 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3")
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei Ianovich [Tue, 10 Dec 2013 04:39:15 +0000 (08:39 +0400)]
ARM: pxa: prevent PXA270 occasional reboot freezes
commit
ff88b4724fde18056a4c539f7327389aec0f4c2d upstream.
Erratum 71 of PXA270M Processor Family Specification Update
(April 19, 2010) explains that watchdog reset time is just
8us insead of 10ms in EMTS.
If SDRAM is not reset, it causes memory bus congestion and
the device hangs. We put SDRAM in selfresh mode before watchdog
reset, removing potential freezes.
Without this patch PXA270-based ICP DAS LP-8x4x hangs after up to 40
reboots. With this patch it has successfully rebooted 500 times.
Signed-off-by: Sergei Ianovich <ynvich@gmail.com>
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Eremin-Solenikov [Sat, 16 Nov 2013 12:47:50 +0000 (16:47 +0400)]
ARM: pxa: tosa: fix keys mapping
commit
506cac15ac86f204b83e3cfccde73eeb4e7c5f34 upstream.
When converting from tosa-keyboard driver to matrix keyboard, tosa keys
received extra 1 column shift. Replace that with correct values to make
keyboard work again.
Fixes:
f69a6548c9d5 ('[ARM] pxa/tosa: make use of the matrix keypad driver')
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anssi Hannula [Tue, 10 Dec 2013 20:46:34 +0000 (22:46 +0200)]
ALSA: hda - hdmi: Fix IEC958 ctl indexes for some simple HDMI devices
commit
c9a6338aecdb92f9d015ecc26d203e54250bebbb upstream.
In case a single HDA card has both HDMI and S/PDIF outputs, the S/PDIF
outputs will have their IEC958 controls created starting from index 16
and the HDMI controls will be created starting from index 0.
However, HDMI simple_playback_build_controls() as used by old VIA and
NVIDIA codecs incorrectly requests the IEC958 controls to be created
with an S/PDIF type instead of HDMI.
In case the card has other codecs that have HDMI outputs, the controls
will be created with wrong index=16, causing them to e.g. be unreachable
by the ALSA "hdmi" alias.
Fix that by making simple_playback_build_controls() request controls
with HDMI indexes.
Not many cards have an affected configuration, but e.g. ASUS M3N78-VM
contains an integrated NVIDIA HDA "card" with:
- a VIA codec that has, among others, an S/PDIF pin incorrectly
labelled as an HDMI pin, and
- an NVIDIA MCP7x HDMI codec.
Reported-by: MysterX on #openelec
Tested-by: MysterX on #openelec
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 10 Dec 2013 16:33:49 +0000 (17:33 +0100)]
ALSA: hda - Mute all aamix inputs as default
commit
ebb93c057dda376414fbc499ad6ace9b527dff5a upstream.
Not all channels have been initialized, so far, especially when aamix
NID itself doesn't have amps but its leaves have. This patch fixes
these holes. Otherwise you might get unexpected loopback inputs,
e.g. from surround channels.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 10 Dec 2013 16:29:26 +0000 (17:29 +0100)]
ALSA: hda - Add static DAC/pin mapping for
AD1986A codec
commit
3690739b013504d33fe9348dd45f6b126aa370fb upstream.
AD1986A codec is a pretty old codec and has really many hidden
restrictions. One of such is that each DAC is dedicated to certain
pin although there are possible connections. Currently, the generic
parser tries to assign individual DACs as much as possible, and this
lead to two bad situations: connections where the sound actually
doesn't work, and connections conflicting other channels.
We may fix this by trying to find the best connections more harder,
but as of now, it's easier to give some hints for paired DAC/pin
connections and honor them if available, since such a hint is needed
only for specific codecs (right now only
AD1986A, and there will be
unlikely any others in future).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefano Panella [Tue, 10 Dec 2013 14:20:28 +0000 (14:20 +0000)]
ALSA: memalloc.h - fix wrong truncation of dma_addr_t
commit
932e9dec380c67ec15ac3eb073bb55797d8b4801 upstream.
When running a 32bit kernel the hda_intel driver is still reporting
a 64bit dma_mask if the HW supports it.
From sound/pci/hda/hda_intel.c:
/* allow 64bit DMA address if supported by H/W */
if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64)))
pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64));
else {
pci_set_dma_mask(pci, DMA_BIT_MASK(32));
pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32));
}
which means when there is a call to dma_alloc_coherent from
snd_malloc_dev_pages a machine address bigger than 32bit can be returned.
This can be true in particular if running the 32bit kernel as a pv dom0
under the Xen Hypervisor or PAE on bare metal.
The problem is that when calling setup_bdle to program the BLE the
dma_addr_t returned from the dma_alloc_coherent is wrongly truncated
from snd_sgbuf_get_addr if running a 32bit kernel:
static inline dma_addr_t snd_sgbuf_get_addr(struct snd_dma_buffer *dmab,
size_t offset)
{
struct snd_sg_buf *sgbuf = dmab->private_data;
dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr;
addr &= PAGE_MASK;
return addr + offset % PAGE_SIZE;
}
where PAGE_MASK in a 32bit kernel is zeroing the upper 32bit af addr.
Without this patch the HW will fetch the 32bit truncated address,
which is not the one obtained from dma_alloc_coherent and will result
to a non working audio but can corrupt host memory at a random location.
The current patch apply to
v3.13-rc3-74-g6c843f5
Signed-off-by: Stefano Panella <stefano.panella@citrix.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 10 Dec 2013 11:15:52 +0000 (12:15 +0100)]
ALSA: compress: Fix 64bit ABI incompatibility
commit
6733cf572a9e20db2b7580a5dd39d5782d571eec upstream.
snd_pcm_uframes_t is defined as unsigned long so it would take
different sizes depending on 32 or 64bit architectures. As we don't
want this ABI incompatibility, and there is no real 64bit user yet,
let's make it the fixed size with __u32.
Also bump the protocol version number to 0.1.2.
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mag [Mon, 26 Aug 2013 07:22:01 +0000 (00:22 -0700)]
Input: xpad - add signature for Razer Onza Classic Edition
commit
ed06349fe8d12dcb718984862b6e839fc8606c34 upstream.
Signed-off-by: Nol "Mag" Archinova <magissia@magissia.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jim Quinlan [Tue, 27 Aug 2013 20:57:51 +0000 (16:57 -0400)]
MIPS: DMA: For BMIPS5000 cores flush region just like non-coherent R10000
commit
f86f55d3ad21b21b736bdeb29bee0f0937b77138 upstream.
The BMIPS5000 (Zephyr) processor utilizes instruction speculation. A
stale misprediction address in either the JTB or the CRS may trigger
a prefetch inside a region that is currently being used by a DMA engine,
which is not IO-coherent. This prefetch will fetch a line into the
scache, and that line will soon become stale (ie wrong) during/after the
DMA. Mayhem ensues.
In dma-default.c, the r10000 is handled as a special case in the same way
that we want to handle Zephyr. So we generalize the exception cases into
a function, and include Zephyr as one of the processors that needs this
special care.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: cernekee@gmail.com
Patchwork: https://patchwork.linux-mips.org/patch/5776/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: John Ulvr <julvr@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 12 Dec 2013 06:36:44 +0000 (22:36 -0800)]
Linux 3.10.24
Tom Lendacky [Thu, 5 Dec 2013 19:09:53 +0000 (13:09 -0600)]
crypto: scatterwalk - Use sg_chain_ptr on chain entries
commit
389a5390583a18e45bc4abd4439291abec5e7a63 upstream.
Now that scatterwalk_sg_chain sets the chain pointer bit the sg_page
call in scatterwalk_sg_next hits a BUG_ON when CONFIG_DEBUG_SG is
enabled. Use sg_chain_ptr instead of sg_page on a chain entry.
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>
Arnaud Ebalard [Tue, 5 Nov 2013 20:45:48 +0000 (21:45 +0100)]
ARM: mvebu: second PCIe unit of Armada XP mv78230 is only x1 capable
commit
12b69a599745fc9e203f61fbb7160b2cc5f479dd upstream.
Various Marvell datasheets advertise second PCIe unit of mv78230
flavour of Armada XP as x4/quad x1 capable. This second unit is in
fact only x1 capable. This patch fixes current mv78230 .dtsi to
reflect that, i.e. makes 1.0 the second interface (instead of 2.0
at the moment). This was successfully tested on a mv78230-based
ReadyNAS 2120 platform with a x1 device (FL1009 XHCI controller)
connected to this second interface.
Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnaud Ebalard [Tue, 5 Nov 2013 20:46:02 +0000 (21:46 +0100)]
ARM: mvebu: fix second and third PCIe unit of Armada XP mv78260
commit
2163e61c92d9337e721a0d067d88ae62b52e0d3e upstream.
mv78260 flavour of Marvell Armada XP SoC has 3 PCIe units. The
two first units are both x4 and quad x1 capable. The third unit
is only x4 capable. This patch fixes mv78260 .dtsi to reflect
those capabilities.
Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Cox [Tue, 3 Dec 2013 21:56:56 +0000 (13:56 -0800)]
drivers/char/i8k.c: add Dell XPLS L421X
commit
9aa5b0181bdf335f0b731d8502e128a862884bcd upstream.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=60772
Signed-off-by: Alan Cox <alan@linux.intel.com>
Reported-by: Leho Kraav <leho@kraav.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Cluytens [Tue, 3 Dec 2013 13:18:57 +0000 (14:18 +0100)]
USB: cdc-acm: Added support for the Lenovo RD02-D400 USB Modem
commit
3b59d16c513da258ec8f6a0b4db85f257a0380d6 upstream.
Signed-off-by: David Cluytens <david.cluytens@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Leitner [Fri, 8 Nov 2013 21:53:11 +0000 (22:53 +0100)]
USB: spcp8x5: correct handling of CS5 setting
commit
711fbdfbf2bc4827214a650afe3f64767a1aba16 upstream.
This patch removes an erroneous check of CSIZE, which made it impossible to set
CS5.
Compiles clean, but couldn't test against hardware.
Signed-off-by: Colin Leitner <colin.leitner@gmail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Leitner [Fri, 8 Nov 2013 21:52:34 +0000 (22:52 +0100)]
USB: mos7840: correct handling of CS5 setting
commit
78692cc3382e0603a47e1f2aaeffe0d99891994d upstream.
This patch removes an erroneous check of CSIZE, which made it impossible to set
CS5.
Compiles clean, but couldn't test against hardware.
Signed-off-by: Colin Leitner <colin.leitner@gmail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Leitner [Tue, 5 Nov 2013 17:02:34 +0000 (18:02 +0100)]
USB: ftdi_sio: fixed handling of unsupported CSIZE setting
commit
8704211f65a2106ba01b6ac9727cdaf9ca11594c upstream.
FTDI UARTs support only 7 or 8 data bits. Until now the ftdi_sio driver would
only report this limitation for CS6 to dmesg and fail to reflect this fact to
tcgetattr.
This patch reverts the unsupported CSIZE setting and reports the fact with less
severance to dmesg for both CS5 and CS6.
To test the patch it's sufficient to call
stty -F /dev/ttyUSB0 cs5
which will succeed without the patch and report an error with the patch
applied.
As an additional fix this patch ensures that the control request will always
include a data bit size.
Signed-off-by: Colin Leitner <colin.leitner@gmail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Leitner [Mon, 4 Nov 2013 18:40:43 +0000 (19:40 +0100)]
USB: pl2303: fixed handling of CS5 setting
commit
a313249937820f8b1996133fc285efbd6aad2c5b upstream.
This patch fixes the CS5 setting on the PL2303 USB-to-serial devices. CS5 has a
value of 0 and the CSIZE setting has been skipped altogether by the enclosing
if. Tested on 3.11.6 and the scope shows the correct output after the fix has
been applied.
Tagged to be added to stable, because it fixes a user visible driver bug and is
simple enough to backport easily.
Signed-off-by: Colin Leitner <colin.leitner@gmail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomas Winkler [Thu, 5 Dec 2013 07:34:44 +0000 (09:34 +0200)]
mei: add 9 series PCH mei device ids
commit
76a9635979e543f04a5885198e68ff28e3311b67 upstream.
And Lynx Point H Refresh and Wildcat Point LP
device ids.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomas Winkler [Wed, 16 Oct 2013 09:09:43 +0000 (12:09 +0300)]
mei: me: add Lynx Point Wellsburg work station device id
commit
838b3a6d62413b336f3dde15ecff161070358957 upstream.
add missing device id for LPT based work station
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Gundersen [Thu, 31 Oct 2013 07:44:49 +0000 (00:44 -0700)]
Input: mousedev - allow disabling even without CONFIG_EXPERT
commit
dfaaed08ecc01bd513248ba7999daf50ce028352 upstream.
Moust (if not all) modern software, including X, uses /dev/eventX rather than
the legacy /dev/mouseX devices. It therefore makes sense for general-purpose
(distro) kernels to use MOUSEDV=m (or even n), so let's drop the EXPERT=y
requirement.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Gundersen [Thu, 31 Oct 2013 07:38:30 +0000 (00:38 -0700)]
Input: allow deselecting serio drivers even without CONFIG_EXPERT
commit
bcd2623073e98f69f84720308db0b142c4da0bd6 upstream.
There is plenty of consumer hardware (e.g., mac books) that does not use AT
keyboards or PS/2 mice. It therefore makes sense for distro kernels to
build the related drivers as modules to avoid loading them on hardware that
does not need them. As such, these options should no longer be protected by
EXPERT.
Moreover, building these drivers as modules gets rid of the following ugly
error during boot:
[ 2.337745] i8042: PNP: No PS/2 controller found. Probing ports directly.
[ 3.439537] i8042: No controller found
Signed-off-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joonyoung Shim [Wed, 11 Sep 2013 21:21:43 +0000 (14:21 -0700)]
lib/genalloc.c: fix overflow of ending address of memory chunk
commit
674470d97958a0ec72f72caf7f6451da40159cc7 upstream.
In struct gen_pool_chunk, end_addr means the end address of memory chunk
(inclusive), but in the implementation it is treated as address + size of
memory chunk (exclusive), so it points to the address plus one instead of
correct ending address.
The ending address of memory chunk plus one will cause overflow on the
memory chunk including the last address of memory map, e.g. when starting
address is 0xFFF00000 and size is 0x100000 on 32bit machine, ending
address will be 0x100000000.
Use correct ending address like starting address + size - 1.
[akpm@linux-foundation.org: add comment to struct gen_pool_chunk:end_addr]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AceLan Kao [Wed, 2 Oct 2013 09:35:27 +0000 (17:35 +0800)]
HID: usbhid: quirk for SiS Touchscreen
commit
684524d35fe8d13be1f2649633e43bd02c96c695 upstream.
BugLink: http://bugs.launchpad.net/bugs/1180881
This device needs to be added to the quirks list with HID_QUIRK_NO_INIT_REPORTS,
otherwise it causes 10 seconds timeout during report initialization.
[12431.828467] hid-multitouch 0003:0457:1013.0475: usb_submit_urb(ctrl) failed: -1
[12431.828507] hid-multitouch 0003:0457:1013.0475: timeout initializing reports
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AceLan Kao [Wed, 2 Oct 2013 09:35:26 +0000 (17:35 +0800)]
HID: usbhid: quirk for Synaptics Large Touchccreen
commit
8171a67d587a09e14a4949a81e070345fedcf410 upstream.
BugLink: http://bugs.launchpad.net/bugs/1180881
Synaptics large touchscreen doesn't support some of the report request
while initializing. The unspoorted request will make the device unreachable,
and will lead to the following usb_submit_urb() function call timeout.
So, add the IDs into HID_QUIRK_NO_INIT_REPORTS quirk.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ivan Vecera [Wed, 6 Nov 2013 13:02:36 +0000 (14:02 +0100)]
tg3: avoid double-freeing of rx data memory
commit
85aec73d595b8847f9c4ea571deb127913f0d508 upstream.
If build_skb fails the memory associated with the ring buffer is freed but
the ri->data member is not zeroed in this case. This causes a double-free
of this memory in tg3_free_rings->... path. The patch moves this block after
setting ri->data to NULL.
It would be nice to fix this bug also in stable >= v3.4 trees.
Cc: Nithin Nayak Sujir <nsujir@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Emmanuel Grumbach [Tue, 15 Oct 2013 19:04:54 +0000 (22:04 +0300)]
iwlwifi: dvm: don't override mac80211's queue setting
commit
f6b129527ca15bae29ffb9417ddaa1c9d99ffc5d upstream.
Since we set IEEE80211_HW_QUEUE_CONTROL, we can let
mac80211 do the queue assignement and don't need to
override its decisions.
While reassiging the same values is harmless of course,
it triggered a WARNING when iwlwifi and mac80211 came
to different conclusions. This happened when mac80211 set
IEEE80211_TX_CTL_SEND_AFTER_DTIM, but didn't route the
packet to the cab_queue because no stations were asleep.
iwlwifi should not override mac80211's decicions for
offchannel packets and packets to be sent after DTIM,
but it should override mac80211's decision for AMPDUs
since we have a special queue for them. So for AMPDU,
we still override info->hw_queue by the AMPDU queue.
This avoids:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2531 at drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
Modules linked in:
CPU: 0 PID: 2531 Comm: hostapd Not tainted 3.12.0-rc5+ #1
Hardware name: /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
0000000000000000 0000000000000009 ffffffff8189aa62 0000000000000000
ffffffff8105a4f2 ffff880058339a48 ffffffff815f8a04 0000000000000000
ffff8800560097b0 0000000000000208 0000000000000000 ffff8800561a9e5e
Call Trace:
[<
ffffffff8189aa62>] ? dump_stack+0x41/0x51
[<
ffffffff8105a4f2>] ? warn_slowpath_common+0x78/0x90
[<
ffffffff815f8a04>] ? iwlagn_tx_skb+0x6c5/0x883
[<
ffffffff815f8a04>] ? iwlagn_tx_skb+0x6c5/0x883
[<
ffffffff818a0040>] ? put_cred+0x15/0x15
[<
ffffffff815f6db4>] ? iwlagn_mac_tx+0x19/0x2f
[<
ffffffff8186cc45>] ? __ieee80211_tx+0x226/0x29b
[<
ffffffff8186e6bd>] ? ieee80211_tx+0xa6/0xb5
[<
ffffffff8186e98b>] ? ieee80211_monitor_start_xmit+0x1e9/0x204
[<
ffffffff8171ce5f>] ? dev_hard_start_xmit+0x271/0x3ec
[<
ffffffff817351ac>] ? sch_direct_xmit+0x66/0x164
[<
ffffffff8171d1bf>] ? dev_queue_xmit+0x1e5/0x3c8
[<
ffffffff817fac5a>] ? packet_sendmsg+0xac5/0xb3d
[<
ffffffff81709a09>] ? sock_sendmsg+0x37/0x52
[<
ffffffff810f9e0c>] ? __do_fault+0x338/0x36b
[<
ffffffff81713820>] ? verify_iovec+0x44/0x94
[<
ffffffff81709e63>] ? ___sys_sendmsg+0x1f1/0x283
[<
ffffffff81140a73>] ? __inode_wait_for_writeback+0x67/0xae
[<
ffffffff8111735e>] ? __cache_free.isra.46+0x178/0x187
[<
ffffffff811173b1>] ? kmem_cache_free+0x44/0x84
[<
ffffffff81132c22>] ? dentry_kill+0x13d/0x149
[<
ffffffff81132f6f>] ? dput+0xe5/0xef
[<
ffffffff81136e04>] ? fget_light+0x2e/0x7c
[<
ffffffff8170ae62>] ? __sys_sendmsg+0x39/0x57
[<
ffffffff818a7e39>] ? system_call_fastpath+0x16/0x1b
---[ end trace
1b3eb79359c1d1e6 ]---
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin K. Petersen [Wed, 23 Oct 2013 10:25:40 +0000 (06:25 -0400)]
SCSI: Disable WRITE SAME for RAID and virtual host adapter drivers
commit
54b2b50c20a61b51199bedb6e5d2f8ec2568fb43 upstream.
Some host adapters do not pass commands through to the target disk
directly. Instead they provide an emulated target which may or may not
accurately report its capabilities. In some cases the physical device
characteristics are reported even when the host adapter is processing
commands on the device's behalf. This can lead to adapter firmware hangs
or excessive I/O errors.
This patch disables WRITE SAME for devices connected to host adapters
that provide an emulated target. Driver writers can disable WRITE SAME
by setting the no_write_same flag in the host adapter template.
[jejb: fix up rejections due to eh_deadline patch]
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
H. Peter Anvin [Wed, 20 Nov 2013 21:31:49 +0000 (13:31 -0800)]
x86-64, build: Always pass in -mno-sse
commit
5551a34e5aeab868f8d37f70d8754868921b4ee5 upstream.
Always pass in the -mno-sse argument, regardless if
-preferred-stack-boundary is supported. We never want to generate SSE
instructions in the kernel unless we *really* know what we're doing.
According to H. J. Lu, any version of gcc new enough that we support
it at all should handle the -mno-sse option, so just add it
unconditionally.
Reported-by: Kevin B. Smith <kevin.b.smith@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: H. J. Lu <hjl.tools@gmail.com>
Link: http://lkml.kernel.org/n/tip-j21wzqv790q834n7yc6g80j1@git.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Landden [Mon, 25 Nov 2013 06:36:28 +0000 (22:36 -0800)]
net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST
commit
d3f7d56a7a4671d395e8af87071068a195257bf6 upstream.
Commit
35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
added an internal flag MSG_SENDPAGE_NOTLAST, similar to
MSG_MORE.
algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
and need to see the new flag as identical to MSG_MORE.
This fixes sendfile() on AF_ALG.
v3: also fix udp
Cc: Tom Herbert <therbert@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Reported-and-tested-by: Shawn Landden <shawnlandden@gmail.com>
Original-patch: Richard Weinberger <richard@nod.at>
Signed-off-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laxman Dewangan [Mon, 25 Nov 2013 14:09:47 +0000 (19:39 +0530)]
irq: Enable all irqs unconditionally in irq_resume
commit
ac01810c9d2814238f08a227062e66a35a0e1ea2 upstream.
When the system enters suspend, it disables all interrupts in
suspend_device_irqs(), including the interrupts marked EARLY_RESUME.
On the resume side things are different. The EARLY_RESUME interrupts
are reenabled in sys_core_ops->resume and the non EARLY_RESUME
interrupts are reenabled in the normal system resume path.
When suspend_noirq() failed or suspend is aborted for any other
reason, we might omit the resume side call to sys_core_ops->resume()
and therefor the interrupts marked EARLY_RESUME are not reenabled and
stay disabled forever.
To solve this, enable all irqs unconditionally in irq_resume()
regardless whether interrupts marked EARLY_RESUMEhave been already
enabled or not.
This might try to reenable already enabled interrupts in the non
failure case, but the only affected platform is XEN and it has been
confirmed that it does not cause any side effects.
[ tglx: Massaged changelog. ]
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by-and-tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Cc: <ian.campbell@citrix.com>
Cc: <rjw@rjwysocki.net>
Cc: <len.brown@intel.com>
Cc: <gregkh@linuxfoundation.org>
Link: http://lkml.kernel.org/r/1385388587-16442-1-git-send-email-ldewangan@nvidia.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hong Zhiguo [Wed, 20 Nov 2013 17:35:05 +0000 (10:35 -0700)]
Update of blkg_stat and blkg_rwstat may happen in bh context. While u64_stats_fetch_retry is only preempt_disable on 32bit UP system. This is not enough to avoid preemption by bh and may read strange 64 bit value.
commit
2c575026fae6e63771bd2a4c1d407214a8096a89 upstream.
Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matt Wilson [Wed, 20 Nov 2013 20:11:35 +0000 (12:11 -0800)]
xen/gnttab: leave lazy MMU mode in the case of a m2p override failure
commit
14883a75ec76b44759385fb12629f4a0f1aef4e3 upstream.
Commit
f62805f1 introduced a bug where lazy MMU mode isn't exited if a
m2p_add/remove_override call fails.
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Anthony Liguori <aliguori@amazon.com>
Signed-off-by: Matt Wilson <msw@amazon.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Wed, 20 Nov 2013 22:07:42 +0000 (23:07 +0100)]
parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
commit
0576da2c08e3d332f1b0653030d28ab804585ab6 upstream.
locale-gen on Debian showed a strange problem on parisc:
mmap2(NULL,
536870912, PROT_NONE, MAP_SHARED, 3, 0) = 0x42a54000
mmap2(0x42a54000, 103860, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)
Basically it was just trying to re-mmap() a file at the same address
which it was given by a previous mmap() call. But this remapping failed
with EINVAL.
The problem is, that when MAP_FIXED and MAP_SHARED flags were used, we didn't
included the mapping-based offset when we verified the alignment of the given
fixed address against the offset which we calculated it in the previous call.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liu Gang [Fri, 22 Nov 2013 08:12:40 +0000 (16:12 +0800)]
powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
commit
1aeef303b5d9e243c41d5b80f8bb059366514a10 upstream.
For MPC8572/MPC8536, the status of GPIOs defined as output
cannot be determined by reading GPDAT register, so the code
use shadow data register instead. But the code may give the
wrong status of GPIOs defined as input under some scenarios:
1. If some pins were configured as inputs and were asserted
high before booting the kernel, the shadow data has been
initialized with those pin values.
2. Some pins have been configured as output first and have
been set to the high value, then reconfigured as input.
The above cases will make the shadow data for those input
pins to be set to high. Then reading the pin status will
always return high even if the actual pin status is low.
The code should eliminate the effects of the shadow data to
the input pins, and the status of those pins should be
read directly from GPDAT.
Acked-by: Scott Wood <scottwood@freescale.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin Schwidefsky [Fri, 22 Nov 2013 19:44:51 +0000 (11:44 -0800)]
time: Fix 1ns/tick drift w/ GENERIC_TIME_VSYSCALL_OLD
commit
4be77398ac9d948773116b6be4a3c91b3d6ea18c upstream.
Since commit
1e75fa8be9f (time: Condense timekeeper.xtime
into xtime_sec - merged in v3.6), there has been an problem
with the error accounting in the timekeeping code, such that
when truncating to nanoseconds, we round up to the next nsec,
but the balancing adjustment to the ntp_error value was dropped.
This causes 1ns per tick drift forward of the clock.
In 3.7, this logic was isolated to only GENERIC_TIME_VSYSCALL_OLD
architectures (s390, ia64, powerpc).
The fix is simply to balance the accounting and to subtract the
added nanosecond from ntp_error. This allows the internal long-term
clock steering to keep the clock accurate.
While this fix removes the regression added in
1e75fa8be9f, the
ideal solution is to move away from GENERIC_TIME_VSYSCALL_OLD
and use the new VSYSCALL method, which avoids entirely the
nanosecond granular rounding, and the resulting short-term clock
adjustment oscillation needed to keep long term accurate time.
[ jstultz: Many thanks to Martin for his efforts identifying this
subtle bug, and providing the fix. ]
Originally-from: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Paul Turner <pjt@google.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1385149491-20307-1-git-send-email-john.stultz@linaro.org
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Tue, 19 Nov 2013 21:34:14 +0000 (16:34 -0500)]
NFSv4: Update list of irrecoverable errors on DELEGRETURN
commit
c97cf606e43b85a6cf158b810375dd77312024db upstream.
If the DELEGRETURN errors out with something like NFS4ERR_BAD_STATEID
then there is no recovery possible. Just quit without returning an error.
Also, note that the client must not assume that the NFSv4 lease has been
renewed when it sees an error on DELEGRETURN.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Thu, 28 Nov 2013 13:33:52 +0000 (14:33 +0100)]
net: smc91: fix crash regression on the versatile
commit
a0c20fb02592d372e744d1d739cda3e1b3defaae upstream.
After commit
e9e4ea74f06635f2ffc1dffe5ef40c854faa0a90
"net: smc91x: dont't use SMC_outw for fixing up halfword-aligned data"
The Versatile SMSC LAN91C111 is crashing like this:
------------[ cut here ]------------
kernel BUG at /home/linus/linux/drivers/net/ethernet/smsc/smc91x.c:599!
Internal error: Oops - BUG: 0 [#1] ARM
Modules linked in:
CPU: 0 PID: 43 Comm: udhcpc Not tainted 3.13.0-rc1+ #24
task:
c6ccfaa0 ti:
c6cd0000 task.ti:
c6cd0000
PC is at smc_hardware_send_pkt+0x198/0x22c
LR is at smc_hardware_send_pkt+0x24/0x22c
pc : [<
c01be324>] lr : [<
c01be1b0>] psr:
20000013
sp :
c6cd1d08 ip :
00000001 fp :
00000000
r10:
c02adb08 r9 :
00000000 r8 :
c6ced802
r7 :
c786fba0 r6 :
00000146 r5 :
c8800000 r4 :
c78d6000
r3 :
0000000f r2 :
00000146 r1 :
00000000 r0 :
00000031
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control:
0005317f Table:
06cf4000 DAC:
00000015
Process udhcpc (pid: 43, stack limit = 0xc6cd01c0)
Stack: (0xc6cd1d08 to 0xc6cd2000)
1d00:
00000010 c8800000 c78d6000 c786fba0 c78d6000 c01be868
1d20:
c01be7a4 00004000 00000000 c786fba0 c6c12b80 c0208554 000004d0 c780fc60
1d40:
00000220 c01fb734 00000000 00000000 00000000 c6c9a440 c6c12b80 c78d6000
1d60:
c786fba0 c6c9a440 00000000 c021d1d8 00000000 00000000 c6c12b80 c78d6000
1d80:
c786fba0 00000001 c6c9a440 c02087f8 c6c9a4a0 00080008 00000000 00000000
1da0:
c78d6000 c786fba0 c78d6000 00000138 00000000 00000000 00000000 00000000
1dc0:
00000000 c027ba74 00000138 00000138 00000001 00000010 c6cedc00 00000000
1de0:
00000008 c7404400 c6cd1eec c6cd1f14 c067a73c c065c0b8 00000000 c067a740
1e00:
01ffffff 002040d0 00000000 00000000 00000000 00000000 00000000 ffffffff
1e20:
43004400 00110022 c6cdef20 c027ae8c c6ccfaa0 be82d65c 00000014 be82d3cc
1e40:
00000000 00000000 00000000 c01f2870 00000000 00000000 00000000 c6cd1e88
1e60:
c6ccfaa0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1e80:
00000000 00000000 00000031 c7802310 c7802300 00000138 c7404400 c0771da0
1ea0:
00000000 c6cd1eec c7800340 00000138 be82d65c 00000014 be82d3cc c6cd1f08
1ec0:
00000014 00000000 c7404400 c7404400 00000138 c01f4628 c78d6000 00000000
1ee0:
00000000 be82d3cc 00000138 c6cd1f08 00000014 c6cd1ee4 00000001 00000000
1f00:
00000000 00000000 00080011 00000002 06000000 ffffffff 0000ffff 00000002
1f20:
06000000 ffffffff 0000ffff c00928c8 c065c520 c6cd1f58 00000003 c009299c
1f40:
00000003 c065c520 c7404400 00000000 c7404400 c01f2218 c78106b0 c7441cb0
1f60:
00000000 00000006 c06799fc 00000000 00000000 00000006 00000000 c01f3ee0
1f80:
00000000 00000000 be82d678 be82d65c 00000014 00000001 00000122 c00139c8
1fa0:
c6cd0000 c0013840 be82d65c 00000014 00000006 be82d3cc 00000138 00000000
1fc0:
be82d65c 00000014 00000001 00000122 00000000 00000000 00018cb1 00000000
1fe0:
00003801 be82d3a8 0003a0c7 b6e9af08 60000010 00000006 00000000 00000000
[<
c01be324>] (smc_hardware_send_pkt+0x198/0x22c) from [<
c01be868>] (smc_hard_start_xmit+0xc4/0x1e8)
[<
c01be868>] (smc_hard_start_xmit+0xc4/0x1e8) from [<
c0208554>] (dev_hard_start_xmit+0x460/0x4cc)
[<
c0208554>] (dev_hard_start_xmit+0x460/0x4cc) from [<
c021d1d8>] (sch_direct_xmit+0x94/0x18c)
[<
c021d1d8>] (sch_direct_xmit+0x94/0x18c) from [<
c02087f8>] (dev_queue_xmit+0x238/0x42c)
[<
c02087f8>] (dev_queue_xmit+0x238/0x42c) from [<
c027ba74>] (packet_sendmsg+0xbe8/0xd28)
[<
c027ba74>] (packet_sendmsg+0xbe8/0xd28) from [<
c01f2870>] (sock_sendmsg+0x84/0xa8)
[<
c01f2870>] (sock_sendmsg+0x84/0xa8) from [<
c01f4628>] (SyS_sendto+0xb8/0xdc)
[<
c01f4628>] (SyS_sendto+0xb8/0xdc) from [<
c0013840>] (ret_fast_syscall+0x0/0x2c)
Code:
e3130002 1a000001 e3130001 0affffcd (
e7f001f2)
---[ end trace
81104fe70e8da7fe ]---
Kernel panic - not syncing: Fatal exception in interrupt
This is because the macro operations in smc91x.h defined
for Versatile are missing SMC_outsw() as used in this
commit.
The Versatile needs and uses the same accessors as the other
platforms in the first if(...) clause, just switch it to using
that and we have one problem less to worry about.
This includes a hunk of a patch from Will Deacon fixin
the other 32bit platforms as well: Innokom, Ramses, PXA,
PCM027.
Checkpatch complains about spacing, but I have opted to
follow the style of this .h-file.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen M. Cameron [Fri, 1 Nov 2013 16:02:25 +0000 (11:02 -0500)]
SCSI: hpsa: return 0 from driver probe function on success, not 1
commit
88bf6d62db4393fa03a58bada9d746312d5b496f upstream.
A return value of 1 is interpreted as an error. See pci_driver.
in local_pci_probe(). If you're wondering how this ever could
have worked, it's because it used to be the case that only return
values less than zero were interpreted as failure. But even in
the current kernel if the driver registers its various entry
points with the kernel, and then returns a value which is
interpreted as failure, those registrations aren't undone, so
the driver still mostly works. However, the driver's remove
function wouldn't be called on rmmod, and pci power management
functions wouldn't work. In the case of Smart Array, since it
has a battery backed cache (or else no cache) even if the driver
is not shut down properly as long as there is no outstanding
i/o, nothing too bad happens, which is why it took so long to
notice.
Requesting backport to stable because the change to pci-driver.c
which requires driver probe functions to return 0 occurred between
2.6.35 and 2.6.36 (the pci power management breakage) and again
between 3.7 and 3.8 (pci_dev->driver getting set to NULL in
local_pci_probe() preventing driver remove function from being
called on rmmod.)
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen M. Cameron [Mon, 23 Sep 2013 18:33:41 +0000 (13:33 -0500)]
SCSI: hpsa: do not discard scsi status on aborted commands
commit
2e311fbabdc23b7eaec77313dc3b9a151a5407b5 upstream.
We inadvertantly discarded the scsi status for aborted commands.
For some commands (e.g. reads from tape drives) these can't be retried,
and if we discarded the scsi status, the scsi mid layer couldn't notice
anything was wrong and the error was not reported.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Williams [Wed, 23 Oct 2013 01:35:19 +0000 (18:35 -0700)]
SCSI: libsas: fix usage of ata_tf_to_fis
commit
ae5fbae0ccd982dfca0ce363036ed92f5b13f150 upstream.
Since commit
110dd8f19df5 "[SCSI] libsas: fix scr_read/write users and
update the libata documentation" we have been passing pmp=1 and is_cmd=0
to ata_tf_to_fis(). Praveen reports that eSATA attached drives do not
discover correctly. His investigation found that the BIOS was passing
pmp=0 while Linux was passing pmp=1 and failing to discover the drives.
Update libsas to follow the libata example of pulling the pmp setting
from the ata_link and correct is_cmd to be 1 since all tf's submitted
through ->qc_issue are commands. Presumably libsas lldds do not care
about is_cmd as they have sideband mechanisms to perform link
management.
http://marc.info/?l=linux-scsi&m=
138179681726990
[jejb: checkpatch fix]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reported-by: Praveen Murali <pmurali@logicube.com>
Tested-by: Praveen Murali <pmurali@logicube.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Bottomley [Fri, 15 Nov 2013 22:58:00 +0000 (14:58 -0800)]
SCSI: enclosure: fix WARN_ON in dual path device removing
commit
a1470c7bf3a4676e62e4c0fb204e339399eb5c59 upstream.
Bug report from: wenxiong@linux.vnet.ibm.com
The issue is happened in dual controller configuration. We got the
sysfs warnings when rmmod the ipr module.
enclosure_unregister() in drivers/msic/enclosure.c, call device_unregister()
for each componment deivce, device_unregister() ->device_del()->kobject_del()
->sysfs_remove_dir(). In sysfs_remove_dir(), set kobj->sd = NULL.
For each componment device,
enclosure_component_release()->enclosure_remove_links()->sysfs_remove_link()
in which checking kobj->sd again, it has been set as NULL when doing
device_unregister. So we saw all these sysfs WARNING.
Tested-by: wenxiong@linux.vnet.ibm.com
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vijaya Mohan Guvva [Thu, 21 Nov 2013 09:37:49 +0000 (01:37 -0800)]
SCSI: bfa: Fix crash when symb name set for offline vport
commit
22a08538dca5c0630226f1c0c58dccd12e463d22 upstream.
This patch fixes a crash when tried setting symbolic name for an offline
vport through sysfs. Crash is due to uninitialized pointer lport->ns,
which gets initialized only on linkup (port online).
Signed-off-by: Vijaya Mohan Guvva <vmohan@brocade.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Kleine-Budde [Sun, 24 Nov 2013 22:31:24 +0000 (23:31 +0100)]
can: c_can: don't call pm_runtime_get_sync() from interrupt context
commit
e35d46adc49b469fd92bdb64fea8af93640e6651 upstream.
The c_can driver contians a callpath (c_can_poll -> c_can_state_change ->
c_can_get_berr_counter) which may call pm_runtime_get_sync() from the IRQ
handler, which is not allowed and results in "BUG: scheduling while atomic".
This problem is fixed by introducing __c_can_get_berr_counter, which will not
call pm_runtime_get_sync().
Reported-by: Andrew Glen <AGlen@bepmarine.com>
Tested-by: Andrew Glen <AGlen@bepmarine.com>
Signed-off-by: Andrew Glen <AGlen@bepmarine.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oliver Hartkopp [Thu, 21 Nov 2013 17:03:07 +0000 (18:03 +0100)]
can: sja1000: fix {pre,post}_irq() handling and IRQ handler return value
commit
2fea6cd303c0d0cd9067da31d873b6a6d5bd75e7 upstream.
This patch fixes the issue that the sja1000_interrupt() function may have
returned IRQ_NONE without processing the optional pre_irq() and post_irq()
function before. Further the irq processing counter 'n' is moved to the end of
the while statement to return correct IRQ_[NONE|HANDLED] values at error
conditions.
Reported-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Mon, 2 Dec 2013 17:44:51 +0000 (09:44 -0800)]
vfs: fix subtle use-after-free of pipe_inode_info
commit
b0d8d2292160bb63de1972361ebed100c64b5b37 upstream.
The pipe code was trying (and failing) to be very careful about freeing
the pipe info only after the last access, with a pattern like:
spin_lock(&inode->i_lock);
if (!--pipe->files) {
inode->i_pipe = NULL;
kill = 1;
}
spin_unlock(&inode->i_lock);
__pipe_unlock(pipe);
if (kill)
free_pipe_info(pipe);
where the final freeing is done last.
HOWEVER. The above is actually broken, because while the freeing is
done at the end, if we have two racing processes releasing the pipe
inode info, the one that *doesn't* free it will decrement the ->files
count, and unlock the inode i_lock, but then still use the
"pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)".
This is *very* hard to trigger in practice, since the race window is
very small, and adding debug options seems to just hide it by slowing
things down.
Simon originally reported this way back in July as an Oops in
kmem_cache_allocate due to a single bit corruption (due to the final
"spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different
allocation that had re-used the free'd pipe-info), it's taken this long
to figure out.
Since the 'pipe->files' accesses aren't even protected by the pipe lock
(we very much use the inode lock for that), the simple solution is to
just drop the pipe lock early. And since there were two users of this
pattern, create a helper function for it.
Introduced commit
ba5bb147330a ("pipe: take allocation and freeing of
pipe_inode_info out of ->i_mutex").
Reported-by: Simon Kirby <sim@hostway.ca>
Reported-by: Ian Applegate <ia@cloudflare.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bo Shen [Tue, 3 Dec 2013 10:04:54 +0000 (18:04 +0800)]
ASoC: wm8731: fix dsp mode configuration
commit
b4af6ef99a60c5b56df137d7accd81ba1ee1254e upstream.
According to WM8731 "PD, Rev 4.9 October 2012" datasheet, when it
works in DSP mode A, LRP = 1, while works in DSP mode B, LRP = 0.
So, fix LRP for DSP mode as the datesheet specification.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Brown [Fri, 22 Nov 2013 14:17:18 +0000 (14:17 +0000)]
ASoC: wm8990: Mark the register map as dirty when powering down
commit
2ab2b74277a86afe0dd92976db695a2bb8b93366 upstream.
Otherwise we'll skip sync on resume.
Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gregory CLEMENT [Mon, 25 Nov 2013 16:26:46 +0000 (17:26 +0100)]
ARM: mvebu: use the virtual CPU registers to access coherency registers
commit
b6dda00cddcc71d2030668bc0cc0fed758c411c2 upstream.
The Armada XP provides a mechanism called "virtual CPU registers" or
"per-CPU register banking", to access the per-CPU registers of the
current CPU, without having to worry about finding on which CPU we're
running. CPU0 has its registers at 0x21800, CPU1 at 0x21900, CPU2 at
0x21A00 and CPU3 at 0x21B00. The virtual registers accessing the
current CPU registers are at 0x21000.
However, in the Device Tree node that provides the register addresses
for the coherency unit (which is responsible for ensuring coherency
between processors, and I/O coherency between processors and the
DMA-capable devices), a mistake was made: the CPU0-specific registers
were specified instead of the virtual CPU registers. This means that
the coherency barrier needed for I/O coherency was not behaving
properly when executed from a CPU different from CPU0. This patch
fixes that by using the virtual CPU registers.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes:
e60304f8cb7bb5 "arm: mvebu: Add hardware I/O Coherency support"
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ludovic Desroches [Fri, 22 Nov 2013 16:08:43 +0000 (17:08 +0100)]
ARM: at91: sama5d3: reduce TWI internal clock frequency
commit
58e7b1d5826ac6a64b1101d8a70162bc084a7d1e upstream.
With some devices, transfer hangs during I2C frame transmission. This issue
disappears when reducing the internal frequency of the TWI IP. Even if it is
indicated that internal clock max frequency is 66MHz, it seems we have
oversampling on I2C signals making TWI believe that a transfer in progress
is done.
This fix has no impact on the I2C bus frequency.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Fri, 29 Nov 2013 00:54:38 +0000 (00:54 +0000)]
ARM: footbridge: fix EBSA285 LEDs
commit
67130c5464f50428aea0b4526a6729d61f9a1d53 upstream.
- The LEDs register is write-only: it can't be read-modify-written.
- The LEDs are write-1-for-off not 0.
- The check for the platform was inverted.
Fixes:
cf6856d693dd ("ARM: mach-footbridge: retire custom LED code")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Thu, 28 Nov 2013 21:55:41 +0000 (21:55 +0000)]
ARM: footbridge: fix VGA initialisation
commit
43659222e7a0113912ed02f6b2231550b3e471ac upstream.
It's no good setting vga_base after the VGA console has been
initialised, because if we do that we get this:
Unable to handle kernel paging request at virtual address
000b8000
pgd =
c0004000
[
000b8000] *pgd=
07ffc831, *pte=
00000000, *ppte=
00000000
0Internal error: Oops: 5017 [#1] ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0+ #49
task:
c03e2974 ti:
c03d8000 task.ti:
c03d8000
PC is at vgacon_startup+0x258/0x39c
LR is at request_resource+0x10/0x1c
pc : [<
c01725d0>] lr : [<
c0022b50>] psr:
60000053
sp :
c03d9f68 ip :
000b8000 fp :
c03d9f8c
r10:
000055aa r9 :
4401a103 r8 :
ffffaa55
r7 :
c03e357c r6 :
c051b460 r5 :
000000ff r4 :
000c0000
r3 :
000b8000 r2 :
c03e0514 r1 :
00000000 r0 :
c0304971
Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
which is an access to the 0xb8000 without the PCI offset required to
make it work.
Fixes:
cc22b4c18540 ("ARM: set vga memory base at run-time")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Thu, 28 Nov 2013 21:43:40 +0000 (21:43 +0000)]
ARM: fix booting low-vectors machines
commit
d8aa712c30148ba26fd89a5dc14de95d4c375184 upstream.
Commit
f6f91b0d9fd9 (ARM: allow kuser helpers to be removed from the
vector page) required two pages for the vectors code. Although the
code setting up the initial page tables was updated, the code which
allocates page tables for new processes wasn't, neither was the code
which tears down the mappings. Fix this.
Fixes:
f6f91b0d9fd9 ("ARM: allow kuser helpers to be removed from the vector page")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Lendacky [Tue, 12 Nov 2013 17:46:04 +0000 (11:46 -0600)]
crypto: authenc - Find proper IV address in ablkcipher callback
commit
fc019c7122dfcd69c50142b57a735539aec5da95 upstream.
When performing an asynchronous ablkcipher operation the authenc
completion callback routine is invoked, but it does not locate and use
the proper IV.
The callback routine, crypto_authenc_encrypt_done, is updated to use
the same method of calculating the address of the IV as is done in
crypto_authenc_encrypt function which sets up the callback.
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>
Horia Geanta [Thu, 28 Nov 2013 13:11:15 +0000 (15:11 +0200)]
crypto: ccm - Fix handling of zero plaintext when computing mac
commit
5638cabf3e4883f38dfb246c30980cebf694fbda upstream.
There are cases when cryptlen can be zero in crypto_ccm_auth():
-encryptiom: input scatterlist length is zero (no plaintext)
-decryption: input scatterlist contains only the mac
plus the condition of having different source and destination buffers
(or else scatterlist length = max(plaintext_len, ciphertext_len)).
These are not handled correctly, leading to crashes like:
root@p4080ds:~/crypto# insmod tcrypt.ko mode=45
------------[ cut here ]------------
kernel BUG at crypto/scatterwalk.c:37!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=8 P4080 DS
Modules linked in: tcrypt(+) crc32c xts xcbc vmac pcbc ecb gcm ghash_generic gf128mul ccm ctr seqiv
CPU: 3 PID: 1082 Comm: cryptomgr_test Not tainted 3.11.0 #14
task:
ee12c5b0 ti:
eecd0000 task.ti:
eecd0000
NIP:
c0204d98 LR:
f9225848 CTR:
c0204d80
REGS:
eecd1b70 TRAP: 0700 Not tainted (3.11.0)
MSR:
00029002 <CE,EE,ME> CR:
22044022 XER:
20000000
GPR00:
f9225c94 eecd1c20 ee12c5b0 eecd1c28 ee879400 ee879400 00000000 ee607464
GPR08:
00000001 00000001 00000000 006b0000 c0204d80 00000000 00000002 c0698e20
GPR16:
ee987000 ee895000 fffffff4 ee879500 00000100 eecd1d58 00000001 00000000
GPR24:
ee879400 00000020 00000000 00000000 ee5b2800 ee607430 00000004 ee607460
NIP [
c0204d98] scatterwalk_start+0x18/0x30
LR [
f9225848] get_data_to_compute+0x28/0x2f0 [ccm]
Call Trace:
[
eecd1c20] [
f9225974] get_data_to_compute+0x154/0x2f0 [ccm] (unreliable)
[
eecd1c70] [
f9225c94] crypto_ccm_auth+0x184/0x1d0 [ccm]
[
eecd1cb0] [
f9225d40] crypto_ccm_encrypt+0x60/0x2d0 [ccm]
[
eecd1cf0] [
c020d77c] __test_aead+0x3ec/0xe20
[
eecd1e20] [
c020f35c] test_aead+0x6c/0xe0
[
eecd1e40] [
c020f420] alg_test_aead+0x50/0xd0
[
eecd1e60] [
c020e5e4] alg_test+0x114/0x2e0
[
eecd1ee0] [
c020bd1c] cryptomgr_test+0x4c/0x60
[
eecd1ef0] [
c0047058] kthread+0xa8/0xb0
[
eecd1f40] [
c000eb0c] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
0f080000 81290024 552807fe 0f080000 5529003a 4bffffb4 90830000 39400000
39000001 8124000c 2f890000 7d28579e <
0f090000>
81240008 91230004 4e800020
---[ end trace
6d652dfcd1be37bd ]---
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Lendacky [Tue, 12 Nov 2013 17:46:10 +0000 (11:46 -0600)]
crypto: scatterwalk - Set the chain pointer indication bit
commit
41da8b5adba77e22584f8b45f9641504fa885308 upstream.
The scatterwalk_crypto_chain function invokes the scatterwalk_sg_chain
function to chain two scatterlists, but the chain pointer indication
bit is not set. When the resulting scatterlist is used, for example,
by sg_nents to count the number of scatterlist entries, a segfault occurs
because sg_nents does not follow the chain pointer to the chained scatterlist.
Update scatterwalk_sg_chain to set the chain pointer indication bit as is
done by the sg_chain function.
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>
Gerald Schaefer [Tue, 19 Nov 2013 16:12:47 +0000 (17:12 +0100)]
crypto: s390 - Fix aes-xts parameter corruption
commit
9dda2769af4f3f3093434648c409bb351120d9e8 upstream.
Some s390 crypto algorithms incorrectly use the crypto_tfm structure to
store private data. As the tfm can be shared among multiple threads, this
can result in data corruption.
This patch fixes aes-xts by moving the xts and pcc parameter blocks from
the tfm onto the stack (48 + 96 bytes).
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Henningsson [Fri, 29 Nov 2013 07:10:20 +0000 (15:10 +0800)]
ALSA: hda - Add mono speaker quirk for Dell Inspiron 5439
commit
eb82594b75b0cf54c667189e061934b7c49b5d42 upstream.
This machine also has mono output if run through DAC node 0x03.
BugLink: https://bugs.launchpad.net/bugs/1256212
Tested-by: David Chen <david.chen@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 4 Dec 2013 12:59:45 +0000 (13:59 +0100)]
ALSA: hda - Fix silent output on MacBook Air 2,1
commit
0756f09c4946fe2d9ce2ebcb6f2e3c58830d22a3 upstream.
MacBook Air 2,1 has a fairly different pin assignment from its brother
MBA 1,1, and yet another quirks are needed for pin 0x18 and 0x19,
similarly like what iMac 9,1 requires, in order to make the sound
working on it.
Reported-and-tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Henningsson [Mon, 2 Dec 2013 10:06:20 +0000 (18:06 +0800)]
ALSA: hda - Fix headset mic input after muted internal mic (Dell/Realtek)
commit
d59915d0655c5864b514f21daaeac98c047875dc upstream.
By trial and error, I found this patch could work around an issue
where the headset mic would stop working if you switch between the
internal mic and the headset mic, and the internal mic was muted.
It still takes a second or two before the headset mic actually starts
working, but still better than nothing.
Information update from Kailang:
The verb was ADC digital mute(bit 6 default 1).
Switch internal mic and headset mic will run alc_headset_mode_default.
The coef index 0x11 will set to 0x0041.
Because headset mode was fixed type. It doesn't need to run
alc_determine_headset_type.
So, the value still keep 0x0041. ADC was muted.
BugLink: https://bugs.launchpad.net/bugs/1256840
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Mon, 2 Dec 2013 14:27:19 +0000 (15:27 +0100)]
ALSA: hda - Another fixup for ASUS laptop with ALC660 codec
commit
e7ca237bfcf6a288702cb95e94ab94f642ccad88 upstream.
ASUS Z35HL laptop also needs the very same fix as the previous one
that was applied to ASUS W7J.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66231
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Fri, 29 Nov 2013 11:47:34 +0000 (12:47 +0100)]
ALSA: hda - Fix silent output on ASUS W7J laptop
commit
6ddf0fd1c462a418a3cbb8b0653820dc48ffbd98 upstream.
The recent kernels got regressions on ASUS W7J with ALC660 codec where
no sound comes out. After a long debugging session, we found out that
setting the pin control on the unused NID 0x10 is mandatory for the
outputs. And, it was found out that another magic of NID 0x0f that is
required for other ASUS laptops isn't needed on this machine.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66081
Reported-and-tested-by: Andrey Lipaev <lipaev@mail.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sun, 8 Dec 2013 16:17:21 +0000 (08:17 -0800)]
Linux 3.10.23
Pierre Ossman [Wed, 6 Nov 2013 19:00:32 +0000 (20:00 +0100)]
drm/radeon/audio: correct ACR table
commit
3e71985f2439d8c4090dc2820e497e6f3d72dcff upstream.
The values were taken from the HDMI spec, but they assumed
exact x/1.001 clocks. Since we round the clocks, we also need
to calculate different N and CTS values.
Note that the N for 25.2/1.001 MHz at 44.1 kHz audio is out of
spec. Hopefully this mode is rarely used and/or HDMI sinks
tolerate overly large values of N.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pierre Ossman [Wed, 6 Nov 2013 19:09:08 +0000 (20:09 +0100)]
drm/radeon/audio: improve ACR calculation
commit
a2098250fbda149cfad9e626afe80abe3b21e574 upstream.
In order to have any realistic chance of calculating proper
ACR values, we need to be able to calculate both N and CTS,
not just CTS. We still aim for the ideal N as specified in
the HDMI spec though.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miroslav Lichvar [Thu, 1 Aug 2013 17:31:35 +0000 (19:31 +0200)]
ntp: Make periodic RTC update more reliable
commit
a97ad0c4b447a132a322cedc3a5f7fa4cab4b304 upstream.
The current code requires that the scheduled update of the RTC happens
in the closest tick to the half of the second. This seems to be
difficult to achieve reliably. The scheduled work may be missing the
target time by a tick or two and be constantly rescheduled every second.
Relax the limit to 10 ticks. As a typical RTC drifts in the 11-minute
update interval by several milliseconds, this shouldn't affect the
overall accuracy of the RTC much.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomoki Sekiyama [Tue, 15 Oct 2013 22:42:19 +0000 (16:42 -0600)]
elevator: acquire q->sysfs_lock in elevator_change()
commit
7c8a3679e3d8e9d92d58f282161760a0e247df97 upstream.
Add locking of q->sysfs_lock into elevator_change() (an exported function)
to ensure it is held to protect q->elevator from elevator_init(), even if
elevator_change() is called from non-sysfs paths.
sysfs path (elv_iosched_store) uses __elevator_change(), non-locking
version, as the lock is already taken by elv_iosched_store().
Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomoki Sekiyama [Tue, 15 Oct 2013 22:42:16 +0000 (16:42 -0600)]
elevator: Fix a race in elevator switching and md device initialization
commit
eb1c160b22655fd4ec44be732d6594fd1b1e44f4 upstream.
The soft lockup below happens at the boot time of the system using dm
multipath and the udev rules to switch scheduler.
[ 356.127001] BUG: soft lockup - CPU#3 stuck for 22s! [sh:483]
[ 356.127001] RIP: 0010:[<
ffffffff81072a7d>] [<
ffffffff81072a7d>] lock_timer_base.isra.35+0x1d/0x50
...
[ 356.127001] Call Trace:
[ 356.127001] [<
ffffffff81073810>] try_to_del_timer_sync+0x20/0x70
[ 356.127001] [<
ffffffff8118b08a>] ? kmem_cache_alloc_node_trace+0x20a/0x230
[ 356.127001] [<
ffffffff810738b2>] del_timer_sync+0x52/0x60
[ 356.127001] [<
ffffffff812ece22>] cfq_exit_queue+0x32/0xf0
[ 356.127001] [<
ffffffff812c98df>] elevator_exit+0x2f/0x50
[ 356.127001] [<
ffffffff812c9f21>] elevator_change+0xf1/0x1c0
[ 356.127001] [<
ffffffff812caa50>] elv_iosched_store+0x20/0x50
[ 356.127001] [<
ffffffff812d1d09>] queue_attr_store+0x59/0xb0
[ 356.127001] [<
ffffffff812143f6>] sysfs_write_file+0xc6/0x140
[ 356.127001] [<
ffffffff811a326d>] vfs_write+0xbd/0x1e0
[ 356.127001] [<
ffffffff811a3ca9>] SyS_write+0x49/0xa0
[ 356.127001] [<
ffffffff8164e899>] system_call_fastpath+0x16/0x1b
This is caused by a race between md device initialization by multipathd and
shell script to switch the scheduler using sysfs.
- multipathd:
SyS_ioctl -> do_vfs_ioctl -> dm_ctl_ioctl -> ctl_ioctl -> table_load
-> dm_setup_md_queue -> blk_init_allocated_queue -> elevator_init
q->elevator = elevator_alloc(q, e); // not yet initialized
- sh -c 'echo deadline > /sys/$DEVPATH/queue/scheduler':
elevator_switch (in the call trace above)
struct elevator_queue *old = q->elevator;
q->elevator = elevator_alloc(q, new_e);
elevator_exit(old); // lockup! (*)
- multipathd: (cont.)
err = e->ops.elevator_init_fn(q); // init fails; q->elevator is modified
(*) When del_timer_sync() is called, lock_timer_base() will loop infinitely
while timer->base == NULL. In this case, as timer will never initialized,
it results in lockup.
This patch introduces acquisition of q->sysfs_lock around elevator_init()
into blk_init_allocated_queue(), to provide mutual exclusion between
initialization of the q->scheduler and switching of the scheduler.
This should fix this bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=902012
Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neil Horman [Fri, 27 Sep 2013 16:53:35 +0000 (12:53 -0400)]
iommu: Remove stack trace from broken irq remapping warning
commit
05104a4e8713b27291c7bb49c1e7e68b4e243571 upstream.
The warning for the irq remapping broken check in intel_irq_remapping.c is
pretty pointless. We need the warning, but we know where its comming from, the
stack trace will always be the same, and it needlessly triggers things like
Abrt. This changes the warning to just print a text warning about BIOS being
broken, without the stack trace, then sets the appropriate taint bit. Since we
automatically disable irq remapping, theres no need to contiue making Abrt jump
at this problem
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Joerg Roedel <joro@8bytes.org>
CC: Bjorn Helgaas <bhelgaas@google.com>
CC: Andy Lutomirski <luto@amacapital.net>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Julian Stecklina [Wed, 9 Oct 2013 08:03:52 +0000 (10:03 +0200)]
iommu/vt-d: Fixed interaction of VFIO_IOMMU_MAP_DMA with IOMMU address limits
commit
f9423606ade08653dd8a43334f0a7fb45504c5cc upstream.
The BUG_ON in drivers/iommu/intel-iommu.c:785 can be triggered from userspace via
VFIO by calling the VFIO_IOMMU_MAP_DMA ioctl on a vfio device with any address
beyond the addressing capabilities of the IOMMU. The problem is that the ioctl code
calls iommu_iova_to_phys before it calls iommu_map. iommu_map handles the case that
it gets addresses beyond the addressing capabilities of its IOMMU.
intel_iommu_iova_to_phys does not.
This patch fixes iommu_iova_to_phys to return NULL for addresses beyond what the
IOMMU can handle. This in turn causes the ioctl call to fail in iommu_map and
(correctly) return EFAULT to the user with a helpful warning message in the kernel
log.
Signed-off-by: Julian Stecklina <jsteckli@os.inf.tu-dresden.de>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simon Wood [Thu, 10 Oct 2013 14:20:13 +0000 (08:20 -0600)]
HID: lg: fix Report Descriptor for Logitech MOMO Force (Black)
commit
348cbaa800f8161168b20f85f72abb541c145132 upstream.
By default the Logitech MOMO Force (Black) presents a combined accel/brake
axis ('Y'). This patch modifies the HID descriptor to present seperate
accel/brake axes ('Y' and 'Z').
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sasha Levin [Tue, 19 Nov 2013 19:25:36 +0000 (14:25 -0500)]
video: kyro: fix incorrect sizes when copying to userspace
commit
2ab68ec927310dc488f3403bb48f9e4ad00a9491 upstream.
kyro would copy u32s and specify sizeof(unsigned long) as the size to copy.
This would copy more data than intended and cause memory corruption and might
leak kernel memory.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Tue, 12 Nov 2013 23:08:32 +0000 (15:08 -0800)]
mm: numa: return the number of base pages altered by protection changes
commit
72403b4a0fbdf433c1fe0127e49864658f6f6468 upstream.
Commit
0255d4918480 ("mm: Account for a THP NUMA hinting update as one
PTE update") was added to account for the number of PTE updates when
marking pages prot_numa. task_numa_work was using the old return value
to track how much address space had been updated. Altering the return
value causes the scanner to do more work than it is configured or
documented to in a single unit of work.
This patch reverts that commit and accounts for the number of THP
updates separately in vmstat. It is up to the administrator to
interpret the pair of values correctly. This is a straight-forward
operation and likely to only be of interest when actively debugging NUMA
balancing problems.
The impact of this patch is that the NUMA PTE scanner will scan slower
when THP is enabled and workloads may converge slower as a result. On
the flip size system CPU usage should be lower than recent tests
reported. This is an illustrative example of a short single JVM specjbb
test
specjbb
3.12.0 3.12.0
vanilla acctupdates
TPut 1 26143.00 ( 0.00%) 25747.00 ( -1.51%)
TPut 7 185257.00 ( 0.00%) 183202.00 ( -1.11%)
TPut 13 329760.00 ( 0.00%) 346577.00 ( 5.10%)
TPut 19 442502.00 ( 0.00%) 460146.00 ( 3.99%)
TPut 25 540634.00 ( 0.00%) 549053.00 ( 1.56%)
TPut 31 512098.00 ( 0.00%) 519611.00 ( 1.47%)
TPut 37 461276.00 ( 0.00%) 474973.00 ( 2.97%)
TPut 43 403089.00 ( 0.00%) 414172.00 ( 2.75%)
3.12.0 3.12.0
vanillaacctupdates
User 5169.64 5184.14
System 100.45 80.02
Elapsed 252.75 251.85
Performance is similar but note the reduction in system CPU time. While
this showed a performance gain, it will not be universal but at least
it'll be behaving as documented. The vmstats are obviously different but
here is an obvious interpretation of them from mmtests.
3.12.0 3.12.0
vanillaacctupdates
NUMA page range updates
1408326 11043064
NUMA huge PMD updates 0 21040
NUMA PTE updates
1408326 291624
"NUMA page range updates" == nr_pte_updates and is the value returned to
the NUMA pte scanner. NUMA huge PMD updates were the number of THP
updates which in combination can be used to calculate how many ptes were
updated from userspace.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reported-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Boyd [Thu, 13 Jun 2013 18:39:50 +0000 (11:39 -0700)]
clockevents: Prefer CPU local devices over global devices
commit
70e5975d3a04be5479a28eec4a2fb10f98ad2785 upstream.
On an SMP system with only one global clockevent and a dummy
clockevent per CPU we run into problems. We want the dummy
clockevents to be registered as the per CPU tick devices, but
we can only achieve that if we register the dummy clockevents
before the global clockevent or if we artificially inflate the
rating of the dummy clockevents to be higher than the rating
of the global clockevent. Failure to do so leads to boot
hangs when the dummy timers are registered on all other CPUs
besides the CPU that accepted the global clockevent as its tick
device and there is no broadcast timer to poke the dummy
devices.
If we're registering multiple clockevents and one clockevent is
global and the other is local to a particular CPU we should
choose to use the local clockevent regardless of the rating of
the device. This way, if the clockevent is a dummy it will take
the tick device duty as long as there isn't a higher rated tick
device and any global clockevent will be bumped out into
broadcast mode, fixing the problem described above.
Reported-and-tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Tested-by: soren.brinkmann@xilinx.com
Cc: John Stultz <john.stultz@linaro.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: John Stultz <john.stultz@linaro.org>
Link: http://lkml.kernel.org/r/20130613183950.GA32061@codeaurora.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kim Phillips <kim.phillips@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Thu, 25 Apr 2013 20:31:50 +0000 (20:31 +0000)]
clockevents: Split out selection logic
commit
45cb8e01b2ecef1c2afb18333e95793fa1a90281 upstream.
Split out the clockevent device selection logic. Preparatory patch to
allow unbinding active clockevent devices.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Link: http://lkml.kernel.org/r/20130425143436.431796247@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kim Phillips <kim.phillips@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Thu, 25 Apr 2013 20:31:49 +0000 (20:31 +0000)]
clockevents: Add module refcount
commit
ccf33d6880f39a35158fff66db13000ae4943fac upstream.
We want to be able to remove clockevent modules as well. Add a
refcount so we don't remove a module with an active clock event
device.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Link: http://lkml.kernel.org/r/20130425143436.307435149@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kim Phillips <kim.phillips@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Thu, 25 Apr 2013 20:31:47 +0000 (20:31 +0000)]
clockevents: Get rid of the notifier chain
commit
7172a286ced0c1f4f239a0fa09db54ed37d3ead2 upstream.
7+ years and still a single user. Kill it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Link: http://lkml.kernel.org/r/20130425143436.098520211@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kim Phillips <kim.phillips@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mateusz Guzik [Thu, 5 Dec 2013 10:09:02 +0000 (11:09 +0100)]
aio: restore locking of ioctx list on removal
Commit
36f5588905c10a8c4568a210d601fe8c3c27e0f0
"aio: refcounting cleanup" resulted in ioctx_lock not being held
during ctx removal, leaving the list susceptible to corruptions.
In mainline kernel the issue went away as a side effect of
db446a08c23d5475e6b08c87acca79ebb20f283c "aio: convert the ioctx list to
table lookup v3".
Fix the problem by restoring appropriate locking.
Signed-off-by: Mateusz Guzik <mguzik@redhat.com>
Reported-by: Eryu Guan <eguan@redhat.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Kent Overstreet <kmo@daterainc.com>
Acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
KOBAYASHI Yoshitake [Sat, 6 Jul 2013 22:35:45 +0000 (07:35 +0900)]
mmc: block: fix a bug of error handling in MMC driver
commit
c8760069627ad3b0dbbea170f0c4c58b16e18d3d upstream.
Current MMC driver doesn't handle generic error (bit19 of device
status) in write sequence. As a result, write data gets lost when
generic error occurs. For example, a generic error when updating a
filesystem management information causes a loss of write data and
corrupts the filesystem. In the worst case, the system will never
boot.
This patch includes the following functionality:
1. To enable error checking for the response of CMD12 and CMD13
in write command sequence
2. To retry write sequence when a generic error occurs
Messages are added for v2 to show what occurs.
Signed-off-by: KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dwight Engen [Thu, 15 Aug 2013 18:08:03 +0000 (14:08 -0400)]
xfs: add capability check to free eofblocks ioctl
commit
8c567a7fab6e086a0284eee2db82348521e7120c upstream.
Check for CAP_SYS_ADMIN since the caller can truncate preallocated
blocks from files they do not own nor have write access to. A more
fine grained access check was considered: require the caller to
specify their own uid/gid and to use inode_permission to check for
write, but this would not catch the case of an inode not reachable
via path traversal from the callers mount namespace.
Add check for read-only filesystem to free eofblocks ioctl.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Cc: Kees Cook <keescook@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Sat, 26 Oct 2013 00:26:17 +0000 (17:26 -0700)]
tcp: gso: fix truesize tracking
[ Upstream commit
0d08c42cf9a71530fef5ebcfe368f38f2dd0476f ]
commit
6ff50cd55545 ("tcp: gso: do not generate out of order packets")
had an heuristic that can trigger a warning in skb_try_coalesce(),
because skb->truesize of the gso segments were exactly set to mss.
This breaks the requirement that
skb->truesize >= skb->len + truesizeof(struct sk_buff);
It can trivially be reproduced by :
ifconfig lo mtu 1500
ethtool -K lo tso off
netperf
As the skbs are looped into the TCP networking stack, skb_try_coalesce()
warns us of these skb under-estimating their truesize.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fan.du [Sun, 1 Dec 2013 08:28:48 +0000 (16:28 +0800)]
{pktgen, xfrm} Update IPv4 header total len and checksum after tranformation
[ Upstream commit
3868204d6b89ea373a273e760609cb08020beb1a ]
commit
a553e4a6317b2cfc7659542c10fe43184ffe53da ("[PKTGEN]: IPSEC support")
tried to support IPsec ESP transport transformation for pktgen, but acctually
this doesn't work at all for two reasons(The orignal transformed packet has
bad IPv4 checksum value, as well as wrong auth value, reported by wireshark)
- After transpormation, IPv4 header total length needs update,
because encrypted payload's length is NOT same as that of plain text.
- After transformation, IPv4 checksum needs re-caculate because of payload
has been changed.
With this patch, armmed pktgen with below cofiguration, Wireshark is able to
decrypted ESP packet generated by pktgen without any IPv4 checksum error or
auth value error.
pgset "flag IPSEC"
pgset "flows 1"
Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hannes Frederic Sowa [Fri, 29 Nov 2013 05:39:44 +0000 (06:39 +0100)]
ipv6: fix possible seqlock deadlock in ip6_finish_output2
[ Upstream commit
7f88c6b23afbd31545c676dea77ba9593a1a14bf ]
IPv6 stats are 64 bits and thus are protected with a seqlock. By not
disabling bottom-half we could deadlock here if we don't disable bh and
a softirq reentrantly updates the same mib.
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Thu, 28 Nov 2013 17:51:22 +0000 (09:51 -0800)]
inet: fix possible seqlock deadlocks
[ Upstream commit
f1d8cba61c3c4b1eb88e507249c4cb8d635d9a76 ]
In commit
c9e9042994d3 ("ipv4: fix possible seqlock deadlock") I left
another places where IP_INC_STATS_BH() were improperly used.
udp_sendmsg(), ping_v4_sendmsg() and tcp_v4_connect() are called from
process context, not from softirq context.
This was detected by lockdep seqlock support.
Reported-by: jongman heo <jongman.heo@samsung.com>
Fixes:
584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
Fixes:
c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
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>
Jiri Pirko [Thu, 28 Nov 2013 17:01:38 +0000 (18:01 +0100)]
team: fix master carrier set when user linkup is enabled
[ Upstream commit
f5e0d34382e18f396d7673a84df8e3342bea7eb6 ]
When user linkup is enabled and user sets linkup of individual port,
we need to recompute linkup (carrier) of master interface so the change
is reflected. Fix this by calling __team_carrier_check() which does the
needed work.
Please apply to all stable kernels as well. Thanks.
Reported-by: Jan Tluka <jtluka@redhat.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Landden [Mon, 25 Nov 2013 06:36:28 +0000 (22:36 -0800)]
net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST
[ Upstream commit
d3f7d56a7a4671d395e8af87071068a195257bf6 ]
Commit
35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
added an internal flag MSG_SENDPAGE_NOTLAST, similar to
MSG_MORE.
algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
and need to see the new flag as identical to MSG_MORE.
This fixes sendfile() on AF_ALG.
v3: also fix udp
Reported-and-tested-by: Shawn Landden <shawnlandden@gmail.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Original-patch: Richard Weinberger <richard@nod.at>
Signed-off-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yang Yingliang [Wed, 27 Nov 2013 06:32:52 +0000 (14:32 +0800)]
net: 8139cp: fix a BUG_ON triggered by wrong bytes_compl
[ Upstream commit
7fe0ee099ad5e3dea88d4ee1b6f20246b1ca57c3 ]
Using iperf to send packets(GSO mode is on), a bug is triggered:
[ 212.672781] kernel BUG at lib/dynamic_queue_limits.c:26!
[ 212.673396] invalid opcode: 0000 [#1] SMP
[ 212.673882] Modules linked in: 8139cp(O) nls_utf8 edd fuse loop dm_mod ipv6 i2c_piix4 8139too i2c_core intel_agp joydev pcspkr hid_generic intel_gtt floppy sr_mod mii button sg cdrom ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore sd_mod usb_common crc_t10dif crct10dif_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata scsi_mod [last unloaded: 8139cp]
[ 212.676084] CPU: 0 PID: 4124 Comm: iperf Tainted: G O 3.12.0-0.7-default+ #16
[ 212.676084] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 212.676084] task:
ffff8800d83966c0 ti:
ffff8800db4c8000 task.ti:
ffff8800db4c8000
[ 212.676084] RIP: 0010:[<
ffffffff8122e23f>] [<
ffffffff8122e23f>] dql_completed+0x17f/0x190
[ 212.676084] RSP: 0018:
ffff880116e03e30 EFLAGS:
00010083
[ 212.676084] RAX:
00000000000005ea RBX:
0000000000000f7c RCX:
0000000000000002
[ 212.676084] RDX:
ffff880111dd0dc0 RSI:
0000000000000bd4 RDI:
ffff8800db6ffcc0
[ 212.676084] RBP:
ffff880116e03e48 R08:
0000000000000992 R09:
0000000000000000
[ 212.676084] R10:
ffffffff8181e400 R11:
0000000000000004 R12:
000000000000000f
[ 212.676084] R13:
ffff8800d94ec840 R14:
ffff8800db440c80 R15:
000000000000000e
[ 212.676084] FS:
00007f6685a3c700(0000) GS:
ffff880116e00000(0000) knlGS:
0000000000000000
[ 212.676084] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 212.676084] CR2:
00007f6685ad6460 CR3:
00000000db714000 CR4:
00000000000006f0
[ 212.676084] Stack:
[ 212.676084]
ffff8800db6ffc00 000000000000000f ffff8800d94ec840 ffff880116e03eb8
[ 212.676084]
ffffffffa041509f ffff880116e03e88 0000000f16e03e88 ffff8800d94ec000
[ 212.676084]
00000bd400059858 000000050000000f ffffffff81094c36 ffff880116e03eb8
[ 212.676084] Call Trace:
[ 212.676084] <IRQ>
[ 212.676084] [<
ffffffffa041509f>] cp_interrupt+0x4ef/0x590 [8139cp]
[ 212.676084] [<
ffffffff81094c36>] ? ktime_get+0x56/0xd0
[ 212.676084] [<
ffffffff8108cf73>] handle_irq_event_percpu+0x53/0x170
[ 212.676084] [<
ffffffff8108d0cc>] handle_irq_event+0x3c/0x60
[ 212.676084] [<
ffffffff8108fdb5>] handle_fasteoi_irq+0x55/0xf0
[ 212.676084] [<
ffffffff810045df>] handle_irq+0x1f/0x30
[ 212.676084] [<
ffffffff81003c8b>] do_IRQ+0x5b/0xe0
[ 212.676084] [<
ffffffff8142beaa>] common_interrupt+0x6a/0x6a
[ 212.676084] <EOI>
[ 212.676084] [<
ffffffffa0416a21>] ? cp_start_xmit+0x621/0x97c [8139cp]
[ 212.676084] [<
ffffffffa0416a09>] ? cp_start_xmit+0x609/0x97c [8139cp]
[ 212.676084] [<
ffffffff81378ed9>] dev_hard_start_xmit+0x2c9/0x550
[ 212.676084] [<
ffffffff813960a9>] sch_direct_xmit+0x179/0x1d0
[ 212.676084] [<
ffffffff813793f3>] dev_queue_xmit+0x293/0x440
[ 212.676084] [<
ffffffff813b0e46>] ip_finish_output+0x236/0x450
[ 212.676084] [<
ffffffff810e59e7>] ? __alloc_pages_nodemask+0x187/0xb10
[ 212.676084] [<
ffffffff813b10e8>] ip_output+0x88/0x90
[ 212.676084] [<
ffffffff813afa64>] ip_local_out+0x24/0x30
[ 212.676084] [<
ffffffff813aff0d>] ip_queue_xmit+0x14d/0x3e0
[ 212.676084] [<
ffffffff813c6fd1>] tcp_transmit_skb+0x501/0x840
[ 212.676084] [<
ffffffff813c8323>] tcp_write_xmit+0x1e3/0xb20
[ 212.676084] [<
ffffffff81363237>] ? skb_page_frag_refill+0x87/0xd0
[ 212.676084] [<
ffffffff813c8c8b>] tcp_push_one+0x2b/0x40
[ 212.676084] [<
ffffffff813bb7e6>] tcp_sendmsg+0x926/0xc90
[ 212.676084] [<
ffffffff813e1d21>] inet_sendmsg+0x61/0xc0
[ 212.676084] [<
ffffffff8135e861>] sock_aio_write+0x101/0x120
[ 212.676084] [<
ffffffff81107cf1>] ? vma_adjust+0x2e1/0x5d0
[ 212.676084] [<
ffffffff812163e0>] ? timerqueue_add+0x60/0xb0
[ 212.676084] [<
ffffffff81130b60>] do_sync_write+0x60/0x90
[ 212.676084] [<
ffffffff81130d44>] ? rw_verify_area+0x54/0xf0
[ 212.676084] [<
ffffffff81130f66>] vfs_write+0x186/0x190
[ 212.676084] [<
ffffffff811317fd>] SyS_write+0x5d/0xa0
[ 212.676084] [<
ffffffff814321e2>] system_call_fastpath+0x16/0x1b
[ 212.676084] Code: ca 41 89 dc 41 29 cc 45 31 db 29 c2 41 89 c5 89 d0 45 29 c5 f7 d0 c1 e8 1f e9 43 ff ff ff 66 0f 1f 44 00 00 31 c0 e9 7b ff ff ff <0f> 0b eb fe 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 c7 47 40 00
[ 212.676084] RIP [<
ffffffff8122e23f>] dql_completed+0x17f/0x190
------------[ cut here ]------------
When a skb has frags, bytes_compl plus skb->len nr_frags times in cp_tx().
It's not the correct value(actually, it should plus skb->len once) and it
will trigger the BUG_ON(bytes_compl > num_queued - dql->num_completed).
So only increase bytes_compl when finish sending all frags. pkts_compl also
has a wrong value, fix it too.
It's introduced by commit
871f0d4c ("8139cp: enable bql").
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Chang [Wed, 27 Nov 2013 07:48:36 +0000 (15:48 +0800)]
r8169: check ALDPS bit and disable it if enabled for the 8168g
[ Upstream commit
1bac1072425c86f1ac85bd5967910706677ef8b3 ]
Windows driver will enable ALDPS function, but linux driver and firmware
do not have any configuration related to ALDPS function for 8168g.
So restart system to linux and remove the NIC cable, LAN enter ALDPS,
then LAN RX will be disabled.
This issue can be easily reproduced on dual boot windows and linux
system with RTL_GIGA_MAC_VER_40 chip.
Realtek said, ALDPS function can be disabled by configuring to PHY,
switch to page 0x0A43, reg0x10 bit2=0.
Signed-off-by: David Chang <dchang@suse.com>
Acked-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Veaceslav Falico [Fri, 29 Nov 2013 08:53:23 +0000 (09:53 +0100)]
af_packet: block BH in prb_shutdown_retire_blk_timer()
[ Upstream commit
ec6f809ff6f19fafba3212f6aff0dda71dfac8e8 ]
Currently we're using plain spin_lock() in prb_shutdown_retire_blk_timer(),
however the timer might fire right in the middle and thus try to re-aquire
the same spinlock, leaving us in a endless loop.
To fix that, use the spin_lock_bh() to block it.
Fixes:
f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
CC: "David S. Miller" <davem@davemloft.net>
CC: Daniel Borkmann <dborkman@redhat.com>
CC: Willem de Bruijn <willemb@google.com>
CC: Phil Sutter <phil@nwl.cc>
CC: Eric Dumazet <edumazet@google.com>
Reported-by: Jan Stancek <jstancek@redhat.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Borkmann [Thu, 21 Nov 2013 15:50:58 +0000 (16:50 +0100)]
packet: fix use after free race in send path when dev is released
[ Upstream commit
e40526cb20b5ee53419452e1f03d97092f144418 ]
Salam reported a use after free bug in PF_PACKET that occurs when
we're sending out frames on a socket bound device and suddenly the
net device is being unregistered. It appears that commit
827d9780
introduced a possible race condition between {t,}packet_snd() and
packet_notifier(). In the case of a bound socket, packet_notifier()
can drop the last reference to the net_device and {t,}packet_snd()
might end up suddenly sending a packet over a freed net_device.
To avoid reverting
827d9780 and thus introducing a performance
regression compared to the current state of things, we decided to
hold a cached RCU protected pointer to the net device and maintain
it on write side via bind spin_lock protected register_prot_hook()
and __unregister_prot_hook() calls.
In {t,}packet_snd() path, we access this pointer under rcu_read_lock
through packet_cached_dev_get() that holds reference to the device
to prevent it from being freed through packet_notifier() while
we're in send path. This is okay to do as dev_put()/dev_hold() are
per-cpu counters, so this should not be a performance issue. Also,
the code simplifies a bit as we don't need need_rls_dev anymore.
Fixes:
827d978037d7 ("af-packet: Use existing netdev reference for bound sockets.")
Reported-by: Salam Noureddine <noureddine@aristanetworks.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Salam Noureddine <noureddine@aristanetworks.com>
Cc: Ben Greear <greearb@candelatech.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ding Tianhong [Sat, 7 Dec 2013 14:12:05 +0000 (22:12 +0800)]
bridge: flush br's address entry in fdb when remove the bridge dev
[ Upstream commit
f873042093c0b418d2351fe142222b625c740149 ]
When the following commands are executed:
brctl addbr br0
ifconfig br0 hw ether <addr>
rmmod bridge
The calltrace will occur:
[ 563.312114] device eth1 left promiscuous mode
[ 563.312188] br0: port 1(eth1) entered disabled state
[ 563.468190] kmem_cache_destroy bridge_fdb_cache: Slab cache still has objects
[ 563.468197] CPU: 6 PID: 6982 Comm: rmmod Tainted: G O 3.12.0-0.7-default+ #9
[ 563.468199] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 563.468200]
0000000000000880 ffff88010f111e98 ffffffff814d1c92 ffff88010f111eb8
[ 563.468204]
ffffffff81148efd ffff88010f111eb8 0000000000000000 ffff88010f111ec8
[ 563.468206]
ffffffffa062a270 ffff88010f111ed8 ffffffffa063ac76 ffff88010f111f78
[ 563.468209] Call Trace:
[ 563.468218] [<
ffffffff814d1c92>] dump_stack+0x6a/0x78
[ 563.468234] [<
ffffffff81148efd>] kmem_cache_destroy+0xfd/0x100
[ 563.468242] [<
ffffffffa062a270>] br_fdb_fini+0x10/0x20 [bridge]
[ 563.468247] [<
ffffffffa063ac76>] br_deinit+0x4e/0x50 [bridge]
[ 563.468254] [<
ffffffff810c7dc9>] SyS_delete_module+0x199/0x2b0
[ 563.468259] [<
ffffffff814e0922>] system_call_fastpath+0x16/0x1b
[ 570.377958] Bridge firewalling registered
--------------------------- cut here -------------------------------
The reason is that when the bridge dev's address is changed, the
br_fdb_change_mac_address() will add new address in fdb, but when
the bridge was removed, the address entry in the fdb did not free,
the bridge_fdb_cache still has objects when destroy the cache, Fix
this by flushing the bridge address entry when removing the bridge.
v2: according to the Toshiaki Makita and Vlad's suggestion, I only
delete the vlan0 entry, it still have a leak here if the vlan id
is other number, so I need to call fdb_delete_by_port(br, NULL, 1)
to flush all entries whose dst is NULL for the bridge.
Suggested-by: Toshiaki Makita <toshiaki.makita1@gmail.com>
Suggested-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vlad Yasevich [Wed, 20 Nov 2013 01:47:15 +0000 (20:47 -0500)]
net: core: Always propagate flag changes to interfaces
[ Upstream commit
d2615bf450694c1302d86b9cc8a8958edfe4c3a4 ]
The following commit:
b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
net: only invoke dev->change_rx_flags when device is UP
tried to fix a problem with VLAN devices and promiscuouse flag setting.
The issue was that VLAN device was setting a flag on an interface that
was down, thus resulting in bad promiscuity count.
This commit blocked flag propagation to any device that is currently
down.
A later commit:
deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
vlan: Don't propagate flag changes on down interfaces
fixed VLAN code to only propagate flags when the VLAN interface is up,
thus fixing the same issue as above, only localized to VLAN.
The problem we have now is that if we have create a complex stack
involving multiple software devices like bridges, bonds, and vlans,
then it is possible that the flags would not propagate properly to
the physical devices. A simple examle of the scenario is the
following:
eth0----> bond0 ----> bridge0 ---> vlan50
If bond0 or eth0 happen to be down at the time bond0 is added to
the bridge, then eth0 will never have promisc mode set which is
currently required for operation as part of the bridge. As a
result, packets with vlan50 will be dropped by the interface.
The only 2 devices that implement the special flag handling are
VLAN and DSA and they both have required code to prevent incorrect
flag propagation. As a result we can remove the generic solution
introduced in
b6c40d68ff6498b7f63ddf97cf0aa818d748dee7 and leave
it to the individual devices to decide whether they will block
flag propagation or not.
Reported-by: Stefan Priebe <s.priebe@profihost.ag>
Suggested-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexei Starovoitov [Wed, 20 Nov 2013 03:12:34 +0000 (19:12 -0800)]
ipv4: fix race in concurrent ip_route_input_slow()
[ Upstream commit
dcdfdf56b4a6c9437fc37dbc9cee94a788f9b0c4 ]
CPUs can ask for local route via ip_route_input_noref() concurrently.
if nh_rth_input is not cached yet, CPUs will proceed to allocate
equivalent DSTs on 'lo' and then will try to cache them in nh_rth_input
via rt_cache_route()
Most of the time they succeed, but on occasion the following two lines:
orig = *p;
prev = cmpxchg(p, orig, rt);
in rt_cache_route() do race and one of the cpus fails to complete cmpxchg.
But ip_route_input_slow() doesn't check the return code of rt_cache_route(),
so dst is leaking. dst_destroy() is never called and 'lo' device
refcnt doesn't go to zero, which can be seen in the logs as:
unregister_netdevice: waiting for lo to become free. Usage count = 1
Adding mdelay() between above two lines makes it easily reproducible.
Fix it similar to nh_pcpu_rth_output case.
Fixes:
d2d68ba9fe8b ("ipv4: Cache input routes in fib_info nexthops.")
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrey Vagin [Tue, 19 Nov 2013 18:10:06 +0000 (22:10 +0400)]
tcp: don't update snd_nxt, when a socket is switched from repair mode
[ Upstream commit
dbde497966804e63a38fdedc1e3815e77097efc2 ]
snd_nxt must be updated synchronously with sk_send_head. Otherwise
tp->packets_out may be updated incorrectly, what may bring a kernel panic.
Here is a kernel panic from my host.
[ 103.043194] BUG: unable to handle kernel NULL pointer dereference at
0000000000000048
[ 103.044025] IP: [<
ffffffff815aaaaf>] tcp_rearm_rto+0xcf/0x150
...
[ 146.301158] Call Trace:
[ 146.301158] [<
ffffffff815ab7f0>] tcp_ack+0xcc0/0x12c0
Before this panic a tcp socket was restored. This socket had sent and
unsent data in the write queue. Sent data was restored in repair mode,
then the socket was switched from reapair mode and unsent data was
restored. After that the socket was switched back into repair mode.
In that moment we had a socket where write queue looks like this:
snd_una snd_nxt write_seq
|_________|________|
|
sk_send_head
After a second switching from repair mode the state of socket was
changed:
snd_una snd_nxt, write_seq
|_________ ________|
|
sk_send_head
This state is inconsistent, because snd_nxt and sk_send_head are not
synchronized.
Bellow you can find a call trace, how packets_out can be incremented
twice for one skb, if snd_nxt and sk_send_head are not synchronized.
In this case packets_out will be always positive, even when
sk_write_queue is empty.
tcp_write_wakeup
skb = tcp_send_head(sk);
tcp_fragment
if (!before(tp->snd_nxt, TCP_SKB_CB(buff)->end_seq))
tcp_adjust_pcount(sk, skb, diff);
tcp_event_new_data_sent
tp->packets_out += tcp_skb_pcount(skb);
I think update of snd_nxt isn't required, when a socket is switched from
repair mode. Because it's initialized in tcp_connect_init. Then when a
write queue is restored, snd_nxt is incremented in tcp_event_new_data_sent,
so it's always is in consistent state.
I have checked, that the bug is not reproduced with this patch and
all tests about restoring tcp connections work fine.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Acked-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ying Xue [Tue, 19 Nov 2013 10:09:27 +0000 (18:09 +0800)]
atm: idt77252: fix dev refcnt leak
[ Upstream commit
b5de4a22f157ca345cdb3575207bf46402414bc1 ]
init_card() calls dev_get_by_name() to get a network deceive. But it
doesn't decrease network device reference count after the device is
used.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fan.du [Tue, 19 Nov 2013 08:53:28 +0000 (16:53 +0800)]
xfrm: Release dst if this dst is improper for vti tunnel
[ Upstream commit
236c9f84868534c718b6889aa624de64763281f9 ]
After searching rt by the vti tunnel dst/src parameter,
if this rt has neither attached to any transformation
nor the transformation is not tunnel oriented, this rt
should be released back to ip layer.
otherwise causing dst memory leakage.
Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Pirko [Wed, 6 Nov 2013 16:52:20 +0000 (17:52 +0100)]
netfilter: push reasm skb through instead of original frag skbs
[ Upstream commit
6aafeef03b9d9ecf255f3a80ed85ee070260e1ae ]
Pushing original fragments through causes several problems. For example
for matching, frags may not be matched correctly. Take following
example:
<example>
On HOSTA do:
ip6tables -I INPUT -p icmpv6 -j DROP
ip6tables -I INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
and on HOSTB you do:
ping6 HOSTA -s2000 (MTU is 1500)
Incoming echo requests will be filtered out on HOSTA. This issue does
not occur with smaller packets than MTU (where fragmentation does not happen)
</example>
As was discussed previously, the only correct solution seems to be to use
reassembled skb instead of separete frags. Doing this has positive side
effects in reducing sk_buff by one pointer (nfct_reasm) and also the reams
dances in ipvs and conntrack can be removed.
Future plan is to remove net/ipv6/netfilter/nf_conntrack_reasm.c
entirely and use code in net/ipv6/reassembly.c instead.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Pirko [Wed, 6 Nov 2013 16:52:19 +0000 (17:52 +0100)]
ip6_output: fragment outgoing reassembled skb properly
[ Upstream commit
9037c3579a277f3a23ba476664629fda8c35f7c4 ]
If reassembled packet would fit into outdev MTU, it is not fragmented
according the original frag size and it is send as single big packet.
The second case is if skb is gso. In that case fragmentation does not happen
according to the original frag size.
This patch fixes these.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>