commit 0b8aecf15e5b1b08abfd971642d98e6e319df505
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Mon Mar 16 14:59:21 2015 +0100

    Linux 3.12.39

commit 13538bcabe53f06d64e65f6dd101f3ba07f3c9c0
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Wed Dec 24 17:43:27 2014 +0300

    clk-gate: fix bit # check in clk_register_gate()
    
    commit 2e9dcdae4068460c45a308dd891be5248260251c upstream.
    
    In case CLK_GATE_HIWORD_MASK flag is passed to clk_register_gate(), the bit #
    should be no higher than 15, however the corresponding check is obviously off-
    by-one.
    
    Fixes: 045779942c04 ("clk: gate: add CLK_GATE_HIWORD_MASK")
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: Michael Turquette <mturquette@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cb3f9ca37d900d0084c985fa965356eb4b7fe6e9
Author: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Date:   Wed Feb 4 00:21:13 2015 +0300

    ath5k: fix spontaneus AR5312 freezes
    
    commit 8bfae4f9938b6c1f033a5159febe97e441d6d526 upstream.
    
    Sometimes while CPU have some load and ath5k doing the wireless
    interface reset the whole WiSoC completely freezes. Set of tests shows
    that using atomic delay function while we wait interface reset helps to
    avoid such freezes.
    
    The easiest way to reproduce this issue: create a station interface,
    start continous scan with wpa_supplicant and load CPU by something. Or
    just create multiple station interfaces and put them all in continous
    scan.
    
    This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use
    usleep_range where possible"), which replaces initial udelay()
    by usleep_range().
    
    I do not know actual source of this issue, but all looks like that HW
    freeze is caused by transaction on internal SoC bus, while wireless
    block is in reset state.
    
    Also I should note that I do not know how many chips are affected, but I
    did not see this issue with chips, other than AR5312.
    
    CC: Jiri Slaby <jirislaby@gmail.com>
    CC: Nick Kossifidis <mickflemm@gmail.com>
    CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
    Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible")
    Reported-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
    Tested-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
    Tested-by: Eric Bree <ebree@nltinc.com>
    Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 168d2e5ef722d727d632b27226e36d14123af5b2
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Thu Feb 26 12:54:46 2015 -0500

    NFSv4: Don't call put_rpccred() under the rcu_read_lock()
    
    commit 7c0af9ffb7bb4e5355470fa60b3eb711ddf226fa upstream.
    
    put_rpccred() can sleep.
    
    Fixes: 8f649c3762547 ("NFSv4: Fix the locking in nfs_inode_reclaim_delegation()")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fec983fe4a8885f402ba647d9c476e6b644ce787
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Mar 1 10:41:37 2015 +0000

    ACPI / video: Load the module even if ACPI is disabled
    
    commit 6e17cb12881ba8d5e456b89f072dc6b70048af36 upstream.
    
    i915.ko depends upon the acpi/video.ko module and so refuses to load if
    ACPI is disabled at runtime if for example the BIOS is broken beyond
    repair. acpi/video provides an optional service for i915.ko and so we
    should just allow the modules to load, but do no nothing in order to let
    the machines boot correctly.
    
    Reported-by: Bill Augur <bill-auger@programmer.net>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Acked-by: Aaron Lu <aaron.lu@intel.com>
    [ rjw: Fixed up the new comment in acpi_video_init() ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8245bceb36e061a8a89044c1517a10fc2156b110
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Feb 19 16:02:15 2015 -0500

    drm/radeon: fix 1 RB harvest config setup for TN/RL
    
    commit dbfb00c3e7e18439f2ebf67fe99bf7a50b5bae1e upstream.
    
    The logic was reversed from what the hw actually exposed.
    Fixes graphics corruption in certain harvest configurations.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 84f9532fa92ab2f82e5eb0089d1ee5693f56753f
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Feb 18 01:05:30 2015 -0500

    drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh
    
    commit 3d2d98ee1af0cf6eebfbd6bff4c17d3601ac1284 upstream.
    
    Just in case it hasn't been calculated for the mode.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 365302800a2667d7a1a1ed54bc691e65c6b8e4b9
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Tue Jan 6 22:34:19 2015 +0100

    HID: fixup the conflicting keyboard mappings quirk
    
    commit 8e7b341037db1835ee6eea64663013cbfcf33575 upstream.
    
    The ignore check that got added in 6ce901eb61 ("HID: input: fix confusion
    on conflicting mappings") needs to properly check for VARIABLE reports
    as well (ARRAY reports should be ignored), otherwise legitimate keyboards
    might break.
    
    Fixes: 6ce901eb61 ("HID: input: fix confusion on conflicting mappings")
    Reported-by: Fredrik Hallenberg <megahallon@gmail.com>
    Reported-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 955c3838cacf128fa7ca929f9c58df74778f6150
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Mon Dec 29 15:21:26 2014 +0100

    HID: input: fix confusion on conflicting mappings
    
    commit 6ce901eb61aa30ba8565c62049ee80c90728ef14 upstream.
    
    On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its
    neighbours look like this:
    
               +---+ +---+ +-------+
               | 1 | | 2 | |   5   |
               +---+ +---+ +-------+
                 +---+ +-----------+
                 | 3 | |     4     |
                 +---+ +-----------+
    
    On a PC-102/105 keyboard (European layout) it looks like this:
    
               +---+ +---+ +-------+
               | 1 | | 2 | |       |
               +---+ +---+ +-+  4  |
                 +---+ +---+ |     |
                 | 3 | | 5 | |     |
                 +---+ +---+ +-----+
    
    (Note that the number of keys is the same, but key '5' is moved down and
     the shape of key '4' is changed. Keys '1' to '3' are exactly the same.)
    
    The keys 1-4 report the same scan-code in HID in both layouts, even though
    the keysym they produce is usually different depending on the XKB-keymap
    used by user-space.
    However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout
    and 0x32 for the lower layout, as defined by the HID spec. This is highly
    confusing as the linux-input API uses a single keycode for both.
    
    So far, this was never a problem as there never has been a keyboard with
    both of those keys present at the same time. It would have to look
    something like this:
    
               +---+ +---+ +-------+
               | 1 | | 2 | |  x31  |
               +---+ +---+ +-------+
                 +---+ +---+ +-----+
                 | 3 | |x32| |  4  |
                 +---+ +---+ +-----+
    
    HID can represent such a keyboard, but the linux-input API cannot.
    Furthermore, any user-space mapping would be confused by this and,
    luckily, no-one ever produced such hardware.
    
    Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to
    the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys
    is present on a hardware, this works just fine.
    
    Lets introduce hardware-vendors into this:
    ------------------------------------------
    
    Unfortunately, it seems way to expensive to produce a different device for
    American and European layouts. Therefore, hardware-vendors put both keys,
    (0x31 and 0x32) on the same keyboard, but only one of them is hooked up
    to the physical button, the other one is 'dead'.
    This means, they can use the same hardware, with a different button-layout
    and automatically produce the correct HID events for American *and*
    European layouts. This is unproblematic for normal keyboards, as the
    'dead' key will never report any KEY-DOWN events. But RollOver keyboards
    send the whole matrix on each key-event, allowing n-key roll-over mode.
    This means, we get a 0x31 and 0x32 event on each key-press. One of them
    will always be 0, the other reports the real state. As we map both to the
    same keycode, we will get spurious key-events, even though the real
    key-state never changed.
    
    The easiest way would be to blacklist 'dead' keys and never handle those.
    We could simply read the 'country' tag of USB devices and blacklist either
    key according to the layout. But... hardware vendors... want the same
    device for all countries and thus many of them set 'country' to 0 for all
    devices. Meh..
    
    So we have to deal with this properly. As we cannot know which of the keys
    is 'dead', we either need a heuristic and track those keys, or we simply
    make use of our value-tracking for HID fields. We simply ignore HID events
    for absolute data if the data didn't change. As HID tracks events on the
    HID level, we haven't done the keycode translation, yet. Therefore, the
    'dead' key is tracked independently of the real key, therefore, any events
    on it will be ignored.
    
    This patch simply discards any HID events for absolute data if it didn't
    change compared to the last report. We need to ignore relative and
    buffered-byte reports for obvious reasons. But those cannot be affected by
    this bug, so we're fine.
    
    Preferably, we'd do this filtering on the HID-core level. But this might
    break a lot of custom drivers, if they do not follow the HID specs.
    Therefore, we do this late in hid-input just before we inject it into the
    input layer (which does the exact same filtering, but on the keycode
    level).
    
    If this turns out to break some devices, we might have to limit filtering
    to EV_KEY events. But lets try to do the Right Thing first, and properly
    filter any absolute data that didn't change.
    
    This patch is tagged for 'stable' as it fixes a lot of n-key RollOver
    hardware. We might wanna wait with backporting for a while, before we know
    it doesn't break anything else, though.
    
    Reported-by: Adam Goode <adam@spicenitz.org>
    Reported-by: Fredrik Hallenberg <megahallon@gmail.com>
    Tested-by: Fredrik Hallenberg <megahallon@gmail.com>
    Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dde15ae3c9adb46ba366ffab34487080e1bb2a22
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Feb 17 14:34:00 2015 -0500

    dm snapshot: fix a possible invalid memory access on unload
    
    commit 22aa66a3ee5b61e0f4a0bfeabcaa567861109ec3 upstream.
    
    When the snapshot target is unloaded, snapshot_dtr() waits until
    pending_exceptions_count drops to zero.  Then, it destroys the snapshot.
    Therefore, the function that decrements pending_exceptions_count
    should not touch the snapshot structure after the decrement.
    
    pending_complete() calls free_pending_exception(), which decrements
    pending_exceptions_count, and then it performs up_write(&s->lock) and it
    calls retry_origin_bios() which dereferences  s->origin.  These two
    memory accesses to the fields of the snapshot may touch the dm_snapshot
    struture after it is freed.
    
    This patch moves the call to free_pending_exception() to the end of
    pending_complete(), so that the snapshot will not be destroyed while
    pending_complete() is in progress.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0a21fde3fe39835289f69d2280a68d570f611824
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Feb 17 14:30:53 2015 -0500

    dm: fix a race condition in dm_get_md
    
    commit 2bec1f4a8832e74ebbe859f176d8a9cb20dd97f4 upstream.
    
    The function dm_get_md finds a device mapper device with a given dev_t,
    increases the reference count and returns the pointer.
    
    dm_get_md calls dm_find_md, dm_find_md takes _minor_lock, finds the
    device, tests that the device doesn't have DMF_DELETING or DMF_FREEING
    flag, drops _minor_lock and returns pointer to the device. dm_get_md then
    calls dm_get. dm_get calls BUG if the device has the DMF_FREEING flag,
    otherwise it increments the reference count.
    
    There is a possible race condition - after dm_find_md exits and before
    dm_get is called, there are no locks held, so the device may disappear or
    DMF_FREEING flag may be set, which results in BUG.
    
    To fix this bug, we need to call dm_get while we hold _minor_lock. This
    patch renames dm_find_md to dm_get_md and changes it so that it calls
    dm_get while holding the lock.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d5a590350fc031273762482cc0d46a6c4a8220b3
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Fri Feb 13 11:05:37 2015 -0800

    dm io: reject unsupported DISCARD requests with EOPNOTSUPP
    
    commit 37527b869207ad4c208b1e13967d69b8bba1fbf9 upstream.
    
    I created a dm-raid1 device backed by a device that supports DISCARD
    and another device that does NOT support DISCARD with the following
    dm configuration:
    
     #  echo '0 2048 mirror core 1 512 2 /dev/sda 0 /dev/sdb 0' | dmsetup create moo
     # lsblk -D
     NAME         DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
     sda                 0        4K       1G         0
     `-moo (dm-0)        0        4K       1G         0
     sdb                 0        0B       0B         0
     `-moo (dm-0)        0        4K       1G         0
    
    Notice that the mirror device /dev/mapper/moo advertises DISCARD
    support even though one of the mirror halves doesn't.
    
    If I issue a DISCARD request (via fstrim, mount -o discard, or ioctl
    BLKDISCARD) through the mirror, kmirrord gets stuck in an infinite
    loop in do_region() when it tries to issue a DISCARD request to sdb.
    The problem is that when we call do_region() against sdb, num_sectors
    is set to zero because q->limits.max_discard_sectors is zero.
    Therefore, "remaining" never decreases and the loop never terminates.
    
    To fix this: before entering the loop, check for the combination of
    REQ_DISCARD and no discard and return -EOPNOTSUPP to avoid hanging up
    the mirror device.
    
    This bug was found by the unfortunate coincidence of pvmove and a
    discard operation in the RHEL 6.5 kernel; upstream is also affected.
    
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Acked-by: "Martin K. Petersen" <martin.petersen@oracle.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9bc83b500a3d2d59e09956755ce271e00f71a335
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Feb 12 10:09:20 2015 -0500

    dm mirror: do not degrade the mirror on discard error
    
    commit f2ed51ac64611d717d1917820a01930174c2f236 upstream.
    
    It may be possible that a device claims discard support but it rejects
    discards with -EOPNOTSUPP.  It happens when using loopback on ext2/ext3
    filesystem driven by the ext4 driver.  It may also happen if the
    underlying devices are moved from one disk on another.
    
    If discard error happens, we reject the bio with -EOPNOTSUPP, but we do
    not degrade the array.
    
    This patch fixes failed test shell/lvconvert-repair-transient.sh in the
    lvm2 testsuite if the testsuite is extracted on an ext2 or ext3
    filesystem and it is being driven by the ext4 driver.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b848046a02bc2a35da3f6a0fbae8db6ff1691cc4
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Tue Jan 27 18:16:51 2015 +0000

    staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back
    
    commit 42b8ce6f55facfa101462e694d33fc6bca471138 upstream.
    
    `do_cmd_ioctl()` in "comedi_fops.c" handles the `COMEDI_CMD` ioctl.
    This returns `-EAGAIN` if it has copied a modified `struct comedi_cmd`
    back to user-space.  (This occurs when the low-level Comedi driver's
    `do_cmdtest()` handler returns non-zero to indicate a problem with the
    contents of the `struct comedi_cmd`, or when the `struct comedi_cmd` has
    the `CMDF_BOGUS` flag set.)
    
    `compat_cmd()` in "comedi_compat32.c" handles the 32-bit compatible
    version of the `COMEDI_CMD` ioctl.  Currently, it never copies a 32-bit
    compatible version of `struct comedi_cmd` back to user-space, which is
    at odds with the way the regular `COMEDI_CMD` ioctl is handled.  To fix
    it, change `compat_cmd()` to copy a 32-bit compatible version of the
    `struct comedi_cmd` back to user-space when the main ioctl handler
    returns `-EAGAIN`.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 23b96e928e19077011c4c96719ea708dcb8c3953
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Jan 24 12:56:32 2015 +0100

    sunxi: clk: Set sun6i-pll1 n_start = 1
    
    commit 76820fcf7aa5a418b69cb7bed31b62d1feb1d6ad upstream.
    
    For all pll-s on sun6i n == 0 means use a multiplier of 1, rather then 0 as
    it means on sun4i / sun5i / sun7i. n_start = 1 is already correctly set
    for sun6i pll6, but was missing for pll1, this commit fixes this.
    
    Cc: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit abe869119f1c7b62e773805416c7ac0d237f570e
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Thu Jun 26 23:55:41 2014 +0800

    clk: sunxi: Support factor clocks with N factor starting not from 0
    
    commit 9a5e6c7eb5ccbb5f0d3a1dffce135f0a727f40e1 upstream.
    
    The PLLs on newer Allwinner SoC's, such as the A31 and A23, have a
    N multiplier factor that starts from 1, not 0.
    
    This patch adds an option to the factor clk driver's config data
    structures to specify the base value of N.
    
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9a0fb408e3294a4a9e058567f21163c024f67269
Author: Soren Brinkmann <soren.brinkmann@xilinx.com>
Date:   Tue Jan 27 11:05:27 2015 -0800

    clk: zynq: Force CPU_2X clock to be ungated
    
    commit 3dccfecdb867fe35b305a4e493ef5652b7d9d4cb upstream.
    
    The CPU_2X clock does not have a classical in-kernel user, but is,
    amongst other things, required for OCM and debug access. Make sure this
    clock is not mistakenly disabled during boot up by enabling it in the
    platform's clock driver.
    
    Fixes: 0ee52b157b8e 'clk: zynq: Add clock controller driver'
    Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
    Signed-off-by: Michael Turquette <mturquette@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 987f065a71f9d4ac3553c7f9b220ce14cf317024
Author: Minh Duc Tran <MinhDuc.Tran@Emulex.Com>
Date:   Mon Feb 9 18:54:09 2015 +0000

    fixed invalid assignment of 64bit mask to host dma_boundary for scatter gather segment boundary limit.
    
    commit f76a610a8b4b6280eaedf48f3af9d5d74e418b66 upstream.
    
    In reference to bug https://bugzilla.redhat.com/show_bug.cgi?id=1097141
    Assert is seen with AMD cpu whenever calling pci_alloc_consistent.
    
    [   29.406183] ------------[ cut here ]------------
    [   29.410505] kernel BUG at lib/iommu-helper.c:13!
    
    Signed-off-by: Minh Tran <minh.tran@emulex.com>
    Fixes: 6733b39a1301b0b020bbcbf3295852e93e624cb1
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d56d66a20a736d16c38717322b9cff0ad5d5598e
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Mon Mar 16 14:52:21 2015 +0100

    ASoC: omap-pcm: Correct dma mask
    
    commit d51199a83a2cf82a291d19ee852c44caa511427d upstream.
    
    DMA_BIT_MASK of 64 is not valid dma address mask for OMAPs, it should
    be set to 32.
    The 64 was introduced by commit (in 2009):
    a152ff24b978 ASoC: OMAP: Make DMA 64 aligned
    
    But the dma_mask and coherent_dma_mask can not be used to specify
    alignment.
    
    Fixes: a152ff24b978 (ASoC: OMAP: Make DMA 64 aligned)
    Reported-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ee5d1445d574b20496064f44ec7fabafd3620aca
Author: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Date:   Fri Feb 27 15:51:56 2015 -0800

    nilfs2: fix potential memory overrun on inode
    
    commit 957ed60b53b519064a54988c4e31e0087e47d091 upstream.
    
    Each inode of nilfs2 stores a root node of a b-tree, and it turned out to
    have a memory overrun issue:
    
    Each b-tree node of nilfs2 stores a set of key-value pairs and the number
    of them (in "bn_nchildren" member of nilfs_btree_node struct), as well as
    a few other "bn_*" members.
    
    Since the value of "bn_nchildren" is used for operations on the key-values
    within the b-tree node, it can cause memory access overrun if a large
    number is incorrectly set to "bn_nchildren".
    
    For instance, nilfs_btree_node_lookup() function determines the range of
    binary search with it, and too large "bn_nchildren" leads
    nilfs_btree_node_get_key() in that function to overrun.
    
    As for intermediate b-tree nodes, this is prevented by a sanity check
    performed when each node is read from a drive, however, no sanity check
    has been done for root nodes stored in inodes.
    
    This patch fixes the issue by adding missing sanity check against b-tree
    root nodes so that it's called when on-memory inodes are read from ifile,
    inode metadata file.
    
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8a1f8bd0262f701364ae1344cd230ef86d273007
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Feb 11 15:25:22 2015 -0800

    mm/hugetlb: take page table lock in follow_huge_pmd()
    
    commit e66f17ff71772b209eed39de35aaa99ba819c93d upstream.
    
    We have a race condition between move_pages() and freeing hugepages, where
    move_pages() calls follow_page(FOLL_GET) for hugepages internally and
    tries to get its refcount without preventing concurrent freeing.  This
    race crashes the kernel, so this patch fixes it by moving FOLL_GET code
    for hugepages into follow_huge_pmd() with taking the page table lock.
    
    This patch intentionally removes page==NULL check after pte_page.
    This is justified because pte_page() never returns NULL for any
    architectures or configurations.
    
    This patch changes the behavior of follow_huge_pmd() for tail pages and
    then tail pages can be pinned/returned.  So the caller must be changed to
    properly handle the returned tail pages.
    
    We could have a choice to add the similar locking to
    follow_huge_(addr|pud) for consistency, but it's not necessary because
    currently these functions don't support FOLL_GET flag, so let's leave it
    for future development.
    
    Here is the reproducer:
    
      $ cat movepages.c
      #include <stdio.h>
      #include <stdlib.h>
      #include <numaif.h>
    
      #define ADDR_INPUT      0x700000000000UL
      #define HPS             0x200000
      #define PS              0x1000
    
      int main(int argc, char *argv[]) {
              int i;
              int nr_hp = strtol(argv[1], NULL, 0);
              int nr_p  = nr_hp * HPS / PS;
              int ret;
              void **addrs;
              int *status;
              int *nodes;
              pid_t pid;
    
              pid = strtol(argv[2], NULL, 0);
              addrs  = malloc(sizeof(char *) * nr_p + 1);
              status = malloc(sizeof(char *) * nr_p + 1);
              nodes  = malloc(sizeof(char *) * nr_p + 1);
    
              while (1) {
                      for (i = 0; i < nr_p; i++) {
                              addrs[i] = (void *)ADDR_INPUT + i * PS;
                              nodes[i] = 1;
                              status[i] = 0;
                      }
                      ret = numa_move_pages(pid, nr_p, addrs, nodes, status,
                                            MPOL_MF_MOVE_ALL);
                      if (ret == -1)
                              err("move_pages");
    
                      for (i = 0; i < nr_p; i++) {
                              addrs[i] = (void *)ADDR_INPUT + i * PS;
                              nodes[i] = 0;
                              status[i] = 0;
                      }
                      ret = numa_move_pages(pid, nr_p, addrs, nodes, status,
                                            MPOL_MF_MOVE_ALL);
                      if (ret == -1)
                              err("move_pages");
              }
              return 0;
      }
    
      $ cat hugepage.c
      #include <stdio.h>
      #include <sys/mman.h>
      #include <string.h>
    
      #define ADDR_INPUT      0x700000000000UL
      #define HPS             0x200000
    
      int main(int argc, char *argv[]) {
              int nr_hp = strtol(argv[1], NULL, 0);
              char *p;
    
              while (1) {
                      p = mmap((void *)ADDR_INPUT, nr_hp * HPS, PROT_READ | PROT_WRITE,
                               MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);
                      if (p != (void *)ADDR_INPUT) {
                              perror("mmap");
                              break;
                      }
                      memset(p, 0, nr_hp * HPS);
                      munmap(p, nr_hp * HPS);
              }
      }
    
      $ sysctl vm.nr_hugepages=40
      $ ./hugepage 10 &
      $ ./movepages 10 $(pgrep -f hugepage)
    
    Fixes: e632a938d914 ("mm: migrate: add hugepage migration code to move_pages()")
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Reported-by: Hugh Dickins <hughd@google.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Luiz Capitulino <lcapitulino@redhat.com>
    Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
    Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    Cc: <stable@vger.kernel.org>	[3.12+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz> [backport to 3.12]

commit a59e2c71bf4901512137c9aaf88d2a95961577e1
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Feb 11 15:25:15 2015 -0800

    mm/hugetlb: reduce arch dependent code around follow_huge_*
    
    commit 61f77eda9bbf0d2e922197ed2dcf88638a639ce5 upstream.
    
    Currently we have many duplicates in definitions around
    follow_huge_addr(), follow_huge_pmd(), and follow_huge_pud(), so this
    patch tries to remove the m.  The basic idea is to put the default
    implementation for these functions in mm/hugetlb.c as weak symbols
    (regardless of CONFIG_ARCH_WANT_GENERAL_HUGETL B), and to implement
    arch-specific code only when the arch needs it.
    
    For follow_huge_addr(), only powerpc and ia64 have their own
    implementation, and in all other architectures this function just returns
    ERR_PTR(-EINVAL).  So this patch sets returning ERR_PTR(-EINVAL) as
    default.
    
    As for follow_huge_(pmd|pud)(), if (pmd|pud)_huge() is implemented to
    always return 0 in your architecture (like in ia64 or sparc,) it's never
    called (the callsite is optimized away) no matter how implemented it is.
    So in such architectures, we don't need arch-specific implementation.
    
    In some architecture (like mips, s390 and tile,) their current
    arch-specific follow_huge_(pmd|pud)() are effectively identical with the
    common code, so this patch lets these architecture use the common code.
    
    One exception is metag, where pmd_huge() could return non-zero but it
    expects follow_huge_pmd() to always return NULL.  This means that we need
    arch-specific implementation which returns NULL.  This behavior looks
    strange to me (because non-zero pmd_huge() implies that the architecture
    supports PMD-based hugepage, so follow_huge_pmd() can/should return some
    relevant value,) but that's beyond this cleanup patch, so let's keep it.
    
    Justification of non-trivial changes:
    - in s390, follow_huge_pmd() checks !MACHINE_HAS_HPAGE at first, and this
      patch removes the check. This is OK because we can assume MACHINE_HAS_HPAGE
      is true when follow_huge_pmd() can be called (note that pmd_huge() has
      the same check and always returns 0 for !MACHINE_HAS_HPAGE.)
    - in s390 and mips, we use HPAGE_MASK instead of PMD_MASK as done in common
      code. This patch forces these archs use PMD_MASK, but it's OK because
      they are identical in both archs.
      In s390, both of HPAGE_SHIFT and PMD_SHIFT are 20.
      In mips, HPAGE_SHIFT is defined as (PAGE_SHIFT + PAGE_SHIFT - 3) and
      PMD_SHIFT is define as (PAGE_SHIFT + PAGE_SHIFT + PTE_ORDER - 3), but
      PTE_ORDER is always 0, so these are identical.
    
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Luiz Capitulino <lcapitulino@redhat.com>
    Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
    Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c534e72c27be7fd23ec15d5080244b0acceb24a9
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Thu Feb 12 15:00:25 2015 -0800

    mm: hwpoison: drop lru_add_drain_all() in __soft_offline_page()
    
    commit 9ab3b598d2dfbdb0153ffa7e4b1456bbff59a25d upstream.
    
    A race condition starts to be visible in recent mmotm, where a PG_hwpoison
    flag is set on a migration source page *before* it's back in buddy page
    poo= l.
    
    This is problematic because no page flag is supposed to be set when
    freeing (see __free_one_page().) So the user-visible effect of this race
    is that it could trigger the BUG_ON() when soft-offlining is called.
    
    The root cause is that we call lru_add_drain_all() to make sure that the
    page is in buddy, but that doesn't work because this function just
    schedule= s a work item and doesn't wait its completion.
    drain_all_pages() does drainin= g directly, so simply dropping
    lru_add_drain_all() solves this problem.
    
    Fixes: f15bdfa802bf ("mm/memory-failure.c: fix memory leak in successful soft offlining")
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Chen Gong <gong.chen@linux.intel.com>
    Cc: <stable@vger.kernel.org>	[3.11+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7a9e5752e88d6f6aedf3052857f398298df9c0ed
Author: Oliver Neukum <oneukum@suse.de>
Date:   Mon Nov 17 17:11:42 2014 +0100

    HID: yet another buggy ELAN touchscreen
    
    commit a32c99e7ab8410bae7c276a7e94ca84d108de034 upstream.
    
    The touchscreen needs the same quirk as the other models.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Reported-by: Bryan Poling <poli0048@umn.edu>
    CC: stable@vger.kernel.org
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit db08039a5f60e9584aba28b8e35f9496134337da
Author: Adel Gadllah <adel.gadllah@gmail.com>
Date:   Fri Oct 31 18:11:25 2014 +0100

    HID: usbhid: enable always-poll quirk for Elan Touchscreen 0103
    
    commit fa51ee1085d6f2fa344d4ba64faadc9c6db0a3f1 upstream.
    
    Yet another device that needs this quirk.
    
    Reported-by: Tanguy de Baritault <tdebaritault@gmail.com>
    Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6e182925c59eb33f03256e9d89cd859f33ef67fd
Author: Oliver Neukum <oneukum@suse.de>
Date:   Tue Sep 30 12:54:56 2014 +0200

    HID: usbhid: add another mouse that needs QUIRK_ALWAYS_POLL
    
    commit 5235166fbc332c8b5dcf49e3a498a8b510a77449 upstream.
    
    There is a second mouse sharing the same vendor strings but different IDs.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4e1ef112bcdc34d314811f15d92c3d81f30d7181
Author: Oliver Neukum <oneukum@suse.de>
Date:   Mon Sep 8 11:21:49 2014 +0200

    HID: usbhid: fix PIXART optical mouse
    
    commit 4980f95755e2966b30ac70d1841f4db66d1a8a22 upstream.
    
    This mouse keeps disconnecting in runlevel 3. It needs the ALWAYS_POLL quirk.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b53b30a957e1f52f6f11f1c9ebeb6f005bee3169
Author: Jakub Sitnicki <jsitnicki@gmail.com>
Date:   Sat Feb 21 20:51:08 2015 +0100

    HID: microsoft: Add ID for NE7K wireless keyboard
    
    commit ef567cf9ddb682dbfa840bf4a2600931299f9555 upstream.
    
    Microsoft Natural Wireless Ergonomic Keyboard 7000 has special My
    Favorites 1..5 keys which are handled through a vendor-defined usage
    page (0xff05).
    
    Apply MS_ERGONOMY quirks handling to USB PID 0x071d (Microsoft Microsoft
    2.4GHz Transceiver V1.0) so that the My Favorites 1..5 keys are reported
    as KEY_F14..18 events.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=52841
    Signed-off-by: Jakub Sitnicki <jsitnicki@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dc9d0f676e3722772d07b2d39f333ba313ea4862
Author: Oliver Neukum <oneukum@suse.de>
Date:   Mon Oct 27 14:53:29 2014 +0100

    xhci: no switching back on non-ULT Haswell
    
    commit b45abacde3d551c6696c6738bef4a1805d0bf27a upstream.
    
    The switch back is limited to ULT even on HP. The contrary
    finding arose by bad luck in BIOS versions for testing.
    This fixes spontaneous resume from S3 on some HP laptops.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3619496bb338a99a26b3943d919443176db7b7f1
Author: Mitko Haralanov <mitko.haralanov@intel.com>
Date:   Fri Jan 16 08:55:27 2015 -0500

    IB/qib: Do not write EEPROM
    
    commit 18c0b82a3e4501511b08d0e8676fb08ac08734a3 upstream.
    
    This changeset removes all the code that allows the driver to write to
    the EEPROM and update the recorded error counters and power on hours.
    
    These two stats are unused and writing them exposes a timing risk
    which could leave the EEPROM in a bad state preventing further normal
    operation of the HCA.
    
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Mitko Haralanov <mitko.haralanov@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7e5e1899efa4ff0380ed1bfce4c2025855da42cf
Author: Tony Battersby <tonyb@cybernetics.com>
Date:   Wed Feb 11 11:32:06 2015 -0500

    sg: fix read() error reporting
    
    commit 3b524a683af8991b4eab4182b947c65f0ce1421b upstream.
    
    Fix SCSI generic read() incorrectly returning success after detecting an
    error.
    
    Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cbe3fbcd4681ae3e69170f7213cee083575228e0
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Feb 19 13:01:37 2015 +0100

    ALSA: hda - Add pin configs for ASUS mobo with IDT 92HD73XX codec
    
    commit 6426460e5d87810e042962281fe3c1e8fc256162 upstream.
    
    BIOS doesn't seem to set up pins for 5.1 and the SPDIF out, so we need
    to give explicitly here.
    
    Reported-and-tested-by: Misan Thropos <misanthropos@gmx.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f9b3a7f0ee758aeacb05ce3dd42dc9675e14b5e7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Dec 18 10:02:41 2014 +0100

    ALSA: pcm: Don't leave PREPARED state after draining
    
    commit 70372a7566b5e552dbe48abdac08c275081d8558 upstream.
    
    When a PCM draining is performed to an empty stream that has been
    already in PREPARED state, the current code just ignores and leaves as
    it is, although the drain is supposed to set all such streams to SETUP
    state.  This patch covers that overlooked case.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d7e3ae47c441894b11dce376ff8d110780872d0d
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Jan 29 02:50:33 2015 +0000

    splice: Apply generic position and size checks to each write
    
    We need to check the position and size of file writes against various
    limits, using generic_write_check().  This was not being done for
    the splice write path.  It was fixed upstream by commit 8d0207652cbe
    ("->splice_write() via ->write_iter()") but we can't apply that.
    
    CVE-2014-7822
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [ kamal: port to 3.13-stable: context ]
    Signed-off-by: Kamal Mostafa <kamal@canonical.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 43bf73e12b705c424066670eda35a5677ae72a13
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jan 29 11:15:17 2015 -0800

    vm: make stack guard page errors return VM_FAULT_SIGSEGV rather than SIGBUS
    
    commit 9c145c56d0c8a0b62e48c8d71e055ad0fb2012ba upstream.
    
    The stack guard page error case has long incorrectly caused a SIGBUS
    rather than a SIGSEGV, but nobody actually noticed until commit
    fee7e49d4514 ("mm: propagate error from stack expansion even for guard
    page") because that error case was never actually triggered in any
    normal situations.
    
    Now that we actually report the error, people noticed the wrong signal
    that resulted.  So far, only the test suite of libsigsegv seems to have
    actually cared, but there are real applications that use libsigsegv, so
    let's not wait for any of those to break.
    
    Reported-and-tested-by: Takashi Iwai <tiwai@suse.de>
    Tested-by: Jan Engelhardt <jengelh@inai.de>
    Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
    Cc: linux-arch@vger.kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 077138613c32e2739bda7c0dc35199879d34b51c
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu Jan 29 19:15:33 2015 -0800

    arc: mm: Fix build failure
    
    commit e262eb9381ad51b5de7a9e762ee773bbd25ce650 upstream.
    
    Fix misspelled define.
    
    Fixes: 33692f27597f ("vm: add VM_FAULT_SIGSEGV handling support")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1868445f57222c177ff2b3ea31f002c1b7eabb08
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jan 29 10:51:32 2015 -0800

    vm: add VM_FAULT_SIGSEGV handling support
    
    commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream.
    
    The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
    "you should SIGSEGV" error, because the SIGSEGV case was generally
    handled by the caller - usually the architecture fault handler.
    
    That results in lots of duplication - all the architecture fault
    handlers end up doing very similar "look up vma, check permissions, do
    retries etc" - but it generally works.  However, there are cases where
    the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.
    
    In particular, when accessing the stack guard page, libsigsegv expects a
    SIGSEGV.  And it usually got one, because the stack growth is handled by
    that duplicated architecture fault handler.
    
    However, when the generic VM layer started propagating the error return
    from the stack expansion in commit fee7e49d4514 ("mm: propagate error
    from stack expansion even for guard page"), that now exposed the
    existing VM_FAULT_SIGBUS result to user space.  And user space really
    expected SIGSEGV, not SIGBUS.
    
    To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
    duplicate architecture fault handlers about it.  They all already have
    the code to handle SIGSEGV, so it's about just tying that new return
    value to the existing code, but it's all a bit annoying.
    
    This is the mindless minimal patch to do this.  A more extensive patch
    would be to try to gather up the mostly shared fault handling logic into
    one generic helper routine, and long-term we really should do that
    cleanup.
    
    Just from this patch, you can generally see that most architectures just
    copied (directly or indirectly) the old x86 way of doing things, but in
    the meantime that original x86 model has been improved to hold the VM
    semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
    "newer" things, so it would be a good idea to bring all those
    improvements to the generic case and teach other architectures about
    them too.
    
    Reported-and-tested-by: Takashi Iwai <tiwai@suse.de>
    Tested-by: Jan Engelhardt <jengelh@inai.de>
    Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
    Cc: linux-arch@vger.kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7c5c89acd372a0354e47e8f94d4e1f6f721ef632
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Dec 15 14:46:06 2014 -0800

    x86: mm: move mmap_sem unlock from mm_fault_error() to caller
    
    commit 7fb08eca45270d0ae86e1ad9d39c40b7a55d0190 upstream.
    
    This replaces four copies in various stages of mm_fault_error() handling
    with just a single one.  It will also allow for more natural placement
    of the unlocking after some further cleanup.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e3bc11535cdd5e26a162dbc280c2e062b7749254
Author: Björn Gerhart <oss@airbjorn.de>
Date:   Wed Feb 18 07:19:44 2015 +0100

    cdc-acm: Add support for Denso cradle CU-321
    
    commit b20b1618b8fca858c83e52da4aa22cd6b13b0359 upstream.
    
    In order to support an older USB cradle by Denso, I added its vendor- and product-ID to the array of usb_device_id acm_ids. In this way cdc-acm feels responsible for this cradle. The related /dev/ttyACM node is being created properly, and the data transfer works.
    
    However, later cradle models by Denso do have proper descriptors, so the patch is not required for these. At the same time both the older and the later model have the same vendor- and product-ID, but they both work with the patched driver.
    
    Declaration of the Denso cradles I tested:
    - both models have the same IDs: vendorID 0x076d, productID 0x0006
    - older model: Denso CU-321 (descriptors not properly set)
    - later model: Denso CU-821 (with proper descriptors)
    
    Signed-off-by: Bjoern Gerhart <oss@airbjorn.de>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 95353e3525c5eb75881dc4ab7690541fb2c1776e
Author: Felipe Balbi <balbi@ti.com>
Date:   Mon Feb 2 17:12:00 2015 -0600

    usb: musb: core: add pm_runtime_irq_safe()
    
    commit 3e43a0725637299a14369e3ef109c25a8ec5c008 upstream.
    
    We need a pm_runtime_get_sync() call from
    within musb_gadget_pullup() to make sure
    registers are accessible at that time.
    
    The problem is that musb_gadget_pullup() is
    called with IRQs disabled and, because of that,
    we need to tell pm_runtime that this pm_runtime_get_sync()
    is IRQ safe.
    
    We can simply add pm_runtime_irq_safe(), however, because
    we need to make our read/write accessor function pointers
    have been initialized before trying to use them. This means
    that all pm_runtime initialization for musb_core needs to
    be moved down so that when we call pm_runtime_irq_safe(),
    the pm_runtime_get_sync() that it calls on the parent, won't
    cause a crash due to NULL musb_read/write accessors.
    
    Reported-by: Pali Rohár <pali.rohar@gmail.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2019319b6ab967b7c3de01472b3feca251976cf7
Author: Felipe Balbi <balbi@ti.com>
Date:   Mon Feb 2 16:24:17 2015 -0600

    usb: gadget: function: phonet: balance usb_ep_disable calls
    
    commit 9ec36f7fe20ef919cc15171e1da1b6739222541a upstream.
    
    f_phonet's ->set_alt() method will call usb_ep_disable()
    potentially on an endpoint which is already disabled. That's
    something the gadget/function driver must guarantee that it's
    always balanced.
    
    In order to balance the calls, just make sure the endpoint
    was enabled before by means of checking the validity of
    driver_data.
    
    Reported-by: Pali Rohár <pali.rohar@gmail.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 476b1ec9fb4ab2f34b6bea7b6d6011d24f094597
Author: Anton Staaf <robotboy@chromium.org>
Date:   Mon Nov 3 08:43:20 2014 -0800

    USB: serial: add Google simple serial SubClass support
    
    commit 679315e5fae1e4614eed0d9aa26999ddcb6a0f77 upstream.
    
    Add support for Google devices that export simple serial
    interfaces using the vendor specific SubClass/Protocol pair
    0x50/0x01.
    
    Signed-off-by: Anton Staaf <robotboy@chromium.org>
    Reviewed-by: Benson Leung <bleung@chromium.org>
    [johan: move id entries and update Kconfig]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8a4eb1f9e832f49960f2db50ccadcdaf081b0987
Author: Alan Wu <alan.c.wu@gmail.com>
Date:   Tue Jan 6 18:32:51 2015 -0800

    HID: microsoft: add support for Japanese Surface Type Cover 3
    
    commit 5e7e9e90b5867a3754159a8ce524299d930fbac8 upstream.
    
    Based on code for the US Surface Type Cover 3
    from commit be3b16341d5cd8cf2a64fcc7a604a8efe6599ff0
    ("HID: add support for MS Surface Pro 3 Type Cover"):
    
    Signed-off-by: Alan Wu <alan.c.wu@gmail.com>
    Tested-by: Karlis Dreizis <karlisdreizis@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6e6b7a8537deb017faa49263781c64eed9df568b
Author: Alan Wu <alan.c.wu@gmail.com>
Date:   Mon Nov 3 18:26:12 2014 -0800

    HID: add support for MS Surface Pro 3 Type Cover
    
    commit be3b16341d5cd8cf2a64fcc7a604a8efe6599ff0 upstream.
    
    Surface Pro 3 Type Cover that works with Ubuntu (and possibly Arch) from this thread. Both trackpad and keyboard work after compiling my own kernel.
    http://ubuntuforums.org/showthread.php?t=2231207&page=2&s=44910e0c56047e4f93dfd9fea58121ef
    
    Also includes Jarrad Whitaker's message which sources
    http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/
    which he says is sourced from a Russian site
    
    Signed-off-by: Alan Wu <alan.c.wu@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3d6797beb662c2e3ac9156b4ce114a2160a225d9
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Jan 29 17:57:43 2014 +0100

    HID: hid-microsoft: Add support for scrollwheel and special keypad keys
    
    commit 3faed1aff786a007b3ea0549ac469e09f48c98f9 upstream.
    
    The Microsoft Office keyboard has a scrollwheel as well as some special keys
    above the keypad which are handled through the custom MS usage page, this
    commit adds support for these.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c8b25999b7bc6a212e8cf0ba5b74f8f8a803da8e
Author: Jim Keir <jimkeir@oracledbadirect.com>
Date:   Fri Jan 23 17:21:12 2015 +0000

    HID: pidff: Fix initialisation forMicrosoft Sidewinder FF Pro 2
    
    commit afd700d933963d07391e3e3dfbfbc05e905960ef upstream.
    
    The FF2 driver (usbhid/hid-pidff.c) sends commands to the stick during ff_init.
    However, this is called inside a block where driver_input_lock is locked, so
    the results of these initial commands are discarded. This behavior is the
    "killer", without this nothing else works.
    
    ff_init issues commands using "hid_hw_request". This eventually goes to
    hid_input_report, which returns -EBUSY because driver_input_lock is locked. The
    change is to delay the ff_init call in hid-core.c until after this lock has
    been released.
    
    Calling hid_device_io_start() releases the lock so the device can be
    configured.  We also need to call hid_device_io_stop() on exit for the lock to
    remain locked while ending the init of the drivers.
    
    [ benjamin.tissoires@redhat.com: imrpoved the changelog a lot ]
    
    Signed-off-by: Jim Keir <jimkeir@oracledbadirect.com>
    Reviewed-by: Benjamin.tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0bea50e7e8d938b0bbf6f7b4e1772f3849f300f3
Author: Ross Skaliotis <rskaliotis@gmail.com>
Date:   Sat Dec 20 19:01:35 2014 -0500

    HID: apple: fix battery support for the 2009 ANSI wireless keyboard
    
    commit cbd366bea2b8513bc0fc1c9e8832cb0ab221d6d5 upstream.
    
    Enabled quirks necessary for correct battery capacity reporting. Cleaned up
    surrounding style.
    
    Signed-off-by: Ross Skaliotis <rskaliotis@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c4772e573e71e266a5f7ea0f7bb870a2490c4e5c
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Feb 27 18:40:31 2015 +0100

    tty: fix up atime/mtime mess, take four
    
    commit f0bf0bd07943bfde8f5ac39a32664810a379c7d3 upstream.
    
    This problem was taken care of three times already in
    * b0de59b5733d18b0d1974a060860a8b5c1b36a2e (TTY: do not update
      atime/mtime on read/write),
    * 37b7f3c76595e23257f61bd80b223de8658617ee (TTY: fix atime/mtime
      regression), and
    * b0b885657b6c8ef63a46bc9299b2a7715d19acde (tty: fix up atime/mtime
      mess, take three)
    
    But it still misses one point. As John Paul correctly points out, we
    do not care about setting date. If somebody ever changes wall
    time backwards (by mistake for example), tty timestamps are never
    updated until the original wall time passes.
    
    So check the absolute difference of times and if it large than "8
    seconds or so", always update the time. That means we will update
    immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the
    check, but it was always that way.
    
    Thanks John for serving me this so nicely debugged.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Reported-by: John Paul Perry <john_paul.perry@alcatel-lucent.com>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 47746745842f8dab521acf532b9972aaff146666
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Fri Feb 27 10:39:17 2015 +0530

    ARC: Fix KSTK_ESP()
    
    commit 13648b0118a24f4fc76c34e6c7b6ccf447e46a2a upstream.
    
    /proc/<pid>/maps currently don't annotate stack vma with "[stack]"
    This is because KSTK_ESP ie expected to return usermode SP of tsk while
    currently it returns the kernel mode SP of a sleeping tsk.
    
    While the fix is trivial, we also need to adjust the ARC kernel stack
    unwinder to not use KSTK_SP and friends any more.
    
    Reported-and-suggested-by: Alexey Brodkin <abrodkin@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit eeb8704af25a6aed534292510da02bcfefb4bf77
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Sat Mar 7 21:08:46 2015 +0000

    sunrpc: fix braino in ->poll()
    
    commit 1711fd9addf214823b993468567cab1f8254fc51 upstream.
    
    POLL_OUT isn't what callers of ->poll() are expecting to see; it's
    actually __SI_POLL | 2 and it's a siginfo code, not a poll bitmap
    bit...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Bruce Fields <bfields@fieldses.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 147e702ad9582b4dae6241952ac19cf174b59695
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Feb 21 22:16:11 2015 -0500

    procfs: fix race between symlink removals and traversals
    
    commit 7e0e953bb0cf649f93277ac8fb67ecbb7f7b04a9 upstream.
    
    use_pde()/unuse_pde() in ->follow_link()/->put_link() resp.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f2331a68c372ea4c53e9d4aa7cda7631f8ce60fb
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Feb 21 22:05:11 2015 -0500

    debugfs: leave freeing a symlink body until inode eviction
    
    commit 0db59e59299f0b67450c5db21f7f316c8fb04e84 upstream.
    
    As it is, we have debugfs_remove() racing with symlink traversals.
    Supply ->evict_inode() and do freeing there - inode will remain
    pinned until we are done with the symlink body.
    
    And rip the idiocy with checking if dentry is positive right after
    we'd verified debugfs_positive(), which is a stronger check...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fde713210941cb25defa34a7f48f2c3e1b7ac10d
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Feb 21 22:19:57 2015 -0500

    autofs4 copy_dev_ioctl(): keep the value of ->size we'd used for allocation
    
    commit 0a280962dc6e117e0e4baa668453f753579265d9 upstream.
    
    X-Coverup: just ask spender
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c37650731ba0255f4f8af11e4a6be982e1c7ff6f
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Feb 18 10:34:51 2015 +0700

    USB: serial: fix tty-device error handling at probe
    
    commit ca4383a3947a83286bc9b9c598a1f55e867871d7 upstream.
    
    Add missing error handling when registering the tty device at port
    probe. This avoids trying to remove an uninitialised character device
    when the port device is removed.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Greg Kroah-Hartman <greg@kroah.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 63953db3a9758add929a797d61f76450a9117624
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Feb 18 10:34:50 2015 +0700

    USB: serial: fix potential use-after-free after failed probe
    
    commit 07fdfc5e9f1c966be8722e8fa927e5ea140df5ce upstream.
    
    Fix return value in probe error path, which could end up returning
    success (0) on errors. This could in turn lead to use-after-free or
    double free (e.g. in port_remove) when the port device is removed.
    
    Fixes: c706ebdfc895 ("USB: usb-serial: call port_probe and port_remove
    at the right times")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Greg Kroah-Hartman <greg@kroah.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9bfa61c9a592d7d843878854a1327fd6f5432b2a
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Mar 4 10:39:06 2015 +0100

    TTY: fix tty_wait_until_sent on 64-bit machines
    
    commit 79fbf4a550ed6a22e1ae1516113e6c7fa5d56a53 upstream.
    
    Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an
    infinite timeout (0) would be passed to the underlying tty-driver's
    wait_until_sent-operation as a negative timeout (-1), causing it to
    return immediately.
    
    This manifests itself for example as tcdrain() returning immediately,
    drivers not honouring the drain flags when setting terminal attributes,
    or even dropped data on close as a requested infinite closing-wait
    timeout would be ignored.
    
    The first symptom  was reported by Asier LLANO who noted that tcdrain()
    returned prematurely when using the ftdi_sio usb-serial driver.
    
    Fix this by passing 0 rather than MAX_SCHEDULE_TIMEOUT (LONG_MAX) to the
    underlying tty driver.
    
    Note that the serial-core wait_until_sent-implementation is not affected
    by this bug due to a lucky chance (comparison to an unsigned maximum
    timeout), and neither is the cyclades one that had an explicit check for
    negative timeouts, but all other tty drivers appear to be affected.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: ZIV-Asier Llano Palacios <asier.llano@cgglobal.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6fc812b4806b3b74ddcd4bf5b3c7dde56cedb339
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Mar 4 10:39:05 2015 +0100

    USB: serial: fix infinite wait_until_sent timeout
    
    commit f528bf4f57e43d1af4b2a5c97f09e43e0338c105 upstream.
    
    Make sure to handle an infinite timeout (0).
    
    Note that wait_until_sent is currently never called with a 0-timeout
    argument due to a bug in tty_wait_until_sent.
    
    Fixes: dcf010503966 ("USB: serial: add generic wait_until_sent
    implementation")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a1f8771268c3d717c5c67caa69b43ddd94a98142
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Mar 4 10:39:03 2015 +0100

    net: irda: fix wait_until_sent poll timeout
    
    commit 2c3fbe3cf28fbd7001545a92a83b4f8acfd9fa36 upstream.
    
    In case an infinite timeout (0) is requested, the irda wait_until_sent
    implementation would use a zero poll timeout rather than the default
    200ms.
    
    Note that wait_until_sent is currently never called with a 0-timeout
    argument due to a bug in tty_wait_until_sent.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit af1fe3c6f09ca298aa73b171f671ffbf2321c8cb
Author: Jouni Malinen <jouni@qca.qualcomm.com>
Date:   Thu Feb 26 15:50:50 2015 +0200

    mac80211: Send EAPOL frames at lowest rate
    
    commit 9c1c98a3bb7b7593b60264b9a07e001e68b46697 upstream.
    
    The current minstrel_ht rate control behavior is somewhat optimistic in
    trying to find optimum TX rate. While this is usually fine for normal
    Data frames, there are cases where a more conservative set of retry
    parameters would be beneficial to make the connection more robust.
    
    EAPOL frames are critical to the authentication and especially the
    EAPOL-Key message 4/4 (the last message in the 4-way handshake) is
    important to get through to the AP. If that message is lost, the only
    recovery mechanism in many cases is to reassociate with the AP and start
    from scratch. This can often be avoided by trying to send the frame with
    more conservative rate and/or with more link layer retries.
    
    In most cases, minstrel_ht is currently using the initial EAPOL-Key
    frames for probing higher rates and this results in only five link layer
    transmission attempts (one at high(ish) MCS and four at MCS0). While
    this works with most APs, it looks like there are some deployed APs that
    may have issues with the EAPOL frames using HT MCS immediately after
    association. Similarly, there may be issues in cases where the signal
    strength or radio environment is not good enough to be able to get
    frames through even at couple of MCS 0 tries.
    
    The best approach for this would likely to be to reduce the TX rate for
    the last rate (3rd rate parameter in the set) to a low basic rate (say,
    6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly
    requires some more effort. For now, we can start with a simple one-liner
    that forces the minimum rate to be used for EAPOL frames similarly how
    the TX rate is selected for the IEEE 802.11 Management frames. This does
    result in a small extra latency added to the cases where the AP would be
    able to receive the higher rate, but taken into account how small number
    of EAPOL frames are used, this is likely to be insignificant. A future
    optimization in the minstrel_ht design can also allow this patch to be
    reverted to get back to the more optimized initial TX rate.
    
    It should also be noted that many drivers that do not use minstrel as
    the rate control algorithm are already doing similar workarounds by
    forcing the lowest TX rate to be used for EAPOL frames.
    
    Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
    Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f2a7b61c4d10ebf1ce21287d2ba28f3f88618d74
Author: Aleksander Morgado <aleksander@aleksander.es>
Date:   Fri Mar 6 17:14:21 2015 +0200

    xhci: fix reporting of 0-sized URBs in control endpoint
    
    commit 45ba2154d12fc43b70312198ec47085f10be801a upstream.
    
    When a control transfer has a short data stage, the xHCI controller generates
    two transfer events: a COMP_SHORT_TX event that specifies the untransferred
    amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
    COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to
    urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless
    urb->actual_length was set already by a previous COMP_SHORT_TX event.
    
    The driver checks this by seeing whether urb->actual_length == 0, but this alone
    is the wrong test, as it is entirely possible for a short transfer to have an
    urb->actual_length = 0.
    
    This patch changes the xhci driver to rely on a new td->urb_length_set flag,
    which is set to true when a COMP_SHORT_TX event is received and the URB length
    updated at that stage.
    
    This fixes a bug which affected the HSO plugin, which relies on URBs with
    urb->actual_length == 0 to halt re-submitting the RX URB in the control
    endpoint.
    
    Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bbadcecc9b8e3e120c1240d64e44683c39e32872
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Feb 24 18:27:01 2015 +0200

    xhci: Allocate correct amount of scratchpad buffers
    
    commit 6596a926b0b6c80b730a1dd2fa91908e0a539c37 upstream.
    
    Include the high order bit fields for Max scratchpad buffers when
    calculating how many scratchpad buffers are needed.
    
    I'm suprised this hasn't caused more issues, we never allocated more than
    32 buffers even if xhci needed more. Either we got lucky and xhci never
    really used past that area, or then we got enough zeroed dma memory anyway.
    
    Should be backported as far back as possible
    
    Reported-by: Tim Chen <tim.c.chen@linux.intel.com>
    Tested-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 660c8a7287d9b825ff2893418cfb7cd48fe0ac06
Author: George Cherian <george.cherian@ti.com>
Date:   Fri Feb 13 10:13:24 2015 +0530

    usb: dwc3: dwc3-omap: Fix disable IRQ
    
    commit 96e5d31244c5542f5b2ea81d76f14ba4b8a7d440 upstream.
    
    In the wrapper the IRQ disable should be done by writing 1's to the
    IRQ*_CLR register. Existing code is broken because it instead writes
    zeros to IRQ*_SET register.
    
    Fix this by adding functions dwc3_omap_write_irqmisc_clr() and
    dwc3_omap_write_irq0_clr() which do the right thing.
    
    Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
    Signed-off-by: George Cherian <george.cherian@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 349fbd792cfa0849b61d87344f2c5fe5935b03be
Author: Max Mansfield <max.m.mansfield@gmail.com>
Date:   Mon Mar 2 18:38:02 2015 -0700

    usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards
    
    commit c7d373c3f0da2b2b78c4b1ce5ae41485b3ef848c upstream.
    
    This patch integrates Cyber Cortex AV boards with the existing
    ftdi_jtag_quirk in order to use serial port 0 with JTAG which is
    required by the manufacturers' software.
    
    Steps: 2
    
    [ftdi_sio_ids.h]
    1. Defined the device PID
    
    [ftdi_sio.c]
    2. Added a macro declaration to the ids array, in order to enable the
    jtag quirk for the device.
    
    Signed-off-by: Max Mansfield <max.m.mansfield@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2576c7db7e0e77419cfe2a6bcf6eac75bd456e67
Author: Mark Glover <mark@actisense.com>
Date:   Fri Feb 13 09:04:39 2015 +0000

    USB: ftdi_sio: add PIDs for Actisense USB devices
    
    commit f6950344d3cf4a1e231b5828b50c4ac168db3886 upstream.
    
    These product identifiers (PID) all deal with marine NMEA format data
    used on motor boats and yachts. We supply the programmed devices to
    Chetco, for use inside their equipment. The PIDs are a direct copy of
    our Windows device drivers (FTDI drivers with altered PIDs).
    
    Signed-off-by: Mark Glover <mark@actisense.com>
    [johan: edit commit message slightly ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 17671b2fbcf11e9d101cc028335ca1a5e77e569f
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Feb 13 10:54:53 2015 -0500

    USB: usbfs: don't leak kernel data in siginfo
    
    commit f0c2b68198589249afd2b1f2c4e8de8c03e19c16 upstream.
    
    When a signal is delivered, the information in the siginfo structure
    is copied to userspace.  Good security practice dicatates that the
    unused fields in this structure should be initialized to 0 so that
    random kernel stack data isn't exposed to the user.  This patch adds
    such an initialization to the two places where usbfs raises signals.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Dave Mielke <dave@mielke.cc>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a8e488401bd772a41726f1280cf3cce556d165ba
Author: Michiel vd Garde <mgparser@gmail.com>
Date:   Fri Feb 27 02:08:29 2015 +0100

    USB: serial: cp210x: Adding Seletek device id's
    
    commit 675af70856d7cc026be8b6ea7a8b9db10b8b38a1 upstream.
    
    These device ID's are not associated with the cp210x module currently,
    but should be. This patch allows the devices to operate upon connecting
    them to the usb bus as intended.
    
    Signed-off-by: Michiel van de Garde <mgparser@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f14b3c6a641171aa18b98597ef6d4eb5015d0b8a
Author: James Hogan <james.hogan@imgtec.com>
Date:   Tue Feb 24 11:46:20 2015 +0000

    KVM: MIPS: Fix trace event to save PC directly
    
    commit b3cffac04eca9af46e1e23560a8ee22b1bd36d43 upstream.
    
    Currently the guest exit trace event saves the VCPU pointer to the
    structure, and the guest PC is retrieved by dereferencing it when the
    event is printed rather than directly from the trace record. This isn't
    safe as the printing may occur long afterwards, after the PC has changed
    and potentially after the VCPU has been freed. Usually this results in
    the same (wrong) PC being printed for multiple trace events. It also
    isn't portable as userland has no way to access the VCPU data structure
    when interpreting the trace record itself.
    
    Lets save the actual PC in the structure so that the correct value is
    accessible later.
    
    Fixes: 669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: linux-mips@linux-mips.org
    Cc: kvm@vger.kernel.org
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6dd5cd79363d7aa0031e421b2909ed189e90ac2d
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Feb 12 17:04:47 2015 +0100

    KVM: emulate: fix CMPXCHG8B on 32-bit hosts
    
    commit 4ff6f8e61eb7f96d3ca535c6d240f863ccd6fb7d upstream.
    
    This has been broken for a long time: it broke first in 2.6.35, then was
    almost fixed in 2.6.36 but this one-liner slipped through the cracks.
    The bug shows up as an infinite loop in Windows 7 (and newer) boot on
    32-bit hosts without EPT.
    
    Windows uses CMPXCHG8B to write to page tables, which causes a
    page fault if running without EPT; the emulator is then called from
    kvm_mmu_page_fault.  The loop then happens if the higher 4 bytes are
    not 0; the common case for this is that the NX bit (bit 63) is 1.
    
    Fixes: 6550e1f165f384f3a46b60a1be9aba4bc3c2adad
    Fixes: 16518d5ada690643453eb0aef3cc7841d3623c2d
    Reported-by: Erik Rull <erik.rull@rdsoftware.de>
    Tested-by: Erik Rull <erik.rull@rdsoftware.de>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 377121bbc802ab818dcb028547e5c4440006f15f
Author: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Date:   Tue Mar 3 16:31:38 2015 +0100

    Btrfs:__add_inode_ref: out of bounds memory read when looking for extended ref.
    
    commit dd9ef135e3542ffc621c4eb7f0091870ec7a1504 upstream.
    
    Improper arithmetics when calculting the address of the extended ref could
    lead to an out of bounds memory read and kernel panic.
    
    Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cf21763462327a33d67d9225561958d170a8a4da
Author: Filipe Manana <fdmanana@suse.com>
Date:   Sun Mar 1 20:36:00 2015 +0000

    Btrfs: fix data loss in the fast fsync path
    
    commit 3a8b36f378060d20062a0918e99fae39ff077bf0 upstream.
    
    When using the fast file fsync code path we can miss the fact that new
    writes happened since the last file fsync and therefore return without
    waiting for the IO to finish and write the new extents to the fsync log.
    
    Here's an example scenario where the fsync will miss the fact that new
    file data exists that wasn't yet durably persisted:
    
    1. fs_info->last_trans_committed == N - 1 and current transaction is
       transaction N (fs_info->generation == N);
    
    2. do a buffered write;
    
    3. fsync our inode, this clears our inode's full sync flag, starts
       an ordered extent and waits for it to complete - when it completes
       at btrfs_finish_ordered_io(), the inode's last_trans is set to the
       value N (via btrfs_update_inode_fallback -> btrfs_update_inode ->
       btrfs_set_inode_last_trans);
    
    4. transaction N is committed, so fs_info->last_trans_committed is now
       set to the value N and fs_info->generation remains with the value N;
    
    5. do another buffered write, when this happens btrfs_file_write_iter
       sets our inode's last_trans to the value N + 1 (that is
       fs_info->generation + 1 == N + 1);
    
    6. transaction N + 1 is started and fs_info->generation now has the
       value N + 1;
    
    7. transaction N + 1 is committed, so fs_info->last_trans_committed
       is set to the value N + 1;
    
    8. fsync our inode - because it doesn't have the full sync flag set,
       we only start the ordered extent, we don't wait for it to complete
       (only in a later phase) therefore its last_trans field has the
       value N + 1 set previously by btrfs_file_write_iter(), and so we
       have:
    
           inode->last_trans <= fs_info->last_trans_committed
               (N + 1)              (N + 1)
    
       Which made us not log the last buffered write and exit the fsync
       handler immediately, returning success (0) to user space and resulting
       in data loss after a crash.
    
    This can actually be triggered deterministically and the following excerpt
    from a testcase I made for xfstests triggers the issue. It moves a dummy
    file across directories and then fsyncs the old parent directory - this
    is just to trigger a transaction commit, so moving files around isn't
    directly related to the issue but it was chosen because running 'sync' for
    example does more than just committing the current transaction, as it
    flushes/waits for all file data to be persisted. The issue can also happen
    at random periods, since the transaction kthread periodicaly commits the
    current transaction (about every 30 seconds by default).
    The body of the test is:
    
      _scratch_mkfs >> $seqres.full 2>&1
      _init_flakey
      _mount_flakey
    
      # Create our main test file 'foo', the one we check for data loss.
      # By doing an fsync against our file, it makes btrfs clear the 'needs_full_sync'
      # bit from its flags (btrfs inode specific flags).
      $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 8K" \
                      -c "fsync" $SCRATCH_MNT/foo | _filter_xfs_io
    
      # Now create one other file and 2 directories. We will move this second file
      # from one directory to the other later because it forces btrfs to commit its
      # currently open transaction if we fsync the old parent directory. This is
      # necessary to trigger the data loss bug that affected btrfs.
      mkdir $SCRATCH_MNT/testdir_1
      touch $SCRATCH_MNT/testdir_1/bar
      mkdir $SCRATCH_MNT/testdir_2
    
      # Make sure everything is durably persisted.
      sync
    
      # Write more 8Kb of data to our file.
      $XFS_IO_PROG -c "pwrite -S 0xbb 8K 8K" $SCRATCH_MNT/foo | _filter_xfs_io
    
      # Move our 'bar' file into a new directory.
      mv $SCRATCH_MNT/testdir_1/bar $SCRATCH_MNT/testdir_2/bar
    
      # Fsync our first directory. Because it had a file moved into some other
      # directory, this made btrfs commit the currently open transaction. This is
      # a condition necessary to trigger the data loss bug.
      $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir_1
    
      # Now fsync our main test file. If the fsync succeeds, we expect the 8Kb of
      # data we wrote previously to be persisted and available if a crash happens.
      # This did not happen with btrfs, because of the transaction commit that
      # happened when we fsynced the parent directory.
      $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo
    
      # Simulate a crash/power loss.
      _load_flakey_table $FLAKEY_DROP_WRITES
      _unmount_flakey
    
      _load_flakey_table $FLAKEY_ALLOW_WRITES
      _mount_flakey
    
      # Now check that all data we wrote before are available.
      echo "File content after log replay:"
      od -t x1 $SCRATCH_MNT/foo
    
      status=0
      exit
    
    The expected golden output for the test, which is what we get with this
    fix applied (or when running against ext3/4 and xfs), is:
    
      wrote 8192/8192 bytes at offset 0
      XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
      wrote 8192/8192 bytes at offset 8192
      XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
      File content after log replay:
      0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
      *
      0020000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
      *
      0040000
    
    Without this fix applied, the output shows the test file does not have
    the second 8Kb extent that we successfully fsynced:
    
      wrote 8192/8192 bytes at offset 0
      XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
      wrote 8192/8192 bytes at offset 8192
      XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
      File content after log replay:
      0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
      *
      0020000
    
    So fix this by skipping the fsync only if we're doing a full sync and
    if the inode's last_trans is <= fs_info->last_trans_committed, or if
    the inode is already in the log. Also remove setting the inode's
    last_trans in btrfs_file_write_iter since it's useless/unreliable.
    
    Also because btrfs_file_write_iter no longer sets inode->last_trans to
    fs_info->generation + 1, don't set last_trans to 0 if we bail out and don't
    bail out if last_trans is 0, otherwise something as simple as the following
    example wouldn't log the second write on the last fsync:
    
      1. write to file
    
      2. fsync file
    
      3. fsync file
           |--> btrfs_inode_in_log() returns true and it set last_trans to 0
    
      4. write to file
           |--> btrfs_file_write_iter() no longers sets last_trans, so it
                remained with a value of 0
      5. fsync
           |--> inode->last_trans == 0, so it bails out without logging the
                second write
    
    A test case for xfstests will be sent soon.
    
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3caad0eda3f36aadd1be4655d431814d2c0b21f7
Author: David Sterba <dsterba@suse.cz>
Date:   Tue Feb 24 18:57:18 2015 +0100

    btrfs: fix lost return value due to variable shadowing
    
    commit 1932b7be973b554ffe20a5bba6ffaed6fa995cdc upstream.
    
    A block-local variable stores error code but btrfs_get_blocks_direct may
    not return it in the end as there's a ret defined in the function scope.
    
    Fixes: d187663ef24c ("Btrfs: lock extents as we map them in DIO")
    Signed-off-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8607e6ba3f48a3bab9476c5afd2e3913387eadd7
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Tue Feb 10 10:36:36 2015 +0200

    mei: make device disabled on stop unconditionally
    
    commit 6c15a8516b8118eb19a59fd0bd22df41b9101c32 upstream.
    
    Set the internal device state to to disabled after hardware reset in stop flow.
    This will cover cases when driver was not brought to disabled state because of
    an error and in stop flow we wish not to retry the reset.
    
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 182830fede67ba3d9f6d52f68dca839bb2118b32
Author: Urs Fässler <urs.fassler@bytesatwork.ch>
Date:   Mon Feb 2 17:12:23 2015 +0100

    iio: ad5686: fix optional reference voltage declaration
    
    commit da019f59cb16570e78feaf10380ac65a3a06861e upstream.
    
    When not using the "_optional" function, a dummy regulator is returned
    and the driver fails to initialize.
    
    Signed-off-by: Urs Fässler <urs.fassler@bytesatwork.ch>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dac99fda24486fa218175047fad75cfa3b2234be
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Fri Jan 23 00:34:02 2015 +0100

    iio: imu: adis16400: Fix sign extension
    
    commit 19e353f2b344ad86cea6ebbc0002e5f903480a90 upstream.
    
    The intention is obviously to sign-extend a 12 bit quantity. But
    because of C's promotion rules, the assignment is equivalent to "val16
    &= 0xfff;". Use the proper API for this.
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 93ba6108cd76089d6ae16abec65ade5b11546d76
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Mar 5 01:09:44 2015 +0100

    x86/asm/entry/64: Remove a bogus 'ret_from_fork' optimization
    
    commit 956421fbb74c3a6261903f3836c0740187cf038b upstream.
    
    'ret_from_fork' checks TIF_IA32 to determine whether 'pt_regs' and
    the related state make sense for 'ret_from_sys_call'.  This is
    entirely the wrong check.  TS_COMPAT would make a little more
    sense, but there's really no point in keeping this optimization
    at all.
    
    This fixes a return to the wrong user CS if we came from int
    0x80 in a 64-bit task.
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/4710be56d76ef994ddf59087aad98c000fbab9a4.1424989793.git.luto@amacapital.net
    [ Backported from tip:x86/asm. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 14ee62dd93f3dd27d8c9d300ba59a91708ba9f33
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Fri Feb 13 22:27:40 2015 +0000

    target: Check for LBA + sectors wrap-around in sbc_parse_cdb
    
    commit aa179935edea9a64dec4b757090c8106a3907ffa upstream.
    
    This patch adds a check to sbc_parse_cdb() in order to detect when
    an LBA + sector vs. end-of-device calculation wraps when the LBA is
    sufficently large enough (eg: 0xFFFFFFFFFFFFFFFF).
    
    Cc: Martin Petersen <martin.petersen@oracle.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dffc0bca5ea9b1ae646fb8fc7c82ca179a866b09
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Fri Feb 13 22:09:47 2015 +0000

    target: Add missing WRITE_SAME end-of-device sanity check
    
    commit 8e575c50a171f2579e367a7f778f86477dfdaf49 upstream.
    
    This patch adds a check to sbc_setup_write_same() to verify
    the incoming WRITE_SAME LBA + number of blocks does not exceed
    past the end-of-device.
    
    Also check for potential LBA wrap-around as well.
    
    Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Cc: Martin Petersen <martin.petersen@oracle.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b18b42fe0a23ff7607cfec88ede23a57e53bec66
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Feb 11 18:34:40 2015 -0800

    target: Fix PR_APTPL_BUF_LEN buffer size limitation
    
    commit f161d4b44d7cc1dc66b53365215227db356378b1 upstream.
    
    This patch addresses the original PR_APTPL_BUF_LEN = 8k limitiation
    for write-out of PR APTPL metadata that Martin has recently been
    running into.
    
    It changes core_scsi3_update_and_write_aptpl() to use vzalloc'ed
    memory instead of kzalloc, and increases the default hardcoded
    length to 256k.
    
    It also adds logic in core_scsi3_update_and_write_aptpl() to double
    the original length upon core_scsi3_update_aptpl_buf() failure, and
    retries until the vzalloc'ed buffer is large enough to accommodate
    the outgoing APTPL metadata.
    
    Reported-by: Martin Svec <martin.svec@zoner.cz>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cfa1450a6d7f9a841b77b7411c5a9787b6ba7f6e
Author: Christian König <christian.koenig@amd.com>
Date:   Tue Feb 10 14:26:39 2015 +0100

    drm/radeon: workaround for CP HW bug on CIK
    
    commit a9c73a0e022c33954835e66fec3cd744af90ec98 upstream.
    
    Emit the EOP twice to avoid cache flushing problems.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ccc0896442c154ce52bf8e125579d5f66faa9a61
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Feb 6 12:53:27 2015 -0500

    drm/radeon: only enable kv/kb dpm interrupts once v3
    
    commit 410af8d7285a0b96314845c75c39fd612b755688 upstream.
    
    Enable at init and disable on fini. Workaround for hardware problems.
    
    v2 (chk): extend commit message
    v3: add new function
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com> (v2)
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 970970dcb4fca4fdcbb1b9bf4d7cd686796dc9d6
Author: Grazvydas Ignotas <notasas@gmail.com>
Date:   Thu Feb 12 15:00:19 2015 -0800

    mm/memory.c: actually remap enough memory
    
    commit 9cb12d7b4ccaa976f97ce0c5fd0f1b6a83bc2a75 upstream.
    
    For whatever reason, generic_access_phys() only remaps one page, but
    actually allows to access arbitrary size.  It's quite easy to trigger
    large reads, like printing out large structure with gdb, which leads to a
    crash.  Fix it by remapping correct size.
    
    Fixes: 28b2ee20c7cb ("access_process_vm device memory infrastructure")
    Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
    Cc: Rik van Riel <riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5a9653fda3cf02a4bd51dae5c64b7bf94363fcae
Author: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Date:   Thu Feb 12 14:59:50 2015 -0800

    mm/compaction: fix wrong order check in compact_finished()
    
    commit 372549c2a3778fd3df445819811c944ad54609ca upstream.
    
    What we want to check here is whether there is highorder freepage in buddy
    list of other migratetype in order to steal it without fragmentation.
    But, current code just checks cc->order which means allocation request
    order.  So, this is wrong.
    
    Without this fix, non-movable synchronous compaction below pageblock order
    would not stopped until compaction is complete, because migratetype of
    most pageblocks are movable and high order freepage made by compaction is
    usually on movable type buddy list.
    
    There is some report related to this bug. See below link.
    
      http://www.spinics.net/lists/linux-mm/msg81666.html
    
    Although the issued system still has load spike comes from compaction,
    this makes that system completely stable and responsive according to his
    report.
    
    stress-highalloc test in mmtests with non movable order 7 allocation
    doesn't show any notable difference in allocation success rate, but, it
    shows more compaction success rate.
    
    Compaction success rate (Compaction success * 100 / Compaction stalls, %)
    18.47 : 28.94
    
    Fixes: 1fb3f8ca0e92 ("mm: compaction: capture a suitable high-order page immediately when it is made available")
    Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Rik van Riel <riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 56ade69589c4c04442f103b1f0d5305851c3071b
Author: Roman Gushchin <klamm@yandex-team.ru>
Date:   Wed Feb 11 15:28:42 2015 -0800

    mm/nommu.c: fix arithmetic overflow in __vm_enough_memory()
    
    commit 8138a67a5557ffea3a21dfd6f037842d4e748513 upstream.
    
    I noticed that "allowed" can easily overflow by falling below 0, because
    (total_vm / 32) can be larger than "allowed".  The problem occurs in
    OVERCOMMIT_NONE mode.
    
    In this case, a huge allocation can success and overcommit the system
    (despite OVERCOMMIT_NONE mode).  All subsequent allocations will fall
    (system-wide), so system become unusable.
    
    The problem was masked out by commit c9b1d0981fcc
    ("mm: limit growth of 3% hardcoded other user reserve"),
    but it's easy to reproduce it on older kernels:
    1) set overcommit_memory sysctl to 2
    2) mmap() large file multiple times (with VM_SHARED flag)
    3) try to malloc() large amount of memory
    
    It also can be reproduced on newer kernels, but miss-configured
    sysctl_user_reserve_kbytes is required.
    
    Fix this issue by switching to signed arithmetic here.
    
    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Cc: Andrew Shewmaker <agshew@gmail.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit da94166fe7c52b887b4c185c365a38daa3a9c7fe
Author: Roman Gushchin <klamm@yandex-team.ru>
Date:   Wed Feb 11 15:28:39 2015 -0800

    mm/mmap.c: fix arithmetic overflow in __vm_enough_memory()
    
    commit 5703b087dc8eaf47bfb399d6cf512d471beff405 upstream.
    
    I noticed, that "allowed" can easily overflow by falling below 0,
    because (total_vm / 32) can be larger than "allowed".  The problem
    occurs in OVERCOMMIT_NONE mode.
    
    In this case, a huge allocation can success and overcommit the system
    (despite OVERCOMMIT_NONE mode).  All subsequent allocations will fall
    (system-wide), so system become unusable.
    
    The problem was masked out by commit c9b1d0981fcc
    ("mm: limit growth of 3% hardcoded other user reserve"),
    but it's easy to reproduce it on older kernels:
    1) set overcommit_memory sysctl to 2
    2) mmap() large file multiple times (with VM_SHARED flag)
    3) try to malloc() large amount of memory
    
    It also can be reproduced on newer kernels, but miss-configured
    sysctl_user_reserve_kbytes is required.
    
    Fix this issue by switching to signed arithmetic here.
    
    [akpm@linux-foundation.org: use min_t]
    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Cc: Andrew Shewmaker <agshew@gmail.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a6b3222b0d5e27b115596bae24f0a91dec6eb19c
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Feb 11 15:25:32 2015 -0800

    mm/hugetlb: add migration entry check in __unmap_hugepage_range
    
    commit 9fbc1f635fd0bd28cb32550211bf095753ac637a upstream.
    
    If __unmap_hugepage_range() tries to unmap the address range over which
    hugepage migration is on the way, we get the wrong page because pte_page()
    doesn't work for migration entries.  This patch simply clears the pte for
    migration entries as we do for hwpoison entries.
    
    Fixes: 290408d4a2 ("hugetlb: hugepage migration core")
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Luiz Capitulino <lcapitulino@redhat.com>
    Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
    Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ea47f0342b5cdfd3dfbce2a8b85a9d82a0614ef2
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Feb 11 15:25:28 2015 -0800

    mm/hugetlb: add migration/hwpoisoned entry check in hugetlb_change_protection
    
    commit a8bda28d87c38c6aa93de28ba5d30cc18e865a11 upstream.
    
    There is a race condition between hugepage migration and
    change_protection(), where hugetlb_change_protection() doesn't care about
    migration entries and wrongly overwrites them.  That causes unexpected
    results like kernel crash.  HWPoison entries also can cause the same
    problem.
    
    This patch adds is_hugetlb_entry_(migration|hwpoisoned) check in this
    function to do proper actions.
    
    Fixes: 290408d4a2 ("hugetlb: hugepage migration core")
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Luiz Capitulino <lcapitulino@redhat.com>
    Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
    Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c272044a55e2df31b31952149f71294615d7e1c3
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Wed Mar 4 08:36:31 2015 +0100

    team: don't traverse port list using rcu in team_set_mac_address
    
    [ Upstream commit 9215f437b85da339a7dfe3db6e288637406f88b2 ]
    
    Currently the list is traversed using rcu variant. That is not correct
    since dev_set_mac_address can be called which eventually calls
    rtmsg_ifinfo_build_skb and there, skb allocation can sleep. So fix this
    by remove the rcu usage here.
    
    Fixes: 3d249d4ca7 "net: introduce ethernet teaming device"
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7a763ff1bb18190791d0823996ba0a039268d2cf
Author: Lorenzo Colitti <lorenzo@google.com>
Date:   Tue Mar 3 23:16:16 2015 +0900

    net: ping: Return EAFNOSUPPORT when appropriate.
    
    [ Upstream commit 9145736d4862145684009d6a72a6e61324a9439e ]
    
    1. For an IPv4 ping socket, ping_check_bind_addr does not check
       the family of the socket address that's passed in. Instead,
       make it behave like inet_bind, which enforces either that the
       address family is AF_INET, or that the family is AF_UNSPEC and
       the address is 0.0.0.0.
    2. For an IPv6 ping socket, ping_check_bind_addr returns EINVAL
       if the socket family is not AF_INET6. Return EAFNOSUPPORT
       instead, for consistency with inet6_bind.
    3. Make ping_v4_sendmsg and ping_v6_sendmsg return EAFNOSUPPORT
       instead of EINVAL if an incorrect socket address structure is
       passed in.
    4. Make IPv6 ping sockets be IPv6-only. The code does not support
       IPv4, and it cannot easily be made to support IPv4 because
       the protocol numbers for ICMP and ICMPv6 are different. This
       makes connect(::ffff:192.0.2.1) fail with EAFNOSUPPORT instead
       of making the socket unusable.
    
    Among other things, this fixes an oops that can be triggered by:
    
        int s = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP);
        struct sockaddr_in6 sin6 = {
            .sin6_family = AF_INET6,
            .sin6_addr = in6addr_any,
        };
        bind(s, (struct sockaddr *) &sin6, sizeof(sin6));
    
    Change-Id: If06ca86d9f1e4593c0d6df174caca3487c57a241
    Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4f9586428f533c47478f73cfedbc13f0610b2db9
Author: Michal Kubeček <mkubecek@suse.cz>
Date:   Mon Mar 2 18:27:11 2015 +0100

    udp: only allow UFO for packets from SOCK_DGRAM sockets
    
    [ Upstream commit acf8dd0a9d0b9e4cdb597c2f74802f79c699e802 ]
    
    If an over-MTU UDP datagram is sent through a SOCK_RAW socket to a
    UFO-capable device, ip_ufo_append_data() sets skb->ip_summed to
    CHECKSUM_PARTIAL unconditionally as all GSO code assumes transport layer
    checksum is to be computed on segmentation. However, in this case,
    skb->csum_start and skb->csum_offset are never set as raw socket
    transmit path bypasses udp_send_skb() where they are usually set. As a
    result, driver may access invalid memory when trying to calculate the
    checksum and store the result (as observed in virtio_net driver).
    
    Moreover, the very idea of modifying the userspace provided UDP header
    is IMHO against raw socket semantics (I wasn't able to find a document
    clearly stating this or the opposite, though). And while allowing
    CHECKSUM_NONE in the UFO case would be more efficient, it would be a bit
    too intrusive change just to handle a corner case like this. Therefore
    disallowing UFO for packets from SOCK_DGRAM seems to be the best option.
    
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b207adc1d085769c9cee16925bc2d7827bcc4a94
Author: Ben Shelton <ben.shelton@ni.com>
Date:   Mon Feb 16 13:47:06 2015 -0600

    usb: plusb: Add support for National Instruments host-to-host cable
    
    [ Upstream commit 42c972a1f390e3bc51ca1e434b7e28764992067f ]
    
    The National Instruments USB Host-to-Host Cable is based on the Prolific
    PL-25A1 chipset.  Add its VID/PID so the plusb driver will recognize it.
    
    Signed-off-by: Ben Shelton <ben.shelton@ni.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2b6de7d31c8dab3c4e2b0c0883fb19d27ce73ebb
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 27 18:35:35 2015 -0800

    macvtap: make sure neighbour code can push ethernet header
    
    [ Upstream commit 2f1d8b9e8afa5a833d96afcd23abcb8cdf8d83ab ]
    
    Brian reported crashes using IPv6 traffic with macvtap/veth combo.
    
    I tracked the crashes in neigh_hh_output()
    
    -> memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD);
    
    Neighbour code assumes headroom to push Ethernet header is
    at least 16 bytes.
    
    It appears macvtap has only 14 bytes available on arches
    where NET_IP_ALIGN is 0 (like x86)
    
    Effect is a corruption of 2 bytes right before skb->head,
    and possible crashes if accessing non existing memory.
    
    This fix should also increase IPv4 performance, as paranoid code
    in ip_finish_output2() wont have to call skb_realloc_headroom()
    
    Reported-by: Brian Rak <brak@vultr.com>
    Tested-by: Brian Rak <brak@vultr.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a835f60198e521de246a585cc81a5719a9a86ece
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Mon Feb 23 18:12:56 2015 +0000

    net: compat: Ignore MSG_CMSG_COMPAT in compat_sys_{send, recv}msg
    
    [ Upstream commit d720d8cec563ce4e4fa44a613d4f2dcb1caf2998 ]
    
    With commit a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg), the
    MSG_CMSG_COMPAT flag is blocked at the compat syscall entry points,
    changing the kernel compat behaviour from the one before the commit it
    was trying to fix (1be374a0518a, net: Block MSG_CMSG_COMPAT in
    send(m)msg and recv(m)msg).
    
    On 32-bit kernels (!CONFIG_COMPAT), MSG_CMSG_COMPAT is 0 and the native
    32-bit sys_sendmsg() allows flag 0x80000000 to be set (it is ignored by
    the kernel). However, on a 64-bit kernel, the compat ABI is different
    with commit a7526eb5d06b.
    
    This patch changes the compat_sys_{send,recv}msg behaviour to the one
    prior to commit 1be374a0518a.
    
    The problem was found running 32-bit LTP (sendmsg01) binary on an arm64
    kernel. Arguably, LTP should not pass 0xffffffff as flags to sendmsg()
    but the general rule is not to break user ABI (even when the user
    behaviour is not entirely sane).
    
    Fixes: a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg)
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7002744d6901a227687196cd1ea12307ea163253
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Mon Feb 23 14:02:54 2015 +0100

    team: fix possible null pointer dereference in team_handle_frame
    
    [ Upstream commit 57e595631904c827cfa1a0f7bbd7cc9a49da5745 ]
    
    Currently following race is possible in team:
    
    CPU0                                        CPU1
                                                team_port_del
                                                  team_upper_dev_unlink
                                                    priv_flags &= ~IFF_TEAM_PORT
    team_handle_frame
      team_port_get_rcu
        team_port_exists
          priv_flags & IFF_TEAM_PORT == 0
        return NULL (instead of port got
                     from rx_handler_data)
                                                  netdev_rx_handler_unregister
    
    The thing is that the flag is removed before rx_handler is unregistered.
    If team_handle_frame is called in between, team_port_exists returns 0
    and team_port_get_rcu will return NULL.
    So do not check the flag here. It is guaranteed by netdev_rx_handler_unregister
    that team_handle_frame will always see valid rx_handler_data pointer.
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit eb83542b81fa8bdbc20a0e69edafedce19aeaaf5
Author: Matthew Thode <mthode@mthode.org>
Date:   Tue Feb 17 18:31:57 2015 -0600

    net: reject creation of netdev names with colons
    
    [ Upstream commit a4176a9391868bfa87705bcd2e3b49e9b9dd2996 ]
    
    colons are used as a separator in netdev device lookup in dev_ioctl.c
    
    Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME
    
    Signed-off-by: Matthew Thode <mthode@mthode.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c07c93a6bac93cca369ecbaf655bf3bb9926d10f
Author: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Date:   Tue Feb 17 20:15:20 2015 +0100

    ematch: Fix auto-loading of ematch modules.
    
    [ Upstream commit 34eea79e2664b314cab6a30fc582fdfa7a1bb1df ]
    
    In tcf_em_validate(), after calling request_module() to load the
    kind-specific module, set em->ops to NULL before returning -EAGAIN, so
    that module_put() is not called again by tcf_em_tree_destroy().
    
    Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
    Acked-by: Cong Wang <cwang@twopensource.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c83355ce6fdafb24031c7032ee011ad4d7f2ca9c
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Feb 17 09:36:22 2015 -0800

    net: phy: Fix verification of EEE support in phy_init_eee
    
    [ Upstream commit 54da5a8be3c1e924c35480eb44c6e9b275f6444e ]
    
    phy_init_eee uses phy_find_setting(phydev->speed, phydev->duplex)
    to find a valid entry in the settings array for the given speed
    and duplex value. For full duplex 1000baseT, this will return
    the first matching entry, which is the entry for 1000baseKX_Full.
    
    If the phy eee does not support 1000baseKX_Full, this entry will not
    match, causing phy_init_eee to fail for no good reason.
    
    Fixes: 9a9c56cb34e6 ("net: phy: fix a bug when verify the EEE support")
    Fixes: 3e7077067e80c ("phy: Expand phy speed/duplex settings array")
    Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a930d60b78912c6aba1a4c17aab752850b4883bd
Author: Alexander Drozdov <al.drozdov@gmail.com>
Date:   Thu Mar 5 10:29:39 2015 +0300

    ipv4: ip_check_defrag should not assume that skb_network_offset is zero
    
    [ Upstream commit 3e32e733d1bbb3f227259dc782ef01d5706bdae0 ]
    
    ip_check_defrag() may be used by af_packet to defragment outgoing packets.
    skb_network_offset() of af_packet's outgoing packets is not zero.
    
    Signed-off-by: Alexander Drozdov <al.drozdov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c0c6450b332d51df46cbe3a697991e42e7460a2e
Author: Alexander Drozdov <al.drozdov@gmail.com>
Date:   Tue Feb 17 13:33:46 2015 +0300

    ipv4: ip_check_defrag should correctly check return value of skb_copy_bits
    
    [ Upstream commit fba04a9e0c869498889b6445fd06cbe7da9bb834 ]
    
    skb_copy_bits() returns zero on success and negative value on error,
    so it is needed to invert the condition in ip_check_defrag().
    
    Fixes: 1bf3751ec90c ("ipv4: ip_check_defrag must not modify skb before unsharing")
    Signed-off-by: Alexander Drozdov <al.drozdov@gmail.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 85320d5deb74d8cdb05082a84ef8d13812c0ea9f
Author: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Date:   Fri Feb 13 14:47:05 2015 -0800

    gen_stats.c: Duplicate xstats buffer for later use
    
    [ Upstream commit 1c4cff0cf55011792125b6041bc4e9713e46240f ]
    
    The gnet_stats_copy_app() function gets called, more often than not, with its
    second argument a pointer to an automatic variable in the caller's stack.
    Therefore, to avoid copying garbage afterwards when calling
    gnet_stats_finish_copy(), this data is better copied to a dynamically allocated
    memory that gets freed after use.
    
    [xiyou.wangcong@gmail.com: remove a useless kfree()]
    
    Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4e522af0f15f3c2f63b789c0a6e6008eeb8f42b3
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Fri Feb 13 13:56:53 2015 -0800

    rtnetlink: call ->dellink on failure when ->newlink exists
    
    [ Upstream commit 7afb8886a05be68e376655539a064ec672de8a8e ]
    
    Ignacy reported that when eth0 is down and add a vlan device
    on top of it like:
    
      ip link add link eth0 name eth0.1 up type vlan id 1
    
    We will get a refcount leak:
    
      unregister_netdevice: waiting for eth0.1 to become free. Usage count = 2
    
    The problem is when rtnl_configure_link() fails in rtnl_newlink(),
    we simply call unregister_device(), but for stacked device like vlan,
    we almost do nothing when we unregister the upper device, more work
    is done when we unregister the lower device, so call its ->dellink().
    
    Reported-by: Ignacy Gawedzki <ignacy.gawedzki@green-communications.fr>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 818201d39770dbb7ec90c6f10bcdc3bf889362a5
Author: Martin KaFai Lau <kafai@fb.com>
Date:   Thu Feb 12 16:14:08 2015 -0800

    ipv6: fix ipv6_cow_metrics for non DST_HOST case
    
    [ Upstream commit 3b4711757d7903ab6fa88a9e7ab8901b8227da60 ]
    
    ipv6_cow_metrics() currently assumes only DST_HOST routes require
    dynamic metrics allocation from inetpeer.  The assumption breaks
    when ndisc discovered router with RTAX_MTU and RTAX_HOPLIMIT metric.
    Refer to ndisc_router_discovery() in ndisc.c and note that dst_metric_set()
    is called after the route is created.
    
    This patch creates the metrics array (by calling dst_cow_metrics_generic) in
    ipv6_cow_metrics().
    
    Test:
    radvd.conf:
    interface qemubr0
    {
    	AdvLinkMTU 1300;
    	AdvCurHopLimit 30;
    
    	prefix fd00:face:face:face::/64
    	{
    		AdvOnLink on;
    		AdvAutonomous on;
    		AdvRouterAddr off;
    	};
    };
    
    Before:
    [root@qemu1 ~]# ip -6 r show | egrep -v unreachable
    fd00:face:face:face::/64 dev eth0  proto kernel  metric 256  expires 27sec
    fe80::/64 dev eth0  proto kernel  metric 256
    default via fe80::74df:d0ff:fe23:8ef2 dev eth0  proto ra  metric 1024  expires 27sec
    
    After:
    [root@qemu1 ~]# ip -6 r show | egrep -v unreachable
    fd00:face:face:face::/64 dev eth0  proto kernel  metric 256  expires 27sec mtu 1300
    fe80::/64 dev eth0  proto kernel  metric 256  mtu 1300
    default via fe80::74df:d0ff:fe23:8ef2 dev eth0  proto ra  metric 1024  expires 27sec mtu 1300 hoplimit 30
    
    Fixes: 8e2ec639173f325 (ipv6: don't use inetpeer to store metrics for routes.)
    Signed-off-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8847ac8980717c27ff7cfec617be1e2261f0a25f
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Thu Feb 5 18:44:04 2015 +0100

    rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY
    
    [ Upstream commit 364d5716a7adb91b731a35765d369602d68d2881 ]
    
    ifla_vf_policy[] is wrong in advertising its individual member types as
    NLA_BINARY since .type = NLA_BINARY in combination with .len declares the
    len member as *max* attribute length [0, len].
    
    The issue is that when do_setvfinfo() is being called to set up a VF
    through ndo handler, we could set corrupted data if the attribute length
    is less than the size of the related structure itself.
    
    The intent is exactly the opposite, namely to make sure to pass at least
    data of minimum size of len.
    
    Fixes: ebc08a6f47ee ("rtnetlink: Add VF config code to rtnetlink")
    Cc: Mitch Williams <mitch.a.williams@intel.com>
    Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7097d6432409cef7ad4996e580eff45025183c99
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Wed Feb 4 23:08:50 2015 +0100

    pktgen: fix UDP checksum computation
    
    [ Upstream commit 7744b5f3693cc06695cb9d6667671c790282730f ]
    
    This patch fixes two issues in UDP checksum computation in pktgen.
    
    First, the pseudo-header uses the source and destination IP
    addresses. Currently, the ports are used for IPv4.
    
    Second, the UDP checksum covers both header and data.  So we need to
    generate the data earlier (move pktgen_finalize_skb up), and compute
    the checksum for UDP header + data.
    
    Fixes: c26bf4a51308c ("pktgen: Add UDPCSUM flag to support UDP checksums")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Acked-by: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7baf34ccb79c727f55b41cc4e5f2bdb40dcf5010
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Mar 10 14:27:10 2015 +0100

    netfilter: xt_socket: fix a stack corruption bug
    
    [ upstream commit 78296c97ca1fd3b104f12e1f1fbc06c46635990b ]
    
    As soon as extract_icmp6_fields() returns, its local storage (automatic
    variables) is deallocated and can be overwritten.
    
    Lets add an additional parameter to make sure storage is valid long
    enough.
    
    While we are at it, adds some const qualifiers.
    
    Cc: <stable@vger.kernel.org> # 3.12.x
    Cc: <stable@vger.kernel.org> # 3.14.x
    Cc: <stable@vger.kernel.org> # 3.18.x
    Cc: <stable@vger.kernel.org> # 3.19.x
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Fixes: b64c9256a9b76 ("tproxy: added IPv6 support to the socket match")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c34a4c75777ab9354db9c2d2eb234ce87e45f0bf
Author: Julian Anastasov <ja@ssi.bg>
Date:   Tue Mar 10 14:27:05 2015 +0100

    ipvs: rerouting to local clients is not needed anymore
    
    [ upstream commit 579eb62ac35845686a7c4286c0a820b4eb1f96aa ]
    
    commit f5a41847acc5 ("ipvs: move ip_route_me_harder for ICMP")
    from 2.6.37 introduced ip_route_me_harder() call for responses to
    local clients, so that we can provide valid rt_src after SNAT.
    It was used by TCP to provide valid daddr for ip_send_reply().
    After commit 0a5ebb8000c5 ("ipv4: Pass explicit daddr arg to
    ip_send_reply()." from 3.0 this rerouting is not needed anymore
    and should be avoided, especially in LOCAL_IN.
    
    Fixes 3.12.33 crash in xfrm reported by Florian Wiessner:
    "3.12.33 - BUG xfrm_selector_match+0x25/0x2f6"
    
    Cc: <stable@vger.kernel.org> # 3.10.x
    Cc: <stable@vger.kernel.org> # 3.12.x
    Cc: <stable@vger.kernel.org> # 3.14.x
    Cc: <stable@vger.kernel.org> # 3.18.x
    Reported-by: Smart Weblications GmbH - Florian Wiessner <f.wiessner@smart-weblications.de>
    Tested-by: Smart Weblications GmbH - Florian Wiessner <f.wiessner@smart-weblications.de>
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 43ef6dfb1464ed5d2a8e2473b6ad405feb10e2ca
Author: Julian Anastasov <ja@ssi.bg>
Date:   Tue Mar 10 14:27:11 2015 +0100

    ipvs: add missing ip_vs_pe_put in sync code
    
    [ upstream commit 528c943f3bb919aef75ab2fff4f00176f09a4019 ]
    
    ip_vs_conn_fill_param_sync() gets in param.pe a module
    reference for persistence engine from __ip_vs_pe_getbyname()
    but forgets to put it. Problem occurs in backup for
    sync protocol v1 (2.6.39).
    
    Also, pe_data usually comes in sync messages for
    connection templates and ip_vs_conn_new() copies
    the pointer only in this case. Make sure pe_data
    is not leaked if it comes unexpectedly for normal
    connections. Leak can happen only if bogus messages
    are sent to backup server.
    
    Fixes: fe5e7a1efb66 ("IPVS: Backup, Adding Version 1 receive capability")
    Cc: <stable@vger.kernel.org> # 3.10.x
    Cc: <stable@vger.kernel.org> # 3.12.x
    Cc: <stable@vger.kernel.org> # 3.14.x
    Cc: <stable@vger.kernel.org> # 3.18.x
    Cc: <stable@vger.kernel.org> # 3.19.x
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4f877b0c89a891eaea726b7972217c8252b250c7
Author: James Hogan <james.hogan@imgtec.com>
Date:   Tue Feb 10 10:02:59 2015 +0000

    MIPS: Export FP functions used by lose_fpu(1) for KVM
    
    commit 3ce465e04bfd8de9956d515d6e9587faac3375dc upstream.
    
    Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
    modules so that KVM can make use of it when it is built as a module.
    
    This fixes the following build error when CONFIG_KVM=m due to commit
    f798217dfd03 ("KVM: MIPS: Don't leak FPU/DSP to guest"):
    
    ERROR: "_save_fp" [arch/mips/kvm/kvm.ko] undefined!
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest)
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Paul Burton <paul.burton@imgtec.com>
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: kvm@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/9260/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    [james.hogan@imgtec.com: Only export when CPU_R4K_FPU=y prior to v3.16,
     so as not to break the Octeon build which excludes FPU support. KVM
     depends on MIPS32r2 anyway.]
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8920e92c8062bb6ee89605a7b72ec9c466fde608
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Dec 4 10:22:57 2014 -0500

    USB: EHCI: adjust error return code
    
    commit c401e7b4a808d50ab53ef45cb8d0b99b238bf2c9 upstream.
    
    The USB stack uses error code -ENOSPC to indicate that the periodic
    schedule is too full, with insufficient bandwidth to accommodate a new
    allocation.  It uses -EFBIG to indicate that an isochronous transfer
    could not be linked into the schedule because it would exceed the
    number of isochronous packets the host controller driver can handle
    (generally because the new transfer would extend too far into the
    future).
    
    ehci-hcd uses the wrong error code at one point.  This patch fixes it,
    along with a misleading comment and debugging message.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5bebf22856156a533aa6a107385e17b1422dba2e
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Fri Feb 27 18:10:07 2015 +0000

    staging: comedi: cb_pcidas64: fix incorrect AI range code handling
    
    commit be8e89087ec2d2c8a1ad1e3db64bf4efdfc3c298 upstream.
    
    The hardware range code values and list of valid ranges for the AI
    subdevice is incorrect for several supported boards.  The hardware range
    code values for all boards except PCI-DAS4020/12 is determined by
    calling `ai_range_bits_6xxx()` based on the maximum voltage of the range
    and whether it is bipolar or unipolar, however it only returns the
    correct hardware range code for the PCI-DAS60xx boards.  For
    PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar
    ranges.  For PCI-DAS64/Mx/16 it returns the wrong code for all the
    ranges and the comedi range table is incorrect.
    
    Change `ai_range_bits_6xxx()` to use a look-up table pointed to by new
    member `ai_range_codes` of `struct pcidas64_board` to map the comedi
    range table indices to the hardware range codes.  Use a new comedi range
    table for the PCI-DAS64/Mx/16 boards (and the commented out variants).
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 52235599ac1399ae8e7fe3ffa4d19ff9a1ca1652
Author: Kalle Valo <kvalo@qca.qualcomm.com>
Date:   Tue Mar 11 12:58:00 2014 +0200

    ath6kl: fix struct hif_scatter_req list handling
    
    commit 31b9cc9a873dcab161999622314f98a75d838975 upstream.
    
    Jason noticed that with Yocto GCC 4.8.1 ath6kl crashes with this iperf command:
    
    iperf -c $TARGET_IP -i 5 -t 50 -w 1M
    
    The crash was:
    
    Unable to handle kernel paging request at virtual address 1a480000
    pgd = 80004000
    [1a480000] *pgd=00000000
    Internal error: Oops: 805 [#1] SMP ARM
    Modules linked in: ath6kl_sdio ath6kl_core [last unloaded: ath6kl_core]
    CPU: 0 PID: 1953 Comm: kworker/u4:0 Not tainted 3.10.9-1.0.0_alpha+dbf364b #1
    Workqueue: ath6kl ath6kl_sdio_write_async_work [ath6kl_sdio]
    task: dcc9a680 ti: dc9ae000 task.ti: dc9ae000
    PC is at v7_dma_clean_range+0x20/0x38
    LR is at dma_cache_maint_page+0x50/0x54
    pc : [<8001a6f8>]    lr : [<800170fc>]    psr: 20000093
    sp : dc9afcf8  ip : 8001a748  fp : 00000004
    r10: 00000000  r9 : 00000001  r8 : 00000000
    r7 : 00000001  r6 : 00000000  r5 : 80cb7000  r4 : 03f9a480
    r3 : 0000001f  r2 : 00000020  r1 : 1a480000  r0 : 1a480000
    Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
    Control: 10c53c7d  Table: 6cc5004a  DAC: 00000015
    Process kworker/u4:0 (pid: 1953, stack limit = 0xdc9ae238)
    Stack: (0xdc9afcf8 to 0xdc9b0000)
    fce0:                                                       80c9b29c 00000000
    fd00: 00000000 80017134 8001a748 dc302ac0 00000000 00000000 dc454a00 80c12ed8
    fd20: dc115410 80017238 00000000 dc454a10 00000001 80017588 00000001 00000000
    fd40: 00000000 dc302ac0 dc9afe38 dc9afe68 00000004 80c12ed8 00000000 dc454a00
    fd60: 00000004 80436f88 00000000 00000000 00000600 0000ffff 0000000c 80c113c4
    fd80: 80c9b29c 00000001 00000004 dc115470 60000013 dc302ac0 dc46e000 dc302800
    fda0: dc9afe10 dc302b78 60000013 dc302ac0 dc46e000 00000035 dc46e5b0 80438c90
    fdc0: dc9afe10 dc302800 dc302800 dc9afe68 dc9afe38 80424cb4 00000005 dc9afe10
    fde0: dc9afe20 80424de8 dc9afe10 dc302800 dc46e910 80424e90 dc473c00 dc454f00
    fe00: 000001b5 7f619d64 dcc7c830 00000000 00000000 dc9afe38 dc9afe68 00000000
    fe20: 00000000 00000000 dc9afe28 dc9afe28 80424d80 00000000 00000035 9cac0034
    fe40: 00000000 00000000 00000000 00000000 000001b5 00000000 00000000 00000000
    fe60: dc9afe68 dc9afe10 3b9aca00 00000000 00000080 00000034 00000000 00000100
    fe80: 00000000 00000000 dc9afe10 00000004 dc454a00 00000000 dc46e010 dc46e96c
    fea0: dc46e000 dc46e964 00200200 00100100 dc46e910 7f619ec0 00000600 80c0e770
    fec0: dc15a900 dcc7c838 00000000 dc46e954 8042d434 dcc44680 dc46e954 dc004400
    fee0: dc454500 00000000 00000000 dc9ae038 dc004400 8003c450 dcc44680 dc004414
    ff00: dc46e954 dc454500 00000001 dcc44680 dc004414 dcc44698 dc9ae000 dc9ae030
    ff20: 00000001 dc9ae000 dc004400 8003d158 8003d020 00000000 00000000 80c53941
    ff40: dc9aff64 dcb71ea0 00000000 dcc44680 8003d020 00000000 00000000 00000000
    ff60: 00000000 80042480 00000000 00000000 000000f8 dcc44680 00000000 00000000
    ff80: dc9aff80 dc9aff80 00000000 00000000 dc9aff90 dc9aff90 dc9affac dcb71ea0
    ffa0: 800423cc 00000000 00000000 8000e018 00000000 00000000 00000000 00000000
    ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
    [<8001a6f8>] (v7_dma_clean_range+0x20/0x38) from [<800170fc>] (dma_cache_maint_page+0x50/0x54)
    [<800170fc>] (dma_cache_maint_page+0x50/0x54) from [<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c)
    [<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c) from [<80017238>] (arm_dma_map_page+0x64/0x68)
    [<80017238>] (arm_dma_map_page+0x64/0x68) from [<80017588>] (arm_dma_map_sg+0x7c/0xf4)
    [<80017588>] (arm_dma_map_sg+0x7c/0xf4) from [<80436f88>] (sdhci_send_command+0x894/0xe00)
    [<80436f88>] (sdhci_send_command+0x894/0xe00) from [<80438c90>] (sdhci_request+0xc0/0x1ec)
    [<80438c90>] (sdhci_request+0xc0/0x1ec) from [<80424cb4>] (mmc_start_request+0xb8/0xd4)
    [<80424cb4>] (mmc_start_request+0xb8/0xd4) from [<80424de8>] (__mmc_start_req+0x60/0x84)
    [<80424de8>] (__mmc_start_req+0x60/0x84) from [<80424e90>] (mmc_wait_for_req+0x10/0x20)
    [<80424e90>] (mmc_wait_for_req+0x10/0x20) from [<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio])
    [<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) from [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio])
    [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) from [<8003c450>] (process_one_work+0x10c/0x370)
    [<8003c450>] (process_one_work+0x10c/0x370) from [<8003d158>] (worker_thread+0x138/0x3fc)
    [<8003d158>] (worker_thread+0x138/0x3fc) from [<80042480>] (kthread+0xb4/0xb8)
    [<80042480>] (kthread+0xb4/0xb8) from [<8000e018>] (ret_from_fork+0x14/0x3c)
    Code: e1a02312 e2423001 e1c00003 f57ff04f (ee070f3a)
    ---[ end trace 0c038f0b8e0b67a3 ]---
    Kernel panic - not syncing: Fatal exception
    
    Jason's analysis:
    
      "The GCC 4.8.1 compiler will not do the for-loop till scat_entries, instead,
       it only run one round loop. This may be caused by that the GCC 4.8.1 thought
       that the scat_list only have one item and then no need to do full iteration,
       but this is simply wrong by looking at the assebly code. This will cause the sg
       buffer not get set when scat_entries > 1 and thus lead to kernel panic.
    
       Note: This issue not observed with GCC 4.7.2, only found on the GCC 4.8.1)"
    
    Fix this by using the normal [0] style for defining unknown number of list
    entries following the struct. This also fixes corruption with scat_q_depth, which
    was mistankely added to the end of struct and overwritten if there were more
    than item in the scat list.
    
    Reported-by: Jason Liu <r64343@freescale.com>
    Tested-by: Jason Liu <r64343@freescale.com>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5fb6f0aa14db88c62ca141279ab71f20d6814788
Author: Hector Marco-Gisbert <hecmargi@upv.es>
Date:   Sat Feb 14 09:33:50 2015 -0800

    x86, mm/ASLR: Fix stack randomization on 64-bit systems
    
    commit 4e7c22d447bb6d7e37bfe39ff658486ae78e8d77 upstream.
    
    The issue is that the stack for processes is not properly randomized on
    64 bit architectures due to an integer overflow.
    
    The affected function is randomize_stack_top() in file
    "fs/binfmt_elf.c":
    
      static unsigned long randomize_stack_top(unsigned long stack_top)
      {
               unsigned int random_variable = 0;
    
               if ((current->flags & PF_RANDOMIZE) &&
                       !(current->personality & ADDR_NO_RANDOMIZE)) {
                       random_variable = get_random_int() & STACK_RND_MASK;
                       random_variable <<= PAGE_SHIFT;
               }
               return PAGE_ALIGN(stack_top) + random_variable;
               return PAGE_ALIGN(stack_top) - random_variable;
      }
    
    Note that, it declares the "random_variable" variable as "unsigned int".
    Since the result of the shifting operation between STACK_RND_MASK (which
    is 0x3fffff on x86_64, 22 bits) and PAGE_SHIFT (which is 12 on x86_64):
    
    	  random_variable <<= PAGE_SHIFT;
    
    then the two leftmost bits are dropped when storing the result in the
    "random_variable". This variable shall be at least 34 bits long to hold
    the (22+12) result.
    
    These two dropped bits have an impact on the entropy of process stack.
    Concretely, the total stack entropy is reduced by four: from 2^28 to
    2^30 (One fourth of expected entropy).
    
    This patch restores back the entropy by correcting the types involved
    in the operations in the functions randomize_stack_top() and
    stack_maxrandom_size().
    
    The successful fix can be tested with:
    
      $ for i in `seq 1 10`; do cat /proc/self/maps | grep stack; done
      7ffeda566000-7ffeda587000 rw-p 00000000 00:00 0                          [stack]
      7fff5a332000-7fff5a353000 rw-p 00000000 00:00 0                          [stack]
      7ffcdb7a1000-7ffcdb7c2000 rw-p 00000000 00:00 0                          [stack]
      7ffd5e2c4000-7ffd5e2e5000 rw-p 00000000 00:00 0                          [stack]
      ...
    
    Once corrected, the leading bytes should be between 7ffc and 7fff,
    rather than always being 7fff.
    
    Signed-off-by: Hector Marco-Gisbert <hecmargi@upv.es>
    Signed-off-by: Ismael Ripoll <iripoll@upv.es>
    [ Rebased, fixed 80 char bugs, cleaned up commit message, added test example and CVE ]
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Fixes: CVE-2015-1593
    Link: http://lkml.kernel.org/r/20150214173350.GA18393@www.outflux.net
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1c222f7b8a7b630426db3ff563a680ca43b415ba
Author: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date:   Mon Feb 16 17:16:45 2015 -0200

    blk-throttle: check stats_cpu before reading it from sysfs
    
    commit 045c47ca306acf30c740c285a77a4b4bda6be7c5 upstream.
    
    When reading blkio.throttle.io_serviced in a recently created blkio
    cgroup, it's possible to race against the creation of a throttle policy,
    which delays the allocation of stats_cpu.
    
    Like other functions in the throttle code, just checking for a NULL
    stats_cpu prevents the following oops caused by that race.
    
    [ 1117.285199] Unable to handle kernel paging request for data at address 0x7fb4d0020
    [ 1117.285252] Faulting instruction address: 0xc0000000003efa2c
    [ 1137.733921] Oops: Kernel access of bad area, sig: 11 [#1]
    [ 1137.733945] SMP NR_CPUS=2048 NUMA PowerNV
    [ 1137.734025] Modules linked in: bridge stp llc kvm_hv kvm binfmt_misc autofs4
    [ 1137.734102] CPU: 3 PID: 5302 Comm: blkcgroup Not tainted 3.19.0 #5
    [ 1137.734132] task: c000000f1d188b00 ti: c000000f1d210000 task.ti: c000000f1d210000
    [ 1137.734167] NIP: c0000000003efa2c LR: c0000000003ef9f0 CTR: c0000000003ef980
    [ 1137.734202] REGS: c000000f1d213500 TRAP: 0300   Not tainted  (3.19.0)
    [ 1137.734230] MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI>  CR: 42008884  XER: 20000000
    [ 1137.734325] CFAR: 0000000000008458 DAR: 00000007fb4d0020 DSISR: 40000000 SOFTE: 0
    GPR00: c0000000003ed3a0 c000000f1d213780 c000000000c59538 0000000000000000
    GPR04: 0000000000000800 0000000000000000 0000000000000000 0000000000000000
    GPR08: ffffffffffffffff 00000007fb4d0020 00000007fb4d0000 c000000000780808
    GPR12: 0000000022000888 c00000000fdc0d80 0000000000000000 0000000000000000
    GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    GPR20: 000001003e120200 c000000f1d5b0cc0 0000000000000200 0000000000000000
    GPR24: 0000000000000001 c000000000c269e0 0000000000000020 c000000f1d5b0c80
    GPR28: c000000000ca3a08 c000000000ca3dec c000000f1c667e00 c000000f1d213850
    [ 1137.734886] NIP [c0000000003efa2c] .tg_prfill_cpu_rwstat+0xac/0x180
    [ 1137.734915] LR [c0000000003ef9f0] .tg_prfill_cpu_rwstat+0x70/0x180
    [ 1137.734943] Call Trace:
    [ 1137.734952] [c000000f1d213780] [d000000005560520] 0xd000000005560520 (unreliable)
    [ 1137.734996] [c000000f1d2138a0] [c0000000003ed3a0] .blkcg_print_blkgs+0xe0/0x1a0
    [ 1137.735039] [c000000f1d213960] [c0000000003efb50] .tg_print_cpu_rwstat+0x50/0x70
    [ 1137.735082] [c000000f1d2139e0] [c000000000104b48] .cgroup_seqfile_show+0x58/0x150
    [ 1137.735125] [c000000f1d213a70] [c0000000002749dc] .kernfs_seq_show+0x3c/0x50
    [ 1137.735161] [c000000f1d213ae0] [c000000000218630] .seq_read+0xe0/0x510
    [ 1137.735197] [c000000f1d213bd0] [c000000000275b04] .kernfs_fop_read+0x164/0x200
    [ 1137.735240] [c000000f1d213c80] [c0000000001eb8e0] .__vfs_read+0x30/0x80
    [ 1137.735276] [c000000f1d213cf0] [c0000000001eb9c4] .vfs_read+0x94/0x1b0
    [ 1137.735312] [c000000f1d213d90] [c0000000001ebb38] .SyS_read+0x58/0x100
    [ 1137.735349] [c000000f1d213e30] [c000000000009218] syscall_exit+0x0/0x98
    [ 1137.735383] Instruction dump:
    [ 1137.735405] 7c6307b4 7f891800 409d00b8 60000000 60420000 3d420004 392a63b0 786a1f24
    [ 1137.735471] 7d49502a e93e01c8 7d495214 7d2ad214 <7cead02a> e9090008 e9490010 e9290018
    
    And here is one code that allows to easily reproduce this, although this
    has first been found by running docker.
    
    void run(pid_t pid)
    {
    	int n;
    	int status;
    	int fd;
    	char *buffer;
    	buffer = memalign(BUFFER_ALIGN, BUFFER_SIZE);
    	n = snprintf(buffer, BUFFER_SIZE, "%d\n", pid);
    	fd = open(CGPATH "/test/tasks", O_WRONLY);
    	write(fd, buffer, n);
    	close(fd);
    	if (fork() > 0) {
    		fd = open("/dev/sda", O_RDONLY | O_DIRECT);
    		read(fd, buffer, 512);
    		close(fd);
    		wait(&status);
    	} else {
    		fd = open(CGPATH "/test/blkio.throttle.io_serviced", O_RDONLY);
    		n = read(fd, buffer, BUFFER_SIZE);
    		close(fd);
    	}
    	free(buffer);
    	exit(0);
    }
    
    void test(void)
    {
    	int status;
    	mkdir(CGPATH "/test", 0666);
    	if (fork() > 0)
    		wait(&status);
    	else
    		run(getpid());
    	rmdir(CGPATH "/test");
    }
    
    int main(int argc, char **argv)
    {
    	int i;
    	for (i = 0; i < NR_TESTS; i++)
    		test();
    	return 0;
    }
    
    Reported-by: Ricardo Marin Matinata <rmm@br.ibm.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a49544209f901729cc409ecd9965eae7f4948b01
Author: David Sterba <dsterba@suse.cz>
Date:   Fri Dec 19 18:38:47 2014 +0100

    btrfs: set proper message level for skinny metadata
    
    commit 5efa0490cc94aee06cd8d282683e22a8ce0a0026 upstream.
    
    This has been confusing people for too long, the message is really just
    informative.
    
    Signed-off-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8d3d232f9093b4443d01616bd12c8cf8668aabdd
Author: Chen Jie <chenjie6@huawei.com>
Date:   Tue Feb 10 12:49:48 2015 -0800

    jffs2: fix handling of corrupted summary length
    
    commit 164c24063a3eadee11b46575c5482b2f1417be49 upstream.
    
    sm->offset maybe wrong but magic maybe right, the offset do not have CRC.
    
    Badness at c00c7580 [verbose debug info unavailable]
    NIP: c00c7580 LR: c00c718c CTR: 00000014
    REGS: df07bb40 TRAP: 0700   Not tainted  (2.6.34.13-WR4.3.0.0_standard)
    MSR: 00029000 <EE,ME,CE>  CR: 22084f84  XER: 00000000
    TASK = df84d6e0[908] 'mount' THREAD: df07a000
    GPR00: 00000001 df07bbf0 df84d6e0 00000000 00000001 00000000 df07bb58 00000041
    GPR08: 00000041 c0638860 00000000 00000010 22084f88 100636c8 df814ff8 00000000
    GPR16: df84d6e0 dfa558cc c05adb90 00000048 c0452d30 00000000 000240d0 000040d0
    GPR24: 00000014 c05ae734 c05be2e0 00000000 00000001 00000000 00000000 c05ae730
    NIP [c00c7580] __alloc_pages_nodemask+0x4d0/0x638
    LR [c00c718c] __alloc_pages_nodemask+0xdc/0x638
    Call Trace:
    [df07bbf0] [c00c718c] __alloc_pages_nodemask+0xdc/0x638 (unreliable)
    [df07bc90] [c00c7708] __get_free_pages+0x20/0x48
    [df07bca0] [c00f4a40] __kmalloc+0x15c/0x1ec
    [df07bcd0] [c01fc880] jffs2_scan_medium+0xa58/0x14d0
    [df07bd70] [c01ff38c] jffs2_do_mount_fs+0x1f4/0x6b4
    [df07bdb0] [c020144c] jffs2_do_fill_super+0xa8/0x260
    [df07bdd0] [c020230c] jffs2_fill_super+0x104/0x184
    [df07be00] [c0335814] get_sb_mtd_aux+0x9c/0xec
    [df07be20] [c033596c] get_sb_mtd+0x84/0x1e8
    [df07be60] [c0201ed0] jffs2_get_sb+0x1c/0x2c
    [df07be70] [c0103898] vfs_kern_mount+0x78/0x1e8
    [df07bea0] [c0103a58] do_kern_mount+0x40/0x100
    [df07bec0] [c011fe90] do_mount+0x240/0x890
    [df07bf10] [c0120570] sys_mount+0x90/0xd8
    [df07bf40] [c00110d8] ret_from_syscall+0x0/0x4
    
    === Exception: c01 at 0xff61a34
        LR = 0x100135f0
    Instruction dump:
    38800005 38600000 48010f41 4bfffe1c 4bfc2d15 4bfffe8c 72e90200 4082fc28
    3d20c064 39298860 8809000d 68000001 <0f000000> 2f800000 419efc0c 38000001
    mount: mounting /dev/mtdblock3 on /common failed: Input/output error
    
    Signed-off-by: Chen Jie <chenjie6@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9a8120f5c8ff17c2bc97d615a7006da7aec67ebe
Author: Daniel J Blueman <daniel@numascale.com>
Date:   Tue Feb 17 11:34:38 2015 +0800

    EDAC, amd64_edac: Prevent OOPS with >16 memory controllers
    
    commit 0c510cc83bdbaac8406f4f7caef34f4da0ba35ea upstream.
    
    When DRAM errors occur on memory controllers after EDAC_MAX_MCS (16),
    the kernel fatally dereferences unallocated structures, see splat below;
    this occurs on at least NumaConnect systems.
    
    Fix by checking if a memory controller info structure was found.
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000320
    IP: [<ffffffff819f714f>] decode_bus_error+0x2f/0x2b0
    PGD 2f8b5a3067 PUD 2f8b5a2067 PMD 0
    Oops: 0000 [#2] SMP
    Modules linked in:
    CPU: 224 PID: 11930 Comm: stream_c.exe.gn Tainted: G   D    3.19.0 #1
    Hardware name: Supermicro H8QGL/H8QGL, BIOS 3.5b    01/28/2015
    task: ffff8807dbfb8c00 ti: ffff8807dd16c000 task.ti: ffff8807dd16c000
    RIP: 0010:[<ffffffff819f714f>] [<ffffffff819f714f>] decode_bus_error+0x2f/0x2b0
    RSP: 0000:ffff8907dfc03c48 EFLAGS: 00010297
    RAX: 0000000000000001 RBX: 9c67400010080a13 RCX: 0000000000001dc6
    RDX: 000000001dc61dc6 RSI: ffff8907dfc03df0 RDI: 000000000000001c
    RBP: ffff8907dfc03ce8 R08: 0000000000000000 R09: 0000000000000022
    R10: ffff891fffa30380 R11: 00000000001cfc90 R12: 0000000000000008
    R13: 0000000000000000 R14: 000000000000001c R15: 00009c6740001000
    FS: 00007fa97ee18700(0000) GS:ffff8907dfc00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000320 CR3: 0000003f889b8000 CR4: 00000000000407e0
    Stack:
     0000000000000000 ffff8907dfc03df0 0000000000000008 9c67400010080a13
     000000000000001c 00009c6740001000 ffff8907dfc03c88 ffffffff810e4f9a
     ffff8907dfc03ce8 ffffffff81b375b9 0000000000000000 0000000000000010
    Call Trace:
     <IRQ>
     ? vprintk_default
     ? printk
     amd_decode_mce
     notifier_call_chain
     atomic_notifier_call_chain
     mce_log
     machine_check_poll
     mce_timer_fn
     ? mce_cpu_restart
     call_timer_fn.isra.29
     run_timer_softirq
     __do_softirq
     irq_exit
     smp_apic_timer_interrupt
     apic_timer_interrupt
     <EOI>
     ? down_read_trylock
     __do_page_fault
     ? __schedule
     do_page_fault
     page_fault
    
    Signed-off-by: Daniel J Blueman <daniel@numascale.com>
    Link: http://lkml.kernel.org/r/1424144078-24589-1-git-send-email-daniel@numascale.com
    [ Boris: massage commit message ]
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz> [backport to 3.12]

commit 8107488ca4689830bc4a11d80017cee009f458ee
Author: Tomáš Hodek <tomas.hodek@volny.cz>
Date:   Mon Feb 23 11:00:38 2015 +1100

    md/raid1: fix read balance when a drive is write-mostly.
    
    commit d1901ef099c38afd11add4cfb3312c02ef21ec4a upstream.
    
    When a drive is marked write-mostly it should only be the
    target of reads if there is no other option.
    
    This behaviour was broken by
    
    commit 9dedf60313fa4dddfd5b9b226a0ef12a512bf9dc
        md/raid1: read balance chooses idlest disk for SSD
    
    which causes a write-mostly device to be *preferred* is some cases.
    
    Restore correct behaviour by checking and setting
    best_dist_disk and best_pending_disk rather than best_disk.
    
    We only need to test one of these as they are both changed
    from -1 or >=0 at the same time.
    
    As we leave min_pending and best_dist unchanged, any non-write-mostly
    device will appear better than the write-mostly device.
    
    Reported-by: Tomáš Hodek <tomas.hodek@volny.cz>
    Reported-by: Dark Penguin <darkpenguin@yandex.ru>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Link: http://marc.info/?l=linux-raid&m=135982797322422
    Fixes: 9dedf60313fa4dddfd5b9b226a0ef12a512bf9dc
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ca39d6db876923873559b43d40684274161cc49e
Author: NeilBrown <neilb@suse.de>
Date:   Wed Feb 18 11:35:14 2015 +1100

    md/raid5: Fix livelock when array is both resyncing and degraded.
    
    commit 26ac107378c4742978216be1005b7291b799c7b2 upstream.
    
    Commit a7854487cd7128a30a7f4f5259de9f67d5efb95f:
      md: When RAID5 is dirty, force reconstruct-write instead of read-modify-write.
    
    Causes an RCW cycle to be forced even when the array is degraded.
    A degraded array cannot support RCW as that requires reading all data
    blocks, and one may be missing.
    
    Forcing an RCW when it is not possible causes a live-lock and the code
    spins, repeatedly deciding to do something that cannot succeed.
    
    So change the condition to only force RCW on non-degraded arrays.
    
    Reported-by: Manibalan P <pmanibalan@amiindia.co.in>
    Bisected-by: Jes Sorensen <Jes.Sorensen@redhat.com>
    Tested-by: Jes Sorensen <Jes.Sorensen@redhat.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Fixes: a7854487cd7128a30a7f4f5259de9f67d5efb95f
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5ce0984a8439645ef0073e96eac12b871a85f6b1
Author: James Hogan <james.hogan@imgtec.com>
Date:   Tue Feb 24 12:25:25 2015 +0000

    metag: Fix KSTK_EIP() and KSTK_ESP() macros
    
    commit c2996cb29bfb73927a79dc96e598a718e843f01a upstream.
    
    The KSTK_EIP() and KSTK_ESP() macros should return the user program
    counter (PC) and stack pointer (A0StP) of the given task. These are used
    to determine which VMA corresponds to the user stack in
    /proc/<pid>/maps, and for the user PC & A0StP in /proc/<pid>/stat.
    
    However for Meta the PC & A0StP from the task's kernel context are used,
    resulting in broken output. For example in following /proc/<pid>/maps
    output, the 3afff000-3b021000 VMA should be described as the stack:
    
      # cat /proc/self/maps
      ...
      100b0000-100b1000 rwxp 00000000 00:00 0          [heap]
      3afff000-3b021000 rwxp 00000000 00:00 0
    
    And in the following /proc/<pid>/stat output, the PC is in kernel code
    (1074234964 = 0x40078654) and the A0StP is in the kernel heap
    (1335981392 = 0x4fa17550):
    
      # cat /proc/self/stat
      51 (cat) R ... 1335981392 1074234964 ...
    
    Fix the definitions of KSTK_EIP() and KSTK_ESP() to use
    task_pt_regs(tsk)->ctx rather than (tsk)->thread.kernel_context. This
    gets the registers from the user context stored after the thread info at
    the base of the kernel stack, which is from the last entry into the
    kernel from userland, regardless of where in the kernel the task may
    have been interrupted, which results in the following more correct
    /proc/<pid>/maps output:
    
      # cat /proc/self/maps
      ...
      0800b000-08070000 r-xp 00000000 00:02 207        /lib/libuClibc-0.9.34-git.so
      ...
      100b0000-100b1000 rwxp 00000000 00:00 0          [heap]
      3afff000-3b021000 rwxp 00000000 00:00 0          [stack]
    
    And /proc/<pid>/stat now correctly reports the PC in libuClibc
    (134320308 = 0x80190b4) and the A0StP in the [stack] region (989864576 =
    0x3b002280):
    
      # cat /proc/self/stat
      51 (cat) R ... 989864576 134320308 ...
    
    Reported-by: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
    Reported-by: Vineet Gupta <Vineet.Gupta1@synopsys.com>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a776835f0bd222c70c8899061e662f10c1611ec3
Author: Jan Kara <jack@suse.cz>
Date:   Mon Feb 23 22:34:17 2015 +1100

    xfs: Fix quota type in quota structures when reusing quota file
    
    commit dfcc70a8c868fe03276fa59864149708fb41930b upstream.
    
    For filesystems without separate project quota inode field in the
    superblock we just reuse project quota file for group quotas (and vice
    versa) if project quota file is allocated and we need group quota file.
    When we reuse the file, quota structures on disk suddenly have wrong
    type stored in d_flags though. Nobody really cares about this (although
    structure type reported to userspace was wrong as well) except
    that after commit 14bf61ffe6ac (quota: Switch ->get_dqblk() and
    ->set_dqblk() to use bytes as space units) assertion in
    xfs_qm_scall_getquota() started to trigger on xfs/106 test (apparently I
    was testing without XFS_DEBUG so I didn't notice when submitting the
    above commit).
    
    Fix the problem by properly resetting ddq->d_flags when running quotacheck
    for a quota file.
    
    Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 22fd0313bf5b16f60932e2f2b2bba4f37ac25a8f
Author: Nicolas Saenz Julienne <nicolassaenzj@gmail.com>
Date:   Thu Feb 19 01:52:25 2015 +0000

    gpio: tps65912: fix wrong container_of arguments
    
    commit 2f97c20e5f7c3582c7310f65a04465bfb0fd0e85 upstream.
    
    The gpio_chip operations receive a pointer the gpio_chip struct which is
    contained in the driver's private struct, yet the container_of call in those
    functions point to the mfd struct defined in include/linux/mfd/tps65912.h.
    
    Signed-off-by: Nicolas Saenz Julienne <nicolassaenzj@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dddaecc27d5dbc30863428edd7bab031e7c7c8d9
Author: Hans Holmberg <hans.holmberg@intel.com>
Date:   Tue Feb 10 09:48:27 2015 +0100

    gpiolib: of: allow of_gpiochip_find_and_xlate to find more than one chip per node
    
    commit 9cf75e9e4ddd587ac12e88e8751c358b7b27e95f upstream.
    
    The change:
    
    7b8792bbdffdff3abda704f89c6a45ea97afdc62
    gpiolib: of: Correct error handling in of_get_named_gpiod_flags
    
    assumed that only one gpio-chip is registred per of-node.
    Some drivers register more than one chip per of-node, so
    adjust the matching function of_gpiochip_find_and_xlate to
    not stop looking for chips if a node-match is found and
    the translation fails.
    
    Fixes: 7b8792bbdffd ("gpiolib: of: Correct error handling in of_get_named_gpiod_flags")
    Signed-off-by: Hans Holmberg <hans.holmberg@intel.com>
    Acked-by: Alexandre Courbot <acourbot@nvidia.com>
    Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Tested-by: Tyler Hall <tylerwhall@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 59e4cc3ee0a1a1550272701ef918464c79d5c73b
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Mon Feb 23 15:13:40 2015 +0000

    arm64: compat Fix siginfo_t -> compat_siginfo_t conversion on big endian
    
    commit 9d42d48a342aee208c1154696196497fdc556bbf upstream.
    
    The native (64-bit) sigval_t union contains sival_int (32-bit) and
    sival_ptr (64-bit). When a compat application invokes a syscall that
    takes a sigval_t value (as part of a larger structure, e.g.
    compat_sys_mq_notify, compat_sys_timer_create), the compat_sigval_t
    union is converted to the native sigval_t with sival_int overlapping
    with either the least or the most significant half of sival_ptr,
    depending on endianness. When the corresponding signal is delivered to a
    compat application, on big endian the current (compat_uptr_t)sival_ptr
    cast always returns 0 since sival_int corresponds to the top part of
    sival_ptr. This patch fixes copy_siginfo_to_user32() so that sival_int
    is copied to the compat_siginfo_t structure.
    
    Reported-by: Bamvor Jian Zhang <bamvor.zhangjian@huawei.com>
    Tested-by: Bamvor Jian Zhang <bamvor.zhangjian@huawei.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dada8422d120086fa688d2e2e5604da0941cd5ef
Author: Martin Vajnar <martin.vajnar@gmail.com>
Date:   Wed Dec 24 00:27:57 2014 +0100

    hx4700: regulator: declare full constraints
    
    commit a52d209336f8fc7483a8c7f4a8a7d2a8e1692a6c upstream.
    
    Since the removal of CONFIG_REGULATOR_DUMMY option, the touchscreen stopped
    working. This patch enables the "replacement" for REGULATOR_DUMMY and
    allows the touchscreen to work even though there is no regulator for "vcc".
    
    Signed-off-by: Martin Vajnar <martin.vajnar@gmail.com>
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5202b3587e768e05f82349df0742a58e6824ec68
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Tue Nov 4 21:30:44 2014 -0200

    KVM: x86: update masterclock values on TSC writes
    
    commit 7f187922ddf6b67f2999a76dcb71663097b75497 upstream.
    
    When the guest writes to the TSC, the masterclock TSC copy must be
    updated as well along with the TSC_OFFSET update, otherwise a negative
    tsc_timestamp is calculated at kvm_guest_time_update.
    
    Once "if (!vcpus_matched && ka->use_master_clock)" is simplified to
    "if (ka->use_master_clock)", the corresponding "if (!ka->use_master_clock)"
    becomes redundant, so remove the do_request boolean and collapse
    everything into a single condition.
    
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8ef0cf0e2fede8b5607986c197128ee2f21adf94
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Tue Feb 17 19:37:15 2015 +0300

    libceph: fix double __remove_osd() problem
    
    commit 7eb71e0351fbb1b242ae70abb7bb17107fe2f792 upstream.
    
    It turns out it's possible to get __remove_osd() called twice on the
    same OSD.  That doesn't sit well with rb_erase() - depending on the
    shape of the tree we can get a NULL dereference, a soft lockup or
    a random crash at some point in the future as we end up touching freed
    memory.  One scenario that I was able to reproduce is as follows:
    
                <osd3 is idle, on the osd lru list>
    <con reset - osd3>
    con_fault_finish()
      osd_reset()
                                  <osdmap - osd3 down>
                                  ceph_osdc_handle_map()
                                    <takes map_sem>
                                    kick_requests()
                                      <takes request_mutex>
                                      reset_changed_osds()
                                        __reset_osd()
                                          __remove_osd()
                                      <releases request_mutex>
                                    <releases map_sem>
        <takes map_sem>
        <takes request_mutex>
        __kick_osd_requests()
          __reset_osd()
            __remove_osd() <-- !!!
    
    A case can be made that osd refcounting is imperfect and reworking it
    would be a proper resolution, but for now Sage and I decided to fix
    this by adding a safe guard around __remove_osd().
    
    Fixes: http://tracker.ceph.com/issues/8087
    
    Cc: Sage Weil <sage@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 27f9c1807c7e33efec5c02ef8a101774839214b8
Author: Ilya Dryomov <idryomov@redhat.com>
Date:   Wed Nov 5 19:33:44 2014 +0300

    libceph: change from BUG to WARN for __remove_osd() asserts
    
    commit cc9f1f518cec079289d11d732efa490306b1ddad upstream.
    
    No reason to use BUG_ON for osd request list assertions.
    
    Signed-off-by: Ilya Dryomov <idryomov@redhat.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 66d37e928df71d6aef8b2dfe8c6dca785653cf1f
Author: Ilya Dryomov <ilya.dryomov@inktank.com>
Date:   Wed Jun 18 13:02:12 2014 +0400

    libceph: assert both regular and lingering lists in __remove_osd()
    
    commit 7c6e6fc53e7335570ed82f77656cedce1502744e upstream.
    
    It is important that both regular and lingering requests lists are
    empty when the OSD is removed.
    
    Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ebf0333679a79508cc79555d178877cd9eb54e80
Author: Anantha Krishnan <ananthk@codeaurora.org>
Date:   Mon Oct 6 16:31:49 2014 +0530

    Bluetooth: Add support for Acer [0489:e078]
    
    commit 4b552bc9edfdc947862af225a0e2521edb5d37a0 upstream.
    
    Add support for the QCA6174 chip.
    
        T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
        D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
        P:  Vendor=0489 ProdID=e078 Rev=00.01
        C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
        I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Signed-off-by: Anantha Krishnan <ananthk@codeaurora.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 48f80a96dd46107d0612605bfc0d6038d7f25e47
Author: James Hogan <james.hogan@imgtec.com>
Date:   Mon Mar 2 11:11:57 2015 +0000

    KVM: MIPS: Don't leak FPU/DSP to guest
    
    [ Upstream commit f798217dfd038af981a18bbe4bc57027a08bb182 ]
    
    The FPU and DSP are enabled via the CP0 Status CU1 and MX bits by
    kvm_mips_set_c0_status() on a guest exit, presumably in case there is
    active state that needs saving if pre-emption occurs. However neither of
    these bits are cleared again when returning to the guest.
    
    This effectively gives the guest access to the FPU/DSP hardware after
    the first guest exit even though it is not aware of its presence,
    allowing FP instructions in guest user code to intermittently actually
    execute instead of trapping into the guest OS for emulation. It will
    then read & manipulate the hardware FP registers which technically
    belong to the user process (e.g. QEMU), or are stale from another user
    process. It can also crash the guest OS by causing an FP exception, for
    which a guest exception handler won't have been registered.
    
    First lets save and disable the FPU (and MSA) state with lose_fpu(1)
    before entering the guest. This simplifies the problem, especially for
    when guest FPU/MSA support is added in the future, and prevents FR=1 FPU
    state being live when the FR bit gets cleared for the guest, which
    according to the architecture causes the contents of the FPU and vector
    registers to become UNPREDICTABLE.
    
    We can then safely remove the enabling of the FPU in
    kvm_mips_set_c0_status(), since there should never be any active FPU or
    MSA state to save at pre-emption, which should plug the FPU leak.
    
    DSP state is always live rather than being lazily restored, so for that
    it is simpler to just clear the MX bit again when re-entering the guest.
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Sanjay Lal <sanjayl@kymasys.com>
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: kvm@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Cc: <stable@vger.kernel.org> # v3.10+: 044f0f03eca0: MIPS: KVM: Deliver guest interrupts
    Cc: <stable@vger.kernel.org> # v3.10+: 3ce465e04bfd: MIPS: Export FP functions used by lose_fpu(1) for KVM
    Cc: <stable@vger.kernel.org> # v3.10+
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 02c76a9a9bdb9afb0dc21ada50709729a584b28c
Author: Alexey Brodkin <abrodkin@synopsys.com>
Date:   Thu Feb 12 21:10:11 2015 +0300

    ARC: fix page address calculation if PAGE_OFFSET != LINUX_LINK_BASE
    
    commit 06f34e1c28f3608b0ce5b310e41102d3fe7b65a1 upstream.
    
    We used to calculate page address differently in 2 cases:
    
    1. In virt_to_page(x) we do
     --->8---
     mem_map + (x - CONFIG_LINUX_LINK_BASE) >> PAGE_SHIFT
     --->8---
    
    2. In in pte_page(x) we do
     --->8---
     mem_map + (pte_val(x) - PAGE_OFFSET) >> PAGE_SHIFT
     --->8---
    
    That leads to problems in case PAGE_OFFSET != CONFIG_LINUX_LINK_BASE -
    different pages will be selected depending on where and how we calculate
    page address.
    
    In particular in the STAR 9000853582 when gdb attempted to read memory
    of another process it got improper page in get_user_pages() because this
    is exactly one of the places where we search for a page by pte_page().
    
    The fix is trivial - we need to calculate page address similarly in both
    cases.
    
    Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 980af92d3ef35388acce34d9cc116b246b70e558
Author: Jay Lan <jlan@sgi.com>
Date:   Mon Sep 29 15:36:57 2014 -0700

    kdb: fix incorrect counts in KDB summary command output
    
    commit 146755923262037fc4c54abc28c04b1103f3cc51 upstream.
    
    The output of KDB 'summary' command should report MemTotal, MemFree
    and Buffers output in kB. Current codes report in unit of pages.
    
    A define of K(x) as
    is defined in the code, but not used.
    
    This patch would apply the define to convert the values to kB.
    Please include me on Cc on replies. I do not subscribe to linux-kernel.
    
    Signed-off-by: Jay Lan <jlan@sgi.com>
    Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 71d9abaaf54f07b4d89d0e5c3bf03fee75e961b4
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date:   Thu Dec 4 14:10:01 2014 +0300

    ARM: pxa: add regulator_has_full_constraints to poodle board file
    
    commit 9bc78f32c2e430aebf6def965b316aa95e37a20c upstream.
    
    Add regulator_has_full_constraints() call to poodle board file to let
    regulator core know that we do not have any additional regulators left.
    This lets it substitute unprovided regulators with dummy ones.
    
    This fixes the following warnings that can be seen on poodle if
    regulators are enabled:
    
    ads7846 spi1.0: unable to get regulator: -517
    spi spi1.0: Driver ads7846 requests probe deferral
    wm8731 0-001b: Failed to get supply 'AVDD': -517
    wm8731 0-001b: Failed to request supplies: -517
    wm8731 0-001b: ASoC: failed to probe component -517
    
    Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Acked-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2b563e615042a8c4b24bdac3216069c077286802
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date:   Thu Dec 4 14:10:00 2014 +0300

    ARM: pxa: add regulator_has_full_constraints to corgi board file
    
    commit 271e80176aae4e5b481f4bb92df9768c6075bbca upstream.
    
    Add regulator_has_full_constraints() call to corgi board file to let
    regulator core know that we do not have any additional regulators left.
    This lets it substitute unprovided regulators with dummy ones.
    
    This fixes the following warnings that can be seen on corgi if
    regulators are enabled:
    
    ads7846 spi1.0: unable to get regulator: -517
    spi spi1.0: Driver ads7846 requests probe deferral
    wm8731 0-001b: Failed to get supply 'AVDD': -517
    wm8731 0-001b: Failed to request supplies: -517
    wm8731 0-001b: ASoC: failed to probe component -517
    corgi-audio corgi-audio: ASoC: failed to instantiate card -517
    
    Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Acked-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7498a0c80997ef0b1572a0cc9b2a206f5eab9311
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Fri Jan 23 17:07:21 2015 -0500

    vt: provide notifications on selection changes
    
    commit 19e3ae6b4f07a87822c1c9e7ed99d31860e701af upstream.
    
    The vcs device's poll/fasync support relies on the vt notifier to signal
    changes to the screen content.  Notifier invocations were missing for
    changes that comes through the selection interface though.  Fix that.
    
    Tested with BRLTTY 5.2.
    
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Cc: Dave Mielke <dave@mielke.cc>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4d1799d640331cd0ca08d0a1287aa54f7f7125f9
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Fri Dec 5 15:13:54 2014 +0100

    usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN
    
    commit 5efd2ea8c9f4f12916ffc8ba636792ce052f6911 upstream.
    
    the following error pops up during "testusb -a -t 10"
    | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,	f134e000/be842000 (bad dma)
    hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
    size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
    hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
    might by identified by buffer_offset() as another buffer. This means the
    buffer which is on a 32 byte boundary will not get freed, instead it
    tries to free another buffer with the error message.
    
    This patch fixes the issue by creating the smallest DMA buffer with the
    size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is
    smaller). This might be 32, 64 or even 128 bytes. The next three pools
    will have the size 128, 512 and 2048.
    In case the smallest pool is 128 bytes then we have only three pools
    instead of four (and zero the first entry in the array).
    The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
    2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
    we would end up with 8KiB buffer in case we have 16KiB pages.
    Instead I think it makes sense to have a common size(s) and extend them
    if there is need to.
    There is a BUILD_BUG_ON() now in case someone has a minalign of more than
    128 bytes.
    
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5752d1a50c56bda3228272ac3e77f7f97632a4d8
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Jan 30 12:58:26 2015 -0500

    USB: fix use-after-free bug in usb_hcd_unlink_urb()
    
    commit c99197902da284b4b723451c1471c45b18537cde upstream.
    
    The usb_hcd_unlink_urb() routine in hcd.c contains two possible
    use-after-free errors.  The dev_dbg() statement at the end of the
    routine dereferences urb and urb->dev even though both structures may
    have been deallocated.
    
    This patch fixes the problem by storing urb->dev in a local variable
    (avoiding the dereference of urb) and moving the dev_dbg() up before
    the usb_put_dev() call.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
    Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
    Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e047f04b6763dd4929a641b663ebc41d548f1027
Author: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Date:   Wed Jan 21 15:24:27 2015 -0500

    USB: cp210x: add ID for RUGGEDCOM USB Serial Console
    
    commit a6f0331236fa75afba14bbcf6668d42cebb55c43 upstream.
    
    Added the USB serial console device ID for Siemens Ruggedcom devices
    which have a USB port for their serial console.
    
    Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 79abbf657e16a14ab146498001f94398c5a5de32
Author: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Date:   Tue Dec 9 14:31:34 2014 +0100

    tty/serial: at91: fix error handling in atmel_serial_probe()
    
    commit 6fbb9bdf0f3fbe23aeff806489791aa876adaffb upstream.
    
    -EDEFER error wasn't handle properly by atmel_serial_probe().
    As an example, when atmel_serial_probe() is called for the first time, we pass
    the test_and_set_bit() test to check whether the port has already been
    initalized. Then we call atmel_init_port(), which may return -EDEFER, possibly
    returned before by clk_get(). Consequently atmel_serial_probe() used to return
    this error code WITHOUT clearing the port bit in the "atmel_ports_in_use" mask.
    When atmel_serial_probe() was called for the second time, it used to fail on
    the test_and_set_bit() function then returning -EBUSY.
    
    When atmel_serial_probe() fails, this patch make it clear the port bit in the
    "atmel_ports_in_use" mask, if needed, before returning the error code.
    
    Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 09179f19a3a7b87482925384ef1c21af546b8910
Author: Peter Hurley <peter@hurleysoftware.com>
Date:   Mon Jan 19 13:05:03 2015 -0500

    tty: Prevent untrappable signals from malicious program
    
    commit 37480a05685ed5b8e1b9bf5e5c53b5810258b149 upstream.
    
    Commit 26df6d13406d1a5 ("tty: Add EXTPROC support for LINEMODE")
    allows a process which has opened a pty master to send _any_ signal
    to the process group of the pty slave. Although potentially
    exploitable by a malicious program running a setuid program on
    a pty slave, it's unknown if this exploit currently exists.
    
    Limit to signals actually used.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Howard Chu <hyc@symas.com>
    Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3e8f58791018d51909486dc5466e2f0bb2013095
Author: Matthew Wilcox <matthew.r.wilcox@intel.com>
Date:   Wed Jan 7 18:04:18 2015 +0200

    axonram: Fix bug in direct_access
    
    commit 91117a20245b59f70b563523edbf998a62fc6383 upstream.
    
    The 'pfn' returned by axonram was completely bogus, and has been since
    2008.
    
    Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cb5085fd318e0c60dd0f56410d5a29b71ea55ef3
Author: Jeff Moyer <jmoyer@redhat.com>
Date:   Mon Jan 12 15:21:01 2015 -0500

    cfq-iosched: fix incorrect filing of rt async cfqq
    
    commit c6ce194325cef342313e3d27620411ce90a89c50 upstream.
    
    Hi,
    
    If you can manage to submit an async write as the first async I/O from
    the context of a process with realtime scheduling priority, then a
    cfq_queue is allocated, but filed into the wrong async_cfqq bucket.  It
    ends up in the best effort array, but actually has realtime I/O
    scheduling priority set in cfqq->ioprio.
    
    The reason is that cfq_get_queue assumes the default scheduling class and
    priority when there is no information present (i.e. when the async cfqq
    is created):
    
    static struct cfq_queue *
    cfq_get_queue(struct cfq_data *cfqd, bool is_sync, struct cfq_io_cq *cic,
    	      struct bio *bio, gfp_t gfp_mask)
    {
    	const int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
    	const int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);
    
    cic->ioprio starts out as 0, which is "invalid".  So, class of 0
    (IOPRIO_CLASS_NONE) is passed to cfq_async_queue_prio like so:
    
    		async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class, ioprio);
    
    static struct cfq_queue **
    cfq_async_queue_prio(struct cfq_data *cfqd, int ioprio_class, int ioprio)
    {
            switch (ioprio_class) {
            case IOPRIO_CLASS_RT:
                    return &cfqd->async_cfqq[0][ioprio];
            case IOPRIO_CLASS_NONE:
                    ioprio = IOPRIO_NORM;
                    /* fall through */
            case IOPRIO_CLASS_BE:
                    return &cfqd->async_cfqq[1][ioprio];
            case IOPRIO_CLASS_IDLE:
                    return &cfqd->async_idle_cfqq;
            default:
                    BUG();
            }
    }
    
    Here, instead of returning a class mapped from the process' scheduling
    priority, we get back the bucket associated with IOPRIO_CLASS_BE.
    
    Now, there is no queue allocated there yet, so we create it:
    
    		cfqq = cfq_find_alloc_queue(cfqd, is_sync, cic, bio, gfp_mask);
    
    That function ends up doing this:
    
    			cfq_init_cfqq(cfqd, cfqq, current->pid, is_sync);
    			cfq_init_prio_data(cfqq, cic);
    
    cfq_init_cfqq marks the priority as having changed.  Then, cfq_init_prio
    data does this:
    
    	ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
    	switch (ioprio_class) {
    	default:
    		printk(KERN_ERR "cfq: bad prio %x\n", ioprio_class);
    	case IOPRIO_CLASS_NONE:
    		/*
    		 * no prio set, inherit CPU scheduling settings
    		 */
    		cfqq->ioprio = task_nice_ioprio(tsk);
    		cfqq->ioprio_class = task_nice_ioclass(tsk);
    		break;
    
    So we basically have two code paths that treat IOPRIO_CLASS_NONE
    differently, which results in an RT async cfqq filed into a best effort
    bucket.
    
    Attached is a patch which fixes the problem.  I'm not sure how to make
    it cleaner.  Suggestions would be welcome.
    
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Tested-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c7d68c6977f177bbe891b1237ff27ecbd9b2571e
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date:   Mon Feb 9 16:42:49 2015 +0300

    cfq-iosched: handle failure of cfq group allocation
    
    commit 69abaffec7d47a083739b79e3066cb3730eba72e upstream.
    
    Cfq_lookup_create_cfqg() allocates struct blkcg_gq using GFP_ATOMIC.
    In cfq_find_alloc_queue() possible allocation failure is not handled.
    As a result kernel oopses on NULL pointer dereference when
    cfq_link_cfqq_cfqg() calls cfqg_get() for NULL pointer.
    
    Bug was introduced in v3.5 in commit cd1604fab4f9 ("blkcg: factor
    out blkio_group creation"). Prior to that commit cfq group lookup
    had returned pointer to root group as fallback.
    
    This patch handles this error using existing fallback oom_cfqq.
    
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Acked-by: Tejun Heo <tj@kernel.org>
    Acked-by: Vivek Goyal <vgoyal@redhat.com>
    Fixes: cd1604fab4f9 ("blkcg: factor out blkio_group creation")
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a291f65de1bc822187f2d6c9ed40bd8e6ba31c84
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Jan 22 00:56:53 2015 -0800

    iscsi-target: Drop problematic active_ts_list usage
    
    commit 3fd7b60f2c7418239d586e359e0c6d8503e10646 upstream.
    
    This patch drops legacy active_ts_list usage within iscsi_target_tq.c
    code.  It was originally used to track the active thread sets during
    iscsi-target shutdown, and is no longer used by modern upstream code.
    
    Two people have reported list corruption using traditional iscsi-target
    and iser-target with the following backtrace, that appears to be related
    to iscsi_thread_set->ts_list being used across both active_ts_list and
    inactive_ts_list.
    
    [   60.782534] ------------[ cut here ]------------
    [   60.782543] WARNING: CPU: 0 PID: 9430 at lib/list_debug.c:53 __list_del_entry+0x63/0xd0()
    [   60.782545] list_del corruption, ffff88045b00d180->next is LIST_POISON1 (dead000000100100)
    [   60.782546] Modules linked in: ib_srpt tcm_qla2xxx qla2xxx tcm_loop tcm_fc libfc scsi_transport_fc scsi_tgt ib_isert rdma_cm iw_cm ib_addr iscsi_target_mod target_core_pscsi target_core_file target_core_iblock target_core_mod configfs ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc autofs4 sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ib_ipoib ib_cm ib_uverbs ib_umad mlx4_en mlx4_ib ib_sa ib_mad ib_core mlx4_core dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support microcode serio_raw pcspkr sb_edac edac_core sg i2c_i801 lpc_ich mfd_core mtip32xx igb i2c_algo_bit i2c_core ptp pps_core ioatdma dca wmi ext3(F) jbd(F) mbcache(F) sd_mod(F) crc_t10dif(F) crct10dif_common(F) ahci(F) libahci(F) isci(F) libsas(F) scsi_transport_sas(F) [last unloaded: speedstep_lib]
    [   60.782597] CPU: 0 PID: 9430 Comm: iscsi_ttx Tainted: GF 3.12.19+ #2
    [   60.782598] Hardware name: Supermicro X9DRX+-F/X9DRX+-F, BIOS 3.00 07/09/2013
    [   60.782599]  0000000000000035 ffff88044de31d08 ffffffff81553ae7 0000000000000035
    [   60.782602]  ffff88044de31d58 ffff88044de31d48 ffffffff8104d1cc 0000000000000002
    [   60.782605]  ffff88045b00d180 ffff88045b00d0c0 ffff88045b00d0c0 ffff88044de31e58
    [   60.782607] Call Trace:
    [   60.782611]  [<ffffffff81553ae7>] dump_stack+0x49/0x62
    [   60.782615]  [<ffffffff8104d1cc>] warn_slowpath_common+0x8c/0xc0
    [   60.782618]  [<ffffffff8104d2b6>] warn_slowpath_fmt+0x46/0x50
    [   60.782620]  [<ffffffff81280933>] __list_del_entry+0x63/0xd0
    [   60.782622]  [<ffffffff812809b1>] list_del+0x11/0x40
    [   60.782630]  [<ffffffffa06e7cf9>] iscsi_del_ts_from_active_list+0x29/0x50 [iscsi_target_mod]
    [   60.782635]  [<ffffffffa06e87b1>] iscsi_tx_thread_pre_handler+0xa1/0x180 [iscsi_target_mod]
    [   60.782642]  [<ffffffffa06fb9ae>] iscsi_target_tx_thread+0x4e/0x220 [iscsi_target_mod]
    [   60.782647]  [<ffffffffa06fb960>] ? iscsit_handle_snack+0x190/0x190 [iscsi_target_mod]
    [   60.782652]  [<ffffffffa06fb960>] ? iscsit_handle_snack+0x190/0x190 [iscsi_target_mod]
    [   60.782655]  [<ffffffff8106f99e>] kthread+0xce/0xe0
    [   60.782657]  [<ffffffff8106f8d0>] ? kthread_freezable_should_stop+0x70/0x70
    [   60.782660]  [<ffffffff8156026c>] ret_from_fork+0x7c/0xb0
    [   60.782662]  [<ffffffff8106f8d0>] ? kthread_freezable_should_stop+0x70/0x70
    [   60.782663] ---[ end trace 9662f4a661d33965 ]---
    
    Since this code is no longer used, go ahead and drop the problematic usage
    all-together.
    
    Reported-by: Gavin Guo <gavin.guo@canonical.com>
    Reported-by: Moussa Ba <moussaba@micron.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7ccb9a7618c0e1b0f15594362268efcc0a58556f
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Wed Feb 11 17:27:55 2015 -0500

    NFSv4.1: Fix a kfree() of uninitialised pointers in decode_cb_sequence_args
    
    commit d8ba1f971497c19cf80da1ea5391a46a5f9fbd41 upstream.
    
    If the call to decode_rc_list() fails due to a memory allocation error,
    then we need to truncate the array size to ensure that we only call
    kfree() on those pointer that were allocated.
    
    Reported-by: David Ramos <daramos@stanford.edu>
    Fixes: 4aece6a19cf7f ("nfs41: cb_sequence xdr implementation")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bcb8bcd16bc2c3654c7b1c4cd2641d8d04a6e752
Author: honclo <honclo@imap.linux.ibm.com>
Date:   Thu Feb 12 21:02:24 2015 -0500

    Added Little Endian support to vtpm module
    
    commit eb71f8a5e33fa1066fb92f0111ab366a341e1f6c upstream.
    
    The tpm_ibmvtpm module is affected by an unaligned access problem.
    ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is
    enabled in Power partition, which supports both little endian and
    big endian modes.
    
    We added little endian support to fix this problem:
    1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS.
    2) added be16_to_cpu and be32_to_cpu calls to make sure data received
       is in LE format on a LE OS.
    
    Signed-off-by: Hon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com>
    Signed-off-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
    [phuewe: manually applied the patch :( ]
    Reviewed-by: Ashley Lai <ashley@ahsleylai.com>
    Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 575bc4a16cd2250b4f195bb90791425e102f6249
Author: Christophe Ricard <christophe.ricard@gmail.com>
Date:   Mon Dec 1 19:32:46 2014 +0100

    tpm/tpm_i2c_stm_st33: Fix potential bug in tpm_stm_i2c_send
    
    commit 1ba3b0b6f218072afe8372d12f1b6bf26a26008e upstream.
    
    When sending data in tpm_stm_i2c_send, each loop iteration send buf.
    Send buf + i instead as the goal of this for loop is to send a number
    of byte from buf that fit in burstcnt. Once those byte are sent, we are
    supposed to send the next ones.
    
    The driver was working because the burstcount value returns always the maximum size for a TPM
    command or response. (0x800 for a command and 0x400 for a response).
    
    Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
    Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3d968940750288bc44a256a01aba105db6aa3d87
Author: Hon Ching (Vicky) Lo <honclo@linux.vnet.ibm.com>
Date:   Sun Nov 30 15:01:28 2014 +0100

    tpm: Fix NULL return in tpm_ibmvtpm_get_desired_dma
    
    commit 84eb186bc37c0900b53077ca21cf6dd15823a232 upstream.
    
    There was an oops in tpm_ibmvtpm_get_desired_dma, which caused
    kernel panic during boot when vTPM is enabled in Power partition
    configured in AMS mode.
    
    vio_bus_probe calls vio_cmo_bus_probe which calls
    tpm_ibmvtpm_get_desired_dma to get the size needed for DMA allocation.
    The problem is, vio_cmo_bus_probe is called before calling probe, which
    for vtpm is tpm_ibmvtpm_probe and it's this function that initializes
    and sets up vtpm's CRQ and gets required data values.  Therefore,
    since this has not yet been done, NULL is returned in attempt to get
    the size for DMA allocation.
    
    We added a NULL check.  In addition, a default buffer size will
    be set when NULL is returned.
    
    Signed-off-by: Hon Ching (Vicky) Lo <honclo@linux.vnet.ibm.com>
    Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b896ee9736f7798c225cbe711ec3eb6f18a8a608
Author: David Howells <dhowells@redhat.com>
Date:   Fri Aug 29 10:33:02 2014 +0100

    TPM: Add new TPMs to the tail of the list to prevent inadvertent change of dev
    
    commit 398a1e71dc827b994b7f2f56c7c2186fea7f8d75 upstream.
    
    Add newly registered TPMs to the tail of the list, not the beginning, so that
    things that are specifying TPM_ANY_NUM don't find that the device they're
    using has inadvertently changed.  Adding a second device would break IMA, for
    instance.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8b931191735976c2d8ec914a9433f4316982d5d6
Author: Scot Doyle <lkml14@scotdoyle.com>
Date:   Wed Sep 24 22:41:10 2014 +0000

    tpm_tis: verify interrupt during init
    
    commit 448e9c55c12d6bd4fa90a7e31d802e045666d7c8 upstream.
    
    Some machines, such as the Acer C720 and Toshiba CB35, have TPMs that do
    not send IRQs while also having an ACPI TPM entry indicating that they
    will be sent. These machines freeze on resume while the tpm_tis module
    waits for an IRQ, eventually timing out.
    
    When in interrupt mode, the tpm_tis module should receive an IRQ during
    module init. Fall back to polling mode if none is received when expected.
    
    Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
    Tested-by: Michael Mullin <masmullin@gmail.com>
    Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    [phuewe: minor checkpatch fixed]
    Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f202b8119ba14714fa1e496f784fee51dc480420
Author: Robert Nelson <robertcnelson@gmail.com>
Date:   Tue Feb 24 10:10:43 2015 -0600

    ARM: dts: am335x-bone*: usb0 is hardwired for peripheral
    
    commit 67fd14b3eca63b14429350e9eadc5fab709a8821 upstream.
    
    Fixes: http://bugs.elinux.org/issues/127
    
    the bb.org community was seeing random reboots before this change.
    
    Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
    Reviewed-by: Felipe Balbi <balbi@ti.com>
    Acked-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bb401d9bb4959a88f3bbb4861fdadc7939cf4eeb
Author: Lokesh Vutla <lokeshvutla@ti.com>
Date:   Thu Jan 8 17:22:04 2015 +0530

    ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3
    
    commit 1c7e36bfc3e2fb2df5e2d1989a4b6fb9055a0f9b upstream.
    
    With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset()
    with DEBUG_LL' we moved from parsing cmdline to identify uart used
    for earlycon to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.
    
    On DRA7 UART3 hwmod doesn't have this flag enabled, and atleast on
    BeagleBoard-X15, where we use UART3 for console, boot fails with
    DEBUG_LL enabled. Enable DEBUG_OMAP4UART3_FLAGS for UART3 hwmod.
    
    For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig.
    
    Fixes: 90020c7b2c5e ("ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data")
    Reviewed-by: Felipe Balbi <balbi@ti.com>
    Acked-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
    Signed-off-by: Paul Walmsley <paul@pwsan.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2b14545fae3daa39f6b05c5ce32e956292303c87
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date:   Thu Jan 15 03:06:22 2015 +0100

    ARM: 8284/1: sa1100: clear RCSR_SMR on resume
    
    commit e461894dc2ce7778ccde1c3483c9b15a85a7fc5f upstream.
    
    StrongARM core uses RCSR SMR bit to tell to bootloader that it was reset
    by entering the sleep mode. After we have resumed, there is little point
    in having that bit enabled. Moreover, if this bit is set before reboot,
    the bootloader can become confused. Thus clear the SMR bit on resume
    just before clearing the scratchpad (resume address) register.
    
    Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d016c1bd3d9f062b27e6f36c5c339f88e25a4712
Author: Vikram Mulukutla <markivx@codeaurora.org>
Date:   Wed Dec 17 18:50:56 2014 -0800

    tracing: Fix unmapping loop in tracing_mark_write
    
    commit 7215853e985a4bef1a6c14e00e89dfec84f1e457 upstream.
    
    Commit 6edb2a8a385f0cdef51dae37ff23e74d76d8a6ce introduced
    an array map_pages that contains the addresses returned by
    kmap_atomic. However, when unmapping those pages, map_pages[0]
    is unmapped before map_pages[1], breaking the nesting requirement
    as specified in the documentation for kmap_atomic/kunmap_atomic.
    
    This was caught by the highmem debug code present in kunmap_atomic.
    Fix the loop to do the unmapping properly.
    
    Link: http://lkml.kernel.org/r/1418871056-6614-1-git-send-email-markivx@codeaurora.org
    
    Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
    Reported-by: Lime Yang <limey@codeaurora.org>
    Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 28d388537dd995cb375177495d1bcd1512415b04
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Feb 11 15:25:19 2015 -0800

    mm/hugetlb: pmd_huge() returns true for non-present hugepage
    
    commit cbef8478bee55775ac312a574aad48af7bb9cf9f upstream.
    
    Migrating hugepages and hwpoisoned hugepages are considered as non-present
    hugepages, and they are referenced via migration entries and hwpoison
    entries in their page table slots.
    
    This behavior causes race condition because pmd_huge() doesn't tell
    non-huge pages from migrating/hwpoisoned hugepages.  follow_page_mask() is
    one example where the kernel would call follow_page_pte() for such
    hugepage while this function is supposed to handle only normal pages.
    
    To avoid this, this patch makes pmd_huge() return true when pmd_none() is
    true *and* pmd_present() is false.  We don't have to worry about mixing up
    non-present pmd entry with normal pmd (pointing to leaf level pte entry)
    because pmd_present() is true in normal pmd.
    
    The same race condition could happen in (x86-specific) gup_pmd_range(),
    where this patch simply adds pmd_present() check instead of pmd_huge().
    This is because gup_pmd_range() is fast path.  If we have non-present
    hugepage in this function, we will go into gup_huge_pmd(), then return 0
    at flag mask check, and finally fall back to the slow path.
    
    Fixes: 290408d4a2 ("hugetlb: hugepage migration core")
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Luiz Capitulino <lcapitulino@redhat.com>
    Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
    Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2301499b1269fbca843e7fa164c2a9e9de27892d
Author: James Hogan <james.hogan@imgtec.com>
Date:   Thu May 29 10:16:32 2014 +0100

    MIPS: KVM: Deliver guest interrupts after local_irq_disable()
    
    commit 044f0f03eca0110e1835b2ea038a484b93950328 upstream.
    
    When about to run the guest, deliver guest interrupts after disabling
    host interrupts. This should prevent an hrtimer interrupt from being
    handled after delivering guest interrupts, and therefore not delivering
    the guest timer interrupt until after the next guest exit.
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: kvm@vger.kernel.org
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: Sanjay Lal <sanjayl@kymasys.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2f81b70c20407bde921e519fb0154fd5de66ce66
Author: Jeff Layton <jlayton@primarydata.com>
Date:   Wed Jan 14 13:08:57 2015 -0500

    nfs: don't call blocking operations while !TASK_RUNNING
    
    commit 6ffa30d3f734d4f6b478081dfc09592021028f90 upstream.
    
    Bruce reported seeing this warning pop when mounting using v4.1:
    
         ------------[ cut here ]------------
         WARNING: CPU: 1 PID: 1121 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0()
        do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff810ff58f>] prepare_to_wait+0x2f/0x90
        Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer ppdev joydev snd virtio_console virtio_balloon pcspkr serio_raw parport_pc parport pvpanic floppy soundcore i2c_piix4 virtio_blk virtio_net qxl drm_kms_helper ttm drm virtio_pci virtio_ring ata_generic virtio pata_acpi
        CPU: 1 PID: 1121 Comm: nfsv4.1-svc Not tainted 3.19.0-rc4+ #25
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153950- 04/01/2014
         0000000000000000 000000004e5e3f73 ffff8800b998fb48 ffffffff8186ac78
         0000000000000000 ffff8800b998fba0 ffff8800b998fb88 ffffffff810ac9da
         ffff8800b998fb68 ffffffff81c923e7 00000000000004d9 0000000000000000
        Call Trace:
         [<ffffffff8186ac78>] dump_stack+0x4c/0x65
         [<ffffffff810ac9da>] warn_slowpath_common+0x8a/0xc0
         [<ffffffff810aca65>] warn_slowpath_fmt+0x55/0x70
         [<ffffffff810ff58f>] ? prepare_to_wait+0x2f/0x90
         [<ffffffff810ff58f>] ? prepare_to_wait+0x2f/0x90
         [<ffffffff810dd2ad>] __might_sleep+0xbd/0xd0
         [<ffffffff8124c973>] kmem_cache_alloc_trace+0x243/0x430
         [<ffffffff810d941e>] ? groups_alloc+0x3e/0x130
         [<ffffffff810d941e>] groups_alloc+0x3e/0x130
         [<ffffffffa0301b1e>] svcauth_unix_accept+0x16e/0x290 [sunrpc]
         [<ffffffffa0300571>] svc_authenticate+0xe1/0xf0 [sunrpc]
         [<ffffffffa02fc564>] svc_process_common+0x244/0x6a0 [sunrpc]
         [<ffffffffa02fd044>] bc_svc_process+0x1c4/0x260 [sunrpc]
         [<ffffffffa03d5478>] nfs41_callback_svc+0x128/0x1f0 [nfsv4]
         [<ffffffff810ff970>] ? wait_woken+0xc0/0xc0
         [<ffffffffa03d5350>] ? nfs4_callback_svc+0x60/0x60 [nfsv4]
         [<ffffffff810d45bf>] kthread+0x11f/0x140
         [<ffffffff810ea815>] ? local_clock+0x15/0x30
         [<ffffffff810d44a0>] ? kthread_create_on_node+0x250/0x250
         [<ffffffff81874bfc>] ret_from_fork+0x7c/0xb0
         [<ffffffff810d44a0>] ? kthread_create_on_node+0x250/0x250
        ---[ end trace 675220a11e30f4f2 ]---
    
    nfs41_callback_svc does most of its work while in TASK_INTERRUPTIBLE,
    which is just wrong. Fix that by finishing the wait immediately if we've
    found that the list has something on it.
    
    Also, we don't expect this kthread to accept signals, so we should be
    using a TASK_UNINTERRUPTIBLE sleep instead. That however, opens us up
    hung task warnings from the watchdog, so have the schedule_timeout
    wake up every 60s if there's no callback activity.
    
    Reported-by: "J. Bruce Fields" <bfields@fieldses.org>
    Signed-off-by: Jeff Layton <jlayton@primarydata.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 04333c0b73dfddeba3d2bdeb5198b220b4a21695
Author: Jisheng Zhang <jszhang@marvell.com>
Date:   Wed Jan 28 19:54:12 2015 +0800

    mmc: sdhci-pxav3: fix setting of pdata->clk_delay_cycles
    
    commit 14460dbaf7a5a0488963fdb8232ad5c8a8cca7b7 upstream.
    
    Current code checks "clk_delay_cycles > 0" to know whether the optional
    "mrvl,clk_delay_cycles" is set or not. But of_property_read_u32() doesn't
    touch clk_delay_cycles if the property is not set. And type of
    clk_delay_cycles is u32, so we may always set pdata->clk_delay_cycles as a
    random value.
    
    This patch fix this problem by check the return value of of_property_read_u32()
    to know whether the optional clk-delay-cycles is set or not.
    
    Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5e1b3dc7688187c293c3005696b0a917b9286383
Author: Sumit.Saxena@avagotech.com <Sumit.Saxena@avagotech.com>
Date:   Mon Jan 5 20:06:13 2015 +0530

    megaraid_sas: disable interrupt_mask before enabling hardware interrupts
    
    commit c2ced1719a1b903350955a511e1666e6d05a7f5b upstream.
    
    Update driver "mask_interrupts" before enable/disable hardware interrupt
    in order to avoid missing interrupts because of "mask_interrupts" still
    set to 1 and hardware interrupts are enabled.
    
    Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
    Signed-off-by: Chaitra Basappa <chaitra.basappa@avagotech.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 20f1c8780877115f2292d56ad209d1f17c611386
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Mon Jan 5 09:51:48 2015 +0100

    power: bq24190: Fix ignored supplicants
    
    commit 478913fdbdfd4a781d91c993eb86838620fe7421 upstream.
    
    The driver mismatched 'num_supplicants' with 'num_supplies' of
    power_supply structure.
    
    It provided list of supplicants (power_supply.supplied_to) but did
    not set the number of supplicants. Instead it set the num_supplies which
    is used when iterating over number of supplies (power_supply.supplied_from).
    
    As a result the list of supplicants was ignored by core because its size
    was 0.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Fixes: d7bf353fd0aa ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
    Signed-off-by: Sebastian Reichel <sre@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit af3de02edc2dd1f2cf959a98863e02bee8398373
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Jan 27 16:51:54 2015 +0100

    power_supply: 88pm860x: Fix leaked power supply on probe fail
    
    commit 24727b45b484e8937dcde53fa8d1aa70ac30ec0c upstream.
    
    Driver forgot to unregister power supply if request_threaded_irq()
    failed in probe(). In such case the memory associated with power supply
    leaked.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Fixes: a830d28b48bf ("power_supply: Enable battery-charger for 88pm860x")
    Signed-off-by: Sebastian Reichel <sre@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a80c93292402eaa3c19bbbff9afca82c8df54e13
Author: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Date:   Tue Feb 10 11:33:50 2015 +0100

    ALSA: hdspm - Constrain periods to 2 on older cards
    
    commit f0153c3d948c1764f6c920a0675d86fc1d75813e upstream.
    
    RME RayDAT and AIO use a fixed buffer size of 16384 samples. With period
    sizes of 32-4096, this translates to 4-512 periods.
    
    The older RME cards have a variable buffer size but require exactly two
    periods.
    
    This patch enforces nperiods=2 on those cards.
    
    Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 60a5053935e8ec6f707b876406b0c5f94998bbd0
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Feb 9 16:51:40 2015 +0300

    ALSA: off by one bug in snd_riptide_joystick_probe()
    
    commit e4940626defdf6c92da1052ad3f12741c1a28c90 upstream.
    
    The problem here is that we check:
    
    	if (dev >= SNDRV_CARDS)
    
    Then we increment "dev".
    
           if (!joystick_port[dev++])
    
    Then we use it as an offset into a array with SNDRV_CARDS elements.
    
    	if (!request_region(joystick_port[dev], 8, "Riptide gameport")) {
    
    This has 3 effects:
    1) If you use the module option to specify the joystick port then it has
       to be shifted one space over.
    2) The wrong error message will be printed on failure if you have over
       32 cards.
    3) Static checkers will correctly complain that are off by one.
    
    Fixes: db1005ec6ff8 ('ALSA: riptide - Fix joystick resource handling')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 63935f3ded0fb12df5b9b53d88f628d34b3d6867
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Fri Jan 2 10:56:28 2015 -0300

    lmedm04: Fix usb_submit_urb BOGUS urb xfer, pipe 1 != type 3 in interrupt urb
    
    commit 15e1ce33182d1d5dbd8efe8d382b9352dc857527 upstream.
    
    A quirk of some older firmwares that report endpoint pipe type as PIPE_BULK
    but the endpoint otheriwse functions as interrupt.
    
    Check if usb_endpoint_type is USB_ENDPOINT_XFER_BULK and set as usb_rcvbulkpipe.
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9e012b00fcb631454ab30d588adf2156ac8426c2
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Mon Jan 19 13:19:38 2015 +0000

    xen/manage: Fix USB interaction issues when resuming
    
    commit 72978b2fe2f2cdf9f319c6c6dcdbe92b38de2be2 upstream.
    
    Commit 61a734d305e1 ("xen/manage: Always freeze/thaw processes when
    suspend/resuming") ensured that userspace processes were always frozen
    before suspending to reduce interaction issues when resuming devices.
    However, freeze_processes() does not freeze kernel threads.  Freeze
    kernel threads as well to prevent deadlocks with the khubd thread when
    resuming devices.
    
    This is what native suspend and resume does.
    
    Example deadlock:
    [ 7279.648010]  [<ffffffff81446bde>] ? xen_poll_irq_timeout+0x3e/0x50
    [ 7279.648010]  [<ffffffff81448d60>] xen_poll_irq+0x10/0x20
    [ 7279.648010]  [<ffffffff81011723>] xen_lock_spinning+0xb3/0x120
    [ 7279.648010]  [<ffffffff810115d1>] __raw_callee_save_xen_lock_spinning+0x11/0x20
    [ 7279.648010]  [<ffffffff815620b6>] ? usb_control_msg+0xe6/0x120
    [ 7279.648010]  [<ffffffff81747e50>] ? _raw_spin_lock_irq+0x50/0x60
    [ 7279.648010]  [<ffffffff8174522c>] wait_for_completion+0xac/0x160
    [ 7279.648010]  [<ffffffff8109c520>] ? try_to_wake_up+0x2c0/0x2c0
    [ 7279.648010]  [<ffffffff814b60f2>] dpm_wait+0x32/0x40
    [ 7279.648010]  [<ffffffff814b6eb0>] device_resume+0x90/0x210
    [ 7279.648010]  [<ffffffff814b7d71>] dpm_resume+0x121/0x250
    [ 7279.648010]  [<ffffffff8144c570>] ? xenbus_dev_request_and_reply+0xc0/0xc0
    [ 7279.648010]  [<ffffffff814b80d5>] dpm_resume_end+0x15/0x30
    [ 7279.648010]  [<ffffffff81449fba>] do_suspend+0x10a/0x200
    [ 7279.648010]  [<ffffffff8144a2f0>] ? xen_pre_suspend+0x20/0x20
    [ 7279.648010]  [<ffffffff8144a1d0>] shutdown_handler+0x120/0x150
    [ 7279.648010]  [<ffffffff8144c60f>] xenwatch_thread+0x9f/0x160
    [ 7279.648010]  [<ffffffff810ac510>] ? finish_wait+0x80/0x80
    [ 7279.648010]  [<ffffffff8108d189>] kthread+0xc9/0xe0
    [ 7279.648010]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
    [ 7279.648010]  [<ffffffff8175087c>] ret_from_fork+0x7c/0xb0
    [ 7279.648010]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
    
    [ 7441.216287] INFO: task khubd:89 blocked for more than 120 seconds.
    [ 7441.219457]       Tainted: G            X 3.13.11-ckt12.kz #1
    [ 7441.222176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 7441.225827] khubd           D ffff88003f433440     0    89      2 0x00000000
    [ 7441.229258]  ffff88003ceb9b98 0000000000000046 ffff88003ce83000 0000000000013440
    [ 7441.232959]  ffff88003ceb9fd8 0000000000013440 ffff88003cd13000 ffff88003ce83000
    [ 7441.236658]  0000000000000286 ffff88003d3e0000 ffff88003ceb9bd0 00000001001aa01e
    [ 7441.240415] Call Trace:
    [ 7441.241614]  [<ffffffff817442f9>] schedule+0x29/0x70
    [ 7441.243930]  [<ffffffff81743406>] schedule_timeout+0x166/0x2c0
    [ 7441.246681]  [<ffffffff81075b80>] ? call_timer_fn+0x110/0x110
    [ 7441.249339]  [<ffffffff8174357e>] schedule_timeout_uninterruptible+0x1e/0x20
    [ 7441.252644]  [<ffffffff81077710>] msleep+0x20/0x30
    [ 7441.254812]  [<ffffffff81555f00>] hub_port_reset+0xf0/0x580
    [ 7441.257400]  [<ffffffff81558465>] hub_port_init+0x75/0xb40
    [ 7441.259981]  [<ffffffff814bb3c9>] ? update_autosuspend+0x39/0x60
    [ 7441.262817]  [<ffffffff814bb4f0>] ? pm_runtime_set_autosuspend_delay+0x50/0xa0
    [ 7441.266212]  [<ffffffff8155a64a>] hub_thread+0x71a/0x1750
    [ 7441.268728]  [<ffffffff810ac510>] ? finish_wait+0x80/0x80
    [ 7441.271272]  [<ffffffff81559f30>] ? usb_port_resume+0x670/0x670
    [ 7441.274067]  [<ffffffff8108d189>] kthread+0xc9/0xe0
    [ 7441.276305]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
    [ 7441.279131]  [<ffffffff8175087c>] ret_from_fork+0x7c/0xb0
    [ 7441.281659]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 206b039ce24d1c5d021b218808622f8d2378f6d5
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Feb 18 21:55:03 2015 +0100

    cpufreq: s3c: remove incorrect __init annotations
    
    commit 61882b63171736571e1139ab5aa929e3bb336016 upstream.
    
    The two functions s3c2416_cpufreq_driver_init and s3c_cpufreq_register
    are marked init but are called from a context that might be run after
    the __init sections are discarded, as the compiler points out:
    
    WARNING: vmlinux.o(.data+0x1ad9dc): Section mismatch in reference from the variable s3c2416_cpufreq_driver to the function .init.text:s3c2416_cpufreq_driver_init()
    WARNING: drivers/built-in.o(.text+0x35b5dc): Section mismatch in reference from the function s3c2410a_cpufreq_add() to the function .init.text:s3c_cpufreq_register()
    
    This removes the __init markings.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 442a17659cc37544aced0dca46cbde54278cff68
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Feb 9 13:38:17 2015 -0500

    cpufreq: speedstep-smi: enable interrupts when waiting
    
    commit d4d4eda23794c701442e55129dd4f8f2fefd5e4d upstream.
    
    On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the
    speedstep-smi driver sometimes loads and sometimes doesn't load with
    "change to state X failed" message.
    
    The hardware sometimes refuses to change frequency and in this case, we
    need to retry later. I found out that we need to enable interrupts while
    waiting. When we enable interrupts, the hardware blockage that prevents
    frequency transition resolves and the transition is possible. With
    disabled interrupts, the blockage doesn't resolve (no matter how long do
    we wait). The exact reasons for this hardware behavior are unknown.
    
    This patch enables interrupts in the function speedstep_set_state that can
    be called with disabled interrupts. However, this function is called with
    disabled interrupts only from speedstep_get_freqs, so it shouldn't cause
    any problem.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bd4b3c108399d1f842472b77bde81d090d936f0f
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Mon Jan 19 17:53:20 2015 +0900

    PCI: Fix infinite loop with ROM image of size 0
    
    commit 16b036af31e1456cb69243a5a0c9ef801ecd1f17 upstream.
    
    If the image size would ever read as 0, pci_get_rom_size() could keep
    processing the same image over and over again.  Exit the loop if we ever
    read a length of zero.
    
    This fixes a soft lockup on boot when the radeon driver calls
    pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card.
    
    [bhelgaas: changelog, reference]
    Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973
    Reported-by: Federico <federicotg@gmail.com>
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 109102cb30e106fd9e06dcd49a0abfcabacb6439
Author: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Date:   Tue Dec 2 17:35:04 2014 +0100

    PCI: Generate uppercase hex for modalias var in uevent
    
    commit 145b3fe579db66fbe999a2bc3fd5b63dffe9636d upstream.
    
    Some implementations of modprobe fail to load the driver for a PCI device
    automatically because the "interface" part of the modalias from the kernel
    is lowercase, and the modalias from file2alias is uppercase.
    
    The "interface" is the low-order byte of the Class Code, defined in PCI
    r3.0, Appendix D.  Most interface types defined in the spec do not use
    alpha characters, so they won't be affected.  For example, 00h, 01h, 10h,
    20h, etc. are unaffected.
    
    Print the "interface" byte of the Class Code in uppercase hex, as we
    already do for the Vendor ID, Device ID, Class, etc.
    
    Commit 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface
    class") fixed only half of the problem.  Some udev implementations rely on
    the uevent file and not the modalias file.
    
    Fixes: d1ded203adf1 ("PCI: add MODALIAS to hotplug event for pci devices")
    Fixes: 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface class")
    Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 86705a9be3029fc8a1c287f421eecd89b4a68504
Author: Seth Forshee <seth.forshee@canonical.com>
Date:   Fri Feb 20 11:45:11 2015 -0600

    HID: i2c-hid: Limit reads to wMaxInputLength bytes for input events
    
    commit 6d00f37e49d95e640a3937a4a1ae07dbe92a10cb upstream.
    
    d1c7e29e8d27 (HID: i2c-hid: prevent buffer overflow in early IRQ)
    changed hid_get_input() to read ihid->bufsize bytes, which can be
    more than wMaxInputLength. This is the case with the Dell XPS 13
    9343, and it is causing events to be missed. In some cases the
    missed events are releases, which can cause the cursor to jump or
    freeze, among other problems. Limit the number of bytes read to
    min(wMaxInputLength, ihid->bufsize) to prevent such problems.
    
    Fixes: d1c7e29e8d27 "HID: i2c-hid: prevent buffer overflow in early IRQ"
    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a113cc3fe1778e770eb5c77a34dc03ecd5fe8da6
Author: Luciano Coelho <luciano.coelho@intel.com>
Date:   Thu Jan 29 12:48:20 2015 +0200

    iwlwifi: mvm: always use mac color zero
    
    commit 5523d11cc46393a1e61b7ef4a0b2d4e7ed9521e4 upstream.
    
    We don't really need to use different mac colors when adding mac
    contexts, because they're not used anywhere.  In fact, the firmware
    doesn't accept 255 as a valid color, so we get into a SYSASSERT 0x3401
    when we reach that.
    
    Remove the color increment to use always zero and avoid reaching 255.
    
    Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9bb35f06515d463d4f1b384b9fc41c4e17cf69aa
Author: Eyal Shapira <eyal@wizery.com>
Date:   Fri Jan 16 11:09:30 2015 +0200

    iwlwifi: mvm: validate tid and sta_id in ba_notif
    
    commit 2cee4762c528a9bd2cdff793197bf591a2196c11 upstream.
    
    These are coming from the FW and are used to access arrays.
    Bad values can cause an out of bounds access so discard
    such ba_notifs and warn.
    
    Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ecbc35f50f8a32abac5b16546c31cf85db3e1eb6
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Thu Jan 29 21:34:00 2015 +0200

    iwlwifi: pcie: disable the SCD_BASE_ADDR when we resume from WoWLAN
    
    commit cd8f438405032ac8ff88bd8f2eca5e0c0063b14b upstream.
    
    The base address of the scheduler in the device's memory
    (SRAM) comes from two different sources. The periphery
    register and the alive notification from the firmware.
    We have a check in iwl_pcie_tx_start that ensures that
    they are the same.
    When we resume from WoWLAN, the firmware may have crashed
    for whatever reason. In that case, the whole device may be
    reset which means that the periphery register will hold a
    meaningless value. When we come to compare
    trans_pcie->scd_base_addr (which really holds the value we
    had when we loaded the WoWLAN firmware upon suspend) and
    the current value of the register, we don't see a match
    unsurprisingly.
    Trick the check to avoid a loud yet harmless WARN.
    Note that when the WoWLAN has crashed, we will see that
    in iwl_trans_pcie_d3_resume which will let the op_mode
    know. Once the op_mode is informed that the WowLAN firmware
    has crashed, it can't do much besides resetting the whole
    device.
    
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 30858d77dc3fe065af5125fc3bdc0c48251d98e4
Author: Jan Kara <jack@suse.cz>
Date:   Tue Feb 10 14:08:32 2015 -0800

    fsnotify: fix handling of renames in audit
    
    commit 6ee8e25fc3e916193bce4ebb43d5439e1e2144ab upstream.
    
    Commit e9fd702a58c4 ("audit: convert audit watches to use fsnotify
    instead of inotify") broke handling of renames in audit.  Audit code
    wants to update inode number of an inode corresponding to watched name
    in a directory.  When something gets renamed into a directory to a
    watched name, inotify previously passed moved inode to audit code
    however new fsnotify code passes directory inode where the change
    happened.  That confuses audit and it starts watching parent directory
    instead of a file in a directory.
    
    This can be observed for example by doing:
    
      cd /tmp
      touch foo bar
      auditctl -w /tmp/foo
      touch foo
      mv bar foo
      touch foo
    
    In audit log we see events like:
    
      type=CONFIG_CHANGE msg=audit(1423563584.155:90): auid=1000 ses=2 op="updated rules" path="/tmp/foo" key=(null) list=4 res=1
      ...
      type=PATH msg=audit(1423563584.155:91): item=2 name="bar" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
      type=PATH msg=audit(1423563584.155:91): item=3 name="foo" inode=1046842 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
      type=PATH msg=audit(1423563584.155:91): item=4 name="foo" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE
      ...
    
    and that's it - we see event for the first touch after creating the
    audit rule, we see events for rename but we don't see any event for the
    last touch.  However we start seeing events for unrelated stuff
    happening in /tmp.
    
    Fix the problem by passing moved inode as data in the FS_MOVED_FROM and
    FS_MOVED_TO events instead of the directory where the change happens.
    This doesn't introduce any new problems because noone besides
    audit_watch.c cares about the passed value:
    
      fs/notify/fanotify/fanotify.c cares only about FSNOTIFY_EVENT_PATH events.
      fs/notify/dnotify/dnotify.c doesn't care about passed 'data' value at all.
      fs/notify/inotify/inotify_fsnotify.c uses 'data' only for FSNOTIFY_EVENT_PATH.
      kernel/audit_tree.c doesn't care about passed 'data' at all.
      kernel/audit_watch.c expects moved inode as 'data'.
    
    Fixes: e9fd702a58c49db ("audit: convert audit watches to use fsnotify instead of inotify")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: Paul Moore <paul@paul-moore.com>
    Cc: Eric Paris <eparis@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 33699d3505d3d2b6b9abdc3a9bcdec0a942c94eb
Author: Dave Chinner <dchinner@redhat.com>
Date:   Thu Jan 22 09:30:23 2015 +1100

    xfs: set superblock buffer type correctly
    
    commit 3443a3bca54588f43286b725d8648d33a38c86f1 upstream.
    
    When the superblock is modified in a transaction, the commonly
    modified fields are not actually copied to the superblock buffer to
    avoid the buffer lock becoming a serialisation point. However, there
    are some other operations that modify the superblock fields within
    the transaction that don't directly log to the superblock but rely
    on the changes to be applied during the transaction commit (to
    minimise the buffer lock hold time).
    
    When we do this, we fail to mark the buffer log item as being a
    superblock buffer and that can lead to the buffer not being marked
    with the corect type in the log and hence causing recovery issues.
    Fix it by setting the type correctly, similar to xfs_mod_sb()...
    
    Tested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7baee9ce9c11ecc371eff4b6b79572ee1822a8ad
Author: Dave Chinner <dchinner@redhat.com>
Date:   Thu Jan 22 09:29:40 2015 +1100

    xfs: inode unlink does not set AGI buffer type
    
    commit f19b872b086711bb4b22c3a0f52f16aa920bcc61 upstream.
    
    This leads to log recovery throwing errors like:
    
    XFS (md0): Mounting V5 Filesystem
    XFS (md0): Starting recovery (logdev: internal)
    XFS (md0): Unknown buffer type 0!
    XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1
    ffff8800ffc53800: 58 41 47 49 .....
    
    Which is the AGI buffer magic number.
    
    Ensure that we set the type appropriately in both unlink list
    addition and removal.
    
    Tested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a48f1a6bfc3ee997dfd719eaecb44a05477b93e2
Author: Dave Chinner <dchinner@redhat.com>
Date:   Thu Jan 22 09:29:05 2015 +1100

    xfs: ensure buffer types are set correctly
    
    commit 0d612fb570b71ea2e49554a770cff4c489018b2c upstream.
    
    Jan Kara reported that log recovery was finding buffers with invalid
    types in them. This should not happen, and indicates a bug in the
    logging of buffers. To catch this, add asserts to the buffer
    formatting code to ensure that the buffer type is in range when the
    transaction is committed.
    
    We don't set a type on buffers being marked stale - they are not
    going to get replayed, the format item exists only for recovery to
    be able to prevent replay of the buffer, so the type does not
    matter. Hence that needs special casing here.
    
    Reported-by: Jan Kara <jack@suse.cz>
    Tested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>