AMD systems which use the C1E workaround in the amd_e400_idle routine
trigger the WARN_ON_ONCE in the broadcast code when onlining a CPU.
The reason is that the idle routine of those AMD systems switches the
cpu into forced broadcast mode early on before the newly brought up
CPU can switch over to high resolution / NOHZ mode. The timer related
CPU1 bringup looks like this:
clockevent_register_device(local_apic);
tick_setup(local_apic);
...
idle()
tick_broadcast_on_off(FORCE);
tick_broadcast_oneshot_control(ENTER)
cpumask_set(cpu, broadcast_oneshot_mask);
halt();
Now the broadcast interrupt on CPU0 sets CPU1 in the
broadcast_pending_mask and wakes CPU1. So CPU1 continues:
local_apic_timer_interrupt()
tick_handle_periodic();
softirq()
tick_init_highres();
cpumask_clr(cpu, broadcast_oneshot_mask);
tick_broadcast_oneshot_control(ENTER)
WARN_ON(cpumask_test(cpu, broadcast_pending_mask);
So while we remove CPU1 from the broadcast_oneshot_mask when we switch
over to highres mode, we do not clear the pending bit, which then
triggers the warning when we go back to idle.
The reason why this is only visible on C1E affected AMD systems is
that the other machines enter the deep sleep states via
acpi_idle/intel_idle and exit the broadcast mode before executing the
remote triggered local_apic_timer_interrupt. So the pending bit is
already cleared when the switch over to highres mode is clearing the
oneshot mask.
The solution is simple: Clear the pending bit together with the mask
bit when we switch over to highres mode.
Stanislaw came up independently with the same patch by enforcing the
C1E workaround and debugging the fallout. I picked mine, because mine
has a changelog :)
Reported-by: poma <pomidorabelisima@gmail.com>
Debugged-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Olaf Hering <olaf@aepfle.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Justin M. Forbes <jforbes@redhat.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1402111434180.21991@ionos.tec.linutronix.de
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The netlink kind (and iproute2 type option) is actually called
'macvtap', not 'macvlan'.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
remove_proc_subtree() doesn't work here as local->ddev has already
been removed, and NULLed out. Use proc_remove() instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes regression caused by commit a16dad7763 "MIPS: Fix
potencial corruption". That commit fixes one corruption scenario in
cost of adding another one, which actually start to cause crashes
on Yeeloong laptop when rtl8187 driver is used.
For correct DMA read operation on machines without DMA coherence, kernel
have to invalidate cache, such it will refill later with new data that
device wrote to memory, when that data is needed to process. We can only
invalidate full cache line. Hence when cache line includes both dma
buffer and some other data (written in cache, but not yet in main
memory), the other data can not hit memory due to invalidation. That
happen on rtl8187 where struct rtl8187_priv fields are located just
before and after small buffers that are passed to USB layer and DMA
is performed on them.
To fix the problem we align buffers and reserve space after them to make
them match cache line.
This patch does not resolve all possible MIPS problems entirely, for
that we have to assure that we always map cache aligned buffers for DMA,
what can be complex or even not possible. But patch fixes visible and
reproducible regression and seems other possible corruptions do not
happen in practice, since Yeeloong laptop works stable without rtl8187
driver.
Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=54391
Reported-by: Petr Pisar <petr.pisar@atlas.cz>
Bisected-by: Tom Li <biergaizi2009@gmail.com>
Reported-and-tested-by: Tom Li <biergaizi2009@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Acked-by: Larry Finger <Larry.Finger@lwfinger.next>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In the original code we shift "AR5K_PHY(256) >> 28" which is zero but
the intent was to shift the return value of ath5k_hw_reg_read() like we
do a couple lines later.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtl_ps_enable_nic() is called from loops that will loop until this function returns true or a
maximum number of retries is performed.
hw_init() returns non-zero on error. In that situation return false to
restore the original design intent to retry hw init when it fails.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Cc: Stable <stable@vger.kernel.org>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans
The observable symptoms in dmesg can be:
- underruns from ALSA playback
- clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled):
[ 250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100
[ 250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable
[ 250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10
[ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[ 250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32)
[ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0
[ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc
[ 250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!!
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x40000000, ofdm_index=0xc
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <===
[ 250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1
[ 250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3
[ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[ 250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore
[ 251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505)
The exact code flow that causes that is:
1. wpa_supplicant send a start_scan request to the nl80211 driver
2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE
3. rtl_ips_nic_on is called which disable local irqs
4. rtl92c_phy_set_rf_power_state() is called
5. rtl_ps_enable_nic() is called and hw_init()is executed and then the interrupts on the device are enabled
A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled
but a quick and dirty solution that has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Cc: Stable <stable@vger.kernel.org>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If an NFS client attempts to get a lock (using NLM) and the lock is
not available, the server will remember the request and when the lock
becomes available it will send a GRANT request to the client to
provide the lock.
If the client already held an adjacent lock, the GRANT callback will
report the union of the existing and new locks, which can confuse the
client.
This happens because __posix_lock_file (called by vfs_lock_file)
updates the passed-in file_lock structure when adjacent or
over-lapping locks are found.
To avoid this problem we take a copy of the two fields that can
be changed (fl_start and fl_end) before the call and restore them
afterwards.
An alternate would be to allocate a 'struct file_lock', initialise it,
use locks_copy_lock() to take a copy, then locks_release_private()
after the vfs_lock_file() call. But that is a lot more work.
Reported-by: Olaf Kirch <okir@suse.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
--
v1 had a couple of issues (large on-stack struct and didn't really work properly).
This version is much better tested.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Commit 6ae668cc19 (drm/i2c: tda998x: check the CEC device creation)
introduced a memory leak in the error path of tda998x_encoder_init
Picked up by the nightly Coverity scan. CID 1174076
Signed-off-by: Dave Jones <davej@fedoraproject.org>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
\E[3J console code (secure clear screen) needs to update_screen(vc)
in order to write-through blanks into off-screen video memory.
This has been removed accidentally in 3.6 by:
commit 81732c3b2f
Author: Jean-François Moine <moinejf@free.fr>
Date: Thu Sep 6 19:24:13 2012 +0200
tty vt: Fix line garbage in virtual console on command line edition
Signed-off-by: Petr Písař <petr.pisar@atlas.cz>
Cc: stable <stable@vger.kernel.org> # 3.6
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Exar XR17V35x family of UARTs have an additional fractional divisor
register (DLD) which was not being used. Calculate and set this
register for these devices to reduce their baud rate error.
Signed-off-by: Joe Schultz <jschultz@xes-inc.com>
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When echoes cannot be flushed to output (usually because the tty
has no more write room) and L_ECHO is subsequently turned off, then
when L_ECHO is turned back on, stale echoes are output.
Output completed echoes regardless of the L_ECHO setting:
1. before normal writes to that tty
2. if the tty was stopped by soft flow control and is being
restarted
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: <stable@vger.kernel.org> # 3.13.x
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8b9ade9f74 coming from Viresh Kumar "tty: serial: sirfsoc: drop
uart_port->lock before calling tty_flip_buffer_push()" broke sirfsoc uart
driver by knic:
[ 5.129122] BUG: spinlock already unlocked on CPU#0, ip6tables/1331
[ 5.132554] lock: sirfsoc_uart_ports+0x4/0x8a0, .magic: dead4ead,
.owner: <none>/-1, .owner_cpu: -1
[ 5.141651] CPU: 0 PID: 1331 Comm: ip6tables Tainted: G
W O 3.10.16 #3
[ 5.148866] [<c0013528>] (unwind_backtrace+0x0/0xe0) from
[<c0010e70>] (show_stack+0x10/0x14)
[ 5.157362] [<c0010e70>] (show_stack+0x10/0x14) from
[<c01a5e68>] (do_raw_spin_unlock+0x40/0xc8)
[ 5.166125] [<c01a5e68>] (do_raw_spin_unlock+0x40/0xc8) from
[<c03ff8b4>] (_raw_spin_unlock+0x8/0x40)
[ 5.175322] [<c03ff8b4>] (_raw_spin_unlock+0x8/0x40) from
[<c0203fcc>] (sirfsoc_uart_pio_rx_chars+0xa4/0xc0)
[ 5.185120] [<c0203fcc>]
(sirfsoc_uart_pio_rx_chars+0xa4/0xc0) from [<c0204fb8>]
(sirfsoc_rx_tmo_process_tl+0xdc/0x1e0)
[ 5.195875] [<c0204fb8>]
(sirfsoc_rx_tmo_process_tl+0xdc/0x1e0) from [<c0024b50>]
(tasklet_action+0x8c/0xec)
[ 5.205673] [<c0024b50>] (tasklet_action+0x8c/0xec) from
[<c00242a8>] (__do_softirq+0xec/0x1d4)
[ 5.214347] [<c00242a8>] (__do_softirq+0xec/0x1d4) from
[<c0024428>] (do_softirq+0x48/0x54)
[ 5.222674] [<c0024428>] (do_softirq+0x48/0x54) from
[<c0024690>] (irq_exit+0x74/0xc0)
[ 5.230573] [<c0024690>] (irq_exit+0x74/0xc0) from
[<c000e1e8>] (handle_IRQ+0x6c/0x90)
[ 5.238465] [<c000e1e8>] (handle_IRQ+0x6c/0x90) from
[<c000d500>] (__irq_svc+0x40/0x70)
[ 5.246446] [<c000d500>] (__irq_svc+0x40/0x70) from
[<c0092e7c>] (mark_page_accessed+0xc/0x68)
[ 5.255034] [<c0092e7c>] (mark_page_accessed+0xc/0x68) from
[<c00a2a4c>] (unmap_single_vma+0x3bc/0x550)
[ 5.264402] [<c00a2a4c>] (unmap_single_vma+0x3bc/0x550) from
[<c00a3b4c>] (unmap_vmas+0x44/0x54)
[ 5.273164] [<c00a3b4c>] (unmap_vmas+0x44/0x54) from
[<c00a81a8>] (exit_mmap+0xc4/0x1e0)
[ 5.281233] [<c00a81a8>] (exit_mmap+0xc4/0x1e0) from
[<c001bb78>] (mmput+0x3c/0xdc)
[ 5.288868] [<c001bb78>] (mmput+0x3c/0xdc) from [<c0021b0c>]
(do_exit+0x30c/0x828)
[ 5.296413] [<c0021b0c>] (do_exit+0x30c/0x828) from
[<c0022dac>] (do_group_exit+0x4c/0xb0)
[ 5.304653] [<c0022dac>] (do_group_exit+0x4c/0xb0) from
[<c0022e20>] (__wake_up_parent+0x0/0x18)
Root cause:
the commit dropped uart_port->lock before calling tty_flip_buffer_push(), but in sirfsoc-uart,
sirfsoc_uart_pio_rx_chars() can be called by sirfsoc_rx_tmo_process_tl(). here uart_port->lock
has not been taken yet. so that caused unpaired lock/unlock.
Solution:
This patch is doing a quick fix for that, it adds spin_lock/unlock(&port->lock) protect to
sirfsoc_uart_pio_rx_chars() in sirfsoc_rx_tmo_process_tl() to keep spin_lock/unlock in pair.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Cc: stable <stable@vger.kernel.org> # 3.12
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aparently 9865 uses standard BAR encoding scheme (unlike 99xx cards).
Current pci_netmos_9900_setup() uses wrong BAR indices for the 9865 PCI
device, function 2. Using standard BAR indices makes all 6 ports work
for me. Thus disable the NetMos 9900 quirk for NetMos 9865 pci device.
For the reference, here is the relevant part of lspci for my device:
02:07.0 Serial controller: MosChip Semiconductor Technology Ltd. PCI
9865 Multi-I/O Controller (prog-if 02 [16550])
Subsystem: Device a000:1000
Flags: bus master, medium devsel, latency 32, IRQ 17
I/O ports at ac00 [size=8]
Memory at fcfff000 (32-bit, non-prefetchable) [size=4K]
Memory at fcffe000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [48] Power Management version 2
Kernel driver in use: serial
02:07.1 Serial controller: MosChip Semiconductor Technology Ltd. PCI
9865 Multi-I/O Controller (prog-if 02 [16550])
Subsystem: Device a000:1000
Flags: bus master, medium devsel, latency 32, IRQ 18
I/O ports at a800 [size=8]
Memory at fcffd000 (32-bit, non-prefetchable) [size=4K]
Memory at fcffc000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [48] Power Management version 2
Kernel driver in use: serial
02:07.2 Communication controller: MosChip Semiconductor Technology Ltd.
PCI 9865 Multi-I/O Controller
Subsystem: Device a000:3004
Flags: bus master, medium devsel, latency 32, IRQ 19
I/O ports at a400 [size=8]
I/O ports at a000 [size=8]
I/O ports at 9c00 [size=8]
I/O ports at 9800 [size=8]
Memory at fcffb000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [48] Power Management version 2
Kernel driver in use: serial
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit eafbe67f84,
n_tty: Refactor input_available_p() by call site
broke poll() when TIME_CHAR(tty) and MIN_CHAR(tty) are both 0.
When TIME_CHAR and MIN_CHAR are both 0, input is available if the
read_cnt is 1 (not 0).
Reported-by: Eric Dumazet <edumazet@google.com>
Tested-by: Eric Dumazet <edumazet@google.com>
Reported-by: Stephane Eranian <eranian@google.com>
Tested-by: David Ahern <dsahern@gmail.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the gpio is not yet available we better also
defer the probing in the rs485 case.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CONFIG_PM will be set if either or both CONFIG_PM_SLEEP and
CONFIG_PM_RUNTIME is set. Compiling the driver with !CONFIG_PM_SLEEP causes
following compilation warnings:
drivers/tty/serial/8250/8250_dw.c:404:12: warning: ‘dw8250_suspend’ defined but not used [-Wunused-function]
drivers/tty/serial/8250/8250_dw.c:413:12: warning: ‘dw8250_resume’ defined but not used [-Wunused-function]
Fix this by using CONFIG_PM_SLEEP instead.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently the info message about a missing wakeirq for uart is printed
every time the serial driver's startup function is called. This happens
multiple times and not just once.
This can cause lots of extra messages at boot time, slowing things down. It is
caused by commit 2a0b965cfb (serial: omap: Add support for optional wake-up)
which was applied for v3.13-rc1.
This patch moves the infomessage to the probe function to display it
only once.
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: stable <stable@vger.kernel.org> # 3.13
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the device has only Ethernet ports, don't try to allocate range
of steerable UD QPs since they aren't needed. This fixes an issue
where mlx4 VFs tried to allocate a range of UD steerable QPs, but
failed to do so.
Fixes: c1c9850112 ("IB/mlx4: Add support for steerable IB UD QPs")
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
If CONFIG_X86_SMAP is disabled, smap_violation() tests for conditions
which are incorrect (as the AC flag doesn't matter), causing spurious
faults.
The dynamic disabling of SMAP (nosmap on the command line) is fine
because it disables X86_FEATURE_SMAP, therefore causing the
static_cpu_has() to return false.
Found by Fengguang Wu's test system.
[ v3: move all predicates into smap_violation() ]
[ v2: use IS_ENABLED() instead of #ifdef ]
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhost
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.7+
If SMAP support is not compiled into the kernel, don't enable SMAP in
CR4 -- in fact, we should clear it, because the kernel doesn't contain
the proper STAC/CLAC instructions for SMAP support.
Found by Fengguang Wu's test system.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhost
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.7+
Retrying indefinitely places too much trust on the aux implementation of
the sink devices.
Reported-by: Daniel Martin <consume.noise@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71267
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Tested-by: Theodore Ts'o <tytso@mit.edu>
Tested-by: Sree Harsha Totakura <freedesktop@h.totakura.in>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Give more slack to sink devices before retrying on native aux
defer. AFAICT the 100 us timeout was not based on the DP spec.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org (on Jani's request)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
NICs supported by iwldvm don't handle well TX AMPDU.
Disable it by default, still leave the possibility to
the user to force enable it with a debug parameter.
NICs supported by iwlmvm don't suffer from the same issue,
leave TX AMPDU enabled by default for these.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
I started noticing problems with KVM guest destruction on Linux
3.12+, where guest memory wasn't being cleaned up. I bisected it
down to the commit introducing the new 'asm goto'-based atomics,
and found this quirk was later applied to those.
Unfortunately, even with GCC 4.8.2 (which ostensibly fixed the
known 'asm goto' bug) I am still getting some kind of
miscompilation. If I enable the asm_volatile_goto quirk for my
compiler, KVM guests are destroyed correctly and the memory is
cleaned up.
So make the quirk unconditional for now, until bug is found
and fixed.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/1392274867-15236-1-git-send-email-steven@uplinklabs.net
Link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Russell King observed 'wierd' looking output from debugfs, and also suggested
better ways of getting device names (use KBUILD_MODNAME, dev_name())
This patch addresses these issues to make the debugfs output correct and better
looking.
While at it, replace seq_printf with seq_puts to remove the checkpatch.pl
warnings.
Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Interestingly, the raid5 code can actually prevent double initialization and
hence can use the following simplified form of callback registration:
register_cpu_notifier(&foobar_cpu_notifier);
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
put_online_cpus();
A hotplug operation that occurs between registering the notifier and calling
get_online_cpus(), won't disrupt anything, because the code takes care to
perform the memory allocations only once.
So reorganize the code in raid5 this way to fix the deadlock with callback
registration.
Cc: linux-raid@vger.kernel.org
Cc: stable@vger.kernel.org (v2.6.32+)
Fixes: 36d1c6476b
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
[Srivatsa: Fixed the unregister_cpu_notifier() deadlock, added the
free_scratch_buffer() helper to condense code further and wrote the changelog.]
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Though my old email address continues to work as alias, updating
to the new address as it's shorter, easier and more appropriate.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Remove the reporting of energy since it does not provide any useful
information about the state of the driver and will be a maintainance
headache going forward since the RAPL energy units register is not
architectural and subject to change between micro-architectures
References: https://bugzilla.kernel.org/show_bug.cgi?id=69831
Fixes: b69880f9cc (intel_pstate: Add trace point to report internal state.)
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Enabling some of the mvebu platforms in the multiplatform config for ARM
enabled these drivers, which also triggered a bunch of warnings when LPAE
is enabled (thus making phys_addr_t 64-bit).
Most changes are switching printk formats, but also a bit of changes to what
used to be array-based pointer arithmetic that could just be done with the
address types instead.
The warnings were:
drivers/dma/mv_xor.c: In function 'mv_xor_tx_submit':
drivers/dma/mv_xor.c:500:3: warning: format '%x' expects argument of type
'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]
drivers/dma/mv_xor.c: In function 'mv_xor_alloc_chan_resources':
drivers/dma/mv_xor.c:553:13: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
drivers/dma/mv_xor.c:555:4: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_memcpy':
drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat]
drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat]
drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_xor':
drivers/dma/mv_xor.c:628:2: warning: format '%u' expects argument of type
'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat]
Acked-by: Vinod Koul <vinod.koul@intel.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Olof Johansson <olof@lixom.net>
Need to take into account that protection sg_list
(copy-buffer) may consist of multiple entries.
Changes from v0:
- Changed commit description
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete. Thus, kstrtoul() should be
used.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The CMD_T_FAILED flag is set used in one place to record the result of a
trivial test, and it is only tested once, few lines later. We might as
well make the code simpler and easier to read by directly doing the test
of "success" where we want to use it.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch fixes Status SNACK handling of BegRun=0 to allow
for all unacknowledged respones to be resent, instead of
always assuming that BegRun would be an explicit value less
than the current ExpStatSN.
Reported-by: santosh kulkarni <santosh.kulkarni@calsoftinc.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Commit fbfe858fea ("target_core_spc: Include target device
descriptor in VPD page 83") added a new length variable, but (due to a
cut and paste mistake?) just checks scsi_name_len against 256 twice.
Fix this to check scsi_target_len for overflow too.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The only place this struct member is touched is in one INIT_LIST_HEAD.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch changes core_alua_state_lba_dependent() to use do_div()
instead sector_div() to avoid the following link error on 32-bit
with CONFIG_LBDAF=n as reported by Jim:
buildlog-1391099072.txt-drivers/built-in.o: In function `target_alua_state_check':
buildlog-1391099072.txt-(.text+0x928d93): undefined reference to `__umoddi3'
buildlog-1391099072.txt:make: *** [vmlinux] Error 1 --
buildlog-1391101753.txt- CC init/version.o
buildlog-1391101753.txt- LD init/built-in.o
buildlog-1391101753.txt-drivers/built-in.o: In function `core_alua_state_lba_dependent':
buildlog-1391101753.txt-/home/jim/linux/drivers/target/target_core_alua.c:503: undefined reference to `__umoddi3'
buildlog-1391101753.txt:make: *** [vmlinux] Error 1
Reported-by: Jim Davis <jim.epost@gmail.com>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch addresses a >= v3.11 free-after-use regression
in core_scsi3_emulate_pro_register() that was introduced
in the following commit:
commit bc118fe4c4
Author: Andy Grover <agrover@redhat.com>
Date: Thu May 16 10:41:04 2013 -0700
target: Further refactoring of core_scsi3_emulate_pro_register()
To avoid the free-after-use, save an type value before hand, and
only call core_scsi3_put_pr_reg() with a valid *pr_reg.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Andy Grover <agrover@redhat.com>
Cc: <stable@vger.kernel.org> #3.11+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
- Fix ARM and Xen FIFO not working.
- Remove more Xen ia64 vestigates.
- Fix UAPI missing Xen files.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJS+j6MAAoJEFjIrFwIi8fJnwsH/2KAR3OU6Xye10bXzHVf/SLD
C7q7OR0tYPSWAesJ+W2B0pzrWbs4sZF+rr0ctLPH0neE6dqxiv2fypT5WHCQDS4E
WLmFtzwxVOXr4wy7vCH5VWP9Xc8ACLnyFHrQXycT7kV4+jlcHC2DkeiJ02bKtUR9
1MgUXem8OrdLvtvKMG7Zlw8c5xgJ5QQskCMMja1DjkRtUYnpgxQk/gqNhf+c20zj
NeRBSvwi2zxYwyH7l26zGusk08cvNEBKDnZaxXsraHXIFMDaLdkmWBEp8Y5Bjn+D
xWHofrRpARPKSODL9wN0ozUdKEVFmlMwfiHB0OqY/rHip3+3ceYJDTZ7brjV3gE=
=i0aW
-----END PGP SIGNATURE-----
Merge tag 'stable/for-linus-3.14-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull Xen bugfixes from Konrad Rzeszutek Wilk:
"This has an healthy amount of code being removed - which we do not use
anymore (the only user of it was ia64 Xen which had been removed
already). The other bug-fixes are to make Xen ARM be able to use the
new event channel mechanism and proper export of header files to
user-space.
Summary:
- Fix ARM and Xen FIFO not working.
- Remove more Xen ia64 vestigates.
- Fix UAPI missing Xen files"
* tag 'stable/for-linus-3.14-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
ia64/xen: Remove Xen support for ia64 even more
xen: install xen/gntdev.h and xen/gntalloc.h
xen/events: bind all new interdomain events to VCPU0
Set the return variable to an error code as done elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Set the return variable to an error code as done elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Make sure all guest-backed object commands are properly packed.
Have the command verifier treat uninitialized command entries as invalid
rather than dereferencing NULL pointers.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Cc: stable@vger.kernel.org
Reported-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
If an ext4 file system is created by some tool other than mke2fs
(perhaps by someone who has a pathalogical fear of the GPL) that
doesn't set one or the other of the EXT2_FLAGS_{UN}SIGNED_HASH flags,
and that file system is then mounted read-only, don't try to modify
the s_flags field. Otherwise, if dm_verity is in use, the superblock
will change, causing an dm_verity failure.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
Two driver fixes, one fixing the mapping of interrupts on da9055 (which
previously wouldn't have worked at all) and a fix for reference counting
OF nodes in the max14577 driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJS+2B5AAoJELSic+t+oim9+pcP/1DexaQDDkebFHiIkoLiNlt1
EEXqAnB3ATS1BdCWzjlPVMRKU62fGpUwXBni1vQnb7d5SzhWAwRaL1socQtx0VoI
8G7xkIRIHthxa+SMCV91Juh9vif+Kg1HQYBAdOXreXQJNWMhhANP4hdQxFV1rt6K
/jRMnmxR9LvskIvJGxGBem5MG8mayK4gS+OUDMPQ2+eXCuhcRKl6FmQVx+3qtlRL
qw+ep9dLTnNaxwhRkimkV27pmB/X6/jRnUCCB+/qd325WVwT7dkCpSqSMfaN+AOF
P1rJMatn9YZpOXFIToM1f3DCoS6KD4cnPO8GkojJf8DREf62/OkTFGUY0OQCI+RQ
VRU0/rM8KvaxJydxqcCbxV7OQ0oVq4UcptBZx4JwQWazgn8Ge91TskCpPepA/LpM
x/U+RJFOXQZKgPcELYOMdcXOIWLBpMv6ZVYsWFmLH9pTowhxEhWlschx3Q+iN7m1
v8jTjvAlTzND3GyoZYzBSNFmsaR0i+VQoFCybrwYnuRLWRfWE3L6HOBdC7tS+aQ5
2IIomLMJ5I4qXXoSKmo8xzVxgBD9tlEuEMlVaZQ6f1tfxDuK/O1m2U1/0s0DKdPW
kUm6JGp7U41NubO0Q/e2BsM/Mp6UX68QtVs/c/n9aCRZml6Qg4sy5cW6JStYhN3E
tdZaNfzjPHH+1pPvXZsE
=bibl
-----END PGP SIGNATURE-----
Merge tag 'regulator-v3.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"Two driver fixes, one fixing the mapping of interrupts on da9055
(which previously wouldn't have worked at all) and a fix for reference
counting OF nodes in the max14577 driver"
* tag 'regulator-v3.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: da9055: Remove use of regmap_irq_get_virq()
regulator: max14577: Add missing of_node_put
- Get #ifdef's right in the <linux/gpio/consumer.h> header.
- Minor fixes to tb10x, clps711x, bcm281xx, intel-mid and
xtensa GPIO drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJS+4lBAAoJEEEQszewGV1zFzIQAKNEGIZrm+GdEKULoJ2E0SIN
MzXRgZV3xiz7giroSdbiF+MBb6rE/0Ixa8EnrZ1JBz+OXCEYKYOS/TXbDNPAnjU2
OI+4aiGUe7cb+Y787z/tggw01twaCYISbdoST+RHwtRi+fizSI0nLLDx3iXMb24t
1EUjQm/Gv+X3zSwt9zYpv3qO/tiQxf6SVTnYOuGS2DDJX6tXwxpFmlGZGf78cBTs
2SdfxZmrDU8M+Mqul4i4BmIVfUsgROZaD7YeYVu7tJp2aPyPgPz6PC1YrxYhxOZH
w4mOhao+anDM8IWBu2jLn6CBl4QN0tgKZJ65dm58wce55q8q/8McOqrSWR9THzAy
W9niY430MXuY1M2ZB1vsJP0ICR5wSKWf6NkIJOsWVTVLDP4JT3kQoOV+zCTHi+Y8
UarlFgf54OazF8y2sUcXgSKHIntjmyU/sT04d+27k6RkJl9Nvu7kzRXu+hZBNiEj
M00E89NxSnUoKQhp5WFcLBBt1MzFxhxRu/Z7EbdkrKIsiIs0iYpZ2met93RjCp/O
zhoKHmyOLuIGqozRUeQvGS4E8J1Gw2c9opIVnqkF7cuQx5l/Au/OGHMB4A5AVwEa
ywV+ipxbI+fVlCbRNFAiKhjHAHsK3jDWEsT7vANSy5lRaegL9RCTvMfj/GP34QAG
gxG2UXLwp37wevGHsV1s
=pj2O
-----END PGP SIGNATURE-----
Merge tag 'gpio-v3.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"Here are some accumulated patches with small fixes for this and that
in a few GPIO drivers, and a more important fix to an #ifdef in the
GPIO consumer header.
Summary:
- Get #ifdef's right in the <linux/gpio/consumer.h> header.
- Minor fixes to tb10x, clps711x, bcm281xx, intel-mid and xtensa GPIO
drivers"
* tag 'gpio-v3.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: consumer.h: Move forward declarations outside #ifdef
gpio: tb10x: GPIO_TB10X needs to select GENERIC_IRQ_CHIP
gpio: clps711x: Add module alias to support module auto loading
gpio: bcm281xx: Update MODULE_AUTHOR
gpio: intel-mid: fix the incorrect return of idle callback
gpio: xtensa: fix build when XCHAL_HAVE_CP is 0
A few driver and documentation fixes, plus a fix for double error
handling which had crept in due to the confusing documentation - it
wasn't clear if the core or the driver was responsible for cleanup
in error cases so both tried to do it with unfortunate results.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJS+haUAAoJELSic+t+oim9wLMP/idNnHkp7sNPrc6dlC+ZpFEY
Dat8RJCO0NAEZIO/CBWaCx47WMVj51VVFxWXf/fp6djwPFcG0BY6OU2xixEOZn//
4u2nmCWA5bQCYBaItxKggZe407/vaBU+9R6XIK5mMHGQyrEZX/88z4N61S4CzrK4
F0GJO1KW3ypi4jI6193Cwuw1T6Gr3GYzu/gD5Yo1kZq5hTRoIt/gFSrolH9Z2yXS
YOJWTWTXzrtGJ/UVD09ukjV9pdxk6qNHp0jtGe+H3RGditPyWuPyttWZIPKR6zdl
GCd11oIGOjzSFbFwDHXocKP+o2oL8Xc6HoD6GK2LHGnHjXO2OZasVsEuQXAlRUSR
X7jr6i+NXiFwuKfbLMdbRahfUWDkFp2rhyJvWpgLZg26dyHiHvpT5CIfT/ep948K
PEoUeXYZXR8u3LgG+WVCcZaVL1VUyDCrvSzVL3C3vx0yGuna1nj7ybKzPPtb96Ub
XB4qNow4FfvubM4ierjZwjZqTSlMjPeXGH1hMUtZYQpUGCS1TuDMElAtWKAxd3ip
7aESg+b+kkfqUulZ9ObGf1K3h7MhH52/sqKbBWUi3DS2BnCGIEqkl+qfBnqBSHwS
cNxCgIg4ohxkEt3DUH1T2+8vAwQSawhjlS/4h+Al+tdzG4HAP7D/cDaCBWFiNf+7
vqvISqHUdpKLPYYF4sON
=rORX
-----END PGP SIGNATURE-----
Merge tag 'spi-v3.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A few driver and documentation fixes, plus a fix for double error
handling which had crept in due to the confusing documentation - it
wasn't clear if the core or the driver was responsible for cleanup in
error cases so both tried to do it with unfortunate results"
* tag 'spi-v3.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: nuc900: Set SPI_LSB_FIRST for master->mode_bits if hw->pdata->lsb is true
spi: rspi: Document support for Renesas QSPI in Kconfig
spi: Fix crash with double message finalisation on error handling
spi: correct the transfer_one_message documentation wording
spi: document the transfer_one spi_master callback
spi: spi.h: clarify the documentation of transfer_one
Thomas Gleixner