UBUNTU: Start new release

Ignore: yes
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
hp-wmi: add more definitions for new event_id's

BugLink: http://bugs.launchpad.net/bugs/1152458

New HP laptops start generating new events, and hp-wmi prints unknown
event_ids for them. This patch also removes these messages

Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
(cherry picked from commit d9e290a0ff16aaa51d968e7a0714ea5e2ca2407d)

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
MFD: rtsx_pcr: Fix probe fail path

BugLink: http://bugs.launchpad.net/bugs/1201321

When rtsx_pci_acquire_irq fails in rtsx_pci_probe, we forget to
disable an MSI (if we enabled it). This results in this warning on the
next attempt to load the module:
WARNING: at drivers/pci/msi.c:834 pci_enable_msi_block+0x2a4/0x2b0()
Hardware name: HP EliteBook 840 G1
Modules linked in: rtsx_pci(+) ...
Pid: 4056, comm: modprobe Tainted: G          I  3.8.0-9405-gd895cb1-1-vanilla #1
Call Trace:
 [<ffffffff81045c6a>] warn_slowpath_common+0x7a/0xc0
 [<ffffffff81045cc5>] warn_slowpath_null+0x15/0x20
 [<ffffffff81302544>] pci_enable_msi_block+0x2a4/0x2b0
 [<ffffffffa05e335a>] rtsx_pci_probe+0x55a/0x720 [rtsx_pci]
...

So properly disable MSI in that case.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
(cherry picked from commit 9d66b568a215fe2da2a9db736ebf9b8d66082d88)
Signed-off-by: Adam Lee <adam.lee@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
mfd: rtsx: Add support for RTL8411B

BugLink: http://bugs.launchpad.net/bugs/1201321

Adding support of model RTL8411B. Since the model is similar to RTL8411,
differences are implemented in rtl8411.c.

Signed-off-by: Roger Tseng <rogerable@realtek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
(back ported from commit 9032eabdd3fcfc00aa513a9eef54002cbabb8c9a)

Conflicts:
	drivers/mfd/rtsx_pcr.c
	drivers/mfd/rtsx_pcr.h

Signed-off-by: Adam Lee <adam.lee@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
veth: reduce stat overhead

BugLink: http://bugs.launchpad.net/bugs/1201869

veth stats are a bit bloated. There is no need to account transmit
and receive stats, since they are absolutely symmetric.

Also use a per device atomic64_t for the dropped counter, as it
should never be used in fast path.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 2681128f0ced8aa4e66f221197e183cc16d244fe)

Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
veth: extend device features

BugLink: http://bugs.launchpad.net/bugs/1201869

veth is lacking most modern facilities, like SG, checksums, TSO.

It makes sense to extend dev->features to get them, or GRO aggregation
is defeated by a forced segmentation.

Reported-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8093315a91340bca52549044975d8c7f673b28a1)

Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
veth: avoid a NULL deref in veth_stats_one

BugLink: http://bugs.launchpad.net/bugs/1201869

commit 2681128f0ced8a (veth: extend device features) added a NULL deref
in veth_stats_one(), as veth_get_stats64() was not testing if the peer
device was setup or not.

At init time, we call dev_get_stats() before veth pair is fully setup.

[  178.854758]  [<ffffffffa00f5677>] veth_get_stats64+0x47/0x70 [veth]
[  178.861013]  [<ffffffff814f0a2d>] dev_get_stats+0x6d/0x130
[  178.866486]  [<ffffffff81504efc>] rtnl_fill_ifinfo+0x47c/0x930
[  178.872299]  [<ffffffff81505b93>] rtmsg_ifinfo+0x83/0x100
[  178.877678]  [<ffffffff81505cc6>] rtnl_configure_link+0x76/0xa0
[  178.883580]  [<ffffffffa00f52fa>] veth_newlink+0x16a/0x350 [veth]
[  178.889654]  [<ffffffff815061cc>] rtnl_newlink+0x4dc/0x5e0
[  178.895128]  [<ffffffff81505e1e>] ? rtnl_newlink+0x12e/0x5e0
[  178.900769]  [<ffffffff8150587d>] rtnetlink_rcv_msg+0x11d/0x310
[  178.906669]  [<ffffffff81505760>] ? __rtnl_unlock+0x20/0x20
[  178.912225]  [<ffffffff81521f89>] netlink_rcv_skb+0xa9/0xd0
[  178.917779]  [<ffffffff81502d55>] rtnetlink_rcv+0x25/0x40
[  178.923159]  [<ffffffff815218d1>] netlink_unicast+0x1b1/0x230
[  178.928887]  [<ffffffff81521c4e>] netlink_sendmsg+0x2fe/0x3b0
[  178.934615]  [<ffffffff814dbe22>] sock_sendmsg+0xd2/0xf0

So we must check if peer was setup in veth_get_stats64()

As pointed out by Ben Hutchings, priv->peer is missing proper
synchronization. Adding RCU protection is a safe and well documented
way to make sure we don't access about to be freed or already
freed data.

Reported-by: Tom Parkin <tparkin@katalix.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit d0e2c55e7c940a3ee91e9e23a2683b593690f1e9)

Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Input: elantech - fix for newer hardware versions (v7)

BugLink: http://bugs.launchpad.net/bugs/1166442

* Fix version recognition in elantech_set_properties

  The new hardware reports itself as v7 but the packets'
  structure is unaltered.

* Fix packet type recognition in elantech_packet_check_v4

  The bitmask used for v6 is too wide, only the last three bits of
  the third byte in a packet (packet[3] & 0x03) are actually used to
  distinguish between packet types.
  Starting from v7, additional information (to be interpreted) is
  stored in the remaining bits (packets[3] & 0x1c).
  In addition, the value stored in (packet[0] & 0x0c) is no longer
  a constant but contains additional information yet to be deciphered.
  This change should be backwards compatible with v6 hardware.

Additional-author: Giovanni Frigione <gio.frigione@gmail.com>
Signed-off-by: Matteo Delfino <kendatsuba@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
(cherry picked from commit 9eebed7de660c0b5ab129a9de4f89d20b60de68c)
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
zram: avoid invalid memory access in zram_exit()

BugLink: http://bugs.launchpad.net/bugs/1204600

commit 6030ea9b35971a4200062f010341ab832e878ac9 upstream.

Memory for zram->disk object may have already been freed after returning
from destroy_device(zram), then it's unsafe for zram_reset_device(zram)
to access zram->disk again.

We can't solve this bug by flipping the order of destroy_device(zram)
and zram_reset_device(zram), that will cause deadlock issues to the
zram sysfs handler.

So fix it by holding an extra reference to zram->disk before calling
destroy_device(zram).

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ luis: backported to 3.5: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
zram: use zram->lock to protect zram_free_page() in swap free notify path

BugLink: http://bugs.launchpad.net/bugs/1204600

commit 57ab048532c0d975538cebd4456491b5c34248f4 upstream.

zram_slot_free_notify() is free-running without any protection from
concurrent operations. So there are race conditions between
zram_bvec_read()/zram_bvec_write() and zram_slot_free_notify(),
and possible consequences include:
1) Trigger BUG_ON(!handle) on zram_bvec_write() side.
2) Access to freed pages on zram_bvec_read() side.
3) Break some fields (bad_compress, good_compress, pages_stored)
   in zram->stats if the swap layer makes concurrently call to
   zram_slot_free_notify().

So enhance zram_slot_free_notify() to acquire writer lock on zram->lock
before calling zram_free_page().

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ luis: backported to 3.5: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
zram: destroy all devices on error recovery path in zram_init()

BugLink: http://bugs.launchpad.net/bugs/1204600

commit 39a9b8ac9333e4268ecff7da6c9d1ab3823ff243 upstream.

On error recovery path of zram_init(), it leaks the zram device object
causing the failure. So change create_device() to free allocated
resources on error path.

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Jerome Marchand <jmarchan@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ luis: backported to 3.5: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
zram: avoid double free in function zram_bvec_write()

BugLink: http://bugs.launchpad.net/bugs/1204600

commit 65c484609a3b25c35e4edcd5f2c38f98f5226093 upstream.

When doing a patial write and the whole page is filled with zero,
zram_bvec_write() will free uncmem twice.

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ luis: backported to 3.5: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
zram: avoid access beyond the zram device

BugLink: http://bugs.launchpad.net/bugs/1204600

commit 12a7ad3b810e77137d0caf97a6dd97591e075b30 upstream.

Function valid_io_request() should verify the entire request are within
the zram device address range. Otherwise it may cause invalid memory
access when accessing/modifying zram->meta->table[index] because the
'index' is out of range. Then it may access non-exist memory, randomly
modify memory belong to other subsystems, which is hard to track down.

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
zram: protect sysfs handler from invalid memory access

BugLink: http://bugs.launchpad.net/bugs/1204600

commit 5863e10b441e7ea4b492f930f1be180a97d026f3 upstream.

Use zram->init_lock to protect access to zram->meta, otherwise it
may cause invalid memory access if zram->meta has been freed by
zram_reset_device().

This issue may be triggered by:
Thread 1:
while true; do cat mem_used_total; done
Thread 2:
while true; do echo 8M > disksize; echo 1 > reset; done

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ luis: backported to 3.5:
  - protect access to zram->mem_pool instead of zram->meta ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
pcmcia: at91_cf: fix gpio_get_value in at91_cf_get_status

BugLink: http://bugs.launchpad.net/bugs/1204600

commit e39506b466edcda2a7e9d0174d7987ae654137b7 upstream.

Commit 80af9e6d (pcmcia at91_cf: fix raw gpio number usage) forgot
to change the parameter in gpio_get_value after adding gpio
validation.

Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
usb: gadget: f_mass_storage: add missing memory barrier for thread_wakeup_needed

BugLink: http://bugs.launchpad.net/bugs/1204600

commit d68c277b501889b3a50c179d1c3d704db7947b83 upstream.

Without this memory barrier, the file-storage thread may fail to
escape from the following while loop, because it may observe new
common->thread_wakeup_needed and old bh->state which are updated by
the callback functions.

	/* Wait for the CBW to arrive */
	while (bh->state != BUF_STATE_FULL) {
		rc = sleep_thread(common);
		if (rc)
			return rc;
	}

Signed-off-by: UCHINO Satoshi <satoshi.uchino@toshiba.co.jp>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
cgroup: fix umount vs cgroup_event_remove() race

BugLink: http://bugs.launchpad.net/bugs/1204600

commit 1c8158eeae0f37d0eee9f1fbe68080df6a408df2 upstream.

 commit 5db9a4d99b0157a513944e9a44d29c9cec2e91dc
 Author: Tejun Heo <tj@kernel.org>
 Date:   Sat Jul 7 16:08:18 2012 -0700

     cgroup: fix cgroup hierarchy umount race

This commit fixed a race caused by the dput() in css_dput_fn(), but
the dput() in cgroup_event_remove() can also lead to the same BUG().

Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
[ luis: backported to 3.5: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
xhci: check for failed dma pool allocation

BugLink: http://bugs.launchpad.net/bugs/1204600

commit 025f880cb2e4d7218d0422d4b07bea1a68959c38 upstream.

Fail and free the container context in case dma_pool_alloc() can't allocate
the raw context data part of it

This patch should be backported to kernels as old as 2.6.31, that
contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 "USB: xhci:
Support for 64-byte contexts".

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: John Youn <johnyoun@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
usb: host: xhci-plat: release mem region while removing module

BugLink: http://bugs.launchpad.net/bugs/1204600

commit 5388a3a5faba8dfa69e5f06c3a415d373c1a4316 upstream.

Do a release_mem_region of the hcd resource. Without this the
subsequent insertion of module fails in request_mem_region.

Signed-off-by: George Cherian <george.cherian@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
USB: option,qcserial: move Novatel Gobi1K IDs to qcserial

BugLink: http://bugs.launchpad.net/bugs/1204600

commit a254810a86aaaac4ac6ba44fa934558b042a17a7 upstream.

These devices are all Gobi1K devices (according to the Windows INF
files) and should be handled by qcserial instead of option.  Their
network port is handled by qmi_wwan.

Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>