commit c0305995d3676c8f7764eb79a7f99de8d18c591a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Sep 9 20:07:57 2018 +0200

    Linux 3.18.122

commit b271f88e1a750763c96d7621e14b154114ea4dd3
Author: Shan Hai <shan.hai@oracle.com>
Date:   Thu Aug 23 02:02:56 2018 +0800

    bcache: release dc->writeback_lock properly in bch_writeback_thread()
    
    commit 3943b040f11ed0cc6d4585fd286a623ca8634547 upstream.
    
    The writeback thread would exit with a lock held when the cache device
    is detached via sysfs interface, fix it by releasing the held lock
    before exiting the while-loop.
    
    Fixes: fadd94e05c02 (bcache: quit dc->writeback_thread when BCACHE_DEV_DETACHING is set)
    Signed-off-by: Shan Hai <shan.hai@oracle.com>
    Signed-off-by: Coly Li <colyli@suse.de>
    Tested-by: Shenghui Wang <shhuiw@foxmail.com>
    Cc: stable@vger.kernel.org #4.17+
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 054206a2797efd01809b8562b865db74112c4423
Author: Christian Brauner <christian@brauner.io>
Date:   Thu Jun 7 13:43:48 2018 +0200

    getxattr: use correct xattr length
    
    commit 82c9a927bc5df6e06b72d206d24a9d10cced4eb5 upstream.
    
    When running in a container with a user namespace, if you call getxattr
    with name = "system.posix_acl_access" and size % 8 != 4, then getxattr
    silently skips the user namespace fixup that it normally does resulting in
    un-fixed-up data being returned.
    This is caused by posix_acl_fix_xattr_to_user() being passed the total
    buffer size and not the actual size of the xattr as returned by
    vfs_getxattr().
    This commit passes the actual length of the xattr as returned by
    vfs_getxattr() down.
    
    A reproducer for the issue is:
    
      touch acl_posix
    
      setfacl -m user:0:rwx acl_posix
    
    and the compile:
    
      #define _GNU_SOURCE
      #include <errno.h>
      #include <stdio.h>
      #include <stdlib.h>
      #include <string.h>
      #include <sys/types.h>
      #include <unistd.h>
      #include <attr/xattr.h>
    
      /* Run in user namespace with nsuid 0 mapped to uid != 0 on the host. */
      int main(int argc, void **argv)
      {
              ssize_t ret1, ret2;
              char buf1[128], buf2[132];
              int fret = EXIT_SUCCESS;
              char *file;
    
              if (argc < 2) {
                      fprintf(stderr,
                              "Please specify a file with "
                              "\"system.posix_acl_access\" permissions set\n");
                      _exit(EXIT_FAILURE);
              }
              file = argv[1];
    
              ret1 = getxattr(file, "system.posix_acl_access",
                              buf1, sizeof(buf1));
              if (ret1 < 0) {
                      fprintf(stderr, "%s - Failed to retrieve "
                                      "\"system.posix_acl_access\" "
                                      "from \"%s\"\n", strerror(errno), file);
                      _exit(EXIT_FAILURE);
              }
    
              ret2 = getxattr(file, "system.posix_acl_access",
                              buf2, sizeof(buf2));
              if (ret2 < 0) {
                      fprintf(stderr, "%s - Failed to retrieve "
                                      "\"system.posix_acl_access\" "
                                      "from \"%s\"\n", strerror(errno), file);
                      _exit(EXIT_FAILURE);
              }
    
              if (ret1 != ret2) {
                      fprintf(stderr, "The value of \"system.posix_acl_"
                                      "access\" for file \"%s\" changed "
                                      "between two successive calls\n", file);
                      _exit(EXIT_FAILURE);
              }
    
              for (ssize_t i = 0; i < ret2; i++) {
                      if (buf1[i] == buf2[i])
                              continue;
    
                      fprintf(stderr,
                              "Unexpected different in byte %zd: "
                              "%02x != %02x\n", i, buf1[i], buf2[i]);
                      fret = EXIT_FAILURE;
              }
    
              if (fret == EXIT_SUCCESS)
                      fprintf(stderr, "Test passed\n");
              else
                      fprintf(stderr, "Test failed\n");
    
              _exit(fret);
      }
    and run:
    
      ./tester acl_posix
    
    On a non-fixed up kernel this should return something like:
    
      root@c1:/# ./t
      Unexpected different in byte 16: ffffffa0 != 00
      Unexpected different in byte 17: ffffff86 != 00
      Unexpected different in byte 18: 01 != 00
    
    and on a fixed kernel:
    
      root@c1:~# ./t
      Test passed
    
    Cc: stable@vger.kernel.org
    Fixes: 2f6f0654ab61 ("userns: Convert vfs posix_acl support to use kuids and kgids")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199945
    Reported-by: Colin Watson <cjwatson@ubuntu.com>
    Signed-off-by: Christian Brauner <christian@brauner.io>
    Acked-by: Serge Hallyn <serge@hallyn.com>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f2f65ee027b305db5dc2fe0e3ccb6f34766e17d
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Jul 25 15:41:55 2018 +0200

    udlfb: set optimal write delay
    
    commit bb24153a3f13dd0dbc1f8055ad97fe346d598f66 upstream.
    
    The default delay 5 jiffies is too much when the kernel is compiled with
    HZ=100 - it results in jumpy cursor in Xwindow.
    
    In order to find out the optimal delay, I benchmarked the driver on
    1280x720x30fps video. I found out that with HZ=1000, 10ms is acceptable,
    but with HZ=250 or HZ=300, we need 4ms, so that the video is played
    without any frame skips.
    
    This patch changes the delay to this value.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76391112d8abeadfa8641b38c2917170fea8520c
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Jul 25 15:41:54 2018 +0200

    fb: fix lost console when the user unplugs a USB adapter
    
    commit 8c5b044299951acd91e830a688dd920477ea1eda upstream.
    
    I have a USB display adapter using the udlfb driver and I use it on an ARM
    board that doesn't have any graphics card. When I plug the adapter in, the
    console is properly displayed, however when I unplug and re-plug the
    adapter, the console is not displayed and I can't access it until I reboot
    the board.
    
    The reason is this:
    When the adapter is unplugged, dlfb_usb_disconnect calls
    unlink_framebuffer, then it waits until the reference count drops to zero
    and then it deallocates the framebuffer. However, the console that is
    attached to the framebuffer device keeps the reference count non-zero, so
    the framebuffer device is never destroyed. When the USB adapter is plugged
    again, it creates a new device /dev/fb1 and the console is not attached to
    it.
    
    This patch fixes the bug by unbinding the console from unlink_framebuffer.
    The code to unbind the console is moved from do_unregister_framebuffer to
    a function unbind_console. When the console is unbound, the reference
    count drops to zero and the udlfb driver frees the framebuffer. When the
    adapter is plugged back, a new framebuffer is created and the console is
    attached to it.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Bernie Thompson <bernie@plugable.com>
    Cc: Ladislav Michl <ladis@linux-mips.org>
    Cc: stable@vger.kernel.org
    [b.zolnierkie: preserve old behavior for do_unregister_framebuffer()]
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c4dcc23dd225272f1215dd8c415c3bfa1072908
Author: Vignesh R <vigneshr@ti.com>
Date:   Mon Jun 11 11:39:56 2018 +0530

    pwm: tiehrpwm: Fix disabling of output of PWMs
    
    commit 38dabd91ff0bde33352ca3cc65ef515599b77a05 upstream.
    
    pwm-tiehrpwm driver disables PWM output by putting it in low output
    state via active AQCSFRC register in ehrpwm_pwm_disable(). But, the
    AQCSFRC shadow register is not updated. Therefore, when shadow AQCSFRC
    register is re-enabled in ehrpwm_pwm_enable() (say to enable second PWM
    output), previous settings are lost as shadow register value is loaded
    into active register. This results in things like PWMA getting enabled
    automatically, when PWMB is enabled and vice versa. Fix this by
    updating AQCSFRC shadow register as well during ehrpwm_pwm_disable().
    
    Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
    Cc: stable@vger.kernel.org
    Signed-off-by: Vignesh R <vigneshr@ti.com>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37ca931c07ed22097bf4cbbe08ef26f9fe5383f5
Author: Richard Weinberger <richard@nod.at>
Date:   Tue Jun 12 00:52:28 2018 +0200

    ubifs: Fix synced_i_size calculation for xattr inodes
    
    commit 59965593205fa4044850d35ee3557cf0b7edcd14 upstream.
    
    In ubifs_jnl_update() we sync parent and child inodes to the flash,
    in case of xattrs, the parent inode (AKA host inode) has a non-zero
    data_len. Therefore we need to adjust synced_i_size too.
    
    This issue was reported by ubifs self tests unter a xattr related work
    load.
    UBIFS error (ubi0:0 pid 1896): dbg_check_synced_i_size: ui_size is 4, synced_i_size is 0, but inode is clean
    UBIFS error (ubi0:0 pid 1896): dbg_check_synced_i_size: i_ino 65, i_mode 0x81a4, i_size 4
    
    Cc: <stable@vger.kernel.org>
    Fixes: 1e51764a3c2a ("UBIFS: add new flash file system")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6510124f1aca5c958036eeb67d0bd57a277d791
Author: Richard Weinberger <richard@nod.at>
Date:   Sun Jul 1 23:20:50 2018 +0200

    Revert "UBIFS: Fix potential integer overflow in allocation"
    
    commit 08acbdd6fd736b90f8d725da5a0de4de2dd6de62 upstream.
    
    This reverts commit 353748a359f1821ee934afc579cf04572406b420.
    It bypassed the linux-mtd review process and fixes the issue not as it
    should.
    
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Silvio Cesare <silvio.cesare@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 155279d482be4d1171df78d481f171571415a202
Author: Richard Weinberger <richard@nod.at>
Date:   Tue Jun 12 20:49:45 2018 +0200

    ubifs: Fix memory leak in lprobs self-check
    
    commit eef19816ada3abd56d9f20c88794cc2fea83ebb2 upstream.
    
    Allocate the buffer after we return early.
    Otherwise memory is being leaked.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 1e51764a3c2a ("UBIFS: add new flash file system")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d024b6d8ff09d485a5b3a7b6ba1efc03cafbebc
Author: Jann Horn <jannh@google.com>
Date:   Mon Jun 25 18:34:19 2018 +0200

    userns: move user access out of the mutex
    
    commit 5820f140edef111a9ea2ef414ab2428b8cb805b1 upstream.
    
    The old code would hold the userns_state_mutex indefinitely if
    memdup_user_nul stalled due to e.g. a userfault region. Prevent that by
    moving the memdup_user_nul in front of the mutex_lock().
    
    Note: This changes the error precedence of invalid buf/count/*ppos vs
    map already written / capabilities missing.
    
    Fixes: 22d917d80e84 ("userns: Rework the user_namespace adding uid/gid...")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jann Horn <jannh@google.com>
    Acked-by: Christian Brauner <christian@brauner.io>
    Acked-by: Serge Hallyn <serge@hallyn.com>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a749f3ef97796d702b2da4106459d46c5bb1adb
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Fri Dec 5 20:03:28 2014 -0600

    userns; Correct the comment in map_write
    
    commit 36476beac4f8ca9dc7722790b2e8ef0e8e51034e upstream.
    
    It is important that all maps are less than PAGE_SIZE
    or else setting the last byte of the buffer to '0'
    could write off the end of the allocated storage.
    
    Correct the misleading comment.
    
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1ca395b1796c1e998e4ebf237c2d559b326d36c
Author: Jann Horn <jannh@google.com>
Date:   Mon Jun 25 18:34:10 2018 +0200

    sys: don't hold uts_sem while accessing userspace memory
    
    commit 42a0cc3478584d4d63f68f2f5af021ddbea771fa upstream.
    
    Holding uts_sem as a writer while accessing userspace memory allows a
    namespace admin to stall all processes that attempt to take uts_sem.
    Instead, move data through stack buffers and don't access userspace memory
    while uts_sem is held.
    
    Cc: stable@vger.kernel.org
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3680c7ecdc05e35d6ed1d7d269ecc8a03dae0748
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat May 13 21:39:49 2017 -0400

    osf_getdomainname(): use copy_to_user()
    
    commit 9ba3eb5103cf56f0daaf07de4507df76e7813ed7 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76b5c9f1a9b0ca8ccfb704eb21cab0e304bb3876
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Aug 22 17:30:14 2018 +0200

    mm/tlb: Remove tlb_remove_table() non-concurrent condition
    
    commit a6f572084fbee8b30f91465f4a085d7a90901c57 upstream.
    
    Will noted that only checking mm_users is incorrect; we should also
    check mm_count in order to cover CPUs that have a lazy reference to
    this mm (and could do speculative TLB operations).
    
    If removing this turns out to be a performance issue, we can
    re-instate a more complete check, but in tlb_table_flush() eliding the
    call_rcu_sched().
    
    Fixes: 267239116987 ("mm, powerpc: move the RCU page-table freeing into generic code")
    Reported-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Rik van Riel <riel@surriel.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: David Miller <davem@davemloft.net>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c6a5c96a60dcdb209e4b6e8373fb6207a9fb69c
Author: Jon Hunter <jonathanh@nvidia.com>
Date:   Tue Jul 3 09:59:47 2018 +0100

    ARM: tegra: Fix Tegra30 Cardhu PCA954x reset
    
    commit 6e1811900b6fe6f2b4665dba6bd6ed32c6b98575 upstream.
    
    On all versions of Tegra30 Cardhu, the reset signal to the NXP PCA9546
    I2C mux is connected to the Tegra GPIO BB0. Currently, this pin on the
    Tegra is not configured as a GPIO but as a special-function IO (SFIO)
    that is multiplexing the pin to an I2S controller. On exiting system
    suspend, I2C commands sent to the PCA9546 are failing because there is
    no ACK. Although it is not possible to see exactly what is happening
    to the reset during suspend, by ensuring it is configured as a GPIO
    and driven high, to de-assert the reset, the failures are no longer
    seen.
    
    Please note that this GPIO is also used to drive the reset signal
    going to the camera connector on the board. However, given that there
    is no camera support currently for Cardhu, this should not have any
    impact.
    
    Fixes: 40431d16ff11 ("ARM: tegra: enable PCA9546 on Cardhu")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86e40c0ccb044d265fdc54c5865b4adaea8d3841
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jul 4 12:59:58 2018 +0300

    pnfs/blocklayout: off by one in bl_map_stripe()
    
    commit 0914bb965e38a055e9245637aed117efbe976e91 upstream.
    
    "dev->nr_children" is the number of children which were parsed
    successfully in bl_parse_stripe().  It could be all of them and then, in
    that case, it is equal to v->stripe.volumes_count.  Either way, the >
    should be >= so that we don't go beyond the end of what we're supposed
    to.
    
    Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Cc: stable@vger.kernel.org # 3.17+
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02de522ac047a34433b9718173a77bd0cc806485
Author: Tomas Bortoli <tomasbortoli@gmail.com>
Date:   Fri Jul 27 13:05:58 2018 +0200

    9p: fix multiple NULL-pointer-dereferences
    
    commit 10aa14527f458e9867cf3d2cc6b8cb0f6704448b upstream.
    
    Added checks to prevent GPFs from raising.
    
    Link: http://lkml.kernel.org/r/20180727110558.5479-1-tomasbortoli@gmail.com
    Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
    Reported-by: syzbot+1a262da37d3bead15c39@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb67901b5d617eeca2939699a3aa5e06c3ea4fe2
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Aug 9 15:37:59 2018 -0400

    uprobes: Use synchronize_rcu() not synchronize_sched()
    
    commit 016f8ffc48cb01d1e7701649c728c5d2e737d295 upstream.
    
    While debugging another bug, I was looking at all the synchronize*()
    functions being used in kernel/trace, and noticed that trace_uprobes was
    using synchronize_sched(), with a comment to synchronize with
    {u,ret}_probe_trace_func(). When looking at those functions, the data is
    protected with "rcu_read_lock()" and not with "rcu_read_lock_sched()". This
    is using the wrong synchronize_*() function.
    
    Link: http://lkml.kernel.org/r/20180809160553.469e1e32@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Fixes: 70ed91c6ec7f8 ("tracing/uprobes: Support ftrace_event_file base multibuffer")
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73b5c3dc570d96e671f3ce5537ebda70237b4181
Author: Snild Dolkow <snild@sony.com>
Date:   Thu Jul 26 09:15:39 2018 +0200

    kthread, tracing: Don't expose half-written comm when creating kthreads
    
    commit 3e536e222f2930534c252c1cc7ae799c725c5ff9 upstream.
    
    There is a window for racing when printing directly to task->comm,
    allowing other threads to see a non-terminated string. The vsnprintf
    function fills the buffer, counts the truncated chars, then finally
    writes the \0 at the end.
    
            creator                     other
            vsnprintf:
              fill (not terminated)
              count the rest            trace_sched_waking(p):
              ...                         memcpy(comm, p->comm, TASK_COMM_LEN)
              write \0
    
    The consequences depend on how 'other' uses the string. In our case,
    it was copied into the tracing system's saved cmdlines, a buffer of
    adjacent TASK_COMM_LEN-byte buffers (note the 'n' where 0 should be):
    
            crash-arm64> x/1024s savedcmd->saved_cmdlines | grep 'evenk'
            0xffffffd5b3818640:     "irq/497-pwr_evenkworker/u16:12"
    
    ...and a strcpy out of there would cause stack corruption:
    
            [224761.522292] Kernel panic - not syncing: stack-protector:
                Kernel stack is corrupted in: ffffff9bf9783c78
    
            crash-arm64> kbt | grep 'comm\|trace_print_context'
            #6  0xffffff9bf9783c78 in trace_print_context+0x18c(+396)
                  comm (char [16]) =  "irq/497-pwr_even"
    
            crash-arm64> rd 0xffffffd4d0e17d14 8
            ffffffd4d0e17d14:  2f71726900000000 5f7277702d373934   ....irq/497-pwr_
            ffffffd4d0e17d24:  726f776b6e657665 3a3631752f72656b   evenkworker/u16:
            ffffffd4d0e17d34:  f9780248ff003231 cede60e0ffffff9b   12..H.x......`..
            ffffffd4d0e17d44:  cede60c8ffffffd4 00000fffffffffd4   .....`..........
    
    The workaround in e09e28671 (use strlcpy in __trace_find_cmdline) was
    likely needed because of this same bug.
    
    Solved by vsnprintf:ing to a local buffer, then using set_task_comm().
    This way, there won't be a window where comm is not terminated.
    
    Link: http://lkml.kernel.org/r/20180726071539.188015-1-snild@sony.com
    
    Cc: stable@vger.kernel.org
    Fixes: bc0c38d139ec7 ("ftrace: latency tracer infrastructure")
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Snild Dolkow <snild@sony.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    [backported to 3.18 / 4.4 by Snild]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5a4dfa99f195c1dde1f6c77e43238c35c363092
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Aug 16 16:08:37 2018 -0400

    tracing/blktrace: Fix to allow setting same value
    
    commit 757d9140072054528b13bbe291583d9823cde195 upstream.
    
    Masami Hiramatsu reported:
    
      Current trace-enable attribute in sysfs returns an error
      if user writes the same setting value as current one,
      e.g.
    
        # cat /sys/block/sda/trace/enable
        0
        # echo 0 > /sys/block/sda/trace/enable
        bash: echo: write error: Invalid argument
        # echo 1 > /sys/block/sda/trace/enable
        # echo 1 > /sys/block/sda/trace/enable
        bash: echo: write error: Device or resource busy
    
      But this is not a preferred behavior, it should ignore
      if new setting is same as current one. This fixes the
      problem as below.
    
        # cat /sys/block/sda/trace/enable
        0
        # echo 0 > /sys/block/sda/trace/enable
        # echo 1 > /sys/block/sda/trace/enable
        # echo 1 > /sys/block/sda/trace/enable
    
    Link: http://lkml.kernel.org/r/20180816103802.08678002@gandalf.local.home
    
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: linux-block@vger.kernel.org
    Cc: stable@vger.kernel.org
    Fixes: cd649b8bb830d ("blktrace: remove sysfs_blk_trace_enable_show/store()")
    Reported-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38a39e3dd4494902e1ad8aa8e0d71c9268e73de3
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed Aug 1 15:40:57 2018 -0400

    tracing: Do not call start/stop() functions when tracing_on does not change
    
    commit f143641bfef9a4a60c57af30de26c63057e7e695 upstream.
    
    Currently, when one echo's in 1 into tracing_on, the current tracer's
    "start()" function is executed, even if tracing_on was already one. This can
    lead to strange side effects. One being that if the hwlat tracer is enabled,
    and someone does "echo 1 > tracing_on" into tracing_on, the hwlat tracer's
    start() function is called again which will recreate another kernel thread,
    and make it unable to remove the old one.
    
    Link: http://lkml.kernel.org/r/1533120354-22923-1-git-send-email-erica.bugden@linutronix.de
    
    Cc: stable@vger.kernel.org
    Fixes: 2df8f8a6a897e ("tracing: Fix regression with irqsoff tracer and tracing_on file")
    Reported-by: Erica Bugden <erica.bugden@linutronix.de>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76eb62bdb1119b400668b0e63cce3edc1678dea6
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Fri Jul 27 09:42:45 2018 +0300

    iio: ad9523: Fix return value for ad952x_store()
    
    commit 9a5094ca29ea9b1da301b31fd377c0c0c4c23034 upstream.
    
    A sysfs write callback function needs to either return the number of
    consumed characters or an error.
    
    The ad952x_store() function currently returns 0 if the input value was "0",
    this will signal that no characters have been consumed and the function
    will be called repeatedly in a loop indefinitely. Fix this by returning
    number of supplied characters to indicate that the whole input string has
    been consumed.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Fixes: cd1678f96329 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator")
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3442d68f5af35117f20f595c530ca6c26992f22
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Jun 25 11:03:07 2018 +0300

    iio: ad9523: Fix displayed phase
    
    commit 5a4e33c1c53ae7d4425f7d94e60e4458a37b349e upstream.
    
    Fix the displayed phase for the ad9523 driver. Currently the most
    significant decimal place is dropped and all other digits are shifted one
    to the left. This is due to a multiplication by 10, which is not necessary,
    so remove it.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Fixes: cd1678f9632 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator")
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ceef7b21cdfb9c3ba31f2945643f918dadab6382
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Thu Aug 2 16:08:52 2018 -0400

    dm cache metadata: save in-core policy_hint_size to on-disk superblock
    
    commit fd2fa95416188a767a63979296fa3e169a9ef5ec upstream.
    
    policy_hint_size starts as 0 during __write_initial_superblock().  It
    isn't until the policy is loaded that policy_hint_size is set in-core
    (cmd->policy_hint_size).  But it never got recorded in the on-disk
    superblock because __commit_transaction() didn't deal with transfering
    the in-core cmd->policy_hint_size to the on-disk superblock.
    
    The in-core cmd->policy_hint_size gets initialized by metadata_open()'s
    __begin_transaction_flags() which re-reads all superblock fields.
    Because the superblock's policy_hint_size was never properly stored, when
    the cache was created, hints_array_available() would always return false
    when re-activating a previously created cache.  This means
    __load_mappings() always considered the hints invalid and never made use
    of the hints (these hints served to optimize).
    
    Another detremental side-effect of this oversight is the cache_check
    utility would fail with: "invalid hint width: 0"
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d90fb2996470afa3d416f7dbafc6482177e2a11e
Author: Tomas Bortoli <tomasbortoli@gmail.com>
Date:   Fri Jul 20 11:27:30 2018 +0200

    net/9p/trans_fd.c: fix race-condition by flushing workqueue before the kfree()
    
    commit 430ac66eb4c5b5c4eb846b78ebf65747510b30f1 upstream.
    
    The patch adds the flush in p9_mux_poll_stop() as it the function used by
    p9_conn_destroy(), in turn called by p9_fd_close() to stop the async
    polling associated with the data regarding the connection.
    
    Link: http://lkml.kernel.org/r/20180720092730.27104-1-tomasbortoli@gmail.com
    Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
    Reported-by: syzbot+39749ed7d9ef6dfb23f6@syzkaller.appspotmail.com
    To: Eric Van Hensbergen <ericvh@gmail.com>
    To: Ron Minnich <rminnich@sandia.gov>
    To: Latchesar Ionkov <lucho@ionkov.net>
    Cc: Yiwen Jiang <jiangyiwen@huwei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7bba0ec33b0b17d1b1609f992825f5b162304738
Author: Tomas Bortoli <tomasbortoli@gmail.com>
Date:   Tue Jul 10 00:29:43 2018 +0200

    net/9p/client.c: version pointer uninitialized
    
    commit 7913690dcc5e18e235769fd87c34143072f5dbea upstream.
    
    The p9_client_version() does not initialize the version pointer. If the
    call to p9pdu_readf() returns an error and version has not been allocated
    in p9pdu_readf(), then the program will jump to the "error" label and will
    try to free the version pointer. If version is not initialized, free()
    will be called with uninitialized, garbage data and will provoke a crash.
    
    Link: http://lkml.kernel.org/r/20180709222943.19503-1-tomasbortoli@gmail.com
    Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
    Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com
    Reviewed-by: Jun Piao <piaojun@huawei.com>
    Reviewed-by: Yiwen Jiang <jiangyiwen@huawei.com>
    Cc: Eric Van Hensbergen <ericvh@gmail.com>
    Cc: Ron Minnich <rminnich@sandia.gov>
    Cc: Latchesar Ionkov <lucho@ionkov.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd38cf65a88ec9dc2be3ebac91d08cc137bdf8bd
Author: jiangyiwen <jiangyiwen@huawei.com>
Date:   Fri Aug 3 12:11:34 2018 +0800

    9p/virtio: fix off-by-one error in sg list bounds check
    
    commit 23cba9cbde0bba05d772b335fe5f66aa82b9ad19 upstream.
    
    Because the value of limit is VIRTQUEUE_NUM, if index is equal to
    limit, it will cause sg array out of bounds, so correct the judgement
    of BUG_ON.
    
    Link: http://lkml.kernel.org/r/5B63D5F6.6080109@huawei.com
    Signed-off-by: Yiwen Jiang <jiangyiwen@huawei.com>
    Reported-By: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Jun Piao <piaojun@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43a2089a1353159c24eaad3f8925c4710b9e7c16
Author: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Date:   Tue Aug 7 19:46:46 2018 +0530

    powerpc/pseries: Fix endianness while restoring of r3 in MCE handler.
    
    commit cd813e1cd7122f2c261dce5b54d1e0c97f80e1a5 upstream.
    
    During Machine Check interrupt on pseries platform, register r3 points
    RTAS extended event log passed by hypervisor. Since hypervisor uses r3
    to pass pointer to rtas log, it stores the original r3 value at the
    start of the memory (first 8 bytes) pointed by r3. Since hypervisor
    stores this info and rtas log is in BE format, linux should make
    sure to restore r3 value in correct endian format.
    
    Without this patch when MCE handler, after recovery, returns to code that
    that caused the MCE may end up with Data SLB access interrupt for invalid
    address followed by kernel panic or hang.
    
      Severe Machine check interrupt [Recovered]
        NIP [d00000000ca301b8]: init_module+0x1b8/0x338 [bork_kernel]
        Initiator: CPU
        Error type: SLB [Multihit]
          Effective address: d00000000ca70000
      cpu 0xa: Vector: 380 (Data SLB Access) at [c0000000fc7775b0]
          pc: c0000000009694c0: vsnprintf+0x80/0x480
          lr: c0000000009698e0: vscnprintf+0x20/0x60
          sp: c0000000fc777830
         msr: 8000000002009033
         dar: a803a30c000000d0
        current = 0xc00000000bc9ef00
        paca    = 0xc00000001eca5c00         softe: 3        irq_happened: 0x01
          pid   = 8860, comm = insmod
      vscnprintf+0x20/0x60
      vprintk_emit+0xb4/0x4b0
      vprintk_func+0x5c/0xd0
      printk+0x38/0x4c
      init_module+0x1c0/0x338 [bork_kernel]
      do_one_initcall+0x54/0x230
      do_init_module+0x8c/0x248
      load_module+0x12b8/0x15b0
      sys_finit_module+0xa8/0x110
      system_call+0x58/0x6c
      --- Exception: c00 (System Call) at 00007fff8bda0644
      SP (7fffdfbfe980) is in userspace
    
    This patch fixes this issue.
    
    Fixes: a08a53ea4c97 ("powerpc/le: Enable RTAS events support")
    Cc: stable@vger.kernel.org # v3.15+
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3f3454eb475f6e7f53bf5029cde593ca267c3a0
Author: Hari Bathini <hbathini@linux.ibm.com>
Date:   Tue Aug 7 02:12:45 2018 +0530

    powerpc/fadump: handle crash memory ranges array index overflow
    
    commit 1bd6a1c4b80a28d975287630644e6b47d0f977a5 upstream.
    
    Crash memory ranges is an array of memory ranges of the crashing kernel
    to be exported as a dump via /proc/vmcore file. The size of the array
    is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
    where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
    value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
    commit 142b45a72e22 ("memblock: Add array resizing support").
    
    On large memory systems with a few DLPAR operations, the memblock memory
    regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
    systems, registering fadump results in crash or other system failures
    like below:
    
      task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
      NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
      REGS: c00000000b73b570 TRAP: 0300   Tainted: G          L   X  (4.4.140+)
      MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 22004484  XER: 20000000
      CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
      ...
      NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
      LR [c0000000000f9e58] resched_curr+0x138/0x160
      Call Trace:
        resched_curr+0x138/0x160 (unreliable)
        check_preempt_curr+0xc8/0xf0
        ttwu_do_wakeup+0x38/0x150
        try_to_wake_up+0x224/0x4d0
        __wake_up_common+0x94/0x100
        ep_poll_callback+0xac/0x1c0
        __wake_up_common+0x94/0x100
        __wake_up_sync_key+0x70/0xa0
        sock_def_readable+0x58/0xa0
        unix_stream_sendmsg+0x2dc/0x4c0
        sock_sendmsg+0x68/0xa0
        ___sys_sendmsg+0x2cc/0x2e0
        __sys_sendmsg+0x5c/0xc0
        SyS_socketcall+0x36c/0x3f0
        system_call+0x3c/0x100
    
    as array index overflow is not checked for while setting up crash memory
    ranges causing memory corruption. To resolve this issue, dynamically
    allocate memory for crash memory ranges and resize it incrementally,
    in units of pagesize, on hitting array size limit.
    
    Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
    Cc: stable@vger.kernel.org # v3.4+
    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
    [mpe: Just use PAGE_SIZE directly, fixup variable placement]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fec7d721a09b917f6fa8b923a28fbac97c1217ba
Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Date:   Fri Aug 10 11:13:52 2018 +0200

    spi: davinci: fix a NULL pointer dereference
    
    commit 563a53f3906a6b43692498e5b3ae891fac93a4af upstream.
    
    On non-OF systems spi->controlled_data may be NULL. This causes a NULL
    pointer derefence on dm365-evm.
    
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>