commit 07dd6cc1fff160143e82cf5df78c1db0b6e03355
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 13 14:21:49 2017 -0700

    Linux 4.13.2

commit 24cb33252843e531194e78222af2d8afb75fac5f
Author: Richard Wareing <rwareing@fb.com>
Date:   Wed Sep 13 09:09:35 2017 +1000

    xfs: XFS_IS_REALTIME_INODE() should be false if no rt device present
    
    commit b31ff3cdf540110da4572e3e29bd172087af65cc upstream.
    
    If using a kernel with CONFIG_XFS_RT=y and we set the RHINHERIT flag on
    a directory in a filesystem that does not have a realtime device and
    create a new file in that directory, it gets marked as a real time file.
    When data is written and a fsync is issued, the filesystem attempts to
    flush a non-existent rt device during the fsync process.
    
    This results in a crash dereferencing a null buftarg pointer in
    xfs_blkdev_issue_flush():
    
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      IP: xfs_blkdev_issue_flush+0xd/0x20
      .....
      Call Trace:
        xfs_file_fsync+0x188/0x1c0
        vfs_fsync_range+0x3b/0xa0
        do_fsync+0x3d/0x70
        SyS_fsync+0x10/0x20
        do_syscall_64+0x4d/0xb0
        entry_SYSCALL64_slow_path+0x25/0x25
    
    Setting RT inode flags does not require special privileges so any
    unprivileged user can cause this oops to occur.  To reproduce, confirm
    kernel is compiled with CONFIG_XFS_RT=y and run:
    
      # mkfs.xfs -f /dev/pmem0
      # mount /dev/pmem0 /mnt/test
      # mkdir /mnt/test/foo
      # xfs_io -c 'chattr +t' /mnt/test/foo
      # xfs_io -f -c 'pwrite 0 5m' -c fsync /mnt/test/foo/bar
    
    Or just run xfstests with MKFS_OPTIONS="-d rtinherit=1" and wait.
    
    Kernels built with CONFIG_XFS_RT=n are not exposed to this bug.
    
    Fixes: f538d4da8d52 ("[XFS] write barrier support")
    Signed-off-by: Richard Wareing <rwareing@fb.com>
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41a5f0a2a8323077533ebc32d1d7cfeb5454457d
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sat Aug 19 10:10:34 2017 -0400

    NFSv4: Fix up mirror allocation
    
    commit 14abcb0bf59a30cf65a74f6c6f53974cd7224bc6 upstream.
    
    There are a number of callers of nfs_pageio_complete() that want to
    continue using the nfs_pageio_descriptor without needing to call
    nfs_pageio_init() again. Examples include nfs_pageio_resend() and
    nfs_pageio_cond_complete().
    
    The problem is that nfs_pageio_complete() also calls
    nfs_pageio_cleanup_mirroring(), which frees up the array of mirrors.
    This can lead to writeback errors, in the next call to
    nfs_pageio_setup_mirroring().
    
    Fix by simply moving the allocation of the mirrors to
    nfs_pageio_setup_mirroring().
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=196709
    Reported-by: JianhongYin <yin-jianhong@163.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c8c0359f0a03864e24a5a5877a69c35bf0b2f92
Author: tarangg@amazon.com <tarangg@amazon.com>
Date:   Thu Sep 7 09:29:23 2017 -0400

    NFS: Sync the correct byte range during synchronous writes
    
    commit e973b1a5999e57da677ab50da5f5479fdc0f0c31 upstream.
    
    Since commit 18290650b1c8 ("NFS: Move buffered I/O locking into
    nfs_file_write()") nfs_file_write() has not flushed the correct byte
    range during synchronous writes.  generic_write_sync() expects that
    iocb->ki_pos points to the right edge of the range rather than the
    left edge.
    
    To replicate the problem, open a file with O_DSYNC, have the client
    write at increasing offsets, and then print the successful offsets.
    Block port 2049 partway through that sequence, and observe that the
    client application indicates successful writes in advance of what the
    server received.
    
    Fixes: 18290650b1c8 ("NFS: Move buffered I/O locking into nfs_file_write()")
    Signed-off-by: Jacob Strauss <jsstraus@amazon.com>
    Signed-off-by: Tarang Gupta <tarangg@amazon.com>
    Tested-by: Tarang Gupta <tarangg@amazon.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65631fea43758154f0e7b7ab23a906aaa97ad780
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Fri Sep 8 21:28:11 2017 -0400

    NFS: Fix 2 use after free issues in the I/O code
    
    commit 196639ebbe63a037fe9a80669140bd292d8bcd80 upstream.
    
    The writeback code wants to send a commit after processing the pages,
    which is why we want to delay releasing the struct path until after
    that's done.
    
    Also, the layout code expects that we do not free the inode before
    we've put the layout segments in pnfs_writehdr_free() and
    pnfs_readhdr_free()
    
    Fixes: 919e3bd9a875 ("NFS: Ensure we commit after writeback is complete")
    Fixes: 4714fb51fd03 ("nfs: remove pgio_header refcount, related cleanup")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03466e0324224a0de496f4ea720c5e6dd863a3e5
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue Aug 22 11:36:17 2017 +0100

    ARM: 8692/1: mm: abort uaccess retries upon fatal signal
    
    commit 746a272e44141af24a02f6c9b0f65f4c4598ed42 upstream.
    
    When there's a fatal signal pending, arm's do_page_fault()
    implementation returns 0. The intent is that we'll return to the
    faulting userspace instruction, delivering the signal on the way.
    
    However, if we take a fatal signal during fixing up a uaccess, this
    results in a return to the faulting kernel instruction, which will be
    instantly retried, resulting in the same fault being taken forever. As
    the task never reaches userspace, the signal is not delivered, and the
    task is left unkillable. While the task is stuck in this state, it can
    inhibit the forward progress of the system.
    
    To avoid this, we must ensure that when a fatal signal is pending, we
    apply any necessary fixup for a faulting kernel instruction. Thus we
    will return to an error path, and it is up to that code to make forward
    progress towards delivering the fatal signal.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Steve Capper <steve.capper@arm.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f6eba3f72f008766a42a5fe0719f0c8385e337c
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Sat Jul 1 15:16:34 2017 +0100

    ARM64: dts: marvell: armada-37xx: Fix GIC maintenance interrupt
    
    commit 95696d292e204073433ed2ef3ff4d3d8f42a8248 upstream.
    
    The GIC-500 integrated in the Armada-37xx SoCs is compliant with
    the GICv3 architecture, and thus provides a maintenance interrupt
    that is required for hypervisors to function correctly.
    
    With the interrupt provided in the DT, KVM now works as it should.
    Tested on an Espressobin system.
    
    Fixes: adbc3695d9e4 ("arm64: dts: add the Marvell Armada 3700 family and a development board")
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb372097356d450b890aaadbfc45deecbe27e3e7
Author: Ben Seri <ben@armis.com>
Date:   Sat Sep 9 23:15:59 2017 +0200

    Bluetooth: Properly check L2CAP config option output buffer length
    
    commit e860d2c904d1a9f38a24eb44c9f34b8f915a6ea3 upstream.
    
    Validate the output buffer length for L2CAP config requests and responses
    to avoid overflowing the stack buffer used for building the option blocks.
    
    Signed-off-by: Ben Seri <ben@armis.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef96511782dd5ad18f000bc88f1f69c34373b8ac
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Aug 25 17:04:15 2017 +0200

    rt2800: fix TX_PIN_CFG setting for non MT7620 chips
    
    commit 83ec489193894e52bd395eec470f4f7c4286d4a5 upstream.
    
    Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not
    initialize TX_PIN_CFG setting. This cause breakage at least on some
    RT3573 devices. To fix the problem patch restores previous behaviour
    for non MT7620 chips.
    
    Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829
    Reported-and-tested-by: Jussi Eloranta <jussi.eloranta@csun.edu>
    Cc: Daniel Golle <daniel@makrotopia.org>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Daniel Golle <daniel@makrotopia.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da341114674be5add8b72d44b8897c9dd0bc9432
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Sep 10 21:19:06 2017 -0700

    Revert "firmware: add sanity check on shutdown/suspend"
    
    commit f007cad159e99fa2acd3b2e9364fbb32ad28b971 upstream.
    
    This reverts commit 81f95076281fdd3bc382e004ba1bce8e82fccbce.
    
    It causes random failures of firmware loading at resume time (well,
    random for me, it seems to be more reliable for others) because the
    firmware disabling is not actually synchronous with any particular
    resume event, and at least the btusb driver that uses a workqueue to
    load the firmware at resume seems to occasionally hit the "firmware
    loading is disabled" logic because the firmware loader hasn't gotten the
    resume event yet.
    
    Some kind of sanity check for not trying to load firmware when it's not
    possible might be a good thing, but this commit was not it.
    
    Greg seems to have silently suffered the same issue, and pointed to the
    likely culprit, and Gabriel C verified the revert fixed it for him too.
    
    Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
    Pointed-at-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Tested-by: Gabriel C <nix.or.die@gmail.com>
    Cc: Luis R. Rodriguez <mcgrof@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d7960e036cc72f46fbd2bec82aacf57382d53d0
Author: Brijesh Singh <brijesh.singh@amd.com>
Date:   Mon Aug 7 14:11:30 2017 -0500

    KVM: SVM: Limit PFERR_NESTED_GUEST_PAGE error_code check to L1 guest
    
    commit 64531a3b70b17c8d3e77f2e49e5e1bb70f571266 upstream.
    
    Commit 147277540bbc ("kvm: svm: Add support for additional SVM NPF error
    codes", 2016-11-23) added a new error code to aid nested page fault
    handling.  The commit unprotects (kvm_mmu_unprotect_page) the page when
    we get a NPF due to guest page table walk where the page was marked RO.
    
    However, if an L0->L2 shadow nested page table can also be marked read-only
    when a page is read only in L1's nested page table.  If such a page
    is accessed by L2 while walking page tables it can cause a nested
    page fault (page table walks are write accesses).  However, after
    kvm_mmu_unprotect_page we may get another page fault, and again in an
    endless stream.
    
    To cover this use case, we qualify the new error_code check with
    vcpu->arch.mmu_direct_map so that the error_code check would run on L1
    guest, and not the L2 guest.  This avoids hitting the above scenario.
    
    Fixes: 147277540bbc54119172481c8ef6d930cc9fbfc2
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: Thomas Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21d9f614bda72f3df578dda4d895135b413fcca3
Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Date:   Fri Sep 8 16:13:12 2017 -0700

    mm/memory.c: fix mem_cgroup_oom_disable() call missing
    
    commit de0c799bba2610a8e1e9a50d76a28614520a4cd4 upstream.
    
    Seen while reading the code, in handle_mm_fault(), in the case
    arch_vma_access_permitted() is failing the call to
    mem_cgroup_oom_disable() is not made.
    
    To fix that, move the call to mem_cgroup_oom_enable() after calling
    arch_vma_access_permitted() as it should not have entered the memcg OOM.
    
    Link: http://lkml.kernel.org/r/1504625439-31313-1-git-send-email-ldufour@linux.vnet.ibm.com
    Fixes: bae473a423f6 ("mm: introduce fault_env")
    Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
    Acked-by: Kirill A. Shutemov <kirill@shutemov.name>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bbb3b440526ae37c2ae5a3e8218cc693d675ac6
Author: Michal Hocko <mhocko@suse.com>
Date:   Fri Sep 8 16:13:15 2017 -0700

    mm/sparse.c: fix typo in online_mem_sections
    
    commit b4ccec41af82b5a5518c6534444412961894f07c upstream.
    
    online_mem_sections() accidentally marks online only the first section
    in the given range.  This is a typo which hasn't been noticed because I
    haven't tested large 2GB blocks previously.  All users of
    pfn_to_online_page would get confused on the the rest of the pfn range
    in the block.
    
    All we need to fix this is to use iterator (pfn) rather than start_pfn.
    
    Link: http://lkml.kernel.org/r/20170904112210.3401-1-mhocko@kernel.org
    Fixes: 2d070eab2e82 ("mm: consider zone which is not fully populated to have holes")
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76bf61477a2da0ae5b5a522a3200bdb241e41d66
Author: David Rientjes <rientjes@google.com>
Date:   Fri Sep 8 16:13:29 2017 -0700

    mm/swapfile.c: fix swapon frontswap_map memory leak on error
    
    commit b6b1fd2a6bedd533aeed83924d7be0e944fded9f upstream.
    
    Free frontswap_map if an error is encountered before enable_swap_info().
    
    Signed-off-by: David Rientjes <rientjes@google.com>
    Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
    Cc: Darrick J. Wong <darrick.wong@oracle.com>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36f31cb67a9197bdaa251c822752cab7263ebeed
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Fri Sep 8 16:13:25 2017 -0700

    mm: kvfree the swap cluster info if the swap file is unsatisfactory
    
    commit 8606a1a94da5c4e49c0fb28af62d2e75c6747716 upstream.
    
    If initializing a small swap file fails because the swap file has a
    problem (holes, etc.) then we need to free the cluster info as part of
    cleanup.  Unfortunately a previous patch changed the code to use kvzalloc
    but did not change all the vfree calls to use kvfree.
    
    Found by running generic/357 from xfstests.
    
    Link: http://lkml.kernel.org/r/20170831233515.GR3775@magnolia
    Fixes: 54f180d3c181 ("mm, swap: use kvzalloc to allocate some swap data structures")
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7d1c698567caf9333a9e3d78f392d4495b9384a
Author: Andy Lutomirski <luto@kernel.org>
Date:   Tue Aug 1 07:11:36 2017 -0700

    selftests/x86/fsgsbase: Test selectors 1, 2, and 3
    
    commit 23d98c204386a98d9ef9f9e744f41443ece4929f upstream.
    
    Those are funny cases.  Make sure they work.
    
    (Something is screwy with signal handling if a selector is 1, 2, or 3.
    Anyone who wants to dive into that rabbit hole is welcome to do so.)
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Borislav Petkov <bpetkov@suse.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Chang Seok <chang.seok.bae@intel.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 860da008a6ccf477480cdac91c4a3826a314fbb8
Author: Shuah Khan <shuahkh@osg.samsung.com>
Date:   Thu Aug 17 16:34:43 2017 -0600

    selftests: timers: Fix run_destructive_tests target to handle skipped tests
    
    commit df9c011c0a23cf1399c01f896cd359d932ab49b5 upstream.
    
    When a test exits with skip exit code of 4, "make run_destructive_tests"
    halts testing. Fix run_destructive_tests target to handle error exit codes.
    
    Reported-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88df15a346fca5afdf1270c7186ffe3841839f64
Author: John Stultz <john.stultz@linaro.org>
Date:   Fri Aug 18 16:23:32 2017 -0700

    kselftests: timers: leap-a-day: Change default arguments to help test runs
    
    commit 98b74e1f31045a63f6148b2d129ca9bf244e24ab upstream.
    
    Change default arguments for leap-a-day to always set the time
    each iteration (rather then waiting for midnight UTC), and to
    only run 10 interations (rather then infinite).
    
    If one wants to wait for midnight UTC, they can use the new -w
    flag, and we add a note to the argument help that -i -1 will
    run infinitely.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Miroslav Lichvar <mlichvar@redhat.com>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Stephen Boyd <stephen.boyd@linaro.org>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: linux-kselftest@vger.kernel.org
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 138f24b8442a62bf5155d49b4334fe375d6394df
Author: Ian W MORRISON <ianwmorrison@gmail.com>
Date:   Thu Aug 31 08:51:03 2017 +1000

    brcmfmac: feature check for multi-scheduled scan fails on bcm4345 devices
    
    commit f957dd3c8db2781c8a334b166800788feb618625 upstream.
    
    The firmware feature check introduced for multi-scheduled scan is also
    failing for bcm4345 devices resulting in a firmware crash.
    The reason for this crash has not yet been root cause so this patch avoids
    the feature check for those device as a short-term fix.
    
    Fixes: 9fe929aaace6 ("brcmfmac: add firmware feature detection for gscan feature")
    Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com>
    Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 260f116ededdd4aa00490b3184b716811496c051
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Sep 8 16:15:54 2017 -0700

    radix-tree: must check __radix_tree_preload() return value
    
    commit bc9ae2247ac92fd4d962507bafa3afffff6660ff upstream.
    
    __radix_tree_preload() only disables preemption if no error is returned.
    
    So we really need to make sure callers always check the return value.
    
    idr_preload() contract is to always disable preemption, so we need
    to add a missing preempt_disable() if an error happened.
    
    Similarly, ida_pre_get() only needs to call preempt_enable() in the
    case no error happened.
    
    Link: http://lkml.kernel.org/r/1504637190.15310.62.camel@edumazet-glaptop3.roam.corp.google.com
    Fixes: 0a835c4f090a ("Reimplement IDR and IDA using the radix tree")
    Fixes: 7ad3d4d85c7a ("ida: Move ida_bitmap to a percpu variable")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Matthew Wilcox <mawilcox@microsoft.com>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8f30b44cd481c035465c87f9c1806819661de07
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Sep 4 12:51:34 2017 -0500

    rtlwifi: btcoexist: Fix antenna selection code
    
    commit 6d622692836950b3c943776f84c4557ff6c02f3b upstream.
    
    In commit 87d8a9f35202 ("rtlwifi: btcoex: call bind to setup btcoex"),
    the code turns on a call to exhalbtc_bind_bt_coex_withadapter(). This
    routine contains a bug that causes incorrect antenna selection for those
    HP laptops with only one antenna and an incorrectly programmed EFUSE.
    These boxes are the ones that need the ant_sel module parameter.
    
    Fixes: 87d8a9f35202 ("rtlwifi: btcoex: call bind to setup btcoex")
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Ping-Ke Shih <pkshih@realtek.com>
    Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
    Cc: Birming Chiu <birming@realtek.com>
    Cc: Shaofu <shaofu@realtek.com>
    Cc: Steven Ting <steventing@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 753eaaf7f754ac9b86408629bf4be4e97364899c
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Sep 4 12:51:33 2017 -0500

    rtlwifi: btcoexist: Fix breakage of ant_sel for rtl8723be
    
    commit a33fcba6ec01efcca33b1afad91057020f247f15 upstream.
    
    In commit bcd37f4a0831 ("rtlwifi: btcoex: 23b 2ant: let bt transmit when
    hw initialisation done"), there is an additional error when the module
    parameter ant_sel is used to select the auxilary antenna. The error is
    that the antenna selection is not checked when writing the antenna
    selection register.
    
    Fixes: bcd37f4a0831 ("rtlwifi: btcoex: 23b 2ant: let bt transmit when hw initialisation done")
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Ping-Ke Shih <pkshih@realtek.com>
    Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
    Cc: Birming Chiu <birming@realtek.com>
    Cc: Shaofu <shaofu@realtek.com>
    Cc: Steven Ting <steventing@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ac0376748c3dc75b0d05091b8cc71d54593f198
Author: Aleksa Sarai <asarai@suse.de>
Date:   Tue Jul 4 21:49:06 2017 +1000

    btrfs: resume qgroup rescan on rw remount
    
    commit 6c6b5a39c4bf3dbd8cf629c9f5450e983c19dbb9 upstream.
    
    Several distributions mount the "proper root" as ro during initrd and
    then remount it as rw before pivot_root(2). Thus, if a rescan had been
    aborted by a previous shutdown, the rescan would never be resumed.
    
    This issue would manifest itself as several btrfs ioctl(2)s causing the
    entire machine to hang when btrfs_qgroup_wait_for_completion was hit
    (due to the fs_info->qgroup_rescan_running flag being set but the rescan
    itself not being resumed). Notably, Docker's btrfs storage driver makes
    regular use of BTRFS_QUOTA_CTL_DISABLE and BTRFS_IOC_QUOTA_RESCAN_WAIT
    (causing this problem to be manifested on boot for some machines).
    
    Cc: Jeff Mahoney <jeffm@suse.com>
    Fixes: b382a324b60f ("Btrfs: fix qgroup rescan resume on mount")
    Signed-off-by: Aleksa Sarai <asarai@suse.de>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Tested-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1bd28c3000115550253578e0fd6c60c3630e438
Author: Daniel Verkamp <daniel.verkamp@intel.com>
Date:   Wed Aug 30 15:18:19 2017 -0700

    nvme-fabrics: generate spec-compliant UUID NQNs
    
    commit 40a5fce495715c48c2e02668144e68a507ac5a30 upstream.
    
    The default host NQN, which is generated based on the host's UUID,
    does not follow the UUID-based NQN format laid out in the NVMe 1.3
    specification.  Remove the "NVMf:" portion of the NQN to match the spec.
    
    Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
    Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a80fc009a5d39193fe29841242795b9a84ac1171
Author: Abhishek Sahu <absahu@codeaurora.org>
Date:   Thu Aug 3 17:56:39 2017 +0200

    mtd: nand: qcom: fix config error for BCH
    
    commit 10777de570016471fd929869c7830a7772893e39 upstream.
    
    The configuration for BCH is not correct in the current driver.
    The ECC_CFG_ECC_DISABLE bit defines whether to enable or disable the
    BCH ECC in which
    
            0x1 : BCH_DISABLED
            0x0 : BCH_ENABLED
    
    But currently host->bch_enabled is being assigned to BCH_DISABLED.
    
    Fixes: c76b78d8ec05a ("mtd: nand: Qualcomm NAND controller driver")
    Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
    Reviewed-by: Archit Taneja <architt@codeaurora.org>
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c8643b0e1ac6b60104b83436a8f351075419dab
Author: Abhishek Sahu <absahu@codeaurora.org>
Date:   Fri Aug 11 17:09:16 2017 +0530

    mtd: nand: qcom: fix read failure without complete bootchain
    
    commit d8a9b320a26c1ea28e51e4f3ecfb593d5aac2910 upstream.
    
    The NAND page read fails without complete boot chain since
    NAND_DEV_CMD_VLD value is not proper. The default power on reset
    value for this register is
    
        0xe - ERASE_START_VALID | WRITE_START_VALID | READ_STOP_VALID
    
    The READ_START_VALID should be enabled for sending PAGE_READ
    command. READ_STOP_VALID should be cleared since normal NAND
    page read does not require READ_STOP command.
    
    Fixes: c76b78d8ec05a ("mtd: nand: Qualcomm NAND controller driver")
    Reviewed-by: Archit Taneja <architt@codeaurora.org>
    Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 020e08094a8ea94c760c8661a0a96a2a9de1fda7
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
Date:   Fri Nov 25 11:32:32 2016 +0100

    mtd: nand: mxc: Fix mxc_v1 ooblayout
    
    commit 3bff08dffe3115a25ce04b95ea75f6d868572c60 upstream.
    
    Commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
    introduced a bug in the OOB layout description. Even if the driver claims
    that 3 ECC bytes are reserved to protect 512 bytes of data, it's actually
    5 ECC bytes to protect 512+6 bytes of data (some OOB bytes are also
    protected using extra ECC bytes).
    
    Fix the mxc_v1_ooblayout_{free,ecc}() functions to reflect this behavior.
    
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Fixes: a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03aa762613569d2211b5a6b9d14eff1acafe2ca4
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sat Aug 5 14:16:24 2017 +0200

    mtd: nand: hynix: add support for 20nm NAND chips
    
    commit fd213b5bae800dc00a2930dcd07f63ab9bbff3f9 upstream.
    
    According to the datasheet of the H27UCG8T2BTR the NAND Technology field
    (6th byte of the "Device Identifier Description", bits 0-2) the
    following values are possible:
    - 0x0 = 48nm
    - 0x1 = 41nm
    - 0x2 = 32nm
    - 0x3 = 26nm
    - 0x4 = 20nm
    - (all others are reserved)
    
    Fix this by extending the mask for this field to allow detecting value
    0x4 (20nm) as valid NAND technology.
    Without this the detection of the ECC requirements fails, because the
    code assumes that the device is a 48nm device (0x4 & 0x3 = 0x0) and
    aborts with "Invalid ECC requirements" because it cannot map the "ECC
    Level". Extending the mask makes the ECC requirement detection code
    recognize this chip as <= 26nm and sets up the ECC step size and ECC
    strength correctly.
    
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Fixes: 78f3482d7480 ("mtd: nand: hynix: Rework NAND ID decoding to extract more information")
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f22616ad598ac90b8e8eae52657bb7f7f42222c4
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Tue Aug 29 12:17:12 2017 +0200

    mtd: nand: make Samsung SLC NAND usable again
    
    commit 69fc01296c92814b62dbfba1600fe7ed2ed304f5 upstream.
    
    commit c51d0ac59f24 ("mtd: nand: Move Samsung specific init/detection
    logic in nand_samsung.c") introduced a regression for Samsung SLC NAND
    chips. Prior to this commit chip->bits_per_cell was initialized by calling
    nand_get_bits_per_cell() before using nand_is_slc().
    With the offending commit this call is skipped, leaving
    chip->bits_per_cell cleared to zero when the manufacturer specific
    '.detect' function calls nand_is_slc() which in turn interprets
    bits_per_cell != 1 as indication for an MLC chip.
    The effect is that e.g. a K9F1G08U0F NAND chip is falsely detected as
    MLC NAND with 4KiB page size rather than SLC with 2KiB page size.
    
    Add a call to nand_get_bits_per_cell() before calling the .detect hook
    function in nand_manufacturer_detect(), so that the nand_is_slc()
    calls in the manufacturer specific code will return correct results.
    
    Fixes: c51d0ac59f24 ("mtd: nand: Move Samsung specific init/detection logic in nand_samsung.c")
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>