07 Dec, 2014
40 commits
-
commit 1f9cd915b64bb95f7b41667b4bf8b22f0a0a557b upstream.
The prep_memcpy call was not setting any meaningful burst and width because it
was relying on the dma_slave_config was not set already.Rework the needed conversion functions, and hardcode the width and burst to
use.Signed-off-by: Maxime Ripard
Signed-off-by: Vinod Koul
Signed-off-by: Greg Kroah-Hartman -
commit 5247a589c24022ab34e780039cc8000c48f2035e upstream.
ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX
Error) interrupt, which triggers the folloing warning:[ 1153.360705] ------------[ cut here ]------------
[ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
[ 1153.360772] Call Trace:
[ 1153.360778] [] dump_stack+0x41/0x52
[ 1153.360782] [] warn_slowpath_common+0x7e/0xa0
[ 1153.360784] [] ? skb_release_head_state+0xb9/0xd0
[ 1153.360786] [] ? skb_release_head_state+0xb9/0xd0
[ 1153.360788] [] warn_slowpath_null+0x22/0x30
[ 1153.360791] [] skb_release_head_state+0xb9/0xd0
[ 1153.360793] [] skb_release_all+0x10/0x30
[ 1153.360795] [] kfree_skb+0x36/0x80
[ 1153.360799] [] ? can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360802] [] can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360805] [] esd_pci402_interrupt+0x34c/0x57a [esd402]
[ 1153.360809] [] handle_irq_event_percpu+0x35/0x180
[ 1153.360811] [] ? handle_irq_event_percpu+0xa3/0x180
[ 1153.360813] [] handle_irq_event+0x31/0x50
[ 1153.360816] [] handle_fasteoi_irq+0x6f/0x120
[ 1153.360818] [] ? handle_edge_irq+0x110/0x110
[ 1153.360822] [] handle_irq+0x71/0x90
[ 1153.360823] [] do_IRQ+0x3c/0xd0
[ 1153.360829] [] common_interrupt+0x2c/0x34
[ 1153.360834] [] ? finish_task_switch+0x47/0xf0
[ 1153.360836] [] __schedule+0x35b/0x7e0
[ 1153.360839] [] ? console_unlock+0x2c4/0x4d0
[ 1153.360842] [] ? n_tty_receive_buf_common+0x890/0x890
[ 1153.360845] [] ? process_one_work+0x196/0x370
[ 1153.360847] [] schedule+0x23/0x60
[ 1153.360849] [] worker_thread+0x161/0x460
[ 1153.360852] [] ? __wake_up_locked+0x1f/0x30
[ 1153.360854] [] ? rescuer_thread+0x2f0/0x2f0
[ 1153.360856] [] kthread+0xa1/0xc0
[ 1153.360859] [] ret_from_kernel_thread+0x21/0x30
[ 1153.360861] [] ? kthread_create_on_node+0x110/0x110
[ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---This patch replaces the kfree_skb() by dev_kfree_skb_any().
Signed-off-by: Thomas Körper
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit 1899045510ff109980d9cc34e330fd8ca3631871 upstream.
Intel Multi-Flex LUNs choke on REPORT SUPPORTED OPERATION CODES
resulting in sd_mod hanging for several minutes on startup.
The issue was introduced with WRITE SAME discovery heuristics.Fixes: 5db44863b6eb ("[SCSI] sd: Implement support for WRITE SAME")
Signed-off-by: Christian Sünkenberg
Signed-off-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman -
commit ab8edab132829b26dd13db6caca3c242cce35dc1 upstream.
This patch addresses a bug where individual vhost-scsi configfs endpoint
groups can be removed from below while active exports to QEMU userspace
still exist, resulting in an OOPs.It adds a configfs_depend_item() in vhost_scsi_set_endpoint() to obtain
an explicit dependency on se_tpg->tpg_group in order to prevent individual
vhost-scsi WWPN endpoints from being released via normal configfs methods
while an QEMU ioctl reference still exists.Also, add matching configfs_undepend_item() in vhost_scsi_clear_endpoint()
to release the dependency, once QEMU's reference to the individual group
at /sys/kernel/config/target/vhost/$WWPN/$TPGT is released.(Fix up vhost_scsi_clear_endpoint() error path - DanC)
Cc: Michael S. Tsirkin
Cc: Paolo Bonzini
Cc: Stefan Hajnoczi
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 4f031fa9f188b2b0641ac20087d9e16bcfb4e49d upstream.
Commit 7ec7c4a9a686c608315739ab6a2b0527a240883c (mac80211: port CCMP to
cryptoapi's CCM driver) introduced a regression when decrypting empty
packets (data_len == 0). This will lead to backtraces like:(scatterwalk_start) from [] (scatterwalk_map_and_copy+0x2c/0xa8)
(scatterwalk_map_and_copy) from [] (crypto_ccm_decrypt+0x7c/0x25c)
(crypto_ccm_decrypt) from [] (ieee80211_aes_ccm_decrypt+0x160/0x170)
(ieee80211_aes_ccm_decrypt) from [] (ieee80211_crypto_ccmp_decrypt+0x1ac/0x238)
(ieee80211_crypto_ccmp_decrypt) from [] (ieee80211_rx_handlers+0x870/0x1d24)
(ieee80211_rx_handlers) from [] (ieee80211_prepare_and_rx_handle+0x8a0/0x91c)
(ieee80211_prepare_and_rx_handle) from [] (ieee80211_rx+0x568/0x730)
(ieee80211_rx) from [] (__carl9170_rx+0x94c/0xa20)
(__carl9170_rx) from [] (carl9170_rx_stream+0x1fc/0x320)
(carl9170_rx_stream) from [] (carl9170_usb_tasklet+0x80/0xc8)
(carl9170_usb_tasklet) from [] (tasklet_hi_action+0x88/0xcc)
(tasklet_hi_action) from [] (__do_softirq+0xcc/0x200)
(__do_softirq) from [] (irq_exit+0x80/0xe0)
(irq_exit) from [] (handle_IRQ+0x64/0x80)
(handle_IRQ) from [] (__irq_svc+0x40/0x4c)
(__irq_svc) from [] (arch_cpu_idle+0x2c/0x34)Such packets can appear for example when using the carl9170 wireless driver
because hardware sometimes generates garbage when the internal FIFO overruns.This patch adds an additional length check.
Fixes: 7ec7c4a9a686 ("mac80211: port CCMP to cryptoapi's CCM driver")
Acked-by: Ard Biesheuvel
Signed-off-by: Ronald Wahl
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman -
commit 9c4b19a07dddda3ba35a2eb9b4134d485908e2f5 upstream.
commit 8c328a262f ("spi: sirf: Avoid duplicate code in various
bits_per_word cases") is wrong in setting data width register of
fifo is not right, it should use sspi->word_width >> 1 to set
related bits. According to hardware spec, the mapping between
register value and data width:
0 - byte
1 - WORD
2 - DWORDFixes: 8c328a262f ("spi: sirf: Avoid duplicate code in various bits_per_word cases") is wrong in setting data width register of
Signed-off-by: Qipan Li
Signed-off-by: Barry Song
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit c1aefbdd050e1fb15e92bcaf34d95b17ea952097 upstream.
We can only use page_address on memory that has been mapped using kmap,
when the buffer passed to the SPI has been allocated by vmalloc the page
has not necessarily been mapped through kmap. This means sometimes
page_address will return NULL causing the pointer we pass to sg_set_buf
to be invalid.As we only call page_address so that we can pass a virtual address to
sg_set_buf which will then immediately call virt_to_page on it, fix this
by calling sg_set_page directly rather then relying on the sg_set_buf
helper.Signed-off-by: Charles Keepax
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 0a8727e69778683495058852f783eeda141a754e upstream.
An IOCTL call that calls spi_setup() and then dw_spi_setup() will
overwrite the persisted last transfer speed. On each transfer, the
SPI speed is compared to the last transfer speed to determine if the
clock divider registers need to be updated (did the speed change?).
This bug was observed with the spidev driver using spi-config to
update the max transfer speed.This fix: Don't overwrite the persisted last transaction clock speed
when updating the SPI parameters in dw_spi_setup(). On the next
transaction, the new speed won't match the persisted last speed
and the hardware registers will be updated.
On initialization, the persisted last transaction clock
speed will be 0 but will be updated after the first SPI
transaction.Move zeroed clock divider check into clock change test because
chip->clk_div is zero on startup and would cause a divide-by-zero
error. The calculation was wrong as well (can't support odd #).Reported-by: Vlastimil Setka
Signed-off-by: Vlastimil Setka
Signed-off-by: Thor Thayer
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 3b726ae2de02a406cc91903f80132daee37b6f1b upstream.
In this case the cm_id->context is the isert_np, and the cm_id->qp
is NULL, so use that to distinct the cases.Since we don't expect any other events on this cm_id we can
just return -1 for explicit termination of the cm_id by the
cma layer.Signed-off-by: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 885e7b0e181c14e4d0ddd26c688bad2b84c1ada9 upstream.
If an initiator sends a zero-length command (e.g. TEST UNIT READY) but
sets the transfer direction in the transport layer to indicate a
data-out phase, we still shouldn't try to transfer data. At best it's
a NOP, and depending on the transport, we might crash on an
uninitialized sg list.Reported-by: Craig Watson
Signed-off-by: Roland Dreier
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit ab477c1ff5e0a744c072404bf7db51bfe1f05b6e upstream.
It is not guaranteed to that srp_sq_size is supported
by the HCA. So if we failed to create the QP with ENOMEM,
try with a smaller srp_sq_size. Keep it up until we hit
MIN_SRPT_SQ_SIZE, then fail the connection.Reported-by: Mark Lehrer
Signed-off-by: Bart Van Assche
Signed-off-by: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit a1f9a4072655843fc03186acbad65990cc05dd2d upstream.
The xpad wireless endpoint is not a bulk endpoint on my devices, but
rather an interrupt one, so the USB core complains when it is submitted.
I'm guessing that the author really did mean that this should be an
interrupt urb, but as there are a zillion different xpad devices out
there, let's cover out bases and handle both bulk and interrupt
endpoints just as easily.Signed-off-by: "Pierre-Loup A. Griffais"
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit bce4f9e764c36bc35dd5c9cf9e057c09f422397d upstream.
The LEN2006 Synaptics touchpad (as found in Thinkpad E540) returns wrong
min max values.touchpad-edge-detector output:
> Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event6
> Move one finger around the touchpad to detect the actual edges
> Kernel says: x [1472..5674], y [1408..4684]
> Touchpad sends: x [1264..5675], y [1171..4688]Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88211
Signed-off-by: Binyamin Sagal
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 3f4aa45ceea5789a4aade536acc27f2e0d3da5e1 upstream.
We cannot restart cacheflush safely if a process provides user-defined
signal handler and signal is pending. In this case -EINTR is returned
and it is expected that process re-invokes syscall. However, there are
a few problems with that:
* looks like nobody bothers checking return value from cacheflush
* but if it did, we don't provide the restart address for that, so the
process has to use the same range again
* ...and again, what might lead to looping foreverSo, remove cacheflush restarting code and terminate cache flushing
as early as fatal signal is pending.Reported-by: Chanho Min
Signed-off-by: Vladimir Murzin
Acked-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit 995ab5189d1d7264e79e665dfa032a19b3ac646e upstream.
Under extremely rare conditions, in an MPCore node consisting of at
least 3 CPUs, two CPUs trying to perform a STREX to data on the same
shared cache line can enter a livelock situation.This patch enables the HW mechanism that overcomes the bug. This fixes
the incorrect setup of the STREX backoff delay bit due to a wrong
description in the specification.Note that enabling the STREX backoff delay mechanism is done by
leaving the bit *cleared*, while the bit was currently being set by
the proc-v7.S code.[Thomas: adapt to latest mainline, slightly reword the commit log, add
stable markers.]Fixes: de4901933f6d ("arm: mm: Add support for PJ4B cpu and init routines")
Signed-off-by: Nadav Haklai
Signed-off-by: Thomas Petazzoni
Acked-by: Gregory CLEMENT
Acked-by: Jason Cooper
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit ef59a20ba375aeb97b3150a118318884743452a8 upstream.
According to the manuals I have, XScale auxiliary register should be
reached with opc_2 = 1 instead of crn = 1. cpu_xscale_proc_init
correctly uses c1, c0, 1 arguments, but cpu_xscale_do_suspend and
cpu_xscale_do_resume use c1, c1, 0. Correct suspend/resume functions to
also use c1, c0, 1.The issue was primarily noticed thanks to qemu reporing "unsupported
instruction" on the pxa suspend path. Confirmed in PXA210/250 and PXA255
XScale Core manuals and in PXA270 and PXA320 Developers Guides.Harware tested by me on tosa (pxa255). Robert confirmed on pxa270 board.
Tested-by: Robert Jarzmik
Signed-off-by: Dmitry Eremin-Solenikov
Acked-by: Robert Jarzmik
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit 2eb04ae010a8fb165ba7aa56e9aa8e7980887dee upstream.
There is a missing of_node_put() to decrement the device_node
reference counter after a of_find_matching_node() in coherency_init().Fixes: 501f928e0097 ("ARM: mvebu: add a coherency_available() call")
Signed-off-by: Thomas Petazzoni
Acked-by: Gregory CLEMENT
Link: https://lkml.kernel.org/r/1414423955-5933-4-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper
Signed-off-by: Greg Kroah-Hartman -
commit c1a2086e2d8c4eb4e8630ba752e911ec180dec67 upstream.
The removal path for selftest data has an off by one error that causes
the code to dereference beyond the end of the nodes[] array on the first
pass through. The old code only worked by chance on a lot of platforms,
but the bug was recently exposed on aarch64.The fix is simple. Decrement the node count before dereferencing, not
after.Reported-by: Kevin Hilman
Cc: Rob Herring
Cc: Gaurav Minocha -
commit ab74d00a39f70e1bc34a01322bb59f3750ca7a8c upstream.
__earlycon_of_table_sentinel.compatible is a char[128], not a pointer, so
it will never be NULL. Checking it against NULL causes the match loop to
run past the end of the array, and eventually match a bogus entry, under
the following conditions:- Kernel command line specifies "earlycon" with no parameters
- DT has a stdout-path pointing to a UART node
- The UART driver doesn't use OF_EARLYCON_DECLARE (or maybe the console
driver is compiled out)Fix this by checking to see if match->compatible is a non-empty string.
Signed-off-by: Kevin Cernekee
Signed-off-by: Rob Herring
Signed-off-by: Greg Kroah-Hartman -
commit 66865de4314caca30598244b86817e774c188afa upstream.
a9ecdc0fdc54 ("of/irq: Fix lookup to use 'interrupts-extended' property
first") updated the description to say that:- Both 'interrupts' and 'interrupts-extended' may be present
- Software should prefer 'interrupts-extended'
- Software that doesn't comprehend 'interrupts-extended' may use
'interrupts'But there is still a paragraph at the end that prohibits having both and
says 'interrupts' should be preferred.Remove the contradictory text.
Fixes: a9ecdc0fdc54 ("of/irq: Fix lookup to use 'interrupts-extended' property first")
Signed-off-by: Bjorn Helgaas
Acked-by: Brian Norris
Acked-by: Mark Rutland
Signed-off-by: Rob Herring
Signed-off-by: Greg Kroah-Hartman -
commit a1d69c60c44134f64945bbf6a6dfda22eaf4a214 upstream.
This is a specific implementation, is the
multiplexer that has the arch-specific knowledge of which
of the implementations needs to be used, so include that.This issue was revealed by kbuild testing
when was added in
resulting in redefinition of get_unaligned_be16 (and
probably others).Reported-by: Fengguang Wu
Signed-off-by: Johannes Berg
Signed-off-by: Arend van Spriel
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 4c69f05eaa428e37890daf88b86a567ce615570b upstream.
Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.Signed-off-by: Dmitry Torokhov
Acked-by: Arend van Spriel
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 0cd75b19899fd86b51a6480fb8c00dcd85a54591 upstream.
The function chandef_to_chanspec() failed when converting a
chandef with bandwidth set to NL80211_CHAN_WIDTH_20_NOHT. This
was reported by user running the device in AP mode.------------[ cut here ]------------
WARNING: CPU: 0 PID: 304 at
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:381
chandef_to_chanspec.isra.11+0x158/0x184()Modules linked in:
CPU: 0 PID: 304 Comm: hostapd Not tainted 3.16.0-rc7-abb+g64aa90f #8
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (warn_slowpath_common+0x6c/0x8c)
[] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24)
[] (warn_slowpath_null) from [] (chandef_to_chanspec.isra.11+0x158/0x184)
[] (chandef_to_chanspec.isra.11) from [] (brcmf_cfg80211_start_ap+0x1e4/0x614)
[] (brcmf_cfg80211_start_ap) from [] (nl80211_start_ap+0x288/0x414)
[] (nl80211_start_ap) from [] (genl_rcv_msg+0x21c/0x38c)
[] (genl_rcv_msg) from [] (netlink_rcv_skb+0xac/0xc0)
[] (netlink_rcv_skb) from [] (genl_rcv+0x20/0x34)
[] (genl_rcv) from [] (netlink_unicast+0x150/0x20c)
[] (netlink_unicast) from [] (netlink_sendmsg+0x2b8/0x398)
[] (netlink_sendmsg) from [] (sock_sendmsg+0x84/0xa8)
[] (sock_sendmsg) from [] (___sys_sendmsg.part.29+0x268/0x278)
[] (___sys_sendmsg.part.29) from [] (__sys_sendmsg+0x4c/0x7c)
[] (__sys_sendmsg) from [] (ret_fast_syscall+0x0/0x44)
---[ end trace 965ee2158c9905a2 ]---Reported-by: Pontus Fuchs
Reviewed-by: Hante Meuleman
Reviewed-by: Daniel (Deognyoun) Kim
Reviewed-by: Franky (Zhenhui) Lin
Reviewed-by: Pieter-Paul Giesberts
Signed-off-by: Arend van Spriel
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 78579b7c7eb45f0e7ec5e9437087ed21749f9a9c upstream.
As reported by Dmitry, on some Chromebooks there are devices with
corresponding ACPI objects and with unusual system wakeup
configuration. Namely, they technically are wakeup-capable, but the
wakeup is handled via a platform-specific out-of-band mechanism and
the ACPI PM layer has no information on the wakeup capability. As
a result, device_may_wakeup(dev) called from acpi_dev_suspend_late()
returns 'true' for those devices, but the wakeup.flags.valid flag is
unset for the corresponding ACPI device objects, so acpi_device_wakeup()
reproducibly fails for them causing acpi_dev_suspend_late() to return
an error code. The entire system suspend is then aborted and the
machines in question cannot suspend at all.Address the problem by ignoring the device_may_wakeup(dev) return
value in acpi_dev_suspend_late() if the ACPI companion of the device
being handled has wakeup.flags.valid unset (in which case it is clear
that the wakeup is supposed to be handled by other means).This fixes a regression introduced by commit a76e9bd89ae7 (i2c:
attach/detach I2C client device to the ACPI power domain) as the
affected systems could suspend and resume successfully before that
commit.Fixes: a76e9bd89ae7 (i2c: attach/detach I2C client device to the ACPI power domain)
Reported-by: Dmitry Torokhov
Reviewed-by: Dmitry Torokhov
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 upstream.
There is platform refusing to respond QR_EC when SCI_EVT isn't set
which is Acer Aspire V5-573G.By disallowing QR_EC to be issued before the previous one has been
completed we are able to reduce the possibilities to trigger issues on
such platforms.Note that this fix can only reduce the occurrence rate of this issue, but
this issue may still occur when such a platform doesn't clear SCI_EVT
before or immediately after completing the previous QR_EC transaction.
This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on
the assumption that the platforms are able to respond even when SCI_EVT
isn't set.But this patch is still useful as it can help to reduce the number of
scheduled QR_EC work items.Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Reported-and-tested-by: Alexander Mezin
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit f82c458a2c3ffb94b431fc6ad791a79df1b3713e upstream.
The fair reader/writer locks mean that btrfs_clear_path_blocking needs
to strictly follow lock ordering rules even when we already have
blocking locks on a given path.Before we can clear a blocking lock on the path, we need to make sure
all of the locks have been converted to blocking. This will remove lock
inversions against anyone spinning in write_lock() against the buffers
we're trying to get read locks on. These inversions didn't exist before
the fair read/writer locks, but now we need to be more careful.We papered over this deadlock in the past by changing
btrfs_try_read_lock() to be a true trylock against both the spinlock and
the blocking lock. This was slower, and not sufficient to fix all the
deadlocks. This patch adds a btrfs_tree_read_lock_atomic(), which
basically means get the spinlock but trylock on the blocking lock.Signed-off-by: Chris Mason
Signed-off-by: Josef Bacik
Reported-by: Patrick Schmid
Signed-off-by: Greg Kroah-Hartman -
commit 835f252c6debd204fcd607c79975089b1ecd3472 upstream.
https://bugzilla.kernel.org/show_bug.cgi?id=86831
Markus reported that when shutting down mysqld (with AIO support,
on a ext3 formatted Harddrive) leads to a negative number of dirty pages
(underrun to the counter). The negative number results in a drastic reduction
of the write performance because the page cache is not used, because the kernel
thinks it is still 2 ^ 32 dirty pages open.Add a warn trace in __dec_zone_state will catch this easily:
static inline void __dec_zone_state(struct zone *zone, enum
zone_stat_item item)
{
atomic_long_dec(&zone->vm_stat[item]);
+ WARN_ON_ONCE(item == NR_FILE_DIRTY &&
atomic_long_read(&zone->vm_stat[item]) < 0);
atomic_long_dec(&vm_stat[item]);
}[ 21.341632] ------------[ cut here ]------------
[ 21.346294] WARNING: CPU: 0 PID: 309 at include/linux/vmstat.h:242
cancel_dirty_page+0x164/0x224()
[ 21.355296] Modules linked in: wutbox_cp sata_mv
[ 21.359968] CPU: 0 PID: 309 Comm: kworker/0:1 Not tainted 3.14.21-WuT #80
[ 21.366793] Workqueue: events free_ioctx
[ 21.370760] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[ 21.378562] [] (show_stack) from []
(dump_stack+0x24/0x28)
[ 21.385840] [] (dump_stack) from []
(warn_slowpath_common+0x84/0x9c)
[ 21.393976] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x2c/0x34)
[ 21.402800] [] (warn_slowpath_null) from []
(cancel_dirty_page+0x164/0x224)
[ 21.411524] [] (cancel_dirty_page) from []
(truncate_inode_page+0x8c/0x158)
[ 21.420272] [] (truncate_inode_page) from []
(truncate_inode_pages_range+0x11c/0x53c)
[ 21.429890] [] (truncate_inode_pages_range) from
[] (truncate_pagecache+0x88/0xac)
[ 21.439252] [] (truncate_pagecache) from []
(truncate_setsize+0x5c/0x74)
[ 21.447731] [] (truncate_setsize) from []
(put_aio_ring_file.isra.14+0x34/0x90)
[ 21.456826] [] (put_aio_ring_file.isra.14) from
[] (aio_free_ring+0x20/0xcc)
[ 21.465660] [] (aio_free_ring) from []
(free_ioctx+0x24/0x44)
[ 21.473190] [] (free_ioctx) from []
(process_one_work+0x134/0x47c)
[ 21.481132] [] (process_one_work) from []
(worker_thread+0x130/0x414)
[ 21.489350] [] (worker_thread) from []
(kthread+0xd4/0xec)
[ 21.496621] [] (kthread) from []
(ret_from_fork+0x14/0x20)
[ 21.503884] ---[ end trace 79c4bf42c038c9a1 ]---The cause is that we set the aio ring file pages as *DIRTY* via SetPageDirty
(bypasses the VFS dirty pages increment) when init, and aio fs uses
*default_backing_dev_info* as the backing dev, which does not disable
the dirty pages accounting capability.
So truncating aio ring file will contribute to accounting dirty pages (VFS
dirty pages decrement), then error occurs.The original goal is keeping these pages in memory (can not be reclaimed
or swapped) in life-time via marking it dirty. But thinking more, we have
already pinned pages via elevating the page's refcount, which can already
achieve the goal, so the SetPageDirty seems unnecessary.In order to fix the issue, using the __set_page_dirty_no_writeback instead
of the nop .set_page_dirty, and dropped the SetPageDirty (don't manually
set the dirty flags, don't disable set_page_dirty(), rely on default behaviour).With the above change, the dirty pages accounting can work well. But as we
known, aio fs is an anonymous one, which should never cause any real write-back,
we can ignore the dirty pages (write back) accounting by disabling the dirty
pages (write back) accounting capability. So we introduce an aio private
backing dev info (disabled the ACCT_DIRTY/WRITEBACK/ACCT_WB capabilities) to
replace the default one.Reported-by: Markus Königshaus
Signed-off-by: Gu Zheng
Acked-by: Andrew Morton
Signed-off-by: Benjamin LaHaise
Signed-off-by: Greg Kroah-Hartman -
commit 911f632c701d9f15a54076cbaca82e7defb339e0 upstream.
The machine originally use the quirk ALC269_FIXUP_HP_GPIO_MIC1_LED,
but the LED doesn't work at all.After this change, the machine will change to use
ALC269_FIXUP_HP_MUTE_LED_MIC1 through pin_fixup_tbl[], and the LED
works well.BugLink: https://bugs.launchpad.net/bugs/1389497
Tested-by: TieFu Chen
Cc: Kailang Yang
Signed-off-by: Hui Wang
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 413cbf469a19e7662ba5025695bf5a573927105a upstream.
AMD/ATI HDMI controller chip models, we already have a filter to lower
to 32bit DMA, but the rest are supposed to be working with 64bit
although the hardware doesn't really work with 63bit but only with 40
or 48bit DMA. In this patch, we take 40bit DMA for safety for the
AMD/ATI controllers as the graphics drivers does.Signed-off-by: Takashi Iwai
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 6e84a8d7ac3ba246ef44e313e92bc16a1da1b04a upstream.
This patch adds a USB control message delay quirk for a few specific Marantz/Denon
devices. Without the delay the DACs will not work properly and produces the
following type of messages:Nov 15 10:09:21 orwell kernel: [ 91.342880] usb 3-13: clock source 41 is not valid, cannot use
Nov 15 10:09:21 orwell kernel: [ 91.343775] usb 3-13: clock source 41 is not valid, cannot useThere are likely other Marantz/Denon devices using the same USB module which exhibit the
same problems. But as this cannot be verified I limited the patch to the devices
I could test.The following two devices are covered by this path:
- Marantz SA-14S1
- Marantz HD-DAC1Signed-off-by: Jurgen Kramer
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit efbd50d2f62fc1f69a3dcd153e63ba28cc8eb27f upstream.
It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds
the missing deallocation.Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
Acked-by: Matthias Fuchs
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit a1377e5397ab321e21b793ec8cd2b6f12bd3c718 upstream.
When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.The initial commit ff8cbf250b44 ("xhci: clear root port wake on bits"),
which also got into stable, turned out to not work correctly and had to
be reverted, and is now rewritten.Signed-off-by: Lu Baolu
Suggested-by: Alan Stern
Acked-by: Alan Stern
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
commit 8e71a322fdb127814bcba423a512914ca5bc6cf5 upstream.
If a device is halted and reuturns a STALL, then the halted endpoint
needs to be cleared both on the host and device side. The host
side halt is cleared by issueing a xhci reset endpoint command. The device side
is cleared with a ClearFeature(ENDPOINT_HALT) request, which should
be issued by the device driver if a URB reruen -EPIPE.Previously we cleared the host side halt after the device side was cleared.
To make sure the host side halt is cleared in time we want to issue the
reset endpoint command immedialtely when a STALL status is encountered.Otherwise we end up not following the specs and not returning -EPIPE
several times in a row when trying to transfer data to a halted endpoint.Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.)
Tested-by: Felipe Balbi
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
commit c3492dbfa1050debf23a5b5cd2bc7514c5b37896 upstream.
A halted endpoint ring must first be reset, then move the ring
dequeue pointer past the problematic TRB. If we start the ring too
early after reset, but before moving the dequeue pointer we
will end up executing the same problematic TRB again.As we always issue a set transfer dequeue command after a reset
endpoint command we can skip starting endpoint rings at reset endpoint
command completion.Without this fix we end up trying to handle the same faulty TD for
contol endpoints. causing timeout, and failing testusb ctrl_out write
tests.Fixes: e9df17e (USB: xhci: Correct assumptions about number of rings per endpoint.)
Tested-by: Felipe Balbi
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
commit 8daee1352d51a32676b84bddcc0e3252d1caa833 upstream.
These disks have a broken uas implementation, the tag field of the status
iu-s is not set properly, so we need to fall-back to usb-storage for these.Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman -
commit 263e80b43559a6103e178a9176938ce171b23872 upstream.
This wireless mouse receiver needs a reset-resume quirk to properly come
out of reset.BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1165206
Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman -
commit 204ec6e07ea7aff863df0f7c53301f9cbbfbb9d3 upstream.
Add PIDs for new Matrix Orbital GTT series products.
Signed-off-by: Troy Clark
[johan: shorten commit message ]
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit ffcfe30ebd8dd703d0fc4324ffe56ea21f5479f4 upstream.
Signed-off-by: Preston Fick
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit 5d1678a33c731b56e245e888fdae5e88efce0997 upstream.
Fix handling of TTY error flags, which are not bitmasks and must
specifically not be ORed together as this prevents the line discipline
from recognising them.Also insert null characters when reporting overrun errors as these are
not associated with the received character.Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit 855515a6d3731242d85850a206f2ec084c917338 upstream.
Fix reporting of overrun errors, which are not associated with a
character. Instead insert a null character and report only once.Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
