commit a8e202812b52b88e2a33d52687b3b0260706231a
Author: Sasha Levin <alexander.levin@verizon.com>
Date:   Sat Sep 17 18:55:26 2016 -0400

    Linux 3.18.42
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit cac5e8f4791997a95521012b29e656171c4ab90d
Author: Sasha Levin <alexander.levin@verizon.com>
Date:   Thu Sep 15 18:55:24 2016 -0400

    Revert "ARC: mm: don't loose PTE_SPECIAL in pte_modify()"
    
    This reverts commit 77c6ffdbce68688492a31702f67c7dbc4eeedd62.
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 7c17faccf5276b2a85dadb877d2abc3e73041213
Author: Emanuel Czirai <icanrealizeum@gmail.com>
Date:   Fri Sep 2 07:35:50 2016 +0200

    x86/AMD: Apply erratum 665 on machines without a BIOS fix
    
    [ Upstream commit d1992996753132e2dafe955cccb2fb0714d3cfc4 ]
    
    AMD F12h machines have an erratum which can cause DIV/IDIV to behave
    unpredictably. The workaround is to set MSRC001_1029[31] but sometimes
    there is no BIOS update containing that workaround so let's do it
    ourselves unconditionally. It is simple enough.
    
    [ Borislav: Wrote commit message. ]
    
    Signed-off-by: Emanuel Czirai <icanrealizeum@gmail.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Yaowu Xu <yaowu@google.com>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/20160902053550.18097-1-bp@alien8.de
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 18ec3adc3d999b303bcf0e1cb907d7dbfb645677
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Wed May 25 13:47:26 2016 -0400

    x86/paravirt: Do not trace _paravirt_ident_*() functions
    
    [ Upstream commit 15301a570754c7af60335d094dd2d1808b0641a5 ]
    
    Łukasz Daniluk reported that on a RHEL kernel that his machine would lock up
    after enabling function tracer. I asked him to bisect the functions within
    available_filter_functions, which he did and it came down to three:
    
      _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64()
    
    It was found that this is only an issue when noreplace-paravirt is added
    to the kernel command line.
    
    This means that those functions are most likely called within critical
    sections of the funtion tracer, and must not be traced.
    
    In newer kenels _paravirt_nop() is defined within gcc asm(), and is no
    longer an issue.  But both _paravirt_ident_{32,64}() causes the
    following splat when they are traced:
    
     mm/pgtable-generic.c:33: bad pmd ffff8800d2435150(0000000001d00054)
     mm/pgtable-generic.c:33: bad pmd ffff8800d3624190(0000000001d00070)
     mm/pgtable-generic.c:33: bad pmd ffff8800d36a5110(0000000001d00054)
     mm/pgtable-generic.c:33: bad pmd ffff880118eb1450(0000000001d00054)
     NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [systemd-journal:469]
     Modules linked in: e1000e
     CPU: 2 PID: 469 Comm: systemd-journal Not tainted 4.6.0-rc4-test+ #513
     Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
     task: ffff880118f740c0 ti: ffff8800d4aec000 task.ti: ffff8800d4aec000
     RIP: 0010:[<ffffffff81134148>]  [<ffffffff81134148>] queued_spin_lock_slowpath+0x118/0x1a0
     RSP: 0018:ffff8800d4aefb90  EFLAGS: 00000246
     RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88011eb16d40
     RDX: ffffffff82485760 RSI: 000000001f288820 RDI: ffffea0000008030
     RBP: ffff8800d4aefb90 R08: 00000000000c0000 R09: 0000000000000000
     R10: ffffffff821c8e0e R11: 0000000000000000 R12: ffff880000200fb8
     R13: 00007f7a4e3f7000 R14: ffffea000303f600 R15: ffff8800d4b562e0
     FS:  00007f7a4e3d7840(0000) GS:ffff88011eb00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00007f7a4e3f7000 CR3: 00000000d3e71000 CR4: 00000000001406e0
     Call Trace:
       _raw_spin_lock+0x27/0x30
       handle_pte_fault+0x13db/0x16b0
       handle_mm_fault+0x312/0x670
       __do_page_fault+0x1b1/0x4e0
       do_page_fault+0x22/0x30
       page_fault+0x28/0x30
       __vfs_read+0x28/0xe0
       vfs_read+0x86/0x130
       SyS_read+0x46/0xa0
       entry_SYSCALL_64_fastpath+0x1e/0xa8
     Code: 12 48 c1 ea 0c 83 e8 01 83 e2 30 48 98 48 81 c2 40 6d 01 00 48 03 14 c5 80 6a 5d 82 48 89 0a 8b 41 08 85 c0 75 09 f3 90 8b 41 08 <85> c0 74 f7 4c 8b 09 4d 85 c9 74 08 41 0f 18 09 eb 02 f3 90 8b
    
    Reported-by: Łukasz Daniluk <lukasz.daniluk@intel.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit f45724343a4a5399386f8df3e548445fc9056c48
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu Sep 1 11:12:00 2016 +0200

    ovl: listxattr: use strnlen()
    
    [ Upstream commit 7cb35119d067191ce9ebc380a599db0b03cbd9d9 ]
    
    Be defensive about what underlying fs provides us in the returned xattr
    list buffer.  If it's not properly null terminated, bail out with a warning
    insead of BUG.
    
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit cc318bc6819922ad17dbcbb5e0ac5164bcbb60d2
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu Sep 1 11:11:59 2016 +0200

    ovl: remove posix_acl_default from workdir
    
    [ Upstream commit c11b9fdd6a612f376a5e886505f1c54c16d8c380 ]
    
    Clear out posix acl xattrs on workdir and also reset the mode after
    creation so that an inherited sgid bit is cleared.
    
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 0b764b2ea1ac39a0d41f49250c8b21b244710025
Author: Tejun Heo <tj@kernel.org>
Date:   Fri Jun 17 17:51:17 2016 -0400

    kernfs: don't depend on d_find_any_alias() when generating notifications
    
    [ Upstream commit df6a58c5c5aa8ecb1e088ecead3fa33ae70181f1 ]
    
    kernfs_notify_workfn() sends out file modified events for the
    scheduled kernfs_nodes.  Because the modifications aren't from
    userland, it doesn't have the matching file struct at hand and can't
    use fsnotify_modify().  Instead, it looked up the inode and then used
    d_find_any_alias() to find the dentry and used fsnotify_parent() and
    fsnotify() directly to generate notifications.
    
    The assumption was that the relevant dentries would have been pinned
    if there are listeners, which isn't true as inotify doesn't pin
    dentries at all and watching the parent doesn't pin the child dentries
    even for dnotify.  This led to, for example, inotify watchers not
    getting notifications if the system is under memory pressure and the
    matching dentries got reclaimed.  It can also be triggered through
    /proc/sys/vm/drop_caches or a remount attempt which involves shrinking
    dcache.
    
    fsnotify_parent() only uses the dentry to access the parent inode,
    which kernfs can do easily.  Update kernfs_notify_workfn() so that it
    uses fsnotify() directly for both the parent and target inodes without
    going through d_find_any_alias().  While at it, supply the target file
    name to fsnotify() from kernfs_node->name.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Evgeny Vereshchagin <evvers@ya.ru>
    Fixes: d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events too")
    Cc: John McCutchan <john@johnmccutchan.com>
    Cc: Robert Love <rlove@rlove.org>
    Cc: Eric Paris <eparis@parisplace.org>
    Cc: stable@vger.kernel.org # v3.16+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 01d0c457d826d81481c8f4485ada438d0d565ce6
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Aug 30 09:51:44 2016 -0700

    dm crypt: fix free of bad values after tfm allocation failure
    
    [ Upstream commit 5d0be84ec0cacfc7a6d6ea548afdd07d481324cd ]
    
    If crypt_alloc_tfms() had to allocate multiple tfms and it failed before
    the last allocation, then it would call crypt_free_tfms() and could free
    pointers from uninitialized memory -- due to the crypt_free_tfms() check
    for non-zero cc->tfms[i].  Fix by allocating zeroed memory.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit ab50c732d66fa6d9c614ad4b5dda6500c4fe57b8
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Aug 30 16:38:42 2016 -0400

    dm crypt: fix error with too large bios
    
    [ Upstream commit 4e870e948fbabf62b78e8410f04c67703e7c816b ]
    
    When dm-crypt processes writes, it allocates a new bio in
    crypt_alloc_buffer().  The bio is allocated from a bio set and it can
    have at most BIO_MAX_PAGES vector entries, however the incoming bio can be
    larger (e.g. if it was allocated by bcache).  If the incoming bio is
    larger, bio_alloc_bioset() fails and an error is returned.
    
    To avoid the error, we test for a too large bio in the function
    crypt_map() and use dm_accept_partial_bio() to split the bio.
    dm_accept_partial_bio() trims the current bio to the desired size and
    asks DM core to send another bio with the rest of the data.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org # v3.16+
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 13312f0f2c1f9135934c3f68a80a261717c1503e
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Mon Aug 29 11:15:36 2016 -0400

    NFSv4.x: Fix a refcount leak in nfs_callback_up_net
    
    [ Upstream commit 98b0f80c2396224bbbed81792b526e6c72ba9efa ]
    
    On error, the callers expect us to return without bumping
    nn->cb_users[].
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Cc: stable@vger.kernel.org # v3.7+
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 4ff77f223a63b18745c4a202970682f138d056cc
Author: Dave Chinner <dchinner@redhat.com>
Date:   Fri Aug 26 16:01:30 2016 +1000

    xfs: fix superblock inprogress check
    
    [ Upstream commit f3d7ebdeb2c297bd26272384e955033493ca291c ]
    
    From inspection, the superblock sb_inprogress check is done in the
    verifier and triggered only for the primary superblock via a
    "bp->b_bn == XFS_SB_DADDR" check.
    
    Unfortunately, the primary superblock is an uncached buffer, and
    hence it is configured by xfs_buf_read_uncached() with:
    
            bp->b_bn = XFS_BUF_DADDR_NULL;  /* always null for uncached buffers */
    
    And so this check never triggers. Fix it.
    
    cc: <stable@vger.kernel.org>
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit b735daae7a6afccbdd2338f11d818dfaac2e9fef
Author: Aleksandr Makarov <aleksandr.o.makarov@gmail.com>
Date:   Wed Aug 24 13:06:22 2016 +0300

    USB: serial: option: add WeTelecom 0x6802 and 0x6803 products
    
    [ Upstream commit 40d9c32525cba79130612650b1abc47c0c0f19a8 ]
    
    These product IDs are listed in Windows driver.
    0x6803 corresponds to WeTelecom WM-D300.
    0x6802 name is unknown.
    
    Signed-off-by: Aleksandr Makarov <aleksandr.o.makarov@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit a6eba2f73bf3e402829724d7bfb736c609467d0f
Author: Aleksandr Makarov <aleksandr.o.makarov@gmail.com>
Date:   Sat Aug 20 13:29:41 2016 +0300

    USB: serial: option: add WeTelecom WM-D200
    
    [ Upstream commit 6695593e4a7659db49ac6eca98c164f7b5589f72 ]
    
    Add support for WeTelecom WM-D200.
    
    T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=22de ProdID=6801 Rev=00.00
    S:  Manufacturer=WeTelecom Incorporated
    S:  Product=WeTelecom Mobile Products
    C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    
    Signed-off-by: Aleksandr Makarov <aleksandr.o.makarov@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit e066faf1b61036126cbc3163fa370d4247e880dc
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Aug 23 15:32:51 2016 -0400

    USB: avoid left shift by -1
    
    [ Upstream commit 53e5f36fbd2453ad69a3369a1db62dc06c30a4aa ]
    
    UBSAN complains about a left shift by -1 in proc_do_submiturb().  This
    can occur when an URB is submitted for a bulk or control endpoint on
    a high-speed device, since the code doesn't bother to check the
    endpoint type; normally only interrupt or isochronous endpoints have
    a nonzero bInterval value.
    
    Aside from the fact that the operation is illegal, it shouldn't matter
    because the result isn't used.  Still, in theory it could cause a
    hardware exception or other problem, so we should work around it.
    This patch avoids doing the left shift unless the shift amount is >= 0.
    
    The same piece of code has another problem.  When checking the device
    speed (the exponential encoding for interrupt endpoints is used only
    by high-speed or faster devices), we need to look for speed >=
    USB_SPEED_SUPER as well as speed == USB_SPEED HIGH.  The patch adds
    this check.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Vittorio Zecca <zeccav@gmail.com>
    Tested-by: Vittorio Zecca <zeccav@gmail.com>
    Suggested-by: Bjørn Mork <bjorn@mork.no>
    CC: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 93c7ae51294639d51ef0f6fbc722daae0544f873
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Aug 16 15:33:28 2016 +0200

    iio: accel: kxsd9: Fix raw read return
    
    [ Upstream commit 7ac61a062f3147dc23e3f12b9dfe7c4dd35f9cb8 ]
    
    Any readings from the raw interface of the KXSD9 driver will
    return an empty string, because it does not return
    IIO_VAL_INT but rather some random value from the accelerometer
    to the caller.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 6ef28f2f902ae5921048d7c4e6913ca4e38a1f3c
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Tue Jul 19 12:17:39 2016 +0100

    staging: comedi: ni_mio_common: fix AO inttrig backwards compatibility
    
    [ Upstream commit f0f4b0cc3a8cffd983f5940d46cd0227f3f5710a ]
    
    Commit ebb657babfa9 ("staging: comedi: ni_mio_common: clarify the
    cmd->start_arg validation and use") introduced a backwards compatibility
    issue in the use of asynchronous commands on the AO subdevice when
    `start_src` is `TRIG_EXT`.  Valid values for `start_src` are `TRIG_INT`
    (for internal, software trigger), and `TRIG_EXT` (for external trigger).
    When set to `TRIG_EXT`.  In both cases, the driver relies on an
    internal, software trigger to set things up (allowing the user
    application to write sufficient samples to the data buffer before the
    trigger), so it acts as a software "pre-trigger" in the `TRIG_EXT` case.
    The software trigger is handled by `ni_ao_inttrig()`.
    
    Prior to the above change, when `start_src` was `TRIG_INT`, `start_arg`
    was required to be 0, and `ni_ao_inttrig()` checked that the software
    trigger number was also 0.  After the above change, when `start_src` was
    `TRIG_INT`, any value was allowed for `start_arg`, and `ni_ao_inttrig()`
    checked that the software trigger number matched this `start_arg` value.
    The backwards compatibility issue is that the internal trigger number
    now has to match `start_arg` when `start_src` is `TRIG_EXT` when it
    previously had to be 0.
    
    Fix the backwards compatibility issue in `ni_ao_inttrig()` by always
    allowing software trigger number 0 when `start_src` is something other
    than `TRIG_INT`.
    
    Thanks to Spencer Olson for reporting the issue.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Reported-by: Spencer Olson <olsonse@umich.edu>
    Fixes: ebb657babfa9 ("staging: comedi: ni_mio_common: clarify the cmd->start_arg validation and use")
    Cc: stable <stable@vger.kernel.org>
    Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 985f3f2373e5f14936d866a823939766321b94e4
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Wed Jul 20 17:07:34 2016 +0100

    staging: comedi: ni_mio_common: fix wrong insn_write handler
    
    [ Upstream commit 5ca05345c56cb979e1a25ab6146437002f95cac8 ]
    
    For counter subdevices, the `s->insn_write` handler is being set to the
    wrong function, `ni_tio_insn_read()`.  It should be
    `ni_tio_insn_write()`.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Reported-by: Éric Piel <piel@delmic.com>
    Fixes: 10f74377eec3 ("staging: comedi: ni_tio: make ni_tio_winsn() a
      proper comedi (*insn_write)"
    Cc: <stable@vger.kernel.org> # 3.17+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit d8107af012415fd200de7786da8f4ebbab6cf834
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Wed Jun 29 20:27:44 2016 +0100

    staging: comedi: daqboard2000: bug fix board type matching code
    
    [ Upstream commit 80e162ee9b31d77d851b10f8c5299132be1e120f ]
    
    `daqboard2000_find_boardinfo()` is supposed to check if the
    DaqBoard/2000 series model is supported, based on the PCI subvendor and
    subdevice ID.  The current code is wrong as it is comparing the PCI
    device's subdevice ID to an expected, fixed value for the subvendor ID.
    It should be comparing the PCI device's subvendor ID to this fixed
    value.  Correct it.
    
    Fixes: 7e8401b23e7f ("staging: comedi: daqboard2000: add back
    subsystem_device check")
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Cc: <stable@vger.kernel.org> # 3.7+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 178bc9085d938641a1d02dba2a3b0b4f8ecf79e9
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Fri Aug 12 01:05:09 2016 +0300

    USB: serial: mos7840: fix non-atomic allocation in write path
    
    [ Upstream commit 3b7c7e52efda0d4640060de747768360ba70a7c0 ]
    
    There is an allocation with GFP_KERNEL flag in mos7840_write(),
    while it may be called from interrupt context.
    
    Follow-up for commit 191252837626 ("USB: kobil_sct: fix non-atomic
    allocation in write path")
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit a1147c771a69625aaea70924cd7128ba35a2a74c
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Fri Aug 12 01:05:08 2016 +0300

    USB: serial: mos7720: fix non-atomic allocation in write path
    
    [ Upstream commit 5a5a1d614287a647b36dff3f40c2b0ceabbc83ec ]
    
    There is an allocation with GFP_KERNEL flag in mos7720_write(),
    while it may be called from interrupt context.
    
    Follow-up for commit 191252837626 ("USB: kobil_sct: fix non-atomic
    allocation in write path")
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 87fe0cd807d1974f852be46f19771813bc355991
Author: Zefan Li <lizefan@huawei.com>
Date:   Tue Aug 9 11:25:01 2016 +0800

    cpuset: make sure new tasks conform to the current config of the cpuset
    
    [ Upstream commit 06f4e94898918bcad00cdd4d349313a439d6911e ]
    
    A new task inherits cpus_allowed and mems_allowed masks from its parent,
    but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems
    before this new task is inserted into the cgroup's task list, the new task
    won't be updated accordingly.
    
    Signed-off-by: Zefan Li <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 5edbe377024b8f702463e1cf6bb32048e9bce8d8
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Mon Aug 8 15:08:49 2016 +0200

    ovl: don't copy up opaqueness
    
    [ Upstream commit 0956254a2d5b9e2141385514553aeef694dfe3b5 ]
    
    When a copy up of a directory occurs which has the opaque xattr set, the
    xattr remains in the upper directory. The immediate behavior with overlayfs
    is that the upper directory is not treated as opaque, however after a
    remount the opaque flag is used and upper directory is treated as opaque.
    This causes files created in the lower layer to be hidden when using
    multiple lower directories.
    
    Fix by not copying up the opaque flag.
    
    To reproduce:
    
     ----8<---------8<---------8<---------8<---------8<---------8<----
    mkdir -p l/d/s u v w mnt
    mount -t overlay overlay -olowerdir=l,upperdir=u,workdir=w mnt
    rm -rf mnt/d/
    mkdir -p mnt/d/n
    umount mnt
    mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt
    touch mnt/d/foo
    umount mnt
    mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt
    ls mnt/d
     ----8<---------8<---------8<---------8<---------8<---------8<----
    
    output should be:  "foo  n"
    
    Reported-by: Derek McGowan <dmcg@drizz.net>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=151291
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit ade4ba0d843dff6c430d00a88e55e373762de825
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Mon Aug 1 00:51:02 2016 -0400

    ext4: validate that metadata blocks do not overlap superblock
    
    [ Upstream commit 829fa70dddadf9dd041d62b82cd7cea63943899d ]
    
    A number of fuzzing failures seem to be caused by allocation bitmaps
    or other metadata blocks being pointed at the superblock.
    
    This can cause kernel BUG or WARNings once the superblock is
    overwritten, so validate the group descriptor blocks to make sure this
    doesn't happen.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit db9e37a1c5f21cec095da9ed53a2c0cbeeb24ee6
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Dec 28 20:47:08 2015 -0500

    [PATCH] arm: fix handling of F_OFD_... in oabi_fcntl64()
    
    [ Upstream commit 76cc404bfdc0d419c720de4daaf2584542734f42 ]
    
    Cc: stable@vger.kernel.org # 3.15+
    Reviewed-by: Jeff Layton <jeff.layton@primarydata.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>