Takashi Iwai [Tue, 10 Mar 2015 11:39:12 +0000 (12:39 +0100)]
ASoC: wm8904: Fix wrong value references for boolean kctl
[ Upstream commit
eaddf6fd959074f6a6e71deffe079c71eef35da6 ]
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 10 Mar 2015 11:39:11 +0000 (12:39 +0100)]
ASoC: wm8903: Fix wrong value references for boolean kctl
[ Upstream commit
24cc883c1fd16df34211ae41624aa6d3cd906693 ]
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 10 Mar 2015 11:39:09 +0000 (12:39 +0100)]
ASoC: wm2000: Fix wrong value references for boolean kctl
[ Upstream commit
00a14c2968e3d55817e0fa35c78106ca840537bf ]
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 10 Mar 2015 11:39:10 +0000 (12:39 +0100)]
ASoC: wm8731: Fix wrong value references for boolean kctl
[ Upstream commit
bd14016fbf31aa199026f1e2358eab695f374eb1 ]
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 10 Mar 2015 11:39:08 +0000 (12:39 +0100)]
ASoC: tas5086: Fix wrong value references for boolean kctl
[ Upstream commit
4c523ef61160b7d478371ddc9f48c8ce0a00d675 ]
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 10 Mar 2015 11:39:14 +0000 (12:39 +0100)]
ASoC: wm8960: Fix wrong value references for boolean kctl
[ Upstream commit
b4a18c8b1af15ebfa9054a3d2aef7b0a7e6f2a05 ]
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 10 Mar 2015 11:39:06 +0000 (12:39 +0100)]
ASoC: es8238: Fix wrong value references for boolean kctl
[ Upstream commit
d223b0e7fcfecc23380e7de45eb6a0e7b328c17c ]
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 10 Mar 2015 11:39:05 +0000 (12:39 +0100)]
ASoC: cs4271: Fix wrong value references for boolean kctl
[ Upstream commit
e8371aa0fecb73fb8a4b2e0296b025b11e7d6229 ]
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Paul Handrigan <Paul.Handrigan@cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 10 Mar 2015 11:39:07 +0000 (12:39 +0100)]
ASoC: pcm1681: Fix wrong value references for boolean kctl
[ Upstream commit
d7f58db49d9ad92bdb12d21fdc2308b76bc2ed38 ]
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Eric Nelson [Fri, 27 Feb 2015 15:06:45 +0000 (08:06 -0700)]
ASoC: sgtl5000: remove useless register write clearing CHRGPUMP_POWERUP
[ Upstream commit
c7d910b87d3c8e9fcf4077089ca4327c12eee099 ]
The SGTL5000_CHIP_ANA_POWER register is cached. Update the cached
value instead of writing it directly.
Patch inspired by Russell King's more colorful remarks in this
patch:
https://github.com/SolidRun/linux-imx6-3.14/commit/dd4bf6a
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Lars-Peter Clausen [Fri, 27 Feb 2015 13:13:04 +0000 (14:13 +0100)]
ASoC: sn95031: Fix control-less DAPM routes
[ Upstream commit
cdd3d2a93f08823a0b9802147dc28c99029dfdfd ]
Routes without a control must use NULL for the control name. The sn95031
driver uses "NULL" instead in a few places. Previous to commit
5fe5b767dc6f
("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
the DAPM core silently ignored non-NULL controls on non-mixer and non-mux
routes. But starting with that commit it will complain and not add the
route breaking the sn95031 driver in the process.
This patch replaces the incorrect "NULL" control name with NULL to fix the
issue.
Fixes:
5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Lars-Peter Clausen [Fri, 27 Feb 2015 13:13:02 +0000 (14:13 +0100)]
ASoC: ak4671: Fix control-less DAPM routes
[ Upstream commit
ce9594c6b332fd6fe464e22a83b0e6e0a287aac6 ]
Routes without a control must use NULL for the control name. The ak4671
driver uses "NULL" instead in a few places. Previous to commit
5fe5b767dc6f
("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
the DAPM core silently ignored non-NULL controls on non-mixer and non-mux
routes. But starting with that commit it will complain and not add the
route breaking the ak4671 driver in the process.
This patch replaces the incorrect "NULL" control name with NULL to fix the
issue.
Fixes:
5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Lars-Peter Clausen [Fri, 27 Feb 2015 13:13:03 +0000 (14:13 +0100)]
ASoC: da732x: Fix control-less DAPM routes
[ Upstream commit
8e6a75c102f8e232b599a06e06731d8c5d5f2c5d ]
Routes without a control must use NULL for the control name. The da732x
driver uses "NULL" instead in a few places. Previous to commit
5fe5b767dc6f
("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
the DAPM core silently ignored non-NULL controls on non-mixer and non-mux
routes. But starting with that commit it will complain and not add the
route breaking the da732x driver in the process.
This patch replaces the incorrect "NULL" control name with NULL to fix the
issue.
Fixes:
5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Sasha Levin [Sat, 4 Apr 2015 02:46:37 +0000 (22:46 -0400)]
Linux 3.18.11
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Nicholas Bellinger [Fri, 27 Feb 2015 11:54:13 +0000 (03:54 -0800)]
target/pscsi: Fix NULL pointer dereference in get_device_type
[ Upstream commit
215a8fe4198f607f34ecdbc9969dae783d8b5a61 ]
This patch fixes a NULL pointer dereference OOPs with pSCSI backends
within target_core_stat.c code. The bug is caused by a configfs attr
read if no pscsi_dev_virt->pdv_sd has been configured.
Reported-by: Olaf Hering <olaf@aepfle.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Nicholas Bellinger [Mon, 23 Feb 2015 08:57:51 +0000 (00:57 -0800)]
iscsi-target: Avoid early conn_logout_comp for iser connections
[ Upstream commit
f068fbc82e7696d67b1bb8189306865bedf368b6 ]
This patch fixes a iser specific logout bug where early complete()
of conn->conn_logout_comp in iscsit_close_connection() was causing
isert_wait4logout() to complete too soon, triggering a use after
free NULL pointer dereference of iscsi_conn memory.
The complete() was originally added for traditional iscsi-target
when a ISCSI_LOGOUT_OP failed in iscsi_target_rx_opcode(), but given
iser-target does not wait in logout failure, this special case needs
to be avoided.
Reported-by: Sagi Grimberg <sagig@mellanox.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Slava Shwartsman <valyushash@gmail.com>
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Nicholas Bellinger [Thu, 5 Mar 2015 03:28:24 +0000 (03:28 +0000)]
target: Fix virtual LUN=0 target_configure_device failure OOPs
[ Upstream commit
5f7da044f8bc1cfb21c962edf34bd5699a76e7ae ]
This patch fixes a NULL pointer dereference triggered by a late
target_configure_device() -> alloc_workqueue() failure that results
in target_free_device() being called with DF_CONFIGURED already set,
which subsequently OOPses in destroy_workqueue() code.
Currently this only happens at modprobe target_core_mod time when
core_dev_setup_virtual_lun0() -> target_configure_device() fails,
and the explicit target_free_device() gets called.
To address this bug originally introduced by commit
0fd97ccf45, go
ahead and move DF_CONFIGURED to end of target_configure_device()
code to handle this special failure case.
Reported-by: Claudio Fleiner <cmf@daterainc.com>
Cc: Claudio Fleiner <cmf@daterainc.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: <stable@vger.kernel.org> # v3.7+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Bart Van Assche [Wed, 18 Feb 2015 14:33:58 +0000 (15:33 +0100)]
target: Fix reference leak in target_get_sess_cmd() error path
[ Upstream commit
7544e597343e2166daba3f32e4708533aa53c233 ]
This patch fixes a se_cmd->cmd_kref leak buf when se_sess->sess_tearing_down
is true within target_get_sess_cmd() submission path code.
This se_cmd reference leak can occur during active session shutdown when
ack_kref=1 is passed by target_submit_cmd_[map_sgls,tmr]() callers.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: <stable@vger.kernel.org> # 3.6+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Vignesh R [Tue, 10 Feb 2015 05:35:42 +0000 (11:05 +0530)]
ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx
[ Upstream commit
7d53d25578486d65bd7cd242bc7816b40e55e62b ]
ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck.
The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the
functional clock of pwmss (l4ls_gclk).
Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk.
Fixes:
4da1c67719f61 ("add tbclk data for ehrpwm")
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Vignesh R [Tue, 10 Feb 2015 05:35:41 +0000 (11:05 +0530)]
ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx
[ Upstream commit
6e22616eba7e25fac5aa6cb6563471afa1815ec2 ]
ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck.
The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the
functional clock of pwmss (l4ls_gclk).
Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk.
Fixes:
9e100ebafb91: ("Fix ehrpwm tbclk data")
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Ravikumar Kattekola [Sat, 31 Jan 2015 17:06:44 +0000 (22:36 +0530)]
ARM: dts: DRA7x: Fix the bypass clock source for dpll_iva and others
[ Upstream commit
d2192ea09858a8535b056fcede1a41d824e0b3d8 ]
Fixes:
ee6c750761 (ARM: dts: dra7 clock data)
On DRA7x, For DPLL_IVA, the ref clock(CLKINP) is connected to sys_clk1 and
the bypass input(CLKINPULOW) is connected to iva_dpll_hs_clk_div clock.
But the bypass input is not directly routed to bypass clkout instead
both CLKINP and CLKINPULOW are connected to bypass clkout via a mux.
This mux is controlled by the bit - CM_CLKSEL_DPLL_IVA[23]:DPLL_BYP_CLKSEL
and it's POR value is zero which selects the CLKINP as bypass clkout.
which means iva_dpll_hs_clk_div is not the bypass clock for dpll_iva_ck
Fix this by adding another mux clock as parent in bypass mode.
This design is common to most of the PLLs and the rest have only one bypass
clock. Below is a list of the DPLLs that need this fix:
DPLL_IVA, DPLL_DDR,
DPLL_DSP, DPLL_EVE,
DPLL_GMAC, DPLL_PER,
DPLL_USB and DPLL_CORE
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alexandre Belloni [Tue, 3 Mar 2015 18:58:22 +0000 (19:58 +0100)]
ARM: at91: pm: fix at91rm9200 standby
[ Upstream commit
84e871660bebfddb9a62ebd6f19d02536e782f0a ]
at91rm9200 standby and suspend to ram has been broken since
00482a4078f4. It is wrongly using AT91_BASE_SYS which is a physical address
and actually doesn't correspond to any register on at91rm9200.
Use the correct at91_ramc_base[0] instead.
Fixes:
00482a4078f4 (ARM: at91: implement the standby function for pm/cpuidle)
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Chen [Fri, 6 Mar 2015 08:04:20 +0000 (16:04 +0800)]
ARM: imx6qdl-sabresd: set swbst_reg as vbus's parent reg
[ Upstream commit
40f737791d4dab26bf23a6331609c604142228bd ]
USB vbus 5V is from PMIC SWBST, so set swbst_reg as vbus's
parent reg, it fixed a bug that the voltage of vbus is incorrect
due to swbst_reg is disabled after boots up.
Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Daniel J Blueman [Tue, 4 Nov 2014 08:29:41 +0000 (16:29 +0800)]
x86: numachip: Fix 16-bit APIC ID truncation
[ Upstream commit
00e7977dd1bbd46e336d7ef907d0fb6b6a4c294f ]
Prevent 16-bit APIC IDs being truncated by using correct mask. This fixes
booting large systems, where the wrong core would receive the startup and
init IPIs, causing hanging.
Signed-off-by: Daniel J Blueman <daniel@numascale.com>
Cc: Steffen Persvold <sp@numascale.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1415089784-28779-1-git-send-email-daniel@numascale.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jiri Slaby [Thu, 5 Mar 2015 08:13:31 +0000 (09:13 +0100)]
x86/vdso: Fix the build on GCC5
[ Upstream commit
e893286918d2cde3a94850d8f7101cd1039e0c62 ]
On gcc5 the kernel does not link:
ld: .eh_frame_hdr table[4] FDE at
0000000000000648 overlaps table[5] FDE at
0000000000000670.
Because prior GCC versions always emitted NOPs on ALIGN directives, but
gcc5 started omitting them.
.LSTARTFDEDLSI1 says:
/* HACK: The dwarf2 unwind routines will subtract 1 from the
return address to get an address in the middle of the
presumed call instruction. Since we didn't get here via
a call, we need to include the nop before the real start
to make up for it. */
.long .LSTART_sigreturn-1-. /* PC-relative start address */
But commit
69d0627a7f6e ("x86 vDSO: reorder vdso32 code") from 2.6.25
replaced .org __kernel_vsyscall+32,0x90 by ALIGN right before
__kernel_sigreturn.
Of course, ALIGN need not generate any NOP in there. Esp. gcc5 collapses
vclock_gettime.o and int80.o together with no generated NOPs as "ALIGN".
So fix this by adding to that point at least a single NOP and make the
function ALIGN possibly with more NOPs then.
Kudos for reporting and diagnosing should go to Richard.
Reported-by: Richard Biener <rguenther@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1425543211-12542-1-git-send-email-jslaby@suse.cz
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Paolo Bonzini [Thu, 5 Mar 2015 10:54:46 +0000 (11:54 +0100)]
kvm: move advertising of KVM_CAP_IRQFD to common code
[ Upstream commit
dc9be0fac70a2ad86e31a81372bb0bdfb6945353 ]
POWER supports irqfds but forgot to advertise them. Some userspace does
not check for the capability, but others check it---thus they work on
x86 and s390 but not POWER.
To avoid that other architectures in the future make the same mistake, let
common code handle KVM_CAP_IRQFD the same way as KVM_CAP_IRQFD_RESAMPLE.
Reported-and-tested-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Fixes:
297e21053a52f060944e9f0de4c64fad9bcd72fc
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Oleg Nesterov [Fri, 13 Mar 2015 08:53:10 +0000 (09:53 +0100)]
x86/fpu: Drop_fpu() should not assume that tsk equals current
[ Upstream commit
f4c3686386393c120710dd34df2a74183ab805fd ]
drop_fpu() does clear_used_math() and usually this is correct
because tsk == current.
However switch_fpu_finish()->restore_fpu_checking() is called before
__switch_to() updates the "current_task" variable. If it fails,
we will wrongly clear the PF_USED_MATH flag of the previous task.
So use clear_stopped_child_used_math() instead.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: <stable@vger.kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pekka Riikonen <priikone@iki.fi>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20150309171041.GB11388@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Oleg Nesterov [Fri, 13 Mar 2015 08:53:09 +0000 (09:53 +0100)]
x86/fpu: Avoid math_state_restore() without used_math() in __restore_xstate_sig()
[ Upstream commit
a7c80ebcac3068b1c3cb27d538d29558c30010c8 ]
math_state_restore() assumes it is called with irqs disabled,
but this is not true if the caller is __restore_xstate_sig().
This means that if ia32_fxstate == T and __copy_from_user()
fails, __restore_xstate_sig() returns with irqs disabled too.
This triggers:
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41
dump_stack
___might_sleep
? _raw_spin_unlock_irqrestore
__might_sleep
down_read
? _raw_spin_unlock_irqrestore
print_vma_addr
signal_fault
sys32_rt_sigreturn
Change __restore_xstate_sig() to call set_used_math()
unconditionally. This avoids enabling and disabling interrupts
in math_state_restore(). If copy_from_user() fails, we can
simply do fpu_finit() by hand.
[ Note: this is only the first step. math_state_restore() should
not check used_math(), it should set this flag. While
init_fpu() should simply die. ]
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pekka Riikonen <priikone@iki.fi>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20150307153844.GB25954@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Stephan Mueller [Thu, 12 Mar 2015 08:17:51 +0000 (09:17 +0100)]
crypto: aesni - fix memory usage in GCM decryption
[ Upstream commit
ccfe8c3f7e52ae83155cb038753f4c75b774ca8a ]
The kernel crypto API logic requires the caller to provide the
length of (ciphertext || authentication tag) as cryptlen for the
AEAD decryption operation. Thus, the cipher implementation must
calculate the size of the plaintext output itself and cannot simply use
cryptlen.
The RFC4106 GCM decryption operation tries to overwrite cryptlen memory
in req->dst. As the destination buffer for decryption only needs to hold
the plaintext memory but cryptlen references the input buffer holding
(ciphertext || authentication tag), the assumption of the destination
buffer length in RFC4106 GCM operation leads to a too large size. This
patch simply uses the already calculated plaintext size.
In addition, this patch fixes the offset calculation of the AAD buffer
pointer: as mentioned before, cryptlen already includes the size of the
tag. Thus, the tag does not need to be added. With the addition, the AAD
will be written beyond the already allocated buffer.
Note, this fixes a kernel crash that can be triggered from user space
via AF_ALG(aead) -- simply use the libkcapi test application
from [1] and update it to use rfc4106-gcm-aes.
Using [1], the changes were tested using CAVS vectors to demonstrate
that the crypto operation still delivers the right results.
[1] http://www.chronox.de/libkcapi.html
CC: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Ard Biesheuvel [Thu, 26 Feb 2015 07:22:05 +0000 (07:22 +0000)]
crypto: arm/aes update NEON AES module to latest OpenSSL version
[ Upstream commit
001eabfd54c0cbf9d7d16264ddc8cc0bee67e3ed ]
This updates the bit sliced AES module to the latest version in the
upstream OpenSSL repository (
e620e5ae37bc). This is needed to fix a
bug in the XTS decryption path, where data chunked in a certain way
could trigger the ciphertext stealing code, which is not supposed to
be active in the kernel build (The kernel implementation of XTS only
supports round multiples of the AES block size of 16 bytes, whereas
the conformant OpenSSL implementation of XTS supports inputs of
arbitrary size by applying ciphertext stealing). This is fixed in
the upstream version by adding the missing #ifndef XTS_CHAIN_TWEAK
around the offending instructions.
The upstream code also contains the change applied by Russell to
build the code unconditionally, i.e., even if __LINUX_ARM_ARCH__ < 7,
but implemented slightly differently.
Cc: stable@vger.kernel.org
Fixes:
e4e7f10bfc40 ("ARM: add support for bit sliced AES using NEON instructions")
Reported-by: Adrian Kotelba <adrian.kotelba@gmail.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Kirill A. Shutemov [Mon, 9 Mar 2015 21:11:12 +0000 (23:11 +0200)]
pagemap: do not leak physical addresses to non-privileged userspace
[ Upstream commit
ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce ]
As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.
This disallows anybody without CAP_SYS_ADMIN to read the pagemap.
[1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
[ Eventually we might want to do anything more finegrained, but for now
this is the simple model. - Linus ]
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mark Seaborn <mseaborn@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Maxime Ripard [Tue, 3 Mar 2015 10:27:23 +0000 (11:27 +0100)]
irqchip: armada-370-xp: Fix chained per-cpu interrupts
[ Upstream commit
5724be8464dceac047c1eaddaa3651cea0ec16ca ]
On the Cortex-A9-based Armada SoCs, the MPIC is not the primary interrupt
controller. Yet, it still has to handle some per-cpu interrupt.
To do so, it is chained with the GIC using a per-cpu interrupt. However, the
current code only call irq_set_chained_handler, which is called and enable that
interrupt only on the boot CPU, which means that the parent per-CPU interrupt
is never unmasked on the secondary CPUs, preventing the per-CPU interrupt to
actually work as expected.
This was not seen until now since the only MPIC PPI users were the Marvell
timers that were not working, but not used either since the system use the ARM
TWD by default, and the ethernet controllers, that are faking there interrupts
as SPI, and don't really expect to have interrupts on the secondary cores
anyway.
Add a CPU notifier that will enable the PPI on the secondary cores when they
are brought up.
Cc: <stable@vger.kernel.org> # 3.15+
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1425378443-28822-1-git-send-email-maxime.ripard@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Sasha Levin [Wed, 4 Feb 2015 22:38:15 +0000 (17:38 -0500)]
PCI: Don't read past the end of sysfs "driver_override" buffer
[ Upstream commit
4efe874aace57dba967624ce1c48322da2447b75 ]
When printing the driver_override parameter when it is 4095 and 4094 bytes
long, the printing code would access invalid memory because we need count+1
bytes for printing.
Fixes:
782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override")
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
CC: stable@vger.kernel.org # v3.16+
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Alexander Graf <agraf@suse.de>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
James Bottomley [Thu, 5 Mar 2015 00:18:33 +0000 (16:18 -0800)]
libsas: Fix Kernel Crash in smp_execute_task
[ Upstream commit
6302ce4d80aa82b3fdb5c5cd68e7268037091b47 ]
This crash was reported:
[ 366.947370] sd 3:0:1:0: [sdb] Spinning up disk....
[ 368.804046] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 368.804072] IP: [<
ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
[ 368.804098] PGD 0
[ 368.804114] Oops: 0002 [#1] SMP
[ 368.804143] CPU 1
[ 368.804151] Modules linked in: sg netconsole s3g(PO) uinput joydev hid_multitouch usbhid hid snd_hda_codec_via cpufreq_userspace cpufreq_powersave cpufreq_stats uhci_hcd cpufreq_conservative snd_hda_intel snd_hda_codec snd_hwdep snd_pcm sdhci_pci snd_page_alloc sdhci snd_timer snd psmouse evdev serio_raw pcspkr soundcore xhci_hcd shpchp s3g_drm(O) mvsas mmc_core ahci libahci drm i2c_core acpi_cpufreq mperf video processor button thermal_sys dm_dmirror exfat_fs exfat_core dm_zcache dm_mod padlock_aes aes_generic padlock_sha iscsi_target_mod target_core_mod configfs sswipe libsas libata scsi_transport_sas picdev via_cputemp hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sd_mod crc_t10dif usb_storage scsi_mod ehci_hcd usbcore usb_common
[ 368.804749]
[ 368.804764] Pid: 392, comm: kworker/u:3 Tainted: P W O 3.4.87-logicube-ng.22 #1 To be filled by O.E.M. To be filled by O.E.M./EPIA-M920
[ 368.804802] RIP: 0010:[<
ffffffff81358457>] [<
ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
[ 368.804827] RSP: 0018:
ffff880117001cc0 EFLAGS:
00010246
[ 368.804842] RAX:
0000000000000000 RBX:
ffff8801185030d0 RCX:
ffff88008edcb420
[ 368.804857] RDX:
0000000000000000 RSI:
0000000000000002 RDI:
ffff8801185030d4
[ 368.804873] RBP:
ffff8801181531c0 R08:
0000000000000020 R09:
00000000fffffffe
[ 368.804885] R10:
0000000000000000 R11:
0000000000000000 R12:
ffff8801185030d4
[ 368.804899] R13:
0000000000000002 R14:
ffff880117001fd8 R15:
ffff8801185030d8
[ 368.804916] FS:
0000000000000000(0000) GS:
ffff88011fc80000(0000) knlGS:
0000000000000000
[ 368.804931] CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
[ 368.804946] CR2:
0000000000000000 CR3:
000000000160b000 CR4:
00000000000006e0
[ 368.804962] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 368.804978] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
[ 368.804995] Process kworker/u:3 (pid: 392, threadinfo
ffff880117000000, task
ffff8801181531c0)
[ 368.805009] Stack:
[ 368.805017]
ffff8801185030d8 0000000000000000 ffffffff8161ddf0 ffffffff81056f7c
[ 368.805062]
000000000000b503 ffff8801185030d0 ffff880118503000 0000000000000000
[ 368.805100]
ffff8801185030d0 ffff8801188b8000 ffff88008edcb420 ffffffff813583ac
[ 368.805135] Call Trace:
[ 368.805153] [<
ffffffff81056f7c>] ? up+0xb/0x33
[ 368.805168] [<
ffffffff813583ac>] ? mutex_lock+0x16/0x25
[ 368.805194] [<
ffffffffa018c414>] ? smp_execute_task+0x4e/0x222 [libsas]
[ 368.805217] [<
ffffffffa018ce1c>] ? sas_find_bcast_dev+0x3c/0x15d [libsas]
[ 368.805240] [<
ffffffffa018ce4f>] ? sas_find_bcast_dev+0x6f/0x15d [libsas]
[ 368.805264] [<
ffffffffa018e989>] ? sas_ex_revalidate_domain+0x37/0x2ec [libsas]
[ 368.805280] [<
ffffffff81355a2a>] ? printk+0x43/0x48
[ 368.805296] [<
ffffffff81359a65>] ? _raw_spin_unlock_irqrestore+0xc/0xd
[ 368.805318] [<
ffffffffa018b767>] ? sas_revalidate_domain+0x85/0xb6 [libsas]
[ 368.805336] [<
ffffffff8104e5d9>] ? process_one_work+0x151/0x27c
[ 368.805351] [<
ffffffff8104f6cd>] ? worker_thread+0xbb/0x152
[ 368.805366] [<
ffffffff8104f612>] ? manage_workers.isra.29+0x163/0x163
[ 368.805382] [<
ffffffff81052c4e>] ? kthread+0x79/0x81
[ 368.805399] [<
ffffffff8135fea4>] ? kernel_thread_helper+0x4/0x10
[ 368.805416] [<
ffffffff81052bd5>] ? kthread_flush_work_fn+0x9/0x9
[ 368.805431] [<
ffffffff8135fea0>] ? gs_change+0x13/0x13
[ 368.805442] Code: 83 7d 30 63 7e 04 f3 90 eb ab 4c 8d 63 04 4c 8d 7b 08 4c 89 e7 e8 fa 15 00 00 48 8b 43 10 4c 89 3c 24 48 89 63 10 48 89 44 24 08 <48> 89 20 83 c8 ff 48 89 6c 24 10 87 03 ff c8 74 35 4d 89 ee 41
[ 368.805851] RIP [<
ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
[ 368.805877] RSP <
ffff880117001cc0>
[ 368.805886] CR2:
0000000000000000
[ 368.805899] ---[ end trace
b720682065d8f4cc ]---
It's directly caused by 89d3cf6 [SCSI] libsas: add mutex for SMP task
execution, but shows a deeper cause: expander functions expect to be able to
cast to and treat domain devices as expanders. The correct fix is to only do
expander discover when we know we've got an expander device to avoid wrongly
casting a non-expander device.
Reported-by: Praveen Murali <pmurali@logicube.com>
Tested-by: Praveen Murali <pmurali@logicube.com>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Al Viro [Fri, 6 Feb 2015 07:07:45 +0000 (02:07 -0500)]
gadgetfs: use-after-free in ->aio_read()
[ Upstream commit
f01d35a15fa04162a58b95970fc01fa70ec9dacd ]
AIO_PREAD requests call ->aio_read() with iovec on caller's stack, so if
we are going to access it asynchronously, we'd better get ourselves
a copy - the one on kernel stack of aio_run_iocb() won't be there
anymore. function/f_fs.c take care of doing that, legacy/inode.c
doesn't...
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jan Beulich [Wed, 11 Mar 2015 13:51:17 +0000 (13:51 +0000)]
xen-pciback: limit guest control of command register
[ Upstream commit
af6fc858a35b90e89ea7a7ee58e66628c55c776b ]
Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses by disabling memory and/or I/O decoding
and subsequently causing (CPU side) accesses to the respective address
ranges, which (depending on system configuration) may be fatal to the
host.
Note that to alter any of the bits collected together as
PCI_COMMAND_GUEST permissive mode is now required to be enabled
globally or on the specific device.
This is CVE-2015-2150 / XSA-120.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Juergen Gross [Thu, 26 Feb 2015 05:52:05 +0000 (06:52 +0100)]
xen/events: avoid NULL pointer dereference in dom0 on large machines
[ Upstream commit
85e40b0539b24518c8bdf63e2605c8522377d00f ]
Using the pvops kernel a NULL pointer dereference was detected on a
large machine (144 processors) when booting as dom0 in
evtchn_fifo_unmask() during assignment of a pirq.
The event channel in question was the first to need a new entry in
event_array[] in events_fifo.c. Unfortunately xen_irq_info_pirq_setup()
is called with evtchn being 0 for a new pirq and the real event channel
number is assigned to the pirq only during __startup_pirq().
It is mandatory to call xen_evtchn_port_setup() after assigning the
event channel number to the pirq to make sure all memory needed for the
event channel is allocated.
Signed-off-by: Juergen Gross <jgross@suse.com>
Cc: <stable@vger.kernel.org> # 3.14+
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Javier Martinez Canillas [Thu, 12 Mar 2015 23:25:49 +0000 (16:25 -0700)]
drivers/rtc/rtc-s3c.c: add .needs_src_clk to s3c6410 RTC data
[ Upstream commit
8792f7772f4f40ffc68bad5f28311205584b734d ]
Commit
df9e26d093d3 ("rtc: s3c: add support for RTC of Exynos3250 SoC")
added an "rtc_src" DT property to specify the clock used as a source to
the S3C real-time clock.
Not all SoCs needs this so commit
eaf3a659086e ("drivers/rtc/rtc-s3c.c:
fix initialization failure without rtc source clock") changed to check
the struct s3c_rtc_data .needs_src_clk to conditionally grab the clock.
But that commit didn't update the data for each IP version so the RTC
broke on the boards that needs a source clock. This is the case of at
least Exynos5250 and Exynos5440 which uses the s3c6410 RTC IP block.
This commit fixes the S3C rtc on the Exynos5250 Snow and Exynos5420
Peach Pit and Pi Chromebooks.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Tyler Baker <tyler.baker@linaro.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
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: Sasha Levin <sasha.levin@oracle.com>
Chris Wilson [Wed, 25 Feb 2015 13:45:26 +0000 (13:45 +0000)]
drm: Don't assign fbs for universal cursor support to files
[ Upstream commit
9a6f5130143c17b91e0a3cbf5cc2d8c1e5a80a63 ]
The internal framebuffers we create to remap legacy cursor ioctls to
plane operations for the universal plane support shouldn't be linke to
the file like normal userspace framebuffers. This bug goes back to the
original universal cursor plane support introduced in
commit
161d0dc1dccb17ff7a38f462c7c0d4ef8bcc5662
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Jun 10 08:28:10 2014 -0700
drm: Support legacy cursor ioctls via universal planes when possible (v4)
The isn't too disastrous since fbs are small, we only create one when the
cursor bo gets changed and ultimately they'll be reaped when the window
server restarts.
Conceptually we'd want to just pass NULL for file_priv when creating it,
but the driver needs the file to lookup the underlying buffer object for
cursor id. Instead let's move the file_priv linking out of
add_framebuffer_internal() into the addfb ioctl implementation, which is
the only place it is needed. And also rename the function for a more
accurate since it only creates the fb, but doesn't add it anywhere.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (fix & commit msg)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (provider of lipstick)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Thomas Hellstrom [Mon, 9 Mar 2015 08:56:21 +0000 (01:56 -0700)]
drm/vmwgfx: Fix a couple of lock dependency violations
[ Upstream commit
5151adb37a5918957f4c33a8d8e7629c0fb00563 ]
Experimental lockdep annotation added to the TTM lock has unveiled a
couple of lock dependency violations in the vmwgfx driver. In both
cases it turns out that the device_private::reservation_sem is not
needed so the offending code is moved out of that lock.
Cc: <stable@vger.kernel.org>
Acked-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Thomas Hellstrom [Thu, 5 Mar 2015 10:33:24 +0000 (02:33 -0800)]
drm/vmwgfx: Reorder device takedown somewhat
[ Upstream commit
3458390b9f0ba784481d23134798faee27b5f16f ]
To take down the MOB and GMR memory types, the driver may have to issue
fence objects and thus make sure that the fence manager is taken down
after those memory types.
Reorder device init accordingly.
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jakub Kicinski [Wed, 11 Mar 2015 17:35:36 +0000 (18:35 +0100)]
Revert "i2c: core: Dispose OF IRQ mapping at client removal time"
[ Upstream commit
a49445727014216703a3c28ccee4cef36d41571e ]
This reverts commit
e4df3a0b6228
("i2c: core: Dispose OF IRQ mapping at client removal time")
Calling irq_dispose_mapping() will destroy the mapping and disassociate
the IRQ from the IRQ chip to which it belongs. Keeping it is OK, because
existent mappings are reused properly.
Also, this commit breaks drivers using devm* for IRQ management on
OF-based systems because devm* cleanup happens in device code, after
bus's remove() method returns.
Signed-off-by: Jakub Kicinski <kubakici@wp.pl>
Reported-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[wsa: updated the commit message with findings fromt the other bug report]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
Fixes:
e4df3a0b6228
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Ryusuke Konishi [Thu, 12 Mar 2015 23:26:00 +0000 (16:26 -0700)]
nilfs2: fix deadlock of segment constructor during recovery
[ Upstream commit
283ee1482f349d6c0c09dfb725db5880afc56813 ]
According to a report from Yuxuan Shui, nilfs2 in kernel 3.19 got stuck
during recovery at mount time. The code path that caused the deadlock was
as follows:
nilfs_fill_super()
load_nilfs()
nilfs_salvage_orphan_logs()
* Do roll-forwarding, attach segment constructor for recovery,
and kick it.
nilfs_segctor_thread()
nilfs_segctor_thread_construct()
* A lock is held with nilfs_transaction_lock()
nilfs_segctor_do_construct()
nilfs_segctor_drop_written_files()
iput()
iput_final()
write_inode_now()
writeback_single_inode()
__writeback_single_inode()
do_writepages()
nilfs_writepage()
nilfs_construct_dsync_segment()
nilfs_transaction_lock() --> deadlock
This can happen if commit
7ef3ff2fea8b ("nilfs2: fix deadlock of segment
constructor over I_SYNC flag") is applied and roll-forward recovery was
performed at mount time. The roll-forward recovery can happen if datasync
write is done and the file system crashes immediately after that. For
instance, we can reproduce the issue with the following steps:
< nilfs2 is mounted on /nilfs (device: /dev/sdb1) >
# dd if=/dev/zero of=/nilfs/test bs=4k count=1 && sync
# dd if=/dev/zero of=/nilfs/test conv=notrunc oflag=dsync bs=4k
count=1 && reboot -nfh
< the system will immediately reboot >
# mount -t nilfs2 /dev/sdb1 /nilfs
The deadlock occurs because iput() can run segment constructor through
writeback_single_inode() if MS_ACTIVE flag is not set on sb->s_flags. The
above commit changed segment constructor so that it calls iput()
asynchronously for inodes with i_nlink == 0, but that change was
imperfect.
This fixes the another deadlock by deferring iput() in segment constructor
even for the case that mount is not finished, that is, for the case that
MS_ACTIVE flag is not set.
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Reported-by: Yuxuan Shui <yshuiv7@gmail.com>
Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Cc: Al Viro <viro@zeniv.linux.org.uk>
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: Sasha Levin <sasha.levin@oracle.com>
Doug Anderson [Tue, 3 Mar 2015 23:20:47 +0000 (15:20 -0800)]
regulator: core: Fix enable GPIO reference counting
[ Upstream commit
29d62ec5f87fbeec8413e2215ddad12e7f972e4c ]
Normally _regulator_do_enable() isn't called on an already-enabled
rdev. That's because the main caller, _regulator_enable() always
calls _regulator_is_enabled() and only calls _regulator_do_enable() if
the rdev was not already enabled.
However, there is one caller of _regulator_do_enable() that doesn't
check: regulator_suspend_finish(). While we might want to make
regulator_suspend_finish() behave more like _regulator_enable(), it's
probably also a good idea to make _regulator_do_enable() robust if it
is called on an already enabled rdev.
At the moment, _regulator_do_enable() is _not_ robust for already
enabled rdevs if we're using an ena_pin. Each time
_regulator_do_enable() is called for an rdev using an ena_pin the
reference count of the ena_pin is incremented even if the rdev was
already enabled. This is not as intended because the ena_pin is for
something else: for keeping track of how many active rdevs there are
sharing the same ena_pin.
Here's how the reference counting works here:
* Each time _regulator_enable() is called we increment
rdev->use_count, so _regulator_enable() calls need to be balanced
with _regulator_disable() calls.
* There is no explicit reference counting in _regulator_do_enable()
which is normally just a warapper around rdev->desc->ops->enable()
with code for supporting delays. It's not expected that the
"ops->enable()" call do reference counting.
* Since regulator_ena_gpio_ctrl() does have reference counting
(handling the sharing of the pin amongst multiple rdevs), we
shouldn't call it if the current rdev is already enabled.
Note that as part of this we cleanup (remove) the initting of
ena_gpio_state in regulator_register(). In _regulator_do_enable(),
_regulator_do_disable() and _regulator_is_enabled() is is clear that
ena_gpio_state should be the state of whether this particular rdev has
requested the GPIO be enabled. regulator_register() was initting it
as the actual state of the pin.
Fixes:
967cfb18c0e3 ("regulator: core: manage enable GPIO list")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Javier Martinez Canillas [Mon, 2 Mar 2015 20:40:39 +0000 (21:40 +0100)]
regulator: Only enable disabled regulators on resume
[ Upstream commit
0548bf4f5ad6fc3bd93c4940fa48078b34609682 ]
The _regulator_do_enable() call ought to be a no-op when called on an
already-enabled regulator. However, as an optimization
_regulator_enable() doesn't call _regulator_do_enable() on an already
enabled regulator. That means we never test the case of calling
_regulator_do_enable() during normal usage and there may be hidden
bugs or warnings. We have seen warnings issued by the tps65090 driver
and bugs when using the GPIO enable pin.
Let's match the same optimization that _regulator_enable() in
regulator_suspend_finish(). That may speed up suspend/resume and also
avoids exposing hidden bugs.
[Use much clearer commit message from Doug Anderson]
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Doug Anderson [Sat, 21 Feb 2015 00:53:38 +0000 (16:53 -0800)]
regulator: rk808: Set the enable time for LDOs
[ Upstream commit
28249b0c2fa361cdac450a6f40242ed45408a24f ]
The LDOs are documented in the rk808 datasheet to have a soft start
time of 400us. Add that to the driver. If this time takes longer on
a certain board the device tree should be able to override with
"regulator-enable-ramp-delay".
This fixes some dw_mmc probing problems (together with other patches
posted to the mmc maiing lists) on rk3288.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Brian King [Wed, 4 Mar 2015 14:09:44 +0000 (08:09 -0600)]
bnx2x: Force fundamental reset for EEH recovery
[ Upstream commit
da293700568ed3d96fcf062ac15d7d7c41377f11 ]
EEH recovery for bnx2x based adapters is not reliable on all Power
systems using the default hot reset, which can result in an
unrecoverable EEH error. Forcing the use of fundamental reset
during EEH recovery fixes this.
Cc: stable<stable@vger.kernel.org>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Maxime Ripard [Wed, 18 Feb 2015 10:32:07 +0000 (11:32 +0100)]
mtd: nand: pxa3xx: Fix PIO FIFO draining
[ Upstream commit
8dad0386b97c4bd6edd56752ca7f2e735fe5beb4 ]
The NDDB register holds the data that are needed by the read and write
commands.
However, during a read PIO access, the datasheet specifies that after each 32
bytes read in that register, when BCH is enabled, we have to make sure that the
RDDREQ bit is set in the NDSR register.
This fixes an issue that was seen on the Armada 385, and presumably other mvebu
SoCs, when a read on a newly erased page would end up in the driver reporting a
timeout from the NAND.
Cc: <stable@vger.kernel.org> # v3.14
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Mon, 16 Mar 2015 09:18:08 +0000 (10:18 +0100)]
ALSA: hda - Treat stereo-to-mono mix properly
[ Upstream commit
cc261738add93947d138d2fabad9f4dbed4e5c00 ]
The commit [
ef403edb7558: ALSA: hda - Don't access stereo amps for
mono channel widgets] fixed the handling of mono widgets in general,
but it still misses an exceptional case: namely, a mono mixer widget
taking a single stereo input. In this case, it has stereo volumes
although it's a mono widget, and thus we have to take care of both
left and right input channels, as stated in HD-audio spec ("7.1.3
Widget Interconnection Rules").
This patch covers this missing piece by adding proper checks of stereo
amps in both the generic parser and the proc output codes.
Reported-by: Raymond Yau <superquad.vortex2@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Sun, 8 Mar 2015 17:29:50 +0000 (18:29 +0100)]
ALSA: hda - Fix regression of HD-audio controller fallback modes
[ Upstream commit
a1f3f1ca66bd12c339b17a0c2ef93a093f90a277 ]
The commit [
63e51fd708f5: ALSA: hda - Don't take unresponsive D3
transition too serious] introduced a conditional fallback behavior to
the HD-audio controller depending on the flag set. However, it
introduced a silly bug, too, that the flag was evaluated in a reverse
way. This resulted in a regression of HD-audio controller driver
where it can't go to the fallback mode at communication errors.
Unfortunately (or fortunately?) this didn't come up until recently
because the affected code path is an error handling that happens only
on an unstable hardware chip. Most of recent chips work stably, thus
they didn't hit this problem. Now, we've got a regression report with
a VIA chip, and this seems indeed requiring the fallback to the
polling mode, and finally the bug was revealed.
The fix is a oneliner to remove the wrong logical NOT in the check.
(Lesson learned - be careful about double negation.)
The bug should be backported to stable, but the patch won't be
applicable to 3.13 or earlier because of the code splits. The stable
fix patches for earlier kernels will be posted later manually.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94021
Fixes:
63e51fd708f5 ('ALSA: hda - Don't take unresponsive D3 transition too serious')
Cc: <stable@vger.kernel.org> # v3.14+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Thu, 12 Mar 2015 19:47:15 +0000 (20:47 +0100)]
ALSA: hda - Add workaround for MacBook Air 5,2 built-in mic
[ Upstream commit
2ddee91abe9cc34ddb6294ee14702b46ae07d460 ]
MacBook Air 5,2 has the same problem as MacBook Pro 8,1 where the
built-in mic records only the right channel. Apply the same
workaround as MBP8,1 to spread the mono channel via a Cirrus codec
vendor-specific COEF setup.
Reported-and-tested-by: Vasil Zlatanov <vasil.zlatanov@gmail.com>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Thu, 12 Mar 2015 19:28:04 +0000 (20:28 +0100)]
ALSA: hda - Set single_adc_amp flag for CS420x codecs
[ Upstream commit
bad994f5b4ab57eec8d56c180edca00505c3eeb2 ]
CS420x codecs seem to deal only the single amps of ADC nodes even
though the nodes receive multiple inputs. This leads to the
inconsistent amp value after S3/S4 resume, for example.
The fix is just to set codec->single_adc_amp flag. Then the driver
handles these ADC amps as if single connections.
Reported-and-tested-by: Vasil Zlatanov <vasil.zlatanov@gmail.com>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Thu, 12 Mar 2015 07:30:11 +0000 (08:30 +0100)]
ALSA: hda - Don't access stereo amps for mono channel widgets
[ Upstream commit
ef403edb75580a3ec5d155f5de82155f0419c621 ]
The current HDA generic parser initializes / modifies the amp values
always in stereo, but this seems causing the problem on ALC3229 codec
that has a few mono channel widgets: namely, these mono widgets react
to actions for both channels equally.
In the driver code, we do care the mono channel and create a control
only for the left channel (as defined in HD-audio spec) for such a
node. When the control is updated, only the left channel value is
changed. However, in the resume, the right channel value is also
restored from the initial value we took as stereo, and this overwrites
the left channel value. This ends up being the silent output as the
right channel has been never touched and remains muted.
This patch covers the places where unconditional stereo amp accesses
are done and converts to the conditional accesses.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94581
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Wed, 11 Mar 2015 15:05:19 +0000 (16:05 +0100)]
ALSA: hda - Fix built-in mic on Compaq Presario CQ60
[ Upstream commit
ddb6ca75b5671b8fbf1909bc588c449ee74b34f9 ]
Compaq Presario CQ60 laptop with CX20561 gives a wrong pin for the
built-in mic NID 0x17 instead of NID 0x1d, and it results in the
non-working mic. This patch just remaps the pin correctly via fixup.
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=920604
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Wed, 11 Mar 2015 17:12:49 +0000 (18:12 +0100)]
ALSA: control: Add sanity checks for user ctl id name string
[ Upstream commit
be3bb8236db2d0fcd705062ae2e2a9d75131222f ]
There was no check about the id string of user control elements, so we
accepted even a control element with an empty string, which is
obviously bogus. This patch adds more sanity checks of id strings.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Daniel Mack [Thu, 12 Mar 2015 08:41:32 +0000 (09:41 +0100)]
ALSA: snd-usb: add quirks for Roland UA-22
[ Upstream commit
fcdcd1dec6d2c7b718385ec743ae5a9a233edad4 ]
The device complies to the UAC1 standard but hides that fact with
proprietary descriptors. The autodetect quirk for Roland devices
catches the audio interface but misses the MIDI part, so a specific
quirk is needed.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Reported-by: Rafa Lafuente <rafalafuente@gmail.com>
Tested-by: Raphaël Doursenaud <raphael@doursenaud.fr>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alexander Sverdlin [Fri, 27 Feb 2015 15:30:21 +0000 (16:30 +0100)]
spi: pl022: Fix race in giveback() leading to driver lock-up
[ Upstream commit
cd6fa8d2ca53cac3226fdcffcf763be390abae32 ]
Commit
fd316941c ("spi/pl022: disable port when unused") introduced a race,
which leads to possible driver lock up (easily reproducible on SMP).
The problem happens in giveback() function where the completion of the transfer
is signalled to SPI subsystem and then the HW SPI controller is disabled. Another
transfer might be setup in between, which brings driver in locked-up state.
Exact event sequence on SMP:
core0 core1
=> pump_transfers()
/* message->state == STATE_DONE */
=> giveback()
=> spi_finalize_current_message()
=> pl022_unprepare_transfer_hardware()
=> pl022_transfer_one_message
=> flush()
=> do_interrupt_dma_transfer()
=> set_up_next_transfer()
/* Enable SSP, turn on interrupts */
writew((readw(SSP_CR1(pl022->virtbase)) |
SSP_CR1_MASK_SSE), SSP_CR1(pl022->virtbase));
...
=> pl022_interrupt_handler()
=> readwriter()
/* disable the SPI/SSP operation */
=> writew((readw(SSP_CR1(pl022->virtbase)) &
(~SSP_CR1_MASK_SSE)), SSP_CR1(pl022->virtbase));
Lockup! SPI controller is disabled and the data will never be received. Whole
SPI subsystem is waiting for transfer ACK and blocked.
So, only signal transfer completion after disabling the controller.
Fixes:
fd316941c (spi/pl022: disable port when unused)
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Andy Shevchenko [Mon, 2 Mar 2015 18:15:58 +0000 (20:15 +0200)]
spi: dw-mid: avoid potential NULL dereference
[ Upstream commit
c9dafb27c84412fe4b17c3b94cc4ffeef5df1833 ]
When DMA descriptor allocation fails we should not try to assign any fields in
the bad descriptor. The patch adds the necessary checks for that.
Fixes:
7063c0d942a1 (spi/dw_spi: add DMA support)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Torsten Fleischer [Tue, 24 Feb 2015 15:32:57 +0000 (16:32 +0100)]
spi: atmel: Fix interrupt setup for PDC transfers
[ Upstream commit
76e1d14b316d6f501ebc001e7a5d86b24ce5b615 ]
Additionally to the current DMA transfer the PDC allows to set up a next DMA
transfer. This is useful for larger SPI transfers.
The driver currently waits for ENDRX as end of the transfer. But ENDRX is set
when the current DMA transfer is done (RCR = 0), i.e. it doesn't include the
next DMA transfer.
Thus a subsequent SPI transfer could be started although there is currently a
transfer in progress. This can cause invalid accesses to the SPI slave devices
and to SPI transfer errors.
This issue has been observed on a hardware with a M25P128 SPI NOR flash.
So instead of ENDRX we should wait for RXBUFF. This flag is set if there is
no more DMA transfer in progress (RCR = RNCR = 0).
Signed-off-by: Torsten Fleischer <torfl6749@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Christophe Ricard [Tue, 13 Jan 2015 22:13:14 +0000 (23:13 +0100)]
tpm/tpm_i2c_stm_st33: Add status check when reading data on the FIFO
[ Upstream commit
c4eadfafb91d5501095c55ffadaa1168743f39d3 ]
Add a return value check when reading data from the FIFO register.
Cc: <stable@vger.kernel.org>
Reviewed-by: Jason Gunthorpe <jason.gunthorpe@obsidianresearch.com>
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Reviewed-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
jmlatten@linux.vnet.ibm.com [Sat, 21 Feb 2015 00:11:24 +0000 (18:11 -0600)]
tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send
[ Upstream commit
62dfd912ab3b5405b6fe72d0135c37e9648071f1 ]
Problem: When IMA and VTPM are both enabled in kernel config,
kernel hangs during bootup on LE OS.
Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send
and tpm_ibmtpm_recv getting called. A trace showed that
tpm_ibmtpm_recv was hanging.
Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send
was sending CRQ message that probably did not make much sense
to phype because of Endianness. The fix below sends correctly
converted CRQ for LE. This was not caught before because it
seems IMA is not enabled by default in kernel config and
IMA exercises this particular code path in vtpm.
Tested with IMA and VTPM enabled in kernel config and VTPM
enabled on both a BE OS and a LE OS ppc64 lpar. This exercised
CRQ and TPM command code paths in vtpm.
Patch is against Peter's tpmdd tree on github which included
Vicky's previous vtpm le patches.
Signed-off-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> # eb71f8a5e33f: "Added Little Endian support to vtpm module"
Cc: <stable@vger.kernel.org>
Reviewed-by: Ashley Lai <ashley@ahsleylai.com>
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jason Low [Fri, 13 Feb 2015 03:58:07 +0000 (11:58 +0800)]
cpuset: Fix cpuset sched_relax_domain_level
[ Upstream commit
283cb41f426b723a0255702b761b0fc5d1b53a81 ]
The cpuset.sched_relax_domain_level can control how far we do
immediate load balancing on a system. However, it was found on recent
kernels that echo'ing a value into cpuset.sched_relax_domain_level
did not reduce any immediate load balancing.
The reason this occurred was because the update_domain_attr_tree() traversal
did not update for the "top_cpuset". This resulted in nothing being changed
when modifying the sched_relax_domain_level parameter.
This patch is able to address that problem by having update_domain_attr_tree()
allow updates for the root in the cpuset traversal.
Fixes:
fc560a26acce ("cpuset: replace cpuset->stack_list with cpuset_for_each_descendant_pre()")
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Jason Low <jason.low2@hp.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Tested-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Zefan Li [Fri, 13 Feb 2015 03:20:30 +0000 (11:20 +0800)]
cpuset: fix a warning when clearing configured masks in old hierarchy
[ Upstream commit
79063bffc81f82689bd90e16da1b49408f3bf095 ]
When we clear cpuset.cpus, cpuset.effective_cpus won't be cleared:
# mount -t cgroup -o cpuset xxx /mnt
# mkdir /mnt/tmp
# echo 0 > /mnt/tmp/cpuset.cpus
# echo > /mnt/tmp/cpuset.cpus
# cat cpuset.cpus
# cat cpuset.effective_cpus
0-15
And a kernel warning in update_cpumasks_hier() is triggered:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 4028 at kernel/cpuset.c:894 update_cpumasks_hier+0x471/0x650()
Cc: <stable@vger.kernel.org> # 3.17+
Signed-off-by: Zefan Li <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Tested-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Zefan Li [Fri, 13 Feb 2015 03:19:49 +0000 (11:19 +0800)]
cpuset: initialize effective masks when clone_children is enabled
[ Upstream commit
790317e1b266c776765a4bdcedefea706ff0fada ]
If clone_children is enabled, effective masks won't be initialized
due to the bug:
# mount -t cgroup -o cpuset xxx /mnt
# echo 1 > cgroup.clone_children
# mkdir /mnt/tmp
# cat /mnt/tmp/
# cat cpuset.effective_cpus
# cat cpuset.cpus
0-15
And then this cpuset won't constrain the tasks in it.
Either the bug or the fix has no effect on unified hierarchy, as
there's no clone_chidren flag there any more.
Reported-by: Christian Brauner <christianvanbrauner@gmail.com>
Reported-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Cc: <stable@vger.kernel.org> # 3.17+
Signed-off-by: Zefan Li <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Tested-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Tejun Heo [Thu, 5 Mar 2015 13:04:13 +0000 (08:04 -0500)]
workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE
[ Upstream commit
8603e1b30027f943cc9c1eef2b291d42c3347af1 ]
cancel[_delayed]_work_sync() are implemented using
__cancel_work_timer() which grabs the PENDING bit using
try_to_grab_pending() and then flushes the work item with PENDING set
to prevent the on-going execution of the work item from requeueing
itself.
try_to_grab_pending() can always grab PENDING bit without blocking
except when someone else is doing the above flushing during
cancelation. In that case, try_to_grab_pending() returns -ENOENT. In
this case, __cancel_work_timer() currently invokes flush_work(). The
assumption is that the completion of the work item is what the other
canceling task would be waiting for too and thus waiting for the same
condition and retrying should allow forward progress without excessive
busy looping
Unfortunately, this doesn't work if preemption is disabled or the
latter task has real time priority. Let's say task A just got woken
up from flush_work() by the completion of the target work item. If,
before task A starts executing, task B gets scheduled and invokes
__cancel_work_timer() on the same work item, its try_to_grab_pending()
will return -ENOENT as the work item is still being canceled by task A
and flush_work() will also immediately return false as the work item
is no longer executing. This puts task B in a busy loop possibly
preventing task A from executing and clearing the canceling state on
the work item leading to a hang.
task A task B worker
executing work
__cancel_work_timer()
try_to_grab_pending()
set work CANCELING
flush_work()
block for work completion
completion, wakes up A
__cancel_work_timer()
while (forever) {
try_to_grab_pending()
-ENOENT as work is being canceled
flush_work()
false as work is no longer executing
}
This patch removes the possible hang by updating __cancel_work_timer()
to explicitly wait for clearing of CANCELING rather than invoking
flush_work() after try_to_grab_pending() fails with -ENOENT.
Link: http://lkml.kernel.org/g/20150206171156.GA8942@axis.com
v3: bit_waitqueue() can't be used for work items defined in vmalloc
area. Switched to custom wake function which matches the target
work item and exclusive wait and wakeup.
v2: v1 used wake_up() on bit_waitqueue() which leads to NULL deref if
the target bit waitqueue has wait_bit_queue's on it. Use
DEFINE_WAIT_BIT() and __wake_up_bit() instead. Reported by Tomeu
Vizoso.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Rabin Vincent <rabin.vincent@axis.com>
Cc: Tomeu Vizoso <tomeu.vizoso@gmail.com>
Cc: stable@vger.kernel.org
Tested-by: Jesper Nilsson <jesper.nilsson@axis.com>
Tested-by: Rabin Vincent <rabin.vincent@axis.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Ahmed S. Darwish [Thu, 26 Feb 2015 15:22:02 +0000 (10:22 -0500)]
can: kvaser_usb: Read all messages in a bulk-in URB buffer
[ Upstream commit
2fec5104f9c61de4cf2205aa355101e19a81f490 ]
The Kvaser firmware can only read and write messages that are
not crossing the USB endpoint's wMaxPacketSize boundary. While
receiving commands from the CAN device, if the next command in
the same URB buffer crossed that max packet size boundary, the
firmware puts a zero-length placeholder command in its place
then moves the real command to the next boundary mark.
The driver did not recognize such behavior, leading to missing
a good number of rx events during a heavy rx load session.
Moreover, a tx URB context only gets freed upon receiving its
respective tx ACK event. Over time, the free tx URB contexts
pool gets depleted due to the missing ACK events. Consequently,
the netif transmission queue gets __permanently__ stopped; no
frames could be sent again except after restarting the CAN
newtwork interface.
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Oliver Hartkopp [Mon, 23 Feb 2015 19:37:54 +0000 (20:37 +0100)]
can: add missing initialisations in CAN related skbuffs
[ Upstream commit
969439016d2cf61fef53a973d7e6d2061c3793b1 ]
When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient
this can lead to a skb_under_panic due to missing skb initialisations.
Add the missing initialisations at the CAN skbuff creation times on driver
level (rx path) and in the network layer (tx path).
Reported-by: Austin Schuh <austin@peloton-tech.com>
Reported-by: Daniel Steer <daniel.steer@mclaren.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Steven Rostedt (Red Hat) [Sat, 7 Mar 2015 00:55:13 +0000 (19:55 -0500)]
ftrace: Fix ftrace enable ordering of sysctl ftrace_enabled
[ Upstream commit
524a38682573b2e15ab6317ccfe50280441514be ]
Some archs (specifically PowerPC), are sensitive with the ordering of
the enabling of the calls to function tracing and setting of the
function to use to be traced.
That is, update_ftrace_function() sets what function the ftrace_caller
trampoline should call. Some archs require this to be set before
calling ftrace_run_update_code().
Another bug was discovered, that ftrace_startup_sysctl() called
ftrace_run_update_code() directly. If the function the ftrace_caller
trampoline changes, then it will not be updated. Instead a call
to ftrace_startup_enable() should be called because it tests to see
if the callback changed since the code was disabled, and will
tell the arch to update appropriately. Most archs do not need this
notification, but PowerPC does.
The problem could be seen by the following commands:
# echo 0 > /proc/sys/kernel/ftrace_enabled
# echo function > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /proc/sys/kernel/ftrace_enabled
# cat /sys/kernel/debug/tracing/trace
The trace will show that function tracing was not active.
Cc: stable@vger.kernel.org # 2.6.27+
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Pratyush Anand [Fri, 6 Mar 2015 18:28:06 +0000 (23:58 +0530)]
ftrace: Fix en(dis)able graph caller when en(dis)abling record via sysctl
[ Upstream commit
1619dc3f8f555ee1cdd3c75db3885d5715442b12 ]
When ftrace is enabled globally through the proc interface, we must check if
ftrace_graph_active is set. If it is set, then we should also pass the
FTRACE_START_FUNC_RET command to ftrace_run_update_code(). Similarly, when
ftrace is disabled globally through the proc interface, we must check if
ftrace_graph_active is set. If it is set, then we should also pass the
FTRACE_STOP_FUNC_RET command to ftrace_run_update_code().
Consider the following situation.
# echo 0 > /proc/sys/kernel/ftrace_enabled
After this ftrace_enabled = 0.
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
Since ftrace_enabled = 0, ftrace_enable_ftrace_graph_caller() is never
called.
# echo 1 > /proc/sys/kernel/ftrace_enabled
Now ftrace_enabled will be set to true, but still
ftrace_enable_ftrace_graph_caller() will not be called, which is not
desired.
Further if we execute the following after this:
# echo nop > /sys/kernel/debug/tracing/current_tracer
Now since ftrace_enabled is set it will call
ftrace_disable_ftrace_graph_caller(), which causes a kernel warning on
the ARM platform.
On the ARM platform, when ftrace_enable_ftrace_graph_caller() is called,
it checks whether the old instruction is a nop or not. If it's not a nop,
then it returns an error. If it is a nop then it replaces instruction at
that address with a branch to ftrace_graph_caller.
ftrace_disable_ftrace_graph_caller() behaves just the opposite. Therefore,
if generic ftrace code ever calls either ftrace_enable_ftrace_graph_caller()
or ftrace_disable_ftrace_graph_caller() consecutively two times in a row,
then it will return an error, which will cause the generic ftrace code to
raise a warning.
Note, x86 does not have an issue with this because the architecture
specific code for ftrace_enable_ftrace_graph_caller() and
ftrace_disable_ftrace_graph_caller() does not check the previous state,
and calling either of these functions twice in a row has no ill effect.
Link: http://lkml.kernel.org/r/e4fbe64cdac0dd0e86a3bf914b0f83c0b419f146.1425666454.git.panand@redhat.com
Cc: stable@vger.kernel.org # 2.6.31+
Signed-off-by: Pratyush Anand <panand@redhat.com>
[
removed extra if (ftrace_start_up) and defined ftrace_graph_active as 0
if CONFIG_FUNCTION_GRAPH_TRACER is not set.
]
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Steven Rostedt (Red Hat) [Thu, 5 Mar 2015 04:10:28 +0000 (23:10 -0500)]
ftrace: Clear REGS_EN and TRAMP_EN flags on disabling record via sysctl
[ Upstream commit
b24d443b8f17d9776f5fc1f6c780a0a21eb02913 ]
When /proc/sys/kernel/ftrace_enabled is set to zero, all function
tracing is disabled. But the records that represent the functions
still hold information about the ftrace_ops that are hooked to them.
ftrace_ops may request "REGS" (have a full set of pt_regs passed to
the callback), or "TRAMP" (the ops has its own trampoline to use).
When the record is updated to represent the state of the ops hooked
to it, it sets "REGS_EN" and/or "TRAMP_EN" to state that the callback
points to the correct trampoline (REGS has its own trampoline).
When ftrace_enabled is set to zero, all ftrace locations are a nop,
so they do not point to any trampoline. But the _EN flags are still
set. This can cause the accounting to go wrong when ftrace_enabled
is cleared and an ops that has a trampoline is registered or unregistered.
For example, the following will cause ftrace to crash:
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
# echo 0 > /proc/sys/kernel/ftrace_enabled
# echo nop > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /proc/sys/kernel/ftrace_enabled
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
As function_graph uses a trampoline, when ftrace_enabled is set to zero
the updates to the record are not done. When enabling function_graph
again, the record will still have the TRAMP_EN flag set, and it will
look for an op that has a trampoline other than the function_graph
ops, and fail to find one.
Cc: stable@vger.kernel.org # 3.17+
Reported-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Russell King [Fri, 6 Mar 2015 10:49:21 +0000 (10:49 +0000)]
Change email address for 8250_pci
[ Upstream commit
f2e0ea861117bda073d1d7ffbd3120c07c0d5d34 ]
I'm still receiving reports to my email address, so let's point this
at the linux-serial mailing list instead.
Cc: <stable@vger.kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Michael S. Tsirkin [Thu, 5 Mar 2015 00:15:49 +0000 (10:45 +1030)]
virtio_console: avoid config access from irq
[ Upstream commit
eeb8a7e8bb123e84daeef84f5a2eab99ad2839a2 ]
when multiport is off, virtio console invokes config access from irq
context, config access is blocking on s390.
Fix this up by scheduling work from config irq - similar to what we do
for multiport configs.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Michael S. Tsirkin [Thu, 5 Mar 2015 00:15:30 +0000 (10:45 +1030)]
virtio_console: init work unconditionally
[ Upstream commit
4f6e24ed9de8634d6471ef86b382cba6d4e57ca8 ]
when multiport is off, we don't initialize config work,
but we then cancel uninitialized control_work on freeze.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Hurley [Sun, 1 Mar 2015 15:11:05 +0000 (10:11 -0500)]
console: Fix console name size mismatch
commit
30a22c215a0007603ffc08021f2e8b64018517dd upstream.
commit
6ae9200f2cab7 ("enlarge console.name") increased the storage
for the console name to 16 bytes, but not the corresponding
struct console_cmdline::name storage. Console names longer than
8 bytes cause read beyond end-of-string and failure to match
console; I'm not sure if there are other unexpected consequences.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
2cf6258c282608633c9477e5c8e319e948565122)
Peter Hurley [Wed, 11 Mar 2015 13:19:16 +0000 (09:19 -0400)]
serial: 8250_dw: Fix deadlock in LCR workaround
[ Upstream commit
7fd6f640f2dd17dac6ddd6702c378cb0bb9cfa11 ]
Trying to write console output from within the serial console driver
while the port->lock is held causes recursive deadlock:
CPU 0
spin_lock_irqsave(&port->lock)
printk()
console_unlock()
call_console_drivers()
serial8250_console_write()
spin_lock_irqsave(&port->lock)
** DEADLOCK **
The 8250_dw i/o accessors try to write a console error message if the
LCR workaround was unsuccessful. When the port->lock is already held
(eg., when called from serial8250_set_termios()), this deadlocks.
Make the error message a FIXME until a general solution is devised.
Cc: Tim Kryger <tim.kryger@gmail.com>
Reported-by: Zhang Zhen <zhenzhang.zhang@huawei.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Miklos Szeredi [Thu, 26 Feb 2015 10:45:47 +0000 (11:45 +0100)]
fuse: notify: don't move pages
[ Upstream commit
0d2783626a53d4c922f82d51fa675cb5d13f0d36 ]
fuse_try_move_page() is not prepared for replacing pages that have already
been read.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Miklos Szeredi [Thu, 26 Feb 2015 10:45:47 +0000 (11:45 +0100)]
fuse: set stolen page uptodate
[ Upstream commit
aa991b3b267e24f578bac7b09cc57579b660304b ]
Regular pipe buffers' ->steal method (generic_pipe_buf_steal()) doesn't set
PG_uptodate.
Don't warn on this condition, just set the uptodate flag.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
JeHyeon Yeon [Mon, 16 Mar 2015 01:03:19 +0000 (01:03 +0000)]
LZ4 : fix the data abort issue
[ Upstream commit
d5e7cafd69da24e6d6cc988fab6ea313a2577efc ]
If the part of the compression data are corrupted, or the compression
data is totally fake, the memory access over the limit is possible.
This is the log from my system usning lz4 decompression.
[6502]data abort, halting
[6503]r0 0x00000000 r1 0x00000000 r2 0xdcea0ffc r3 0xdcea0ffc
[6509]r4 0xb9ab0bfd r5 0xdcea0ffc r6 0xdcea0ff8 r7 0xdce80000
[6515]r8 0x00000000 r9 0x00000000 r10 0x00000000 r11 0xb9a98000
[6522]r12 0xdcea1000 usp 0x00000000 ulr 0x00000000 pc 0x820149bc
[6528]spsr 0x400001f3
and the memory addresses of some variables at the moment are
ref:0xdcea0ffc, op:0xdcea0ffc, oend:0xdcea1000
As you can see, COPYLENGH is 8bytes, so @ref and @op can access the momory
over @oend.
Signed-off-by: JeHyeon Yeon <tom.yeon@windriver.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Tue, 17 Mar 2015 15:53:33 +0000 (11:53 -0400)]
drm/radeon: drop ttm two ended allocation
[ Upstream commit
a239118a24b3bf9089751068e431dfb63dc4168b ]
radeon_bo_create() calls radeon_ttm_placement_from_domain()
before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
uses the ttm bo size to determine when to select top down
allocation but since the ttm bo is not initialized yet the
check is always false. It only took effect when buffers
were validated later. It also seemed to regress suspend
and resume on some systems possibly due to it not
taking effect in radeon_bo_create().
radeon_bo_create() and radeon_ttm_placement_from_domain()
need to be reworked substantially for this to be optimally
effective. Re-enable it at that point.
Noticed-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Maarten Lankhorst [Tue, 3 Mar 2015 08:56:42 +0000 (09:56 +0100)]
drm/radeon: fix wait to actually occur after the signaling callback
[ Upstream commit
b6610101718d4ab90d793c482625e98eb1262cad ]
A normal wait adds to the front of the tail. By doing something
similar to fence_default_wait the fence code can run without racing.
This is a complete fix for "panic on suspend from KDE with radeon",
and a partial fix for "Radeon: System pauses on TAHITI". On tahiti
si_irq_set needs to be fixed too, to completely flush the writes
before radeon_fence_activity is called in radeon_fence_enable_signaling.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Reported-by: Jon Arne Jørgensen <jonjon.arnearne@gmail.com>
Reported-and-tested-by: Gustaw Smolarczyk <wielkiegie@gmail.com>
Cc: stable@vger.kernel.org (v3.18+)
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Christian König [Thu, 19 Feb 2015 08:40:28 +0000 (09:40 +0100)]
drm/radeon: drop setting UPLL to sleep mode
[ Upstream commit
a17d4996e051e78d164989b894608cf37cd5110b ]
Just keep it working, seems to fix some PLL problems.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Tue, 3 Mar 2015 22:00:43 +0000 (17:00 -0500)]
drm/radeon: fix interlaced modes on DCE8
[ Upstream commit
77ae5f4b48a0445426c9c1ef7c0f28b717e35d55 ]
Need to double the viewport height.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Tue, 3 Mar 2015 01:39:56 +0000 (20:39 -0500)]
drm/radeon: do a posting read in rs600_set_irq
[ Upstream commit
54acf107e4e66d1f4a697e08a7f60dba9fcf07c3 ]
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Tue, 3 Mar 2015 01:43:53 +0000 (20:43 -0500)]
drm/radeon: do a posting read in si_set_irq
[ Upstream commit
0586915ec10d0ae60de5cd3381ad25a704760402 ]
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Tue, 3 Mar 2015 01:45:24 +0000 (20:45 -0500)]
drm/radeon: do a posting read in cik_set_irq
[ Upstream commit
cffefd9bb31cd35ab745d3b49005d10616d25bdc ]
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Tue, 3 Mar 2015 01:41:31 +0000 (20:41 -0500)]
drm/radeon: do a posting read in r600_set_irq
[ Upstream commit
9d1393f23d5656cdd5f368efd60694d4aeed81d3 ]
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Tue, 3 Mar 2015 01:36:26 +0000 (20:36 -0500)]
drm/radeon: do a posting read in r100_set_irq
[ Upstream commit
f957063fee6392bb9365370db6db74dc0b2dce0a ]
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Tue, 3 Mar 2015 01:42:53 +0000 (20:42 -0500)]
drm/radeon: do a posting read in evergreen_set_irq
[ Upstream commit
c320bb5f6dc0cb88a811cbaf839303e0a3916a92 ]
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Tommi Rantala [Mon, 2 Mar 2015 19:36:07 +0000 (21:36 +0200)]
drm/radeon: fix DRM_IOCTL_RADEON_CS oops
[ Upstream commit
a28b2a47edcd0cb7c051b445f71a426000394606 ]
Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the
following oops.
Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort().
----------------------------------
#include <stdint.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <drm/radeon_drm.h>
static const struct drm_radeon_cs cs;
int main(int argc, char **argv)
{
return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, &cs);
}
----------------------------------
[ttrantal@test2 ~]$ ./main /dev/dri/card0
[ 46.904650] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 46.905022] IP: [<
ffffffff814d6df2>] list_sort+0x42/0x240
[ 46.905022] PGD
68f29067 PUD
688b5067 PMD 0
[ 46.905022] Oops: 0002 [#1] SMP
[ 46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58
[ 46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007
[ 46.905022] task:
ffff880058e2bcc0 ti:
ffff880058e64000 task.ti:
ffff880058e64000
[ 46.905022] RIP: 0010:[<
ffffffff814d6df2>] [<
ffffffff814d6df2>] list_sort+0x42/0x240
[ 46.905022] RSP: 0018:
ffff880058e67998 EFLAGS:
00010246
[ 46.905022] RAX:
0000000000000000 RBX:
0000000000000000 RCX:
0000000000000000
[ 46.905022] RDX:
ffffffff81644410 RSI:
ffff880058e67b40 RDI:
ffff880058e67a58
[ 46.905022] RBP:
ffff880058e67a88 R08:
0000000000000000 R09:
0000000000000000
[ 46.905022] R10:
ffff880058e2bcc0 R11:
ffffffff828e6ca0 R12:
ffffffff81644410
[ 46.905022] R13:
ffff8800694b8018 R14:
0000000000000000 R15:
ffff880058e679b0
[ 46.905022] FS:
00007fdc65a65700(0000) GS:
ffff88006d600000(0000) knlGS:
0000000000000000
[ 46.905022] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 46.905022] CR2:
0000000000000000 CR3:
0000000058dd9000 CR4:
00000000000006f0
[ 46.905022] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 46.905022] DR3:
0000000000000000 DR6:
00000000ffff4ff0 DR7:
0000000000000400
[ 46.905022] Stack:
[ 46.905022]
ffff880058e67b40 ffff880058e2bcc0 ffff880058e67a78 0000000000000000
[ 46.905022]
0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 46.905022]
0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 46.905022] Call Trace:
[ 46.905022] [<
ffffffff81644a65>] radeon_cs_parser_fini+0x195/0x220
[ 46.905022] [<
ffffffff81645069>] radeon_cs_ioctl+0xa9/0x960
[ 46.905022] [<
ffffffff815e1f7c>] drm_ioctl+0x19c/0x640
[ 46.905022] [<
ffffffff810f8fdd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 46.905022] [<
ffffffff810f90ad>] ? trace_hardirqs_on+0xd/0x10
[ 46.905022] [<
ffffffff8160c066>] radeon_drm_ioctl+0x46/0x80
[ 46.905022] [<
ffffffff81211868>] do_vfs_ioctl+0x318/0x570
[ 46.905022] [<
ffffffff81462ef6>] ? selinux_file_ioctl+0x56/0x110
[ 46.905022] [<
ffffffff81211b41>] SyS_ioctl+0x81/0xa0
[ 46.905022] [<
ffffffff81dc6312>] system_call_fastpath+0x12/0x17
[ 46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff
ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7
00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85
[ 46.905022] RIP [<
ffffffff814d6df2>] list_sort+0x42/0x240
[ 46.905022] RSP <
ffff880058e67998>
[ 46.905022] CR2:
0000000000000000
[ 47.149253] ---[ end trace
09576b4e8b2c20b8 ]---
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Catalin Marinas [Wed, 11 Mar 2015 12:20:39 +0000 (12:20 +0000)]
arm64: Invalidate the TLB corresponding to intermediate page table levels
[ Upstream commit
285994a62c80f1d72c6924282bcb59608098d5ec ]
The ARM architecture allows the caching of intermediate page table
levels and page table freeing requires a sequence like:
pmd_clear()
TLB invalidation
pte page freeing
With commit
5e5f6dc10546 (arm64: mm: enable HAVE_RCU_TABLE_FREE logic),
the page table freeing batching was moved from tlb_remove_page() to
tlb_remove_table(). The former takes care of TLB invalidation as this is
also shared with pte clearing and page cache page freeing. The latter,
however, does not invalidate the TLBs for intermediate page table levels
as it probably relies on the architecture code to do it if required.
When the mm->mm_users < 2, tlb_remove_table() does not do any batching
and page table pages are freed before tlb_finish_mmu() which performs
the actual TLB invalidation.
This patch introduces __tlb_flush_pgtable() for arm64 and calls it from
the {pte,pmd,pud}_free_tlb() directly without relying on deferred page
table freeing.
Fixes:
5e5f6dc10546 arm64: mm: enable HAVE_RCU_TABLE_FREE logic
Reported-by: Jon Masters <jcm@redhat.com>
Tested-by: Jon Masters <jcm@redhat.com>
Tested-by: Steve Capper <steve.capper@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Will Deacon [Wed, 29 Oct 2014 10:03:09 +0000 (10:03 +0000)]
mmu_gather: move minimal range calculations into generic code
[ Upstream commit
fb7332a9fedfd62b1ba6530c86f39f0fa38afd49 ]
On architectures with hardware broadcasting of TLB invalidation messages
, it makes sense to reduce the range of the mmu_gather structure when
unmapping page ranges based on the dirty address information passed to
tlb_remove_tlb_entry.
arm64 already does this by directly manipulating the start/end fields
of the gather structure, but this confuses the generic code which
does not expect these fields to change and can end up calculating
invalid, negative ranges when forcing a flush in zap_pte_range.
This patch moves the minimal range calculation out of the arm64 code
and into the generic implementation, simplifying zap_pte_range in the
process (which no longer needs to care about start/end, since they will
point to the appropriate ranges already). With the range being tracked
by core code, the need_flush flag is dropped in favour of checking that
the end of the range has actually been set.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Michal Simek <monstr@monstr.eu>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Suzuki K. Poulose [Thu, 19 Mar 2015 18:17:09 +0000 (18:17 +0000)]
arm64: Honor __GFP_ZERO in dma allocations
[ Upstream commit
7132813c384515c9dede1ae20e56f3895feb7f1e ]
Current implementation doesn't zero out the pages allocated.
Honor the __GFP_ZERO flag and zero out if set.
Cc: <stable@vger.kernel.org> # v3.14+
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Eric Dumazet [Tue, 18 Nov 2014 07:06:20 +0000 (23:06 -0800)]
tcp: make connect() mem charging friendly
[ Upstream commit
355a901e6cf1b2b763ec85caa2a9f04fbcc4ab4a ]
While working on sk_forward_alloc problems reported by Denys
Fedoryshchenko, we found that tcp connect() (and fastopen) do not call
sk_wmem_schedule() for SYN packet (and/or SYN/DATA packet), so
sk_forward_alloc is negative while connect is in progress.
We can fix this by calling regular sk_stream_alloc_skb() both for the
SYN packet (in tcp_connect()) and the syn_data packet in
tcp_send_syn_data()
Then, tcp_send_syn_data() can avoid copying syn_data as we simply
can manipulate syn_data->cb[] to remove SYN flag (and increment seq)
Instead of open coding memcpy_fromiovecend(), simply use this helper.
This leaves in socket write queue clean fast clone skbs.
This was tested against our fastopen packetdrill tests.
Reported-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Catalin Marinas [Fri, 20 Mar 2015 16:48:13 +0000 (16:48 +0000)]
net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour
[ Upstream commit
91edd096e224941131f896b86838b1e59553696a ]
Commit
db31c55a6fb2 (net: clamp ->msg_namelen instead of returning an
error) introduced the clamping of msg_namelen when the unsigned value
was larger than sizeof(struct sockaddr_storage). This caused a
msg_namelen of -1 to be valid. The native code was subsequently fixed by
commit
dbb490b96584 (net: socket: error on a negative msg_namelen).
In addition, the native code sets msg_namelen to 0 when msg_name is
NULL. This was done in commit (
6a2a2b3ae075 net:socket: set msg_namelen
to 0 if msg_name is passed as NULL in msghdr struct from userland) and
subsequently updated by
08adb7dabd48 (fold verify_iovec() into
copy_msghdr_from_user()).
This patch brings the get_compat_msghdr() in line with
copy_msghdr_from_user().
Fixes:
db31c55a6fb2 (net: clamp ->msg_namelen instead of returning an error)
Cc: David S. Miller <davem@davemloft.net>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Josh Hunt [Thu, 19 Mar 2015 23:19:30 +0000 (19:19 -0400)]
tcp: fix tcp fin memory accounting
[ Upstream commit
d22e1537181188e5dc8cbc51451832625035bdc2 ]
tcp_send_fin() does not account for the memory it allocates properly, so
sk_forward_alloc can be negative in cases where we've sent a FIN:
ss example output (ss -amn | grep -B1 f4294):
tcp FIN-WAIT-1 0 1 192.168.0.1:45520 192.0.2.1:8080
skmem:(r0,rb87380,t0,tb87380,
f4294966016,w1280,o0,bl0)
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Steven Barth [Thu, 19 Mar 2015 15:16:04 +0000 (16:16 +0100)]
ipv6: fix backtracking for throw routes
[ Upstream commit
73ba57bfae4a1914f6a6dac71e3168dd900e00af ]
for throw routes to trigger evaluation of other policy rules
EAGAIN needs to be propagated up to fib_rules_lookup
similar to how its done for IPv4
A simple testcase for verification is:
ip -6 rule add lookup 33333 priority 33333
ip -6 route add throw 2001:db8::1
ip -6 route add 2001:db8::1 via fe80::1 dev wlan0 table 33333
ip route get 2001:db8::1
Signed-off-by: Steven Barth <cyrus@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Ondrej Zary [Wed, 18 Mar 2015 22:01:01 +0000 (23:01 +0100)]
Revert "net: cx82310_eth: use common match macro"
[ Upstream commit
8d006e0105978619fb472e150c88b0d49337fe2b ]
This reverts commit
11ad714b98f6d9ca0067568442afe3e70eb94845 because
it breaks cx82310_eth.
The custom USB_DEVICE_CLASS macro matches
bDeviceClass, bDeviceSubClass and bDeviceProtocol
but the common USB_DEVICE_AND_INTERFACE_INFO matches
bInterfaceClass, bInterfaceSubClass and bInterfaceProtocol instead, which are
not specified.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Al Viro [Sat, 14 Mar 2015 05:34:56 +0000 (05:34 +0000)]
rxrpc: bogus MSG_PEEK test in rxrpc_recvmsg()
[ Upstream commit
7d985ed1dca5c90535d67ce92ef6ca520302340a ]
[I would really like an ACK on that one from dhowells; it appears to be
quite straightforward, but...]
MSG_PEEK isn't passed to ->recvmsg() via msg->msg_flags; as the matter of
fact, neither the kernel users of rxrpc, nor the syscalls ever set that bit
in there. It gets passed via flags; in fact, another such check in the same
function is done correctly - as flags & MSG_PEEK.
It had been that way (effectively disabled) for 8 years, though, so the patch
needs beating up - that case had never been tested. If it is correct, it's
-stable fodder.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Al Viro [Sat, 14 Mar 2015 05:22:21 +0000 (05:22 +0000)]
caif: fix MSG_OOB test in caif_seqpkt_recvmsg()
[ Upstream commit
3eeff778e00c956875c70b145c52638c313dfb23 ]
It should be checking flags, not msg->msg_flags. It's ->sendmsg()
instances that need to look for that in ->msg_flags, ->recvmsg() ones
(including the other ->recvmsg() instance in that file, as well as
unix_dgram_recvmsg() this one claims to be imitating) check in flags.
Braino had been introduced in commit dcda13 ("caif: Bugfix - use MSG_TRUNC
in receive") back in 2010, so it goes quite a while back.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Eric Dumazet [Fri, 13 Mar 2015 16:49:59 +0000 (09:49 -0700)]
inet_diag: fix possible overflow in inet_diag_dump_one_icsk()
[ Upstream commit
c8e2c80d7ec00d020320f905822bf49c5ad85250 ]
inet_diag_dump_one_icsk() allocates too small skb.
Add inet_sk_attr_size() helper right before inet_sk_diag_fill()
so that it can be updated if/when new attributes are added.
iproute2/ss currently does not use this dump_one() interface,
this might explain nobody noticed this problem yet.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
projects / profile / wearable / platform / kernel / linux-3.18-exynos7270.git / log