5 years agoipv4: fix error handling in icmp_protocol.
Li Wei [Thu, 21 Feb 2013 22:18:44 +0000 (22:18 +0000)]
ipv4: fix error handling in icmp_protocol.

[ Upstream commit 5b0520425e5ea81ba95ec486dd6bbb59a09fff0e ]

Now we handle icmp errors in each transport protocol's err_handler,
for icmp protocols, that is ping_err. Since this handler only care
of those icmp errors triggered by echo request, errors triggered
by echo reply(which sent by kernel) are sliently ignored.

So wrap ping_err() with icmp_err() to deal with those icmp errors.

Signed-off-by: Li Wei <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6: use a stronger hash for tcp
Eric Dumazet [Thu, 21 Feb 2013 12:18:52 +0000 (12:18 +0000)]
ipv6: use a stronger hash for tcp

[ Upstream commit 08dcdbf6a7b9d14c2302c5bd0c5390ddf122f664 ]

It looks like its possible to open thousands of TCP IPv6
sessions on a server, all landing in a single slot of TCP hash
table. Incoming packets have to lookup sockets in a very
long list.

We should hash all bits from foreign IPv6 addresses, using
a salt and hash mix, not a simple XOR.

inet6_ehashfn() can also separately use the ports, instead
of xoring them.

Reported-by: Neal Cardwell <>
Signed-off-by: Eric Dumazet <>
Cc: Yuchung Cheng <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv4: fix a bug in ping_err().
Li Wei [Thu, 21 Feb 2013 00:09:54 +0000 (00:09 +0000)]
ipv4: fix a bug in ping_err().

[ Upstream commit b531ed61a2a2a77eeb2f7c88b49aa5ec7d9880d8 ]

We should get 'type' and 'code' from the outer ICMP header.

Signed-off-by: Li Wei <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6: fix race condition regarding dst->expires and dst->from.
YOSHIFUJI Hideaki [Wed, 20 Feb 2013 00:29:08 +0000 (00:29 +0000)]
ipv6: fix race condition regarding dst->expires and dst->from.

[ Upstream commit ecd9883724b78cc72ed92c98bcb1a46c764fff21 ]

Eric Dumazet wrote:
| Some strange crashes happen in rt6_check_expired(), with access
| to random addresses.
| At first glance, it looks like the RTF_EXPIRES and
| stuff added in commit 1716a96101c49186b
| (ipv6: fix problem with expired dst cache)
| are racy : same dst could be manipulated at the same time
| on different cpus.
| At some point, our stack believes rt->dst.from contains a dst pointer,
| while its really a jiffie value (as rt->dst.expires shares the same area
| of memory)
| rt6_update_expires() should be fixed, or am I missing something ?
| CC Neil because of

Because we do not have any locks for dst_entry, we cannot change
essential structure in the entry; e.g., we cannot change reference
to other entity.

To fix this issue, split 'from' and 'expires' field in dst_entry
out of union.  Once it is 'from' is assigned in the constructor,
keep the reference until the very last stage of the life time of
the object.

Of course, it is unsafe to change 'from', so make rt6_set_from simple
just for fresh entries.

Reported-by: Eric Dumazet <>
Reported-by: Neil Horman <>
CC: Gao Feng <>
Signed-off-by: YOSHIFUJI Hideaki <>
Reviewed-by: Eric Dumazet <>
Reported-by: Steinar H. Gunderson <>
Reviewed-by: Neil Horman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoppp: set qdisc_tx_busylock to avoid LOCKDEP splat
Eric Dumazet [Tue, 19 Feb 2013 18:42:03 +0000 (10:42 -0800)]
ppp: set qdisc_tx_busylock to avoid LOCKDEP splat

[ Upstream commit 303c07db487be59ae9fda10600ea65ca11c21497 ]

If a qdisc is installed on a ppp device, its possible to get
a lockdep splat under stress, because nested dev_queue_xmit() can
lock busylock a second time (on a different device, so its a false

Avoid this problem using a distinct lock_class_key for ppp

Reported-by: Yanko Kaneti <>
Tested-by: Yanko Kaneti <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoxfrm: release neighbor upon dst destruction
Romain KUNTZ [Mon, 18 Feb 2013 02:36:24 +0000 (02:36 +0000)]
xfrm: release neighbor upon dst destruction

[ Upstream commit 18cf0d0784b4a634472ed24d0d7ca1c721d93e90 ]

Neighbor is cloned in xfrm6_fill_dst but seems to never be released.
Neighbor entry should be released when XFRM6 dst entry is destroyed
in xfrm6_dst_destroy, otherwise references may be kept forever on
the device pointed by the neighbor entry.

I may not have understood all the subtleties of XFRM & dst so I would
be happy to receive comments on this patch.

Signed-off-by: Romain Kuntz <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet: fix a compile error when SOCK_REFCNT_DEBUG is enabled
Ying Xue [Fri, 15 Feb 2013 22:28:25 +0000 (22:28 +0000)]
net: fix a compile error when SOCK_REFCNT_DEBUG is enabled

[ Upstream commit dec34fb0f5b7873de45132a84a3af29e61084a6b ]

When SOCK_REFCNT_DEBUG is enabled, below build error is met:

kernel/sysctl_binary.o: In function `sk_refcnt_debug_release':
include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release'
kernel/sysctl.o:include/net/sock.h:1025: first defined here
kernel/audit.o: In function `sk_refcnt_debug_release':
include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release'
kernel/sysctl.o:include/net/sock.h:1025: first defined here
make[1]: *** [kernel/built-in.o] Error 1
make: *** [kernel] Error 2

So we decide to make sk_refcnt_debug_release static to eliminate
the error.

Signed-off-by: Ying Xue <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoxen-netback: cancel the credit timer when taking the vif down
David Vrabel [Thu, 14 Feb 2013 03:18:58 +0000 (03:18 +0000)]
xen-netback: cancel the credit timer when taking the vif down

[ Upstream commit 3e55f8b306cf305832a4ac78aa82e1b40e818ece ]

If the credit timer is left armed after calling
xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
the vif which will then oops as vif->netbk == NULL.

This may happen both in the fatal error path and during normal
disconnection from the front end.

The sequencing during shutdown is critical to ensure that: a)
vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
is not freed.

1. Mark as unschedulable (netif_carrier_off()).
2. Synchronously cancel the timer.
3. Remove the vif from the schedule list.
4. Remove it from it netback thread group.
5. Wait for vif->refcnt to become 0.

Signed-off-by: David Vrabel <>
Acked-by: Ian Campbell <>
Reported-by: Christopher S. Aker <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoxen-netback: correctly return errors from netbk_count_requests()
David Vrabel [Thu, 14 Feb 2013 03:18:57 +0000 (03:18 +0000)]
xen-netback: correctly return errors from netbk_count_requests()

[ Upstream commit 35876b5ffc154c357476b2c3bdab10feaf4bd8f0 ]

netbk_count_requests() could detect an error, call
netbk_fatal_tx_error() but return 0.  The vif may then be used
afterwards (e.g., in a call to netbk_tx_error().

Since netbk_fatal_tx_error() could set vif->refcnt to 1, the vif may
be freed immediately after the call to netbk_fatal_tx_error() (e.g.,
if the vif is also removed).

Netback thread              Xenwatch thread
netbk_fatal_tx_err()        netback_remove()
netbk_tx_err() Oops!

Signed-off-by: Wei Liu <>
Signed-off-by: Jan Beulich <>
Signed-off-by: David Vrabel <>
Reported-by: Christopher S. Aker <>
Acked-by: Ian Campbell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet: cdc_ncm: fix probing of devices with multiple control interface altsettings
Bjørn Mork [Wed, 13 Feb 2013 12:09:52 +0000 (12:09 +0000)]
net: cdc_ncm: fix probing of devices with multiple control interface altsettings

[ Upstream commit f350ca03703133c94fe742f6fa6ff0fd8f5a9a09 ]

commit bd329e1 ("net: cdc_ncm: do not bind to NCM compatible MBIM devices")
added a test for a CDC MBIM altsetting, implementing the cdc_ncm part of
MBIM backward compatibility support.  This intentionally made the driver
behave differently for CDC NCM devices with 2 alternate settings for the
Communication interface, depending on whether or not CONFIG_USB_NET_CDC_MBIM
was enabled.  This is correct iff alternate setting #1 really *is* a MBIM
setting.  If not, then NCM probing will use a different altsetting than before,
possibly causing probing failures depending on CONFIG_USB_NET_CDC_MBIM.

Fix by setting the altsetting back to default after the test, restoring the
previous behaviour for non MBIM devices.

This bug causes probing of Huawei E3276 devices to fail when the MBIM driver
is enabled, because these devices have a second alternate setting with no CDC
functional descriptors.

Reported-and-tested-by: Jonathan A. <>
Cc: Greg Suarez <>
Cc: Alexey Orishko <>
Signed-off-by: Bjørn Mork <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoHID: wiimote: fix nunchuck button parser
David Herrmann [Mon, 18 Feb 2013 00:47:15 +0000 (01:47 +0100)]
HID: wiimote: fix nunchuck button parser

commit 89bdd0c6f38ccf0de43d5a36ede384a730f3394e upstream.

The buttons of the Wii Remote Nunchuck extension are actually active low.
Fix the parser to forward the inverted values. The comment in the function
always said "0 == pressed" but the implementation was wrong from the

Reported-by: Victor Quicksilver <>
Signed-off-by: David Herrmann <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agommc: core: expose RPMB partition only for CMD23 capable hosts
Balaji T K [Fri, 25 Jan 2013 11:30:30 +0000 (17:00 +0530)]
mmc: core: expose RPMB partition only for CMD23 capable hosts

commit d0123ccac55088811bde4f76c4a3fdbd39c3cfba upstream.

SET_BLOCK_COUNT CMD23 is needed for all access to RPMB partition.  If
block count is not set by CMD23, all subsequent read/write commands fail
as per eMMC specification. So, If the host does not support CMD23, do not
expose RPMB partition.

Accessing RPMB partition can cause hang / huge delay for hosts which do
not support CMD23.

Signed-off-by: Balaji T K <>
Reported-and-Tested-by: Peter Ujfalusi <>
Signed-off-by: Chris Ball <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agommc: sdhci-esdhc-imx: fix host version read
Shawn Guo [Tue, 15 Jan 2013 15:30:27 +0000 (23:30 +0800)]
mmc: sdhci-esdhc-imx: fix host version read

commit ef4d0888bb7e1b963880f086575081c3d39cad2d upstream.

When commit 95a2482 (mmc: sdhci-esdhc-imx: add basic imx6q usdhc
support) works around host version issue on imx6q, it gets the
register address fixup "reg ^= 2" lost for imx25/35/51/53 esdhc.
Thus, the controller version on these SoCs is wrongly identified
as v1 while it's actually v2.

Add the address fixup back and take a different approach to correct
imx6q host version, so that the host version read gets back to work
for all SoCs.

Signed-off-by: Shawn Guo <>
Signed-off-by: Chris Ball <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agofbcon: fix locking harder
Dave Airlie [Fri, 25 Jan 2013 01:38:56 +0000 (11:38 +1000)]
fbcon: fix locking harder

commit 054430e773c9a1e26f38e30156eff02dedfffc17 upstream.

Okay so Alan's patch handled the case where there was no registered fbcon,
however the other path entered in set_con2fb_map pit.

In there we called fbcon_takeover, but we also took the console lock in a couple
of places. So push the console lock out to the callers of set_con2fb_map,

this means fbmem and switcheroo needed to take the lock around the fb notifier
entry points that lead to this.

This should fix the efifb regression seen by Maarten.

Tested-by: Maarten Lankhorst <>
Tested-by: Lu Hua <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agofb: Yet another band-aid for fixing lockdep mess
Takashi Iwai [Fri, 25 Jan 2013 00:28:18 +0000 (10:28 +1000)]
fb: Yet another band-aid for fixing lockdep mess

commit e93a9a868792ad71cdd09d75e5a02d8067473c4e upstream.

I've still got lockdep warnings even after Alan's patch, and it seems that
yet more band aids are required to paper over similar paths for
unbind_con_driver() and unregister_con_driver().  After this hack, lockdep
warnings are finally gone.

Signed-off-by: Takashi Iwai <>
Cc: Alan Cox <>
Cc: Florian Tobias Schandinat <>
Cc: Jiri Kosina <>
Tested-by: Sedat Dilek <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agofb: rework locking to fix lock ordering on takeover
Alan Cox [Fri, 25 Jan 2013 00:28:15 +0000 (10:28 +1000)]
fb: rework locking to fix lock ordering on takeover

commit 50e244cc793d511b86adea24972f3a7264cae114 upstream.

Adjust the console layer to allow a take over call where the caller
already holds the locks.  Make the fb layer lock in order.

This is partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.

[ remove stray non-ascii char, tidy comment]
[ export do_take_over_console()]
[airlied: cleanup another non-ascii char]
Signed-off-by: Alan Cox <>
Cc: Florian Tobias Schandinat <>
Cc: Stephen Rothwell <>
Cc: Jiri Kosina <>
Tested-by: Sedat Dilek <>
Reviewed-by: Daniel Vetter <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agofbcon: don't lose the console font across generic->chip driver switch
Dave Airlie [Thu, 24 Jan 2013 06:12:41 +0000 (16:12 +1000)]
fbcon: don't lose the console font across generic->chip driver switch

commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream.

If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however when we then load the native KMS
driver, the first thing it does is tear down the generic framebuffer driver.

The thing is the generic code is doing the right thing, it frees the font
because otherwise it would leak memory. However we can assume that if you
are removing the generic firmware driver (vesa/efi/offb), that a new driver
*should* be loading soon after, so we effectively leak the font.

However the old code left a dangling pointer in vc-> and we
can now reuse that dangling pointer to load the font into the new
driver, now that we aren't freeing it.


Signed-off-by: Dave Airlie <>
Cc: Kay Sievers <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrivers/video: fsl-diu-fb: fix bugs in interrupt handling
Anatolij Gustschin [Sat, 19 Jan 2013 09:59:10 +0000 (10:59 +0100)]
drivers/video: fsl-diu-fb: fix bugs in interrupt handling

commit b2639b5f1d01f218dc95537a1c352b3a551c4dd5 upstream.

Since commit f74de500 "drivers/video: fsl-diu-fb: streamline
enabling of interrupts" the interrupt handling in the driver
is broken. Enabling diu interrupt causes an interrupt storm and
results in system lockup.

The cookie for the interrupt handler function passed to request_irq()
is wrong (it must be a pointer to the diu struct, and not the address
of the pointer to the diu struct). As a result the interrupt handler
can not read diu registers and acknowledge the interrupt. Fix cookie
arguments for request_irq() and free_irq().

Registering the diu interrupt handler in probe() must happen before
install_fb() calls since this function registers framebuffer devices
and if fbcon tries to take over framebuffer after registering a frame
buffer device, it will call fb_open of the diu driver and enable the
interrupts. At this time the diu interrupt handler must be registered

Disabling the interrupts in fsl_diu_release() must happen only if all
other AOIs are closed. Otherwise closing an overlay plane will disable
the interrupts even if the primary frame buffer plane is opened. Add
an appropriate check in the release function.

Signed-off-by: Anatolij Gustschin <>
Cc: Timur Tabi <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrivers/video: fsl-diu-fb: fix pixel formats for 24 and 16 bpp
Anatolij Gustschin [Thu, 17 Jan 2013 20:28:37 +0000 (21:28 +0100)]
drivers/video: fsl-diu-fb: fix pixel formats for 24 and 16 bpp

commit 5d3cc311a76073f6e0a27c0752f7e41f69e95ea7 upstream.

Framebuffer colors for 24 and 16 bpp are currently wrong. The order
of the color component arguments in the MAKE_PF() is not natural
and causes some confusion. The generated pixel format values for 24
and 16 bpp depths do not much the values in the comments.

Fix the macro arguments to be in the natural RGB order and adjust
the arguments for all depths to generate correct pixel format values
(equal to the values mentioned in the comments).

Signed-off-by: Anatolij Gustschin <>
Cc: Timur Tabi <>
Acked-by: Timur Tabi <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agopcmcia/vrc4171: Add missing spinlock init
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoPurge existing TLB entries in set_pte_at and ptep_set_wrprotect
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 <>
Signed-off-by: James Bottomley <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agopowerpc/eeh: Fix crash when adding a device in a slot with DDW
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 <>
Acked-by: Gavin Shan <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agouprobes/powerpc: Add dependency on single step emulation
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 <>
Signed-off-by: Suzuki K. Poulose <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agopowerpc/kexec: Disable hard IRQ before kexec
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 <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoARM: 7643/1: sched: correct update_sched_clock()
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 <>
Signed-off-by: Russell King <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoarm64: compat: use compat_uptr_t type for compat_ucontext.uc_link
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 <>
Signed-off-by: Will Deacon <>
Signed-off-by: Catalin Marinas <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoARM: integrator: ensure ap_syscon_base is initialised when !CONFIG_MMU
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 <>
Signed-off-by: Will Deacon <>
Signed-off-by: Olof Johansson <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoARM: i.MX25: clk: parent per5_clk to AHB clock
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
                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]

[2]: 2012d9ca2a1381ae3e733330a7f0d1d2f1988bba
[3]: 6bbaec5676e4f475b0d78743cbd4c70a8804ce14

Signed-off-by: Steffen Trumtrar <>
Signed-off-by: Sascha Hauer <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoARM: samsung: fix assembly syntax for new gas
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 <>
Acked-by: Kukjin Kim <>
Cc: Ben Dooks <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoARM: at91/DT: remove atmel,use-dma-* from 9x5 and 9n12 USART nodes
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

Reported-by: Douglas Gilbert <>
Signed-off-by: Nicolas Ferre <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoARM: PXA3xx: program the CSMSADRCFG register
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 <>
Acked-by: Eric Miao <>
Signed-off-by: Haojian Zhuang <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoARM: 7635/1: versatile: fix the PCI IRQ regression
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

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 <>
Signed-off-by: Linus Walleij <>
Signed-off-by: Russell King <>
Cc: Paul Gortmaker <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoASoC: arizona: Fixed a bug in FLL fractional calculation
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 <>
Signed-off-by: Charles Keepax <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoASoC: wm2200: correct IN2L and IN3L digital mute
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 <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agostaging: vt6656: Fix URB submitted while active warning.
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agostaging: vt6656: Revert: 64bit fixes: dpc.c incorrect addressing of void structure.
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.
staging: vt6656: Fix inconsistent structure packing

Reported-by: Ben Hutchings <>
Signed-off-by: Malcolm Priestley <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agostaging: vt6656: revert : 64 bit- Correctly address void structure.
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.
staging: vt6656: Fix inconsistent structure packing

Reported-by: Ben Hutchings <>
Signed-off-by: Malcolm Priestley <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agostaging: comedi: ni_labpc: correct differential channel sequence for AI commands
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
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agostaging: comedi: ni_labpc: set up command4 register *after* command3
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agostaging: comedi: disallow COMEDI_DEVCONFIG on non-board minors
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agostaging: zsmalloc: Fix TLB coherency and build problem
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

Reported-by: Matt Sealey <>
Cc: Dan Magenheimer <>
Cc: Russell King <>
Cc: Konrad Rzeszutek Wilk <>
Cc: Nitin Gupta <>
Cc: Seth Jennings <>
Signed-off-by: Minchan Kim <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: Handle untiled planes when computing their offsets
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

Fixes regression from commit c2c75131244507c93f812862fdbd4f3a37139401
Author: Daniel Vetter <>
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)

Signed-off-by: Chris Wilson <>
Cc: Daniel Vetter <>
Reviewed-by: Ville Syrjälä <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: inverted brightness quirk for Acer Aspire 4736Z
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.

Cc: Jani Nikula <>
Tested-by: Jani Monoses <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap
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.

Spotted-by: Ville Syrjälä <>
Reviewed-by: Ben Widawsky <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: add missing \n to UTS_RELEASE in the error_state
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.

commit 4518f611ba21ba165ea3714055938a8984a44ff9
Author: Daniel Vetter <>
Date:   Wed Jan 23 16:16:35 2013 +0100

    drm/i915: dump UTS_RELEASE into the error_state

Signed-off-by: Jani Nikula <>
Reviewed-by: Chris Wilson <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: Set i9xx sdvo clock limits according to specifications
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 <>
Reviewed-by: Chris Wilson <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: disable shared panel fitter for pipe
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 <>

Signed-off-by: Mika Kuoppala <>
Tested-by: Andreas Sturmlechner <>
[danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: write backlight harder
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 <>
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.

Cc: Takashi Iwai <>
Reviewed-by: Jani Nikula <>
Acked-by: Takashi Iwai <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: Fix RC6VIDS encode/decode
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 <>
Signed-off-by: Ben Widawsky <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: Fix CAGF for HSW
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 <>
Cc: Paulo Zanoni <>
Reviewed-by: Paulo Zanoni <>
Tested-by: Paulo Zanoni <>
Signed-off-by: Ben Widawsky <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: Only run idle processing from i915_gem_retire_requests_worker
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 <>
Reported-and-tested-by: Alexander Lam <>
Reviewed-by: Rodrigo Vivi <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: Preserve the FDI line reversal override bit on CPT
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 <>
Reviewed-by: Rodrigo Vivi <>
Reviewed-by: Paulo Zanoni <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/i915: Preserve the DDI link reversal configuration
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 <>
  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

Signed-off-by: Damien Lespiau <>
Reviewed-by: Paulo Zanoni <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoget rid of unprotected dereferencing of mnt->mnt_ns
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

Signed-off-by: Al Viro <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agointel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
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

Reported-and-tested-by: Mihai Moldovan <>
Cc: David Woodhouse <>
Cc: "Sankaran, Rajesh" <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/usb: bind driver to correct device
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

Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoRevert "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S"
Daniel Vetter [Wed, 13 Feb 2013 10:37:48 +0000 (20:37 +1000)]

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.

Signed-off-by: Daniel Vetter <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm: Use C8 instead of RGB332 when determining the format from depth/bpp
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

This fixes 8bpp fbcon on i915, since i915 will only accept C8 and not

Signed-off-by: Ville Syrjälä <>
Acked-by: Dave Airlie <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm: Fill depth/bits_per_pixel for C8 format
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ä <>
Acked-by: Dave Airlie <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm: shut up invalid edid messages
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 <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm: don't add inferred modes for monitors that don't support them
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)".

Reviewed-by: Alex Deucher <>
Reviewed-by: Adam Jackson <>
Signed-off-by: Paulo Zanoni <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoPCI: Fix PCI Express Capability accessors for PCI_EXP_FLAGS
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

[bhelgaas:  tweak changelog]
Signed-off-by: Alex Williamson <>
Signed-off-by: Bjorn Helgaas <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovgacon/vt: clear buffer attributes when we load a 512 character font (v2)
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/udl: disable fb_defio by default
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/udl: make usage as a console safer
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: properly validate the atpx interface
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.


Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: remove overzealous warning in hdmi handling
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.


Signed-off-by: Alex Deucher <>
Reviewed-by: Jerome Glisse <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: fix multi-head power profile stability on BTC+ asics
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon/dce6: fix display powergating
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agosparc64: Fix huge PMD to PTE translation for sun4u in TLB miss handler.
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:


_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

sequence instead.

This fixes "git gc" crashes on sun4u machines.

Reported-by: Meelis Roos <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agosparc64: Fix tsb_grow() in atomic context.
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

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 <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agosparc64: Handle hugepage TSB being NULL.
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agosparc64: Fix gfp_flags setting in tsb_grow().
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 <>
Acked-by: David Rientjes <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoGFS2: Get a block reservation before resizing a file
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 <>
Signed-off-by: Steven Whitehouse <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoALSA: hda - hdmi: ELD shouldn't be valid after unplug
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 <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoALSA: hda - Fix broken workaround for HDMI/SPDIF conflicts
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,

Reported-by: Stephan Raue <>
Reported-by: Anssi Hannula <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoALSA: hda - Workaround for silent output on Sony Vaio VGC-LN51JGB with ALC889
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 <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoALSA: hda - Fix default multichannel HDMI mapping regression
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 <>
Signed-off-by: Anssi Hannula <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoALSA: hda - Release assigned pin/cvt at error path of hdmi_pcm_open()
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoALSA: hda - Disable runtime PM for Intel 5 Series/3400
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.


Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoALSA: usb: Fix Processing Unit Descriptor parsers
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

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 <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoALSA: usb/quirks, fix out-of-bounds access
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 <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoALSA: usb-audio: fix Roland A-PRO support
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

Signed-off-by: Clemens Ladisch <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agop54usb: corrected USB ID for T-Com Sinus 154 data II
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 (md5sum:
7d676323ac60d6e1a3b6d61e8c528248). It works.

Signed-off-by: Tomasz Guszkowski <>
Acked-By: Christian Lamparter <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoNFSv4.1: Don't decode skipped layoutgets
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
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:11.0/0000:02:01.0/irq
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)
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 <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoNFSv4.1: Fix bulk recall and destroy of layouts
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoNFSv4.1: Fix an ABBA locking issue with session and state serialisation
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 <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoNLM: Ensure that we resend all pending blocking locks after a reclaim
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 <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoumount oops when remove blocklayoutdriver first
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

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)
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<>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrivercore: Fix ordering between deferred_probe and exiting initcalls
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 <>
Tested-by: Haojian Zhuang <>
Cc: Arnd Bergmann <>
Cc: Russell King <>
Cc: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agomm/fadvise.c: drain all pagevecs if POSIX_FADV_DONTNEED fails to discard all pages
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) {
buf[expected] = 0;
memset(buf, 'a', expected);

/* Prepare the mincore vec */
vec = malloc(FILESIZE_PAGES);
if (vec == NULL) {

/* Bind ourselves to CPU 0 */
CPU_SET(0, &set);
if (sched_setaffinity(getpid(), sizeof(set), &set) == -1) {

/* open file, unlink and write buffer */
fd = open("fadvise-test-file", O_CREAT|O_EXCL|O_RDWR);
if (fd == -1) {
while (written < expected) {
ssize_t this_write;
this_write = write(fd, buf + written, expected - written);

if (this_write == -1) {

written += this_write;

 * Force ourselves to another CPU. If fadvise only flushes the local
 * CPUs pagevecs then the fadvise will fail to discard all file pages
CPU_SET(1, &set);
if (sched_setaffinity(getpid(), sizeof(set), &set) == -1) {

/* sync and fadvise to discard the page cache */
if (posix_fadvise(fd, 0, expected, POSIX_FADV_DONTNEED) == -1) {

/* 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) {
if (mincore(buf, expected, vec) == -1) {

/* Check residency */
for (i = 0, resident = 0; i < FILESIZE_PAGES; i++) {
if (vec[i])
if (resident != 0) {
printf("Nr unexpected pages resident: %d\n", resident);

munmap(buf, expected);

Signed-off-by: Mel Gorman <>
Reported-by: Rob van der Heij <>
Tested-by: Rob van der Heij <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotmpfs: fix use-after-free of mempolicy object
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

    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<          (null)>]           (null)
    Oops: 0010 [#1] SMP DEBUG_PAGEALLOC
    Call Trace:

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

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)
    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 <>
Acked-by: Hugh Dickins <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoKEYS: Revert one application of "Fix unreachable code" patch
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

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 <>
Cc: Jiri Kosina <>
Cc: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrivers/video/backlight/adp88?0_bl.c: fix resume
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 <>
Acked-by: Michael Hennerich <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoocfs2: unlock super lock if lockres refresh failed
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 <>
Cc: Joel Becker <>
Cc: Mark Fasheh <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agofs/block_dev.c: page cache wrongly left invalidated after revalidate_disk()
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

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/ --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 <>
Cc: Al Viro <>
Cc: Jeff Moyer <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoinotify: remove broken mask checks causing unmount to be EINVAL
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 <>
Signed-off-by: Paul Gortmaker <>
Cc: Jerome Marchand <>
Cc: John McCutchan <>
Cc: Robert Love <>
Cc: Eric Paris <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agofutex: Revert "futex: Mark get_robust_list as deprecated"
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 <>
Cc: Cyrill Gorcunov <>
Cc: Richard Weinberger <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agos390/kvm: Fix store status for ACRS/FPRS
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 <>
Signed-off-by: Gleb Natapov <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoKVM: s390: Handle hosts not supporting s390-virtio.
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 <>
Reviewed-by: Alexander Graf <>
Signed-off-by: Cornelia Huck <>
Signed-off-by: Gleb Natapov <>
Signed-off-by: Greg Kroah-Hartman <>