Jean Delvare [Sun, 16 Dec 2012 21:00:50 +0000 (22:00 +0100)]
pcmcia/vrc4171: Add missing spinlock init
commit
811af9723859884f2f771f3174f3ddedab7c53b5 upstream.
It doesn't seem this spinlock was properly initialized. This bug was
introduced by commit
7a410e8d4d97457c8c381e2de9cdc7bd3306badc.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John David Anglin [Tue, 15 Jan 2013 00:45:00 +0000 (19:45 -0500)]
Purge existing TLB entries in set_pte_at and ptep_set_wrprotect
commit
7139bc1579901b53db7e898789e916ee2fb52d78 upstream.
This patch goes a long way toward fixing the minifail bug, and
it significantly improves the stability of SMP machines such as
the rp3440. When write protecting a page for COW, we need to
purge the existing translation. Otherwise, the COW break
doesn't occur as expected because the TLB may still have a stale entry
which allows writes.
[jejb: fix up checkpatch errors]
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thadeu Lima de Souza Cascardo [Fri, 28 Dec 2012 09:13:19 +0000 (09:13 +0000)]
powerpc/eeh: Fix crash when adding a device in a slot with DDW
commit
6a040ce72598159a74969a2d01ab0ba5ee6536b3 upstream.
The DDW code uses a eeh_dev struct from the pci_dev. However, this is
not set until eeh_add_device_late is called.
Since pci_bus_add_devices is called before eeh_add_device_late, the PCI
devices are added to the bus, making drivers' probe hooks to be called.
These will call set_dma_mask, which will call the DDW code, which will
require the eeh_dev struct from pci_dev. This would result in a crash,
due to a NULL dereference.
Calling eeh_add_device_late after pci_bus_add_devices would make the
system BUG, because device files shouldn't be added to devices there
were not added to the system. So, a new function is needed to add such
files only after pci_bus_add_devices have been called.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Acked-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suzuki K. Poulose [Mon, 7 Jan 2013 00:26:57 +0000 (00:26 +0000)]
uprobes/powerpc: Add dependency on single step emulation
commit
5e249d4528528c9a77da051a89ec7f99d31b83eb upstream.
Uprobes uses emulate_step in sstep.c, but we haven't explicitly specified
the dependency. On pseries HAVE_HW_BREAKPOINT protects us, but 44x has no
such luxury.
Consolidate other users that depend on sstep and create a new config option.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Cc: linuxppc-dev@ozlabs.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Phileas Fogg [Fri, 22 Feb 2013 23:32:19 +0000 (00:32 +0100)]
powerpc/kexec: Disable hard IRQ before kexec
commit
8520e443aa56cc157b015205ea53e7b9fc831291 upstream.
Disable hard IRQ before kexec a new kernel image.
Not doing it can result in corrupted data in the memory segments
reserved for the new kernel.
Signed-off-by: Phileas Fogg <phileas-fogg@mail.ru>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joonsoo Kim [Sat, 9 Feb 2013 04:52:45 +0000 (05:52 +0100)]
ARM: 7643/1: sched: correct update_sched_clock()
commit
7c4e9ced424be4d36df6a3e3825763e97ee97607 upstream.
If we want load epoch_cyc and epoch_ns atomically,
we should update epoch_cyc_copy first of all.
This notify reader that updating is in progress.
If we update epoch_cyc first like as current implementation,
there is subtle error case.
Look at the below example.
<Initial Condition>
cyc = 9
ns = 900
cyc_copy = 9
== CASE 1 ==
<CPU A = reader> <CPU B = updater>
write cyc = 10
read cyc = 10
read ns = 900
write ns = 1000
write cyc_copy = 10
read cyc_copy = 10
output = (10, 900)
== CASE 2 ==
<CPU A = reader> <CPU B = updater>
read cyc = 9
write cyc = 10
write ns = 1000
read ns = 1000
read cyc_copy = 9
write cyc_copy = 10
output = (9, 1000)
If atomic read is ensured, output should be (9, 900) or (10, 1000).
But, output in example case are not.
So, change updating sequence in order to correct this problem.
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Wed, 6 Feb 2013 11:42:23 +0000 (11:42 +0000)]
arm64: compat: use compat_uptr_t type for compat_ucontext.uc_link
commit
c0e01d5d8f15c085236df184e5bc3d79a8b700cd upstream.
struct compat_ucontext * is a 64-bit pointer, so we need to use a
compat_uptr_t instead to avoid declaring a structure incompatible with
what AArch32 userspace expects.
Reported-by: Edmund Grimley-Evans <Edmund.Grimley-Evans@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Wed, 6 Feb 2013 18:25:12 +0000 (18:25 +0000)]
ARM: integrator: ensure ap_syscon_base is initialised when !CONFIG_MMU
commit
ab2a724a2ef9cee5957692257a5d1f08fd7acbbd upstream.
When running on Integrator/AP using atags, ap_syscon_base is initialised
in ->map_io, which isn't called for !MMU platforms.
Instead, initialise the pointer in ->machine_init, as we do when booting
with device-tree.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steffen Trumtrar [Wed, 30 Jan 2013 13:16:00 +0000 (14:16 +0100)]
ARM: i.MX25: clk: parent per5_clk to AHB clock
commit
4b526ca5f627188425184a22ed46c91baa602d43 upstream.
The mxc-timer on the imx25 needs to be derived from the AHB clock.
If a bootloader reparents this clock to the ipg_clk_highfreq, which according
to the datasheet is a valid operation, the system can/will produce lockups/
freezes after some time [1].
This can be forced with code like
while(1)
syscall(SYS_clock_gettime, CLOCK_REALTIME, &tp);
This was already fixed with the commit
"i.MX25 GPT clock fix: ensure correct the clock source" [2],
for 3.1-rc2, but was lost, when i.MX was converted to the common clock framework
("ARM i.MX25: implement clocks using common clock framework") [3]
[1]: http://lists.arm.linux.org.uk/lurker/message/
20130129.161230.
229bda17.en.html
[2]:
2012d9ca2a1381ae3e733330a7f0d1d2f1988bba
[3]:
6bbaec5676e4f475b0d78743cbd4c70a8804ce14
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Tue, 8 Jan 2013 21:58:31 +0000 (21:58 +0000)]
ARM: samsung: fix assembly syntax for new gas
commit
2815774bb38445006074e16251b9ef5123bdc616 upstream.
Recent assembler versions complain about extraneous
whitespace inside [] brackets. This fixes all of
these instances for the samsung platforms. We should
backport this to all kernels that might need to
be built with new binutils.
arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]'
arch/arm/kernel/debug.S: Assembler messages:
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages:
arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000)))]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Ferre [Wed, 30 Jan 2013 14:32:26 +0000 (15:32 +0100)]
ARM: at91/DT: remove atmel,use-dma-* from 9x5 and 9n12 USART nodes
commit
c3f0f282d950a1e87496a2633ed9e924e275ff8c upstream.
Fix the use of USART on both at91sam9x5 and at91sam9n12. In DTS, the
atmel,use-dma-[rx|tx] property is present but a DMA channel cannot be used.
Indeed the connexion between the DMA engine and the slave is not implemented
yet in Device Tree.
Note however that this property is also used for PDC (private DMA) on older
SoCs. This is why the driver alone cannot determine the validity of this
property.
Reported-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Igor Grinberg [Sun, 13 Jan 2013 11:49:47 +0000 (13:49 +0200)]
ARM: PXA3xx: program the CSMSADRCFG register
commit
d107a204154ddd79339203c2deeb7433f0cf6777 upstream.
The Chip Select Configuration Register must be programmed to 0x2 in
order to achieve the correct behavior of the Static Memory Controller.
Without this patch devices wired to DFI and accessed through SMC cannot
be accessed after resume from S2.
Do not rely on the boot loader to program the CSMSADRCFG register by
programming it in the kernel smemc module.
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Mon, 28 Jan 2013 20:58:22 +0000 (21:58 +0100)]
ARM: 7635/1: versatile: fix the PCI IRQ regression
commit
e3e92a7be6936dff1de80e66b0b683d54e9e02d8 upstream.
The PCI IRQs were regressing due to two things:
- The PCI glue layer was using an hard-coded IRQ 27 offset.
This caused the immediate regression.
- The SIC IRQ mask was inverted (i.e. a bit was indeed set to
one for each valid IRQ on the SIC, but accidentally inverted
in the init call). This has been around forever, but we have
been saved by some other forgiving code that would reserve
IRQ descriptors in this range, as the versatile is
non-sparse.
When the IRQs were bumped up 32 steps so as to avoid using IRQ
zero and avoid touching the 16 legacy IRQs, things broke.
Introduce an explicit valid mask for the IRQs that are active
on the PIC/SIC, and pass that. Use the BIT() macro from
<linux/bitops.h> to make sure we hit the right bits, readily
defined in <mach/platform.h>.
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ryo Tsutsui [Sun, 3 Feb 2013 08:18:00 +0000 (17:18 +0900)]
ASoC: arizona: Fixed a bug in FLL fractional calculation
commit
01f58153aefc158fd690b337d29ad140e963959d upstream.
Previously arizona_calc_fll() was checking if the target frequency is
exactly divisible by reference frequency, but should have been product
of the ratio and the reference frequency.
Also scale down the Lamba and Theta coefficients be under 16-bits in
order to match the registers.
Signed-off-by: Ryo Tsutsui <ryo.tsutsui@wolfsonmicro.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Rattray [Fri, 1 Feb 2013 15:51:41 +0000 (15:51 +0000)]
ASoC: wm2200: correct IN2L and IN3L digital mute
commit
0d2b6422529a26ac4dee06196524ba9da70cf735 upstream.
Signed-off-by: Chris Rattray <crattray@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Malcolm Priestley [Wed, 30 Jan 2013 20:07:29 +0000 (20:07 +0000)]
staging: vt6656: Fix URB submitted while active warning.
commit
ae5943de8c8c4438cbac5cda599ff0b88c224468 upstream.
This error happens because PIPEnsControlOut and PIPEnsControlIn unlock the
spin lock for delay, letting in another thread.
The patch moves the current MP_SET_FLAG to before filling
of sUsbCtlRequest for pControlURB and clears it in event of failing.
Any thread calling either function while fMP_CONTROL_READS or fMP_CONTROL_WRITES
flags set will return STATUS_FAILURE.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Malcolm Priestley [Tue, 22 Jan 2013 20:13:34 +0000 (20:13 +0000)]
staging: vt6656: Revert: 64bit fixes: dpc.c incorrect addressing of void structure.
commit
392c6ff87f568d573239b763855160d1f06114de upstream.
The patch was totally wrong and is reverted.
The problem was ultimately fixed by upstream commit.
1ee4c55fc9620451b2a825d793042a7e0775391b
staging: vt6656: Fix inconsistent structure packing
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Malcolm Priestley [Tue, 22 Jan 2013 20:12:34 +0000 (20:12 +0000)]
staging: vt6656: revert : 64 bit- Correctly address void structure.
commit
d61ac98a4bd86b3217f0c6e058bd0b3a3282899b upstream.
The patch is wrong and is partially reverted.
The NULL check of pTransmitKey->pvKeyTable is kept.
The problem was ultimately fixed by upstream commit.
1ee4c55fc9620451b2a825d793042a7e0775391b
staging: vt6656: Fix inconsistent structure packing
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 1 Feb 2013 14:51:58 +0000 (14:51 +0000)]
staging: comedi: ni_labpc: correct differential channel sequence for AI commands
commit
4c4bc25d0fa6beaf054c0b4c3b324487f266c820 upstream.
Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting
meaningful output from a Lab-PC+ in differential mode for AI cmds, but
AI insn reads gave correct readings. He tracked it down to two
problems, one of which is addressed by this patch.
It seems the setting of the channel bits for particular scanning modes
was incorrect for differential mode. (Only half the number of channels
are available in differential mode; comedi refers to them as channels 0,
1, 2 and 3, but the hardware documentation refers to them as channels 0,
2, 4 and 6.) In differential mode, the setting of the channel enable
bits in the command1 register should depend on whether the scan enable
bit is set. Effectively, we need to double the comedi channel number
when the scan enable bit is not set in differential mode. The scan
enable bit gets set when the AI scan mode is `MODE_MULT_CHAN_UP` or
`MODE_MULT_CHAN_DOWN`, and gets cleared when the AI scan mode is
`MODE_SINGLE_CHAN` or `MODE_SINGLE_CHAN_INTERVAL`. The existing test
for whether the comedi channel number needs to be doubled in
differential mode is incorrect in `labpc_ai_cmd()`. This patch corrects
the test.
Thanks to Tuomas for suggesting the fix.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 1 Feb 2013 14:51:57 +0000 (14:51 +0000)]
staging: comedi: ni_labpc: set up command4 register *after* command3
commit
22056e2b46246d97ff0f7c6e21a77b8daa07f02c upstream.
Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting
meaningful output from a Lab-PC+ in differential mode for AI cmds, but
AI insn reads gave correct readings. He tracked it down to two
problems, one of which is addressed by this patch.
It seems that writing to the command3 register after writing to the
command4 register in `labpc_ai_cmd()` messes up the differential
reference bit setting in the command4 register. Set up the command4
register after the command3 register (as in `labpc_ai_rinsn()`) to avoid
the problem.
Thanks to Tuomas for suggesting the fix.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 28 Jan 2013 16:14:31 +0000 (16:14 +0000)]
staging: comedi: disallow COMEDI_DEVCONFIG on non-board minors
commit
754ab5c0e55dd118273ca2c217c4d95e9fbc8259 upstream.
Comedi has two sorts of minor devices:
(a) normal board minor devices in the range 0 to
COMEDI_NUM_BOARD_MINORS-1 inclusive; and
(b) special subdevice minor devices in the range COMEDI_NUM_BOARD_MINORS
upwards that are used to open the same underlying comedi device as the
normal board minor devices, but with non-default read and write
subdevices for asynchronous commands.
The special subdevice minor devices get created when a board supporting
asynchronous commands is attached to a normal board minor device, and
destroyed when the board is detached from the normal board minor device.
One way to attach or detach a board is by using the COMEDI_DEVCONFIG
ioctl. This should only be used on normal board minors as the special
subdevice minors are too ephemeral. In particular, the change
introduced in commit
7d3135af399e92cf4c9bbc5f86b6c140aab3b88c ("staging:
comedi: prevent auto-unconfig of manually configured devices") breaks
horribly for special subdevice minor devices.
Since there's no legitimate use for the COMEDI_DEVCONFIG ioctl on a
special subdevice minor device node, disallow it and return -ENOTTY.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Minchan Kim [Mon, 28 Jan 2013 01:00:08 +0000 (10:00 +0900)]
staging: zsmalloc: Fix TLB coherency and build problem
commit
9915518887e83764269d5b617d01782893877ed3 upstream.
Recently, Matt Sealey reported he fail to build zsmalloc caused by
using of local_flush_tlb_kernel_range which are architecture dependent
function so !CONFIG_SMP in ARM couldn't implement it so it ends up
build error following as.
MODPOST 216 modules
LZMA arch/arm/boot/compressed/piggy.lzma
AS arch/arm/boot/compressed/lib1funcs.o
ERROR: "v7wbi_flush_kern_tlb_range"
[drivers/staging/zsmalloc/zsmalloc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs....
The reason we used that function is copy method by [1]
was really slow in ARM but at that time.
More severe problem is ARM can prefetch speculatively on other CPUs
so under us, other TLBs can have an entry only if we do flush local
CPU. Russell King pointed that. Thanks!
We don't have many choices except using flush_tlb_kernel_range.
My experiment in ARMv7 processor 4 core didn't make any difference with
zsmapbench[2] between local_flush_tlb_kernel_range and flush_tlb_kernel_range
but still page-table based is much better than copy-based.
* bigger is better.
1. local_flush_tlb_kernel_range: 3918795 mappings
2. flush_tlb_kernel_range : 3989538 mappings
3. copy-based: 635158 mappings
This patch replace local_flush_tlb_kernel_range with
flush_tlb_kernel_range which are avaialbe in all architectures
because we already have used it in vmalloc allocator which are
generic one so build problem should go away and performane loss
shoud be void.
[1] f553646, zsmalloc: add page table mapping method
[2] https://github.com/spartacus06/zsmapbench
Reported-by: Matt Sealey <matt@genesi-usa.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Thu, 21 Feb 2013 20:04:31 +0000 (20:04 +0000)]
drm/i915: Handle untiled planes when computing their offsets
commit
bc752862170c135d6c09fb22d79eeb451023568e upstream.
We trim the fb to fit the CRTC by computing the offset of that CRTC to
its nearest tile_row origin. This allows us to use framebuffers that are
larger than the CRTC limits without additional work.
However, we failed to compute the offset for a linear framebuffer
correctly as we treated its x-advance in whole tiles (instead of the
linear increment expected), leaving the CRTC misaligned with its
contents.
Fixes regression from commit
c2c75131244507c93f812862fdbd4f3a37139401
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jul 5 12:17:30 2012 +0200
drm/i915: adjust framebuffer base address on gen4+
v2: Adjust relative x-coordinate after linear alignment (vsyrjala)
v3: Repaint with pokadots (vsyrjala)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61152
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Fri, 15 Feb 2013 17:35:30 +0000 (18:35 +0100)]
drm/i915: inverted brightness quirk for Acer Aspire 4736Z
commit
ac4199e0f047546aa40172785e26c82b54bbe811 upstream.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53881
Cc: Jani Nikula <jani.nikula@intel.com>
Tested-by: Jani Monoses <jani@ubuntu.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Thu, 14 Feb 2013 18:46:07 +0000 (19:46 +0100)]
drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap
commit
eb32e4584d8e9d6cbec20550d4f91396de2cdb55 upstream.
Yet another remnant ... this might explain why l3 remapping didn't
really work on HSW.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441
Spotted-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jani Nikula [Thu, 14 Feb 2013 09:23:35 +0000 (11:23 +0200)]
drm/i915: add missing \n to UTS_RELEASE in the error_state
commit
fdfa175d0a9cfa2082ce24e67e284e5acbba452a upstream.
Amending
commit
4518f611ba21ba165ea3714055938a8984a44ff9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jan 23 16:16:35 2013 +0100
drm/i915: dump UTS_RELEASE into the error_state
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Patrik Jakobsson [Wed, 13 Feb 2013 21:20:22 +0000 (22:20 +0100)]
drm/i915: Set i9xx sdvo clock limits according to specifications
commit
4f7dfb6788dd022446847fbbfbe45e13bedb5be2 upstream.
The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9.
Since we do all calculations based on them being register values (which are
subtracted by 2) we need to specify them accordingly.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mika Kuoppala [Fri, 8 Feb 2013 14:35:37 +0000 (16:35 +0200)]
drm/i915: disable shared panel fitter for pipe
commit
24a1f16de97c4cf0029d9acd04be06db32208726 upstream.
If encoder is switched off by BIOS, but the panel fitter is left on,
we never try to turn off the panel fitter and leave it still attached
to the pipe - which can cause blurry output elsewhere.
Based on work by Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com>
[danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny
comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Wed, 6 Feb 2013 10:24:41 +0000 (11:24 +0100)]
drm/i915: write backlight harder
commit
cf0a6584aa6d382f802f2c3cacac23ccbccde0cd upstream.
770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit
commit
770c12312ad617172b1a65b911d3e6564fc5aca8
Author: Takashi Iwai <tiwai@suse.de>
Date: Sat Aug 11 08:56:42 2012 +0200
drm/i915: Fix blank panel at reopening lid
changed the register write sequence for restoring the backlight, which
helped prevent non-working backlights on some machines. Turns out that
the original sequence was the right thing to do for a different set of
machines. Worse, setting the backlight level _after_ enabling it seems
to reset it somehow. So we need to make that one conditional upon the
backlight having been reset to zero, and add the old one back.
Cargo-culting at it's best, but it seems to work.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Cc: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Widawsky [Sat, 2 Feb 2013 00:41:14 +0000 (16:41 -0800)]
drm/i915: Fix RC6VIDS encode/decode
commit
7083e05072b88d503d257b6f012ce56367f3ac97 upstream.
The RC6 VIDS has a linear ramp starting at 250mv, which means any values
below 250 are invalid. The old buggy macros tried to adjust for this to
be more flexible, but there is no need. As Dan pointed out the ENCODE
only ever has one value. The only invalid value for decode is an input
of 0 which means something is really wonky, and the cases where DECODE
are used either don't matter (debug values), or would be implicitly
correct (the check for less than 450).
This patch makes simpler, easier to read macros which are actually
correct. Maybe this patch can actually fix some bugs now.
Thanks to Dan for catching this. /me hides
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Widawsky [Tue, 29 Jan 2013 20:00:15 +0000 (12:00 -0800)]
drm/i915: Fix CAGF for HSW
commit
f82855d342b6c8483c56e6d2e200a71731509a39 upstream.
The shift changed, hurray.
Reported-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Tue, 8 Jan 2013 11:02:57 +0000 (11:02 +0000)]
drm/i915: Only run idle processing from i915_gem_retire_requests_worker
commit
725a5b54028916cd2511a251c5b5b13d1715addc upstream.
When adding the fb idle detection to mark-inactive, it was forgotten
that userspace can drive the processing of retire-requests. We assumed
that it would be principally driven by the retire requests worker,
running once every second whilst active and so we would get the deferred
timer for free. Instead we spend too many CPU cycles reclocking the LVDS
preventing real work from being done.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Alexander Lam <lambchop468@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58843
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Damien Lespiau [Tue, 11 Dec 2012 18:48:29 +0000 (18:48 +0000)]
drm/i915: Preserve the FDI line reversal override bit on CPT
commit
3e68320ef84528604d971afc3cadfbe208bef001 upstream.
The FDI link has supported link reversal to make the PCB layout
engineer's life easier for quite a while and we have always presered
this bit as we programmed FDI_RX_CTL with a read/modify/write sequence.
We're trying to take a bit more control over what the BIOS leaves in
various register and with the introduction of DDI, started to program
FDI_RX_CTL fully.
There's a fused bit to indicate DMI link reversal and FDI defaults to
mirroring that configuration. We have a bit to override that behaviour
that we need to preserve from the BIOS.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Damien Lespiau [Tue, 11 Dec 2012 18:48:30 +0000 (18:48 +0000)]
drm/i915: Preserve the DDI link reversal configuration
commit
876a8cdf92b23d268275cdce4397df0c37dac3fe upstream.
Similarly to:
commit
6a0d1df3d3a0d2370541164eb0595fe35dcd6de3
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Tue Dec 11 15:18:28 2012 +0000
drm/i915: Preserve the FDI line reversal override bit on CPT
DDI port support lane reversal to easy the PCB layouting work. Let's
preserve the bit configured by the BIOS (until we find how to correctly
retrieve the information from the VBT, but this does sound more fragile
then just relying on the BIOS that has, hopefully, been validated
already.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sat, 23 Feb 2013 03:45:42 +0000 (22:45 -0500)]
get rid of unprotected dereferencing of mnt->mnt_ns
commit
9b40bc90abd126bcc5da5658059b8e72e285e559 upstream.
It's safe only under namespace_sem or vfsmount_lock; all places
in fs/namespace.c that want mnt->mnt_ns->user_ns actually want to use
current->nsproxy->mnt_ns->user_ns (note the calls of check_mnt() in
there).
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Mon, 21 Jan 2013 18:48:59 +0000 (19:48 +0100)]
intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
commit
210561ffd72d00eccf12c0131b8024d5436bae95 upstream.
We already have the quirk entry for the mobile platform, but also
reports on some desktop versions. So be paranoid and set it
everywhere.
References: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.html
Reported-and-tested-by: Mihai Moldovan <ionic@ionic.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: "Sankaran, Rajesh" <rajesh.sankaran@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Airlie [Thu, 7 Feb 2013 00:10:04 +0000 (10:10 +1000)]
drm/usb: bind driver to correct device
commit
9f23de52b64f7fb801fd76f3dd8651a0dc89187b upstream.
While looking at plymouth on udl I noticed that plymouth was trying
to use its fb plugin not its drm one, it was trying to drmOpen a driver called
usb not udl, noticed that we actually had out driver pointing at the wrong
device.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Wed, 13 Feb 2013 10:37:48 +0000 (20:37 +1000)]
Revert "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S"
commit
db3985e5ca8f50fc17606855ba394783d11683a5 upstream.
This reverts commit
6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b.
The quirk cause a regression, and it looks like the original bug was
simply a lack of FIFO bandwidth on the i915G of the reporter. Which
should eventually be fixed as soon as we get around to implemented
DSPARB FIFO reassignment on gen 3.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Thu, 31 Jan 2013 17:43:38 +0000 (19:43 +0200)]
drm: Use C8 instead of RGB332 when determining the format from depth/bpp
commit
d84f031bd230fdf9c3b7734940c859bf28b90219 upstream.
Support for real RGB332 is a rarity, most hardware only really support
C8. So use C8 instead of RGB332 when determining the format based on
depth/bpp.
This fixes 8bpp fbcon on i915, since i915 will only accept C8 and not
RGB332.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59572
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Tested-by: mlsemon35@gmail.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Thu, 31 Jan 2013 17:43:37 +0000 (19:43 +0200)]
drm: Fill depth/bits_per_pixel for C8 format
commit
c51a6bc5f6d328926a9a4a1247c5030faf190a80 upstream.
Set depth/bits_per_pixel to 8 for C8 format.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maarten Lankhorst [Tue, 29 Jan 2013 13:27:39 +0000 (14:27 +0100)]
drm: shut up invalid edid messages
commit
f934ec8c34b9dcefb5a4f35b0bda33bca289cbe6 upstream.
My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam every few seconds.
I get it the first time that the entire block is all 0xff..
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paulo Zanoni [Fri, 15 Feb 2013 15:36:27 +0000 (13:36 -0200)]
drm: don't add inferred modes for monitors that don't support them
commit
196e077dc165a307efbd9e7569f81bbdbcf18f65 upstream.
If bit 0 of the features byte (0x18) is set to 0, then, according to
the EDID spec, "the display is non-continuous frequency (multi-mode)
and is only specified to accept the video timing formats that are
listed in Base EDID and certain Extension Blocks".
For more information, please see the EDID spec, check the notes of the
table that explains the "Feature Support" byte (18h) and also the
notes on the tables of the section that explains "Display Range Limits
& Additional Timing Description Definition (tag #FDh)".
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Williamson [Thu, 14 Feb 2013 18:35:42 +0000 (11:35 -0700)]
PCI: Fix PCI Express Capability accessors for PCI_EXP_FLAGS
commit
969daa349f4821a02936af7202b51a9affc7b6da upstream.
PCI_EXP_FLAGS_TYPE is a mask, not an offset. Fix it.
Previously, pcie_capability_read_word(..., PCI_EXP_FLAGS, ...) would
fail.
[bhelgaas: tweak changelog]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Airlie [Thu, 24 Jan 2013 04:14:19 +0000 (14:14 +1000)]
vgacon/vt: clear buffer attributes when we load a 512 character font (v2)
commit
2a2483072393b27f4336ab068a1f48ca19ff1c1e upstream.
When we switch from 256->512 byte font rendering mode, it means the
current contents of the screen is being reinterpreted. The bit that holds
the high bit of the 9-bit font, may have been previously set, and thus
the new font misrenders.
The problem case we see is grub2 writes spaces with the bit set, so it
ends up with data like 0x820, which gets reinterpreted into 0x120 char
which the font translates into G with a circumflex. This flashes up on
screen at boot and is quite ugly.
A current side effect of this patch though is that any rendering on the
screen changes color to a slightly darker color, but at least the screen
no longer corrupts.
v2: as suggested by hpa, always clear the attribute space, whether we
are are going to or from 512 chars.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Airlie [Thu, 7 Feb 2013 02:30:25 +0000 (12:30 +1000)]
drm/udl: disable fb_defio by default
commit
677d23b70bf949f75746c80cbae92c233c6b5e2a upstream.
There seems to be a bad interaction between gem/shmem and defio on top,
I get list corruption on the page lru in the shmem code.
Turn it off for now until we get some more digging done.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Airlie [Thu, 7 Feb 2013 01:19:15 +0000 (11:19 +1000)]
drm/udl: make usage as a console safer
commit
bcb39af4486be07e896fc374a2336bad3104ae0a upstream.
Okay you don't really want to use udl devices as your console, but if
you are unlucky enough to do so, you run into a lot of schedule while atomic
due to printk being called from all sorts of funky places. So check if we
are in an atomic context, and queue the damage for later, the next printk
should cause it to appear. This isn't ideal, but it is simple, and seems to
work okay in my testing here.
(dirty area idea came from xenfb)
fixes a bunch of sleeping while atomic issues running fbcon on udl devices.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 19 Feb 2013 17:55:52 +0000 (12:55 -0500)]
drm/radeon: properly validate the atpx interface
commit
43a23aa450cc19fe8996caf09e7e21ae5f6e56e8 upstream.
Some bioses don't set the function mask correctly
which caused required functions to be disabled.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=53111
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 12 Feb 2013 13:39:10 +0000 (08:39 -0500)]
drm/radeon: remove overzealous warning in hdmi handling
commit
c944b2abb067130542055666f23409fd5e1afc8e upstream.
hdmi audio works fine. The warning just confuses users.
fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 11 Feb 2013 13:44:48 +0000 (08:44 -0500)]
drm/radeon: fix multi-head power profile stability on BTC+ asics
commit
7ae764b11ed63279e9dcf25be972ff4ca21a9875 upstream.
vddci needs to track mclk for multi-head.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 5 Feb 2013 16:47:09 +0000 (11:47 -0500)]
drm/radeon/dce6: fix display powergating
commit
0e3d50bfcbd338254795a700dcff429a96cba1a6 upstream.
Only enable it when we disable the display rather than
at DPMS time since enabling it requires a full modeset
to restore the display state. Fixes blank screens in
certain cases.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Wed, 20 Feb 2013 20:38:40 +0000 (12:38 -0800)]
sparc64: Fix huge PMD to PTE translation for sun4u in TLB miss handler.
[ Upstream commit
76968ad2eac6456270353de168b21f04f4b3d1d3 ]
When we set the sun4u version of the PTE execute bit, it's:
or REG, _PAGE_EXEC_4U, REG
_PAGE_EXEC_4U is 0x1000, unfortunately the immedate field of the
'or' instruction is a signed 13-bit value. So the above actually
assembles into:
or REG, -4096, REG
completely corrupting the final PTE value.
Set it with a:
sethi %hi(_PAGE_EXEC_4U), TMP
or REG, TMP, REG
sequence instead.
This fixes "git gc" crashes on sun4u machines.
Reported-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Wed, 20 Feb 2013 06:34:10 +0000 (22:34 -0800)]
sparc64: Fix tsb_grow() in atomic context.
[ Upstream commit
0fbebed682ff2788dee58e8d7f7dda46e33aa10b ]
If our first THP installation for an MM is via the set_pmd_at() done
during khugepaged's collapsing we'll end up in tsb_grow() trying to do
a GFP_KERNEL allocation with several locks held.
Simply using GFP_ATOMIC in this situation is not the best option
because we really can't have this fail, so we'd really like to keep
this an order 0 GFP_KERNEL allocation if possible.
Also, doing the TSB allocation from khugepaged is a really bad idea
because we'll allocate it potentially from the wrong NUMA node in that
context.
So what we do is defer the hugepage TSB allocation until the first TLB
miss we take on a hugepage. This is slightly tricky because we have
to handle two unusual cases:
1) Taking the first hugepage TLB miss in the window trap handler.
We'll call the winfix_trampoline when that is detected.
2) An initial TSB allocation via TLB miss races with a hugetlb
fault on another cpu running the same MM. We handle this by
unconditionally loading the TSB we see into the current cpu
even if it's non-NULL at hugetlb_setup time.
Reported-by: Meelis Roos <mroos@ut.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Tue, 19 Feb 2013 21:20:08 +0000 (13:20 -0800)]
sparc64: Handle hugepage TSB being NULL.
[ Upstream commit
bcd896bae0166b4443503482a26ecf84d9ba60ab ]
Accomodate the possibility that the TSB might be NULL at
the point that update_mmu_cache() is invoked. This is
necessary because we will sometimes need to defer the TSB
allocation to the first fault that happens in the 'mm'.
Seperate out the hugepage PTE test into a seperate function
so that the logic is clearer.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Tue, 19 Feb 2013 20:56:18 +0000 (12:56 -0800)]
sparc64: Fix gfp_flags setting in tsb_grow().
[ Upstream commit
a55ee1ff751f88252207160087d8197bb7538d4c ]
We should "|= more_flags" rather than "= more_flags".
Reported-by: David Rientjes <rientjes@google.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bob Peterson [Fri, 1 Feb 2013 17:03:02 +0000 (12:03 -0500)]
GFS2: Get a block reservation before resizing a file
commit
d2b47cfb26fe06002b8011707baac71a9ae8166f upstream.
This patch allocates a block reservation structure before growing
or shrinking a file. Without this structure, the grow or shink code
can reference the bad pointer.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Henningsson [Tue, 19 Feb 2013 15:11:22 +0000 (16:11 +0100)]
ALSA: hda - hdmi: ELD shouldn't be valid after unplug
commit
bbfd8a19b6913f50a362457c34d49bfafe5e456e upstream.
Currently, eld_valid is never set to false, except at kernel module
load time. This patch makes sure that eld is no longer valid when
the cable is (hot-)unplugged.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 12 Feb 2013 16:02:41 +0000 (17:02 +0100)]
ALSA: hda - Fix broken workaround for HDMI/SPDIF conflicts
commit
ea9b43addc4d90ca5b029f47f85ca152320a1e8d upstream.
The commit [
dcda58061: ALSA: hda - Add workaround for conflicting
IEC958 controls] introduced a workaround for cards that have both
SPDIF and HDMI devices for giving device=1 to SPDIF control elements.
It turned out, however, that this workaround doesn't work well -
- The workaround checks only conflicts in a single codec, but SPDIF
and HDMI are provided by multiple codecs in many cases, and
- ALSA mixer abstraction doesn't care about the device number in ctl
elements, thus you'll get errors from amixer such as
% amixer scontrols -c 0
ALSA lib simple_none.c:1551:(simple_add1) helem (MIXER,'IEC958
Playback Switch',0,1,0) appears twice or more
amixer: Mixer hw:0 load error: Invalid argument
This patch fixes the previous broken workaround. Instead of changing
the device number of SPDIF ctl elements, shift the element indices of
such controls up to 16. Also, the conflict check is performed over
all codecs found on the bus.
HDMI devices will be put to dev=0,index=0 as before. Only the
conflicting SPDIF device is moved to a different place. The new place
of SPDIF device is supposed by the updated alsa-lib HDA-Intel.conf,
respectively.
Reported-by: Stephan Raue <stephan@openelec.tv>
Reported-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fernando Luis Vazquez Cao [Tue, 12 Feb 2013 07:47:44 +0000 (16:47 +0900)]
ALSA: hda - Workaround for silent output on Sony Vaio VGC-LN51JGB with ALC889
commit
12e31a78c70dc12897fda2489113f445c0e94a18 upstream.
Some Vaio all-in-one desktop PCs (for example VGC-LN51JGB) are affected by
the same issue that caused Vaio Z laptops to become silent: the speaker pin
must be connected to the first DAC even though the codec itself advertises
flexible routing through any of the DACs.
Use the no-primary-hp fixup for choosing the speaker pin as the primary so
that the right DAC is assigned on this device.
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anssi Hannula [Sun, 3 Feb 2013 15:55:45 +0000 (17:55 +0200)]
ALSA: hda - Fix default multichannel HDMI mapping regression
commit
20608731f479d48be6bcb88e727f360ddf98ddaf upstream.
Commit
d45e6889ee69456a4d5b1bbb32252f460cd48fa9 ("ALSA: hda - Provide
the proper channel mapping for generic HDMI driver") added support for
custom channel maps in the HDA HDMI driver. Due to a mistake in an
'if' condition the custom map is always used even when no such map has
been set. This causes incorrect channel mapping for multichannel audio
by default.
Pass per_pin->chmap_set to hdmi_setup_channel_mapping() as a parameter
so that it can use it for detecting if a custom map has been set instead
of checking if map is NULL (which is never the case).
Reported-by: Staffan Lindberg <pike@xbmc.org>
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Fri, 1 Feb 2013 13:01:27 +0000 (14:01 +0100)]
ALSA: hda - Release assigned pin/cvt at error path of hdmi_pcm_open()
commit
2ad779b7329d6894a80df94e693e72eaa0d56790 upstream.
If the driver detects and invalid ELD, it gives an open error.
But it forgot to release the assigned pin, converter and spdif ctls
before returning.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Thu, 14 Feb 2013 08:44:55 +0000 (09:44 +0100)]
ALSA: hda - Disable runtime PM for Intel 5 Series/3400
commit
2c1350fdeaefefe1a149d3b083383409f43f0daa upstream.
We've got a regression report wrt the IRQ issue related with the
power-save on a Dell machine, and disabling runtime PM works around.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53441
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pawel Moll [Thu, 21 Feb 2013 01:55:50 +0000 (01:55 +0000)]
ALSA: usb: Fix Processing Unit Descriptor parsers
commit
b531f81b0d70ffbe8d70500512483227cc532608 upstream.
Commit
99fc86450c439039d2ef88d06b222fd51a779176 "ALSA: usb-mixer:
parse descriptors with structs" introduced a set of useful parsers
for descriptors. Unfortunately the parses for the Processing Unit
Descriptor came with a very subtle bug...
Functions uac_processing_unit_iProcessing() and
uac_processing_unit_specific() were indexing the baSourceID array
forgetting the fields before the iProcessing and process-specific
descriptors.
The problem was observed with Sound Blaster Extigy mixer,
where nNrModes in Up/Down-mix Processing Unit Descriptor
was accessed at offset 10 of the descriptor (value 0)
instead of offset 15 (value 7). In result the resulting
control had interesting limit values:
Simple mixer control 'Channel Routing Mode Select',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - -1
Mono: -1 [100%]
Fixed by starting from the bmControls, which was calculated
correctly, instead of baSourceID.
Now the mentioned control is fine:
Simple mixer control 'Channel Routing Mode Select',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 6
Mono: 0 [0%]
Signed-off-by: Pawel Moll <mail@pawelmoll.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Slaby [Sun, 17 Feb 2013 13:33:04 +0000 (14:33 +0100)]
ALSA: usb/quirks, fix out-of-bounds access
commit
4909a0caabb8b4352efcea223e58b86f8bc1f98b upstream.
bootresponse in snd_usb_mbox2_boot_quirk is only 12 (decimal) u8's
long, but i9s passed to snd_usb_ctl_msg as it would be 0x12 (hexa)
long. Fix that by having proper size of the array, i.e. 0x12.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clemens Ladisch [Thu, 31 Jan 2013 20:14:33 +0000 (21:14 +0100)]
ALSA: usb-audio: fix Roland A-PRO support
commit
7da58046482fceb17c4a0d4afefd9507ec56de7f upstream.
The quirk for the Roland/Cakewalk A-PRO keyboards accidentally used the
wrong interface number, which prevented the driver from attaching to the
device.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomasz Guszkowski [Tue, 5 Feb 2013 21:10:31 +0000 (22:10 +0100)]
p54usb: corrected USB ID for T-Com Sinus 154 data II
commit
008e33f733ca51acb2dd9d88ea878693b04d1d2a upstream.
Corrected USB ID for T-Com Sinus 154 data II. ISL3887-based. The
device was tested in managed mode with no security, WEP 128
bit and WPA-PSK (TKIP) with firmware 2.13.1.0.lm87.arm (md5sum:
7d676323ac60d6e1a3b6d61e8c528248). It works.
Signed-off-by: Tomasz Guszkowski <tsg@o2.pl>
Acked-By: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Weston Andros Adamson [Fri, 15 Feb 2013 21:03:46 +0000 (16:03 -0500)]
NFSv4.1: Don't decode skipped layoutgets
commit
085b7a45c63d3da5be155faab9249a5cab224561 upstream.
layoutget's prepare hook can call rpc_exit with status = NFS4_OK (0).
Because of this, nfs4_proc_layoutget can't depend on a 0 status to mean
that the RPC was successfully sent, received and parsed.
To fix this, use the result's len member to see if parsing took place.
This fixes the following OOPS -- calling xdr_init_decode() with a buffer length
0 doesn't set the stream's 'p' member and ends up using uninitialized memory
in filelayout_decode_layout.
BUG: unable to handle kernel paging request at
0000000000008050
IP: [<
ffffffff81282e78>] memcpy+0x18/0x120
PGD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:11.0/0000:02:01.0/irq
CPU 1
Modules linked in: nfs_layout_nfsv41_files nfs lockd fscache auth_rpcgss nfs_acl autofs4 sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log dm_mod ppdev parport_pc parport snd_ens1371 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc e1000 microcode vmware_balloon i2c_piix4 i2c_core sg shpchp ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix mptspi mptscsih mptbase scsi_transport_spi [last unloaded: speedstep_lib]
Pid: 1665, comm: flush-0:22 Not tainted 2.6.32-356-test-2 #2 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
RIP: 0010:[<
ffffffff81282e78>] [<
ffffffff81282e78>] memcpy+0x18/0x120
RSP: 0018:
ffff88003dfab588 EFLAGS:
00010206
RAX:
ffff88003dc42000 RBX:
ffff88003dfab610 RCX:
0000000000000009
RDX:
000000003f807ff0 RSI:
0000000000008050 RDI:
ffff88003dc42000
RBP:
ffff88003dfab5b0 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000080 R12:
0000000000000024
R13:
ffff88003dc42000 R14:
ffff88003f808030 R15:
ffff88003dfab6a0
FS:
0000000000000000(0000) GS:
ffff880003420000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
CR2:
0000000000008050 CR3:
000000003bc92000 CR4:
00000000001407e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process flush-0:22 (pid: 1665, threadinfo
ffff88003dfaa000, task
ffff880037f77540)
Stack:
ffffffffa0398ac1 ffff8800397c5940 ffff88003dfab610 ffff88003dfab6a0
<d>
ffff88003dfab5d0 ffff88003dfab680 ffffffffa01c150b ffffea0000d82e70
<d>
000000508116713b 0000000000000000 0000000000000000 0000000000000000
Call Trace:
[<
ffffffffa0398ac1>] ? xdr_inline_decode+0xb1/0x120 [sunrpc]
[<
ffffffffa01c150b>] filelayout_decode_layout+0xeb/0x350 [nfs_layout_nfsv41_files]
[<
ffffffffa01c17fc>] filelayout_alloc_lseg+0x8c/0x3c0 [nfs_layout_nfsv41_files]
[<
ffffffff8150e6ce>] ? __wait_on_bit+0x7e/0x90
Signed-off-by: Weston Andros Adamson <dros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Tue, 12 Feb 2013 14:48:42 +0000 (09:48 -0500)]
NFSv4.1: Fix bulk recall and destroy of layouts
commit
fd9a8d7160937f94aad36ac80d7255b4988740ac upstream.
The current code in pnfs_destroy_all_layouts() assumes that removing
the layout from the server->layouts list is sufficient to make it
invisible to other processes. This ignores the fact that most
users access the layout through the nfs_inode->layout...
There is further breakage due to lack of reference counting of the
layouts, meaning that the whole thing Oopses at the drop of a hat.
The code in initiate_bulk_draining() is almost correct, and can be
used as a model for pnfs_destroy_all_layouts(), so move that
code to pnfs.c, and refactor the code to allow us to choose between
a single filesystem bulk recall, and a recall of all layouts.
Also note that initiate_bulk_draining() currently calls iput() while
holding locks. Fix that too.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Tue, 12 Feb 2013 00:01:21 +0000 (19:01 -0500)]
NFSv4.1: Fix an ABBA locking issue with session and state serialisation
commit
c8da19b9866ea84e9ad1c369393ea95d54ee7845 upstream.
Ensure that if nfs_wait_on_sequence() causes our rpc task to wait for
an NFSv4 state serialisation lock, then we also drop the session slot.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Tue, 19 Feb 2013 17:04:42 +0000 (12:04 -0500)]
NLM: Ensure that we resend all pending blocking locks after a reclaim
commit
666b3d803a511fbc9bc5e5ea8ce66010cf03ea13 upstream.
Currently, nlmclnt_lock will break out of the for(;;) loop when
the reclaimer wakes up the blocking lock thread by setting
nlm_lck_denied_grace_period. This causes the lock request to fail
with an ENOLCK error.
The intention was always to ensure that we resend the lock request
after the grace period has expired.
Reported-by: Wangyuan Zhang <Wangyuan.Zhang@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fanchaoting [Mon, 4 Feb 2013 13:15:02 +0000 (21:15 +0800)]
umount oops when remove blocklayoutdriver first
commit
5a12cca697aca5dfba42a7d4c3356acc0445a2b0 upstream.
now pnfs client uses block layout, maybe we can remove
blocklayoutdriver first. if we umount later,
it can cause oops in unset_pnfs_layoutdriver.
because nfss->pnfs_curr_ld->clear_layoutdriver is invalid.
reproduce it:
modprobe blocklayoutdriver
mount -t nfs4 -o minorversion=1 pnfsip:/ /mnt/
rmmod blocklayoutdriver
umount /mnt
then you can see following
CPU 0
Pid: 17023, comm: umount.nfs4 Tainted: GF O 3.7.0-rc6-pnfs #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
RIP: 0010:[<
ffffffffa04cfe6d>] [<
ffffffffa04cfe6d>] unset_pnfs_layoutdriver+0x1d/0x70 [nfsv4]
RSP: 0018:
ffff8800022d9e48 EFLAGS:
00010286
RAX:
ffffffffa04a1b00 RBX:
ffff88000b013800 RCX:
0000000000000001
RDX:
ffffffff81ae8ee0 RSI:
ffff880001ee94b8 RDI:
ffff88000b013800
RBP:
ffff8800022d9e58 R08:
0000000000000001 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000000 R12:
ffff880001ee9400
R13:
ffff8800105978c0 R14:
00007fff25846c08 R15:
0000000001bba550
FS:
00007f45ae7f0700(0000) GS:
ffff880012c00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
ffffffffa04a1b38 CR3:
0000000002c0c000 CR4:
00000000000006f0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process umount.nfs4 (pid: 17023, threadinfo
ffff8800022d8000, task
ffff880006e48aa0)
Stack:
ffff8800105978c0 ffff88000b013800 ffff8800022d9e78 ffffffffa04cd0ce
ffff8800022d9e78 ffff88000b013800 ffff8800022d9ea8 ffffffffa04755a7
ffff8800022d9ea8 ffff880002f96400 ffff88000b013800 ffff880002f96400
Call Trace:
[<
ffffffffa04cd0ce>] nfs4_destroy_server+0x1e/0x30 [nfsv4]
[<
ffffffffa04755a7>] nfs_free_server+0xb7/0x150 [nfs]
[<
ffffffffa047d4d5>] nfs_kill_super+0x35/0x40 [nfs]
[<
ffffffff81178d35>] deactivate_locked_super+0x45/0x70
[<
ffffffff8117986a>] deactivate_super+0x4a/0x70
[<
ffffffff81193ee2>] mntput_no_expire+0xd2/0x130
[<
ffffffff81194d62>] sys_umount+0x72/0xe0
[<
ffffffff8154af59>] system_call_fastpath+0x16/0x1b
Code: 06 e1 b8 ea ff ff ff eb 9e 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 8b 87 80 03 00 00 48 89 fb 48 85 c0 74 29 <48> 8b 40 38 48 85 c0 74 02 ff d0 48 8b 03 3e ff 48 04 0f 94 c2
RIP [<
ffffffffa04cfe6d>] unset_pnfs_layoutdriver+0x1d/0x70 [nfsv4]
RSP <
ffff8800022d9e48>
CR2:
ffffffffa04a1b38
---[ end trace
29f75aaedda058bf ]---
Signed-off-by: fanchaoting<fanchaoting@cn.fujitsu.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Grant Likely [Thu, 14 Feb 2013 18:14:27 +0000 (18:14 +0000)]
drivercore: Fix ordering between deferred_probe and exiting initcalls
commit
d72cca1eee5b26e313da2a380d4862924e271031 upstream.
One of the side effects of deferred probe is that some drivers which
used to be probed before initcalls completed are now happening slightly
later. This causes two problems.
- If a console driver gets deferred, then it may not be ready when
userspace starts. For example, if a uart depends on pinctrl, then the
uart will get deferred and /dev/console will not be available
- __init sections will be discarded before built-in drivers are probed.
Strictly speaking, __init functions should not be called in a drivers
__probe path, but there are a lot of drivers (console stuff again)
that do anyway. In the past it was perfectly safe to do so because all
built-in drivers got probed before the end of initcalls.
This patch fixes the problem by forcing the first pass of the deferred
list to complete at late_initcall time. This is late enough to catch the
drivers that are known to have the above issues.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Sat, 23 Feb 2013 00:35:59 +0000 (16:35 -0800)]
mm/fadvise.c: drain all pagevecs if POSIX_FADV_DONTNEED fails to discard all pages
commit
67d46b296a1ba1477c0df8ff3bc5e0167a0b0732 upstream.
Rob van der Heij reported the following (paraphrased) on private mail.
The scenario is that I want to avoid backups to fill up the page
cache and purge stuff that is more likely to be used again (this is
with s390x Linux on z/VM, so I don't give it as much memory that
we don't care anymore). So I have something with LD_PRELOAD that
intercepts the close() call (from tar, in this case) and issues
a posix_fadvise() just before closing the file.
This mostly works, except for small files (less than 14 pages)
that remains in page cache after the face.
Unfortunately Rob has not had a chance to test this exact patch but the
test program below should be reproducing the problem he described.
The issue is the per-cpu pagevecs for LRU additions. If the pages are
added by one CPU but fadvise() is called on another then the pages
remain resident as the invalidate_mapping_pages() only drains the local
pagevecs via its call to pagevec_release(). The user-visible effect is
that a program that uses fadvise() properly is not obeyed.
A possible fix for this is to put the necessary smarts into
invalidate_mapping_pages() to globally drain the LRU pagevecs if a
pagevec page could not be discarded. The downside with this is that an
inode cache shrink would send a global IPI and memory pressure
potentially causing global IPI storms is very undesirable.
Instead, this patch adds a check during fadvise(POSIX_FADV_DONTNEED) to
check if invalidate_mapping_pages() discarded all the requested pages.
If a subset of pages are discarded it drains the LRU pagevecs and tries
again. If the second attempt fails, it assumes it is due to the pages
being mapped, locked or dirty and does not care. With this patch, an
application using fadvise() correctly will be obeyed but there is a
downside that a malicious application can force the kernel to send
global IPIs and increase overhead.
If accepted, I would like this to be considered as a -stable candidate.
It's not an urgent issue but it's a system call that is not working as
advertised which is weak.
The following test program demonstrates the problem. It should never
report that pages are still resident but will without this patch. It
assumes that CPU 0 and 1 exist.
int main() {
int fd;
int pagesize = getpagesize();
ssize_t written = 0, expected;
char *buf;
unsigned char *vec;
int resident, i;
cpu_set_t set;
/* Prepare a buffer for writing */
expected = FILESIZE_PAGES * pagesize;
buf = malloc(expected + 1);
if (buf == NULL) {
printf("ENOMEM\n");
exit(EXIT_FAILURE);
}
buf[expected] = 0;
memset(buf, 'a', expected);
/* Prepare the mincore vec */
vec = malloc(FILESIZE_PAGES);
if (vec == NULL) {
printf("ENOMEM\n");
exit(EXIT_FAILURE);
}
/* Bind ourselves to CPU 0 */
CPU_ZERO(&set);
CPU_SET(0, &set);
if (sched_setaffinity(getpid(), sizeof(set), &set) == -1) {
perror("sched_setaffinity");
exit(EXIT_FAILURE);
}
/* open file, unlink and write buffer */
fd = open("fadvise-test-file", O_CREAT|O_EXCL|O_RDWR);
if (fd == -1) {
perror("open");
exit(EXIT_FAILURE);
}
unlink("fadvise-test-file");
while (written < expected) {
ssize_t this_write;
this_write = write(fd, buf + written, expected - written);
if (this_write == -1) {
perror("write");
exit(EXIT_FAILURE);
}
written += this_write;
}
free(buf);
/*
* Force ourselves to another CPU. If fadvise only flushes the local
* CPUs pagevecs then the fadvise will fail to discard all file pages
*/
CPU_ZERO(&set);
CPU_SET(1, &set);
if (sched_setaffinity(getpid(), sizeof(set), &set) == -1) {
perror("sched_setaffinity");
exit(EXIT_FAILURE);
}
/* sync and fadvise to discard the page cache */
fsync(fd);
if (posix_fadvise(fd, 0, expected, POSIX_FADV_DONTNEED) == -1) {
perror("posix_fadvise");
exit(EXIT_FAILURE);
}
/* map the file and use mincore to see which parts of it are resident */
buf = mmap(NULL, expected, PROT_READ, MAP_SHARED, fd, 0);
if (buf == NULL) {
perror("mmap");
exit(EXIT_FAILURE);
}
if (mincore(buf, expected, vec) == -1) {
perror("mincore");
exit(EXIT_FAILURE);
}
/* Check residency */
for (i = 0, resident = 0; i < FILESIZE_PAGES; i++) {
if (vec[i])
resident++;
}
if (resident != 0) {
printf("Nr unexpected pages resident: %d\n", resident);
exit(EXIT_FAILURE);
}
munmap(buf, expected);
close(fd);
free(vec);
exit(EXIT_SUCCESS);
}
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reported-by: Rob van der Heij <rvdheij@gmail.com>
Tested-by: Rob van der Heij <rvdheij@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Thelen [Sat, 23 Feb 2013 00:36:01 +0000 (16:36 -0800)]
tmpfs: fix use-after-free of mempolicy object
commit
5f00110f7273f9ff04ac69a5f85bb535a4fd0987 upstream.
The tmpfs remount logic preserves filesystem mempolicy if the mpol=M
option is not specified in the remount request. A new policy can be
specified if mpol=M is given.
Before this patch remounting an mpol bound tmpfs without specifying
mpol= mount option in the remount request would set the filesystem's
mempolicy object to a freed mempolicy object.
To reproduce the problem boot a DEBUG_PAGEALLOC kernel and run:
# mkdir /tmp/x
# mount -t tmpfs -o size=100M,mpol=interleave nodev /tmp/x
# grep /tmp/x /proc/mounts
nodev /tmp/x tmpfs rw,relatime,size=102400k,mpol=interleave:0-3 0 0
# mount -o remount,size=200M nodev /tmp/x
# grep /tmp/x /proc/mounts
nodev /tmp/x tmpfs rw,relatime,size=204800k,mpol=??? 0 0
# note ? garbage in mpol=... output above
# dd if=/dev/zero of=/tmp/x/f count=1
# panic here
Panic:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
[...]
Oops: 0010 [#1] SMP DEBUG_PAGEALLOC
Call Trace:
mpol_shared_policy_init+0xa5/0x160
shmem_get_inode+0x209/0x270
shmem_mknod+0x3e/0xf0
shmem_create+0x18/0x20
vfs_create+0xb5/0x130
do_last+0x9a1/0xea0
path_openat+0xb3/0x4d0
do_filp_open+0x42/0xa0
do_sys_open+0xfe/0x1e0
compat_sys_open+0x1b/0x20
cstar_dispatch+0x7/0x1f
Non-debug kernels will not crash immediately because referencing the
dangling mpol will not cause a fault. Instead the filesystem will
reference a freed mempolicy object, which will cause unpredictable
behavior.
The problem boils down to a dropped mpol reference below if
shmem_parse_options() does not allocate a new mpol:
config = *sbinfo
shmem_parse_options(data, &config, true)
mpol_put(sbinfo->mpol)
sbinfo->mpol = config.mpol /* BUG: saves unreferenced mpol */
This patch avoids the crash by not releasing the mempolicy if
shmem_parse_options() doesn't create a new mpol.
How far back does this issue go? I see it in both 2.6.36 and 3.3. I did
not look back further.
Signed-off-by: Greg Thelen <gthelen@google.com>
Acked-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Howells [Thu, 21 Feb 2013 12:00:25 +0000 (12:00 +0000)]
KEYS: Revert one application of "Fix unreachable code" patch
commit
fe9453a1dcb5fb146f9653267e78f4a558066f6f upstream.
A patch to fix some unreachable code in search_my_process_keyrings() got
applied twice by two different routes upstream as commits
e67eab39bee2
and
b010520ab3d2 (both "fix unreachable code").
Unfortunately, the second application removed something it shouldn't
have and this wasn't detected by GIT. This is due to the patch not
having sufficient lines of context to distinguish the two places of
application.
The effect of this is relatively minor: inside the kernel, the keyring
search routines may search multiple keyrings and then prioritise the
errors if no keys or negative keys are found in any of them. With the
extra deletion, the presence of a negative key in the thread keyring
(causing ENOKEY) is incorrectly overridden by an error searching the
process keyring.
So revert the second application of the patch.
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lars-Peter Clausen [Fri, 22 Feb 2013 00:44:04 +0000 (16:44 -0800)]
drivers/video/backlight/adp88?0_bl.c: fix resume
commit
5eb02c01bd1f3ef195989ab05e835e2b0711b5a9 upstream.
Clearing the NSTBY bit in the control register also automatically clears
the BLEN bit. So we need to make sure to set it again during resume,
otherwise the backlight will stay off.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Junxiao Bi [Fri, 22 Feb 2013 00:42:45 +0000 (16:42 -0800)]
ocfs2: unlock super lock if lockres refresh failed
commit
3278bb748d2437eb1464765f36429e5d6aa91c38 upstream.
If lockres refresh failed, the super lock will never be released which
will cause some processes on other cluster nodes hung forever.
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Mark Fasheh <mfasheh@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MITSUNARI Shigeo [Fri, 22 Feb 2013 00:42:01 +0000 (16:42 -0800)]
fs/block_dev.c: page cache wrongly left invalidated after revalidate_disk()
commit
7630b661da330b35dd57b6f5d6d62b386f2dd751 upstream.
We found that bdev->bd_invalidated was left set once revalidate_disk()
is called, which results in page cache flush every time that device is
open.
Specifically, we found this problem in MD block device. Once we resize
a MD device, mdadm --monitor periodically flush all page cache for that
device every 60 or 1000 seconds when it opens the device.
This bug lies since at least 3.2.0 till the latest kernel(3.6.2). Patch
is attached.
The following steps will reproduce the problem.
1. prepair a block device (eg /dev/sdb).
2. create two partitions:
sudo parted /dev/sdb
mklabel gpt
mkpart primary 0% 50%
mkpart primary 50% 100%
3. create a md device.
sudo mdadm -C /dev/md/hoge -l 1 -n 2 -e 1.2 --assume-clean --auto=md --symlink=no /dev/sdb1 /dev/sdb2
4. create file system and mount it
sudo mkfs.ext3 /dev/md/hoge
sudo mkdir /mnt/test
sudo mount /dev/md/hoge /mnt/test
5. try to resize the device
sudo mdadm -G /dev/md/hoge --size=max
6. create a file to fill file cache.
sudo dd if=/dev/urandom of=/mnt/test/data bs=1M count=10
and verify the current status of file by free command.
7. mdadm monitor will open the md device every 1000 seconds and you
will find all file cache on the device are cleared.
The timing can be reduced by the following steps.
a) kill mdadm and restart it with --delay option
/sbin/mdadm --monitor --delay=30 --pid-file /var/run/mdadm/monitor.pid --daemonise --scan --syslog
or open the md device directly.
sudo dd if=/dev/md/hoge of=/dev/null bs=4096 count=1
Signed-off-by: MITSUNARI Shigeo <herumi@nifty.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jim Somerville [Fri, 22 Feb 2013 00:41:59 +0000 (16:41 -0800)]
inotify: remove broken mask checks causing unmount to be EINVAL
commit
676a0675cf9200ac047fb50825f80867b3bb733b upstream.
Running the command:
inotifywait -e unmount /mnt/disk
immediately aborts with a -EINVAL return code. This is however a valid
parameter. This abort occurs only if unmount is the sole event
parameter. If other event parameters are supplied, then the unmount
event wait will work.
The problem was introduced by commit
44b350fc23e ("inotify: Fix mask
checks"). In that commit, it states:
The mask checks in inotify_update_existing_watch() and
inotify_new_watch() are useless because inotify_arg_to_mask()
sets FS_IN_IGNORED and FS_EVENT_ON_CHILD bits anyway.
But instead of removing the useless checks, it did this:
mask = inotify_arg_to_mask(arg);
- if (unlikely(!mask))
+ if (unlikely(!(mask & IN_ALL_EVENTS)))
return -EINVAL;
The problem is that IN_ALL_EVENTS doesn't include IN_UNMOUNT, and other
parts of the code keep IN_UNMOUNT separate from IN_ALL_EVENTS. So the
check should be:
if (unlikely(!(mask & (IN_ALL_EVENTS | IN_UNMOUNT))))
But inotify_arg_to_mask(arg) always sets the IN_UNMOUNT bit in the mask
anyway, so the check is always going to pass and thus should simply be
removed. Also note that inotify_arg_to_mask completely controls what
mask bits get set from arg, there's no way for invalid bits to get
enabled there.
Lets fix it by simply removing the useless broken checks.
Signed-off-by: Jim Somerville <Jim.Somerville@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: John McCutchan <john@johnmccutchan.com>
Cc: Robert Love <rlove@rlove.org>
Cc: Eric Paris <eparis@parisplace.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Mon, 18 Feb 2013 08:52:08 +0000 (09:52 +0100)]
futex: Revert "futex: Mark get_robust_list as deprecated"
commit
fe2b05f7ca9f906be61dced5489f63b8b4d7c770 upstream.
This reverts commit
ec0c4274e33c0373e476b73e01995c53128f1257.
get_robust_list() is in use and a removal would break existing user
space. With the permission checks in place it's not longer a security
hole. Remove the deprecation warnings.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: akpm@linux-foundation.org
Cc: paul.gortmaker@windriver.com
Cc: davej@redhat.com
Cc: keescook@chromium.org
Cc: ebiederm@xmission.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian Borntraeger [Fri, 25 Jan 2013 14:34:15 +0000 (15:34 +0100)]
s390/kvm: Fix store status for ACRS/FPRS
commit
15bc8d8457875f495c59d933b05770ba88d1eacb upstream.
On store status we need to copy the current state of registers
into a save area. Currently we might save stale versions:
The sie state descriptor doesnt have fields for guest ACRS,FPRS,
those registers are simply stored in the host registers. The host
program must copy these away if needed. We do that in vcpu_put/load.
If we now do a store status in KVM code between vcpu_put/load, the
saved values are not up-to-date. Lets collect the ACRS/FPRS before
saving them.
This also fixes some strange problems with hotplug and virtio-ccw,
since the low level machine check handler (on hotplug a machine check
will happen) will revalidate all registers with the content of the
save area.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cornelia Huck [Fri, 14 Dec 2012 16:02:16 +0000 (17:02 +0100)]
KVM: s390: Handle hosts not supporting s390-virtio.
commit
55c171a6d90dc0574021f9c836127cfd1a7d2e30 upstream.
Running under a kvm host does not necessarily imply the presence of
a page mapped above the main memory with the virtio information;
however, the code includes a hard coded access to that page.
Instead, check for the presence of the page and exit gracefully
before we hit an addressing exception if it does not exist.
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robin Holt [Sat, 23 Feb 2013 00:35:34 +0000 (16:35 -0800)]
mmu_notifier_unregister NULL Pointer deref and multiple ->release() callouts
commit
751efd8610d3d7d67b7bdf7f62646edea7365dd7 upstream.
There is a race condition between mmu_notifier_unregister() and
__mmu_notifier_release().
Assume two tasks, one calling mmu_notifier_unregister() as a result of a
filp_close() ->flush() callout (task A), and the other calling
mmu_notifier_release() from an mmput() (task B).
A B
t1 srcu_read_lock()
t2 if (!hlist_unhashed())
t3 srcu_read_unlock()
t4 srcu_read_lock()
t5 hlist_del_init_rcu()
t6 synchronize_srcu()
t7 srcu_read_unlock()
t8 hlist_del_rcu() <--- NULL pointer deref.
Additionally, the list traversal in __mmu_notifier_release() is not
protected by the by the mmu_notifier_mm->hlist_lock which can result in
callouts to the ->release() notifier from both mmu_notifier_unregister()
and __mmu_notifier_release().
-stable suggestions:
The stable trees prior to 3.7.y need commits
21a92735f660 and
70400303ce0c cherry-picked in that order prior to cherry-picking this
commit. The 3.7.y tree already has those two commits.
Signed-off-by: Robin Holt <holt@sgi.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Sagi Grimberg <sagig@mellanox.co.il>
Cc: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Helgaas [Tue, 29 Jan 2013 23:44:27 +0000 (16:44 -0700)]
Driver core: treat unregistered bus_types as having no devices
commit
4fa3e78be7e985ca814ce2aa0c09cbee404efcf7 upstream.
A bus_type has a list of devices (klist_devices), but the list and the
subsys_private structure that contains it are not initialized until the
bus_type is registered with bus_register().
The panic/reboot path has fixups that look up devices in pci_bus_type. If
we panic before registering pci_bus_type, the bus_type exists but the list
does not, so mach_reboot_fixups() trips over a null pointer and panics
again:
mach_reboot_fixups
pci_get_device
..
bus_find_device(&pci_bus_type, ...)
bus->p is NULL
Joonsoo reported a problem when panicking before PCI was initialized.
I think this patch should be sufficient to replace the patch he posted
here: https://lkml.org/lkml/2012/12/28/75 ("[PATCH] x86, reboot: skip
reboot_fixups in early boot phase")
Reported-by: Joonsoo Kim <js1304@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Minchan Kim [Wed, 30 Jan 2013 02:41:39 +0000 (11:41 +0900)]
zram: Fix deadlock bug in partial read/write
commit
7e5a5104c6af709a8d97d5f4711e7c917761d464 upstream.
Now zram allocates new page with GFP_KERNEL in zram I/O path
if IO is partial. Unfortunately, It may cause deadlock with
reclaim path like below.
write_page from fs
fs_lock
allocation(GFP_KERNEL)
reclaim
pageout
write_page from fs
fs_lock <-- deadlock
This patch fixes it by using GFP_NOIO. In read path, we
reorganize code flow so that kmap_atomic is called after the
GFP_NOIO allocation.
Acked-by: Jerome Marchand <jmarchand@redhat.com>
Acked-by: Nitin Gupta <ngupta@vflare.org>
[ penberg@kernel.org: don't use GFP_ATOMIC ]
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
George Spelvin [Tue, 12 Feb 2013 07:27:20 +0000 (02:27 -0500)]
pps: Fix a use-after free bug when unregistering a source.
commit
d953e0e837e65ecc1ddaa4f9560f7925878a0de6 upstream.
Remove the cdev from the system (with cdev_del) *before* deallocating it
(in pps_device_destruct, called via kobject_put from device_destroy).
Also prevent deallocating a device with open file handles.
A better long-term fix is probably to remove the cdev from the pps_device
entirely, and instead have all devices reference one global cdev. Then
the deallocation ordering becomes simpler.
But that's more complex and invasive change, so we leave that
for later.
Signed-off-by: George Spelvin <linux@horizon.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
George Spelvin [Sun, 10 Feb 2013 09:41:56 +0000 (04:41 -0500)]
pps: Use pps_lookup_dev to reduce ldisc coupling
commit
03a7ffe4e542310838bac70ef85acc17536b6d7c upstream.
Now that N_TTY uses tty->disc_data for its private data,
'subclass' ldiscs cannot use ->disc_data for their own private data.
(This is a regression is v3.8-rc1)
Use pps_lookup_dev to associate the tty with the pps source instead.
This fixes a crashing regression in 3.8-rc1.
Signed-off-by: George Spelvin <linux@horizon.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
George Spelvin [Sun, 10 Feb 2013 09:08:32 +0000 (04:08 -0500)]
pps: Add pps_lookup_dev() function
commit
513b032c98b4b9414aa4e9b4a315cb1bf0380101 upstream.
The PPS serial line discipline wants to attach a PPS device to a tty
without changing the tty code to add a struct pps_device * pointer.
Since the number of PPS devices in a typical system is generally very low
(n=1 is by far the most common), it's practical to search the entire list
of allocated pps devices. (We capture the timestamp before the lookup,
so the timing isn't affected.)
It is a bit ugly that this function, which is part of the in-kernel
PPS API, has to be in pps.c as opposed to kapi,c, but that's not
something that affects users.
Signed-off-by: George Spelvin <linux@horizon.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Liu [Mon, 18 Feb 2013 14:57:58 +0000 (14:57 +0000)]
xen: close evtchn port if binding to irq fails
commit
e7e44e444876478d50630f57b0c31d29f6725020 upstream.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Bader [Fri, 15 Feb 2013 08:48:52 +0000 (09:48 +0100)]
xen: Send spinlock IPI to all waiters
commit
76eaca031f0af2bb303e405986f637811956a422 upstream.
There is a loophole between Xen's current implementation of
pv-spinlocks and the scheduler. This was triggerable through
a testcase until v3.6 changed the TLB flushing code. The
problem potentially is still there just not observable in the
same way.
What could happen was (is):
1. CPU n tries to schedule task x away and goes into a slow
wait for the runq lock of CPU n-# (must be one with a lower
number).
2. CPU n-#, while processing softirqs, tries to balance domains
and goes into a slow wait for its own runq lock (for updating
some records). Since this is a spin_lock_irqsave in softirq
context, interrupts will be re-enabled for the duration of
the poll_irq hypercall used by Xen.
3. Before the runq lock of CPU n-# is unlocked, CPU n-1 receives
an interrupt (e.g. endio) and when processing the interrupt,
tries to wake up task x. But that is in schedule and still
on_cpu, so try_to_wake_up goes into a tight loop.
4. The runq lock of CPU n-# gets unlocked, but the message only
gets sent to the first waiter, which is CPU n-# and that is
busily stuck.
5. CPU n-# never returns from the nested interruption to take and
release the lock because the scheduler uses a busy wait.
And CPU n never finishes the task migration because the unlock
notification only went to CPU n-#.
To avoid this and since the unlocking code has no real sense of
which waiter is best suited to grab the lock, just send the IPI
to all of them. This causes the waiters to return from the hyper-
call (those not interrupted at least) and do active spinlocking.
BugLink: http://bugs.launchpad.net/bugs/1011792
Acked-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Pitre [Mon, 25 Feb 2013 01:06:09 +0000 (20:06 -0500)]
tty vt: fix character insertion overflow
commit
a883b70d8e0a88278c0a1f80753b4dc99962b541 upstream.
Commit
81732c3b2fed ("tty vt: Fix line garbage in virtual console on
command line edition") broke insert_char() in multiple ways. Then
commit
b1a925f44a3a ("tty vt: Fix a regression in command line edition")
partially fixed it. However, the buffer being moved is still too large
and overflowing beyond the end of the current line, corrupting existing
characters on the next line.
Example test case:
echo -e "abc\nde\x1b[A\x1b[4h \x1b[4l\x1b[B"
Expected result:
ab c
de
Current result:
ab c
e
Needless to say that this is very annoying when inserting words in the
middle of paragraphs with certain text editors.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jussi Kivilinna [Mon, 18 Feb 2013 08:29:30 +0000 (10:29 +0200)]
rtlwifi: usb: allocate URB control message setup_packet and data buffer separately
commit
bc6b89237acb3dee6af6e64e51a18255fef89cc2 upstream.
rtlwifi allocates both setup_packet and data buffer of control message urb,
using shared kmalloc in _usbctrl_vendorreq_async_write. Structure used for
allocating is:
struct {
u8 data[254];
struct usb_ctrlrequest dr;
};
Because 'struct usb_ctrlrequest' is __packed, setup packet is unaligned and
DMA mapping of both 'data' and 'dr' confuses ARM/sunxi, leading to memory
corruptions and freezes.
Patch changes setup packet to be allocated separately.
[v2]:
- Use WARN_ON_ONCE instead of WARN_ON
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Fri, 8 Feb 2013 18:28:18 +0000 (12:28 -0600)]
rtlwifi: rtl8192cu: Add new USB ID
commit
8708aac79e4572ba673d7a21e94ddca9f3abb7fc upstream.
A new model of the RTL8188CUS has appeared.
Reported-and-tested-by: Thomas Rosenkrantz <tom.rosary@googlemail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Wed, 6 Feb 2013 18:54:17 +0000 (12:54 -0600)]
rtlwifi: rtl8192cu: Fix NULL dereference BUG when using new_id
commit
957f4aca5fa0db69635271bc4621cc0b65b2d590 upstream.
When the new_id entry in /sysfs is used for a foreign USB device, rtlwifi
BUGS with a NULL pointer dereference because the per-driver configuration
data is not available. The probe function has been restructured as
suggested by Ben Hutchings <bhutchings@solarflare.com>.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Sun, 17 Feb 2013 17:01:20 +0000 (17:01 +0000)]
b43: Increase number of RX DMA slots
commit
ccae0e50c16a7f7adb029c169147400d1ce9f703 upstream.
Bastian Bittorf reported that some of the silent freezes on a Linksys WRT54G
were due to overflow of the RX DMA ring buffer, which was created with 64
slots. That finding reminded me that I was seeing similar crashed on a netbook,
which also has a relatively slow processor. After increasing the number of
slots to 128, runs on the netbook that previously failed now worked; however,
I found that 109 slots had been used in one test. For that reason, the number
of slots is being increased to 256.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Bastian Bittorf <bittorf@bluebottle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Chan [Wed, 30 Jan 2013 01:54:44 +0000 (17:54 -0800)]
serial_core: Fix type definition for PORT_BRCM_TRUMANAGE.
commit
85f024401bf80746ae08b7fd5809a9b16accf0b1 upstream.
It was mistakenly defined to be 24 instead of the next higher number 25.
Reported-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Stephen Hurd <shurd@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Thu, 14 Feb 2013 20:01:06 +0000 (21:01 +0100)]
serial: imx: Fix recursive locking bug
commit
677fe555cbfb188af58cce105f4dae9505e58c31 upstream.
commit
9ec1882df2 (tty: serial: imx: console write routing is unsafe
on SMP) introduced a recursive locking bug in imx_console_write().
The callchain is:
imx_rxint()
spin_lock_irqsave(&sport->port.lock,flags);
...
uart_handle_sysrq_char();
sysrq_function();
printk();
imx_console_write();
spin_lock_irqsave(&sport->port.lock,flags); <--- DEAD
The bad news is that the kernel debugging facilities can dectect the
problem, but the printks never surface on the serial console for
obvious reasons.
There is a similar issue with oops_in_progress. If the kernel crashes
we really don't want to be stuck on the lock and unable to tell what
happened.
In general most UP originated drivers miss these checks and nobody
ever notices because CONFIG_PROVE_LOCKING seems to be still ignored by
a large number of developers.
The solution is to avoid locking in the sysrq case and trylock in the
oops_in_progress case.
This scheme is used in other drivers as well and it would be nice if
we could move this to a common place, so the usual copy/paste/modify
bugs can be avoided.
Now there is another issue with this scheme:
CPU0 CPU1
printk()
rxint()
sysrq_detection() -> sets port->sysrq
return from interrupt
console_write()
if (port->sysrq)
avoid locking
port->sysrq is reset with the next receive character. So as long as
the port->sysrq is not reset and this can take an endless amount of
time if after the break no futher receive character follows, all
console writes happen unlocked.
While the current writer is protected against other console writers by
the console sem, it's unprotected against open/close or other
operations which fiddle with the port. That's what the above mentioned
commit tried to solve.
That's an issue in all drivers which use that scheme and unfortunately
there is no easy workaround. The only solution is to have a separate
indicator port->sysrq_cpu. uart_handle_sysrq_char() then sets it to
smp_processor_id() before calling into handle_sysrq() and resets it to
-1 after that. Then change the locking check to:
if (port->sysrq_cpu == smp_processor_id())
locked = 0;
else if (oops_in_progress)
locked = spin_trylock_irqsave(port->lock, flags);
else
spin_lock_irqsave(port->lock, flags);
That would force all other cpus into the spin_lock path. Problem
solved, but that's way beyond the scope of this fix and really wants
to be implemented in a common function which calls the uart specific
write function to avoid another gazillion of hard to debug
copy/paste/modify bugs.
Reported-and-tested-by: Tim Sander <tim@krieglstein.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 13 Feb 2013 16:53:28 +0000 (17:53 +0100)]
USB: serial: fix null-pointer dereferences on disconnect
commit
b2ca699076573c94fee9a73cb0d8645383b602a0 upstream.
Make sure serial-driver dtr_rts is called with disc_mutex held after
checking the disconnected flag.
Due to a bug in the tty layer, dtr_rts may get called after a device has
been disconnected and the tty-device unregistered. Some drivers have had
individual checks for disconnect to make sure the disconnected interface
was not accessed, but this should really be handled in usb-serial core
(at least until the long-standing tty-bug has been fixed).
Note that the problem has been made more acute with commit
0998d0631001
("device-core: Ensure drvdata = NULL when no driver is bound") as the
port data is now also NULL when dtr_rts is called resulting in further
oopses.
Reported-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Tue, 29 Jan 2013 19:07:41 +0000 (20:07 +0100)]
tty: set_termios/set_termiox should not return -EINTR
commit
183d95cdd834381c594d3aa801c1f9f9c0c54fa9 upstream.
See https://bugzilla.redhat.com/show_bug.cgi?id=904907
read command causes bash to abort with double free or corruption (out).
A simple test-case from Roman:
// Compile the reproducer and send sigchld ti that process.
// EINTR occurs even if SA_RESTART flag is set.
void handler(int sig)
{
}
main()
{
struct sigaction act;
act.sa_handler = handler;
act.sa_flags = SA_RESTART;
sigaction (SIGCHLD, &act, 0);
struct termio ttp;
ioctl(0, TCGETA, &ttp);
while(1)
{
if (ioctl(0, TCSETAW, ttp) < 0)
{
if (errno == EINTR)
{
fprintf(stderr, "BUG!"); return(1);
}
}
}
}
Change set_termios/set_termiox to return -ERESTARTSYS to fix this
particular problem.
I didn't dare to change other EINTR's in drivers/tty/, but they look
equally wrong.
Reported-by: Roman Rakus <rrakus@redhat.com>
Reported-by: Lingzhu Xiang <lxiang@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dirkjan Bussink [Wed, 30 Jan 2013 10:44:50 +0000 (11:44 +0100)]
tty: Prevent deadlock in n_gsm driver
commit
4d9b109060f690f5c835130ff54165ae157b3087 upstream.
This change fixes a deadlock when the multiplexer is closed while there
are still client side ports open.
When the multiplexer is closed and there are active tty's it tries to
close them with tty_vhangup. This has a problem though, because
tty_vhangup needs the tty_lock. This patch changes it to unlock the
tty_lock before attempting the hangup and relocks afterwards. The
additional call to tty_port_tty_set is needed because otherwise the
port stays active because of the reference counter.
This change also exposed another problem that other code paths don't
expect that the multiplexer could have been closed. This patch also adds
checks for these cases in the gsmtty_ class of function that could be
called.
The documentation explicitly states that "first close all virtual ports
before closing the physical port" but we've found this to not always
reality in our field situations. The GPRS / UTMS modem sometimes crashes
and needs a power cycle in that case which means cleanly shutting down
everything is not always possible. This change makes it much more robust
for our situation where at least the system is recoverable with this patch
and doesn't hang in a deadlock situation inside the kernel.
The patch is against the long term support kernel (3.4.27) and should
apply cleanly to more recent branches. Tested with a Telit GE864-QUADV2
and Telit HE910 modem.
Signed-off-by: Dirkjan Bussink <dirkjan.bussink@nedap.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Mon, 4 Feb 2013 09:28:15 +0000 (10:28 +0100)]
ALSA: aloop: Fix Oops while PM resume
commit
edac894389f9c9de2a1368c78809c824b343f3a5 upstream.
snd-aloop driver has no proper PM implementation, thus the PM resume
may trigger Oops due to leftover timer instance. This patch adds the
missing suspend/resume implementation.
Reported-and-tested-by: El boulangero <elboulangero@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>