1. 30 Apr, 2017 34 commits
    • Sergey Ryazanov's avatar
      MIPS: MSP71xx: remove odd locking in PCI config space access code · 375f2a85
      Sergey Ryazanov authored
      commit c4a30537 upstream.
      
      Caller (generic PCI code) already do proper locking so no need to add
      another one here.
      Signed-off-by: default avatarSergey Ryazanov <ryazanov.s.a@gmail.com>
      Cc: Linux MIPS <linux-mips@linux-mips.org>
      Patchwork: https://patchwork.linux-mips.org/patch/7601/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      375f2a85
    • Arnd Bergmann's avatar
      hostap: avoid uninitialized variable use in hfa384x_get_rid · 83b7c38b
      Arnd Bergmann authored
      commit 48dc5fb3 upstream.
      
      The driver reads a value from hfa384x_from_bap(), which may fail,
      and then assigns the value to a local variable. gcc detects that
      in in the failure case, the 'rlen' variable now contains
      uninitialized data:
      
      In file included from ../drivers/net/wireless/intersil/hostap/hostap_pci.c:220:0:
      drivers/net/wireless/intersil/hostap/hostap_hw.c: In function 'hfa384x_get_rid':
      drivers/net/wireless/intersil/hostap/hostap_hw.c:842:5: warning: 'rec' may be used uninitialized in this function [-Wmaybe-uninitialized]
        if (le16_to_cpu(rec.len) == 0) {
      
      This restructures the function as suggested by Russell King, to
      make it more readable and get more reliable error handling, by
      handling each failure mode using a goto.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      83b7c38b
    • Richard Leitner's avatar
      misc: ioc4: simplify wave period measurement in clock_calibrate · b0d69335
      Richard Leitner authored
      commit 769105aa upstream.
      
      The loop for measuring the square wave periods over some cycles is
      refactored to be more easily readable. This includes avoiding a
      "by-hand-implemented" for loop with a "real" one and adding some
      comments.
      
      Furthermore the following compiler warning is avoided by this patch:
      drivers/misc/ioc4.c: In function ‘ioc4_probe’:
      drivers/misc/ioc4.c:194:16: warning: ‘start’ may be used uninitialized
      in this function [-Wmaybe-uninitialized]
        period = (end - start) /
                      ^
      drivers/misc/ioc4.c:148:11: note: ‘start’ was declared here
        uint64_t start, end, period;
                 ^
      Signed-off-by: default avatarRichard Leitner <dev@g0hl1n.net>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0d69335
    • Arnd Bergmann's avatar
      net: vxge: avoid unused function warnings · db65717e
      Arnd Bergmann authored
      commit 57e7c8ce upstream.
      
      When CONFIG_PCI_MSI is disabled, we get warnings about unused functions
      in the vxge driver:
      
      drivers/net/ethernet/neterion/vxge/vxge-main.c:2121:13: warning: 'adaptive_coalesce_tx_interrupts' defined but not used [-Wunused-function]
      drivers/net/ethernet/neterion/vxge/vxge-main.c:2149:13: warning: 'adaptive_coalesce_rx_interrupts' defined but not used [-Wunused-function]
      
      We could add another #ifdef here, but it's nicer to avoid those warnings
      for good by converting the existing #ifdef to if(IS_ENABLED()), which has
      the same effect but provides better compile-time coverage in general,
      and lets the compiler understand better when the function is intentionally
      unused.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db65717e
    • Arnd Bergmann's avatar
      tty: nozomi: avoid a harmless gcc warning · c59bad24
      Arnd Bergmann authored
      commit a4f642a8 upstream.
      
      The nozomi wireless data driver has its own helper function to
      transfer data from a FIFO, doing an extra byte swap on big-endian
      architectures, presumably to bring the data back into byte-serial
      order after readw() or readl() perform their implicit byteswap.
      
      This helper function is used in the receive_data() function to
      first read the length into a 32-bit variable, which causes
      a compile-time warning:
      
      drivers/tty/nozomi.c: In function 'receive_data':
      drivers/tty/nozomi.c:857:9: warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      The problem is that gcc is unsure whether the data was actually
      read or not. We know that it is at this point, so we can replace
      it with a single readl() to shut up that warning.
      
      I am leaving the byteswap in there, to preserve the existing
      behavior, even though this seems fishy: Reading the length of
      the data into a cpu-endian variable should normally not use
      a second byteswap on big-endian systems, unless the hardware
      is aware of the CPU endianess.
      
      There appears to be a lot more confusion about endianess in this
      driver, so it probably has not worked on big-endian systems in
      a long time, if ever, and I have no way to test it. It's well
      possible that this driver has not been used by anyone in a while,
      the last patch that looks like it was tested on the hardware is
      from 2008.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c59bad24
    • Arnd Bergmann's avatar
      brcmfmac: avoid gcc-5.1 warning · b342040b
      Arnd Bergmann authored
      commit 22f44150 upstream.
      
      gcc-5.0 gained a new warning in the fwsignal portion of the brcmfmac
      driver:
      
      drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c: In function 'brcmf_fws_txs_process':
      drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      This is a false positive, and marking the brcmf_fws_hanger_poppkt function
      as 'static inline' makes the warning go away. I have checked the object
      file output and while a little code gets moved around, the size of
      the binary remains identical.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b342040b
    • Kevin Cernekee's avatar
      Fix signed/unsigned pointer warning · a3f3f11f
      Kevin Cernekee authored
      commit 97c7134a upstream.
      
      Commit 2ae83bf9 ("[CIFS] Fix setting time before epoch (negative
      time values)") changed "u64 t" to "s64 t", which makes do_div() complain
      about a pointer signedness mismatch:
      
            CC      fs/cifs/netmisc.o
          In file included from ./arch/mips/include/asm/div64.h:12:0,
                           from include/linux/kernel.h:124,
                           from include/linux/list.h:8,
                           from include/linux/wait.h:6,
                           from include/linux/net.h:23,
                           from fs/cifs/netmisc.c:25:
          fs/cifs/netmisc.c: In function ‘cifs_NTtimeToUnix’:
          include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast [enabled by default]
            (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
                                      ^
          fs/cifs/netmisc.c:941:22: note: in expansion of macro ‘do_div’
             ts.tv_nsec = (long)do_div(t, 10000000) * 100;
      
      Introduce a temporary "u64 abs_t" variable to fix this.
      Signed-off-by: default avatarKevin Cernekee <cernekee@gmail.com>
      Signed-off-by: default avatarSteve French <steve.french@primarydata.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3f3f11f
    • Arnd Bergmann's avatar
      nfsd: work around a gcc-5.1 warning · a5fd3dcb
      Arnd Bergmann authored
      commit 6ac75368 upstream.
      
      gcc-5.0 warns about a potential uninitialized variable use in nfsd:
      
      fs/nfsd/nfs4state.c: In function 'nfsd4_process_open2':
      fs/nfsd/nfs4state.c:3781:3: warning: 'old_deny_bmap' may be used uninitialized in this function [-Wmaybe-uninitialized]
         reset_union_bmap_deny(old_deny_bmap, stp);
         ^
      fs/nfsd/nfs4state.c:3760:16: note: 'old_deny_bmap' was declared here
        unsigned char old_deny_bmap;
                      ^
      
      This is a false positive, the code path that is warned about cannot
      actually be reached.
      
      This adds an initialization for the variable to make the warning go
      away.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5fd3dcb
    • Markos Chandras's avatar
      MIPS: asm: compiler: Add new macros to set ISA and arch asm annotations · 503d2d26
      Markos Chandras authored
      commit be513698 upstream.
      
      There are certain places where the code uses .set mips32 or .set mips64
      or .set arch=r4000. In preparation of MIPS R6 support, and in order to
      use as less #ifdefs as possible, we define new macros to set similar
      annotations for MIPS R6.
      Signed-off-by: default avatarMarkos Chandras <markos.chandras@imgtec.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      503d2d26
    • Paul Burton's avatar
      net: ti: cpmac: Fix compiler warning due to type confusion · aef5c5b8
      Paul Burton authored
      commit 2f5281ba upstream.
      
      cpmac_start_xmit() used the max() macro on skb->len (an unsigned int)
      and ETH_ZLEN (a signed int literal). This led to the following compiler
      warning:
      
        In file included from include/linux/list.h:8:0,
                         from include/linux/module.h:9,
                         from drivers/net/ethernet/ti/cpmac.c:19:
        drivers/net/ethernet/ti/cpmac.c: In function 'cpmac_start_xmit':
        include/linux/kernel.h:748:17: warning: comparison of distinct pointer
        types lacks a cast
          (void) (&_max1 == &_max2);  \
                         ^
        drivers/net/ethernet/ti/cpmac.c:560:8: note: in expansion of macro 'max'
          len = max(skb->len, ETH_ZLEN);
                ^
      
      On top of this, it assigned the result of the max() macro to a signed
      integer whilst all further uses of it result in it being cast to varying
      widths of unsigned integer.
      
      Fix this up by using max_t to ensure the comparison is performed as
      unsigned integers, and for consistency change the type of the len
      variable to unsigned int.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aef5c5b8
    • Oliver O'Halloran's avatar
      mm/init: fix zone boundary creation · 09f7ddc4
      Oliver O'Halloran authored
      commit 90cae1fe upstream.
      
      As a part of memory initialisation the architecture passes an array to
      free_area_init_nodes() which specifies the max PFN of each memory zone.
      This array is not necessarily monotonic (due to unused zones) so this
      array is parsed to build monotonic lists of the min and max PFN for each
      zone.  ZONE_MOVABLE is special cased here as its limits are managed by
      the mm subsystem rather than the architecture.  Unfortunately, this
      special casing is broken when ZONE_MOVABLE is the not the last zone in
      the zone list.  The core of the issue is:
      
      	if (i == ZONE_MOVABLE)
      		continue;
      	arch_zone_lowest_possible_pfn[i] =
      		arch_zone_highest_possible_pfn[i-1];
      
      As ZONE_MOVABLE is skipped the lowest_possible_pfn of the next zone will
      be set to zero.  This patch fixes this bug by adding explicitly tracking
      where the next zone should start rather than relying on the contents
      arch_zone_highest_possible_pfn[].
      
      Thie is low priority.  To get bitten by this you need to enable a zone
      that appears after ZONE_MOVABLE in the zone_type enum.  As far as I can
      tell this means running a kernel with ZONE_DEVICE or ZONE_CMA enabled,
      so I can't see this affecting too many people.
      
      I only noticed this because I've been fiddling with ZONE_DEVICE on
      powerpc and 4.6 broke my test kernel.  This bug, in conjunction with the
      changes in Taku Izumi's kernelcore=mirror patch (d91749c1) and
      powerpc being the odd architecture which initialises max_zone_pfn[] to
      ~0ul instead of 0 caused all of system memory to be placed into
      ZONE_DEVICE at boot, followed a panic since device memory cannot be used
      for kernel allocations.  I've already submitted a patch to fix the
      powerpc specific bits, but I figured this should be fixed too.
      
      Link: http://lkml.kernel.org/r/1462435033-15601-1-git-send-email-oohall@gmail.comSigned-off-by: default avatarOliver O'Halloran <oohall@gmail.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09f7ddc4
    • Alex Williamson's avatar
      iommu/vt-d: Remove unused variable · a7c1eda4
      Alex Williamson authored
      commit 509fca89 upstream.
      
      Unused after commit 71684406 ("iommu/vt-d: Detach domain *only*
      from attached iommus").  Reported by 0-day builder.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7c1eda4
    • Andre Przywara's avatar
      fs/nfs: fix new compiler warning about boolean in switch · 4064f65a
      Andre Przywara authored
      commit c7757074 upstream.
      
      The brand new GCC 5.1.0 warns by default on using a boolean in the
      switch condition. This results in the following warning:
      
      fs/nfs/nfs4proc.c: In function 'nfs4_proc_get_rootfh':
      fs/nfs/nfs4proc.c:3100:10: warning: switch condition has boolean value [-Wswitch-bool]
        switch (auth_probe) {
                ^
      
      This code was obviously using switch to make use of the fall-through
      semantics (without the usual comment, though).
      Rewrite that code using if statements to avoid the warning and make
      the code a bit more readable on the way.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4064f65a
    • Peter Zijlstra (Intel)'s avatar
      perf: Avoid horrible stack usage · 803e3757
      Peter Zijlstra (Intel) authored
      commit 86038c5e upstream.
      
      Both Linus (most recent) and Steve (a while ago) reported that perf
      related callbacks have massive stack bloat.
      
      The problem is that software events need a pt_regs in order to
      properly report the event location and unwind stack. And because we
      could not assume one was present we allocated one on stack and filled
      it with minimal bits required for operation.
      
      Now, pt_regs is quite large, so this is undesirable. Furthermore it
      turns out that most sites actually have a pt_regs pointer available,
      making this even more onerous, as the stack space is pointless waste.
      
      This patch addresses the problem by observing that software events
      have well defined nesting semantics, therefore we can use static
      per-cpu storage instead of on-stack.
      
      Linus made the further observation that all but the scheduler callers
      of perf_sw_event() have a pt_regs available, so we change the regular
      perf_sw_event() to require a valid pt_regs (where it used to be
      optional) and add perf_sw_event_sched() for the scheduler.
      
      We have a scheduler specific call instead of a more generic _noregs()
      like construct because we can assume non-recursion from the scheduler
      and thereby simplify the code further (_noregs would have to put the
      recursion context call inline in order to assertain which __perf_regs
      element to use).
      
      One last note on the implementation of perf_trace_buf_prepare(); we
      allow .regs = NULL for those cases where we already have a pt_regs
      pointer available and do not need another.
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Reported-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Javi Merino <javi.merino@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
      Cc: Vaibhav Nagarnaik <vnagarnaik@google.com>
      Link: http://lkml.kernel.org/r/20141216115041.GW3337@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      803e3757
    • Alban Bedel's avatar
      MIPS: Fix the build on jz4740 after removing the custom gpio.h · 8e0aa9da
      Alban Bedel authored
      commit 5b235dc2 upstream.
      
      Somehow the wrong version of the patch to remove the use of custom
      gpio.h on mips has been merged. This patch add the missing fixes for a
      build error on jz4740 because linux/gpio.h doesn't provide any machine
      specfics definitions anymore.
      Signed-off-by: default avatarAlban Bedel <albeu@free.fr>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/11089/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e0aa9da
    • Arnd Bergmann's avatar
      dm bufio: hide bogus warning · e9bf6fcf
      Arnd Bergmann authored
      mips-gcc-5.3 warns about correct code on linux-3.18 and earlier:
      
      In file included from ../include/linux/blkdev.h:4:0,
                       from ../drivers/md/dm-bufio.h:12,
                       from ../drivers/md/dm-bufio.c:9:
      ../drivers/md/dm-bufio.c: In function 'alloc_buffer':
      ../include/linux/sched.h:1975:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
        current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flags;
                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
      ../drivers/md/dm-bufio.c:325:11: note: 'noio_flag' was declared here
      
      The warning disappeared on later kernels with this commit: be0c37c9
      ("MIPS: Rearrange PTE bits into fixed positions.")  I assume this only
      happened because it changed some inlining decisions.
      
      On 3.18.y, we can shut up the warning by adding an extra initialization.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e9bf6fcf
    • Arnd Bergmann's avatar
      gadgetfs: fix uninitialized variable in error handling · 279b8b78
      Arnd Bergmann authored
      gcc warns about a bug in 3.18.y:
      
      drivers/usb/gadget/legacy/inode.c:648:10: warning: 'value' may be used
      
      This is caused by the backport of f01d35a1 from 4.0 to 3.18:
      c81fc59b gadgetfs: use-after-free in ->aio_read()
      
      The backported patch was buggy, but the mainline code was rewritten
      in a larger patch directly following this one in a way that fixed the
      bug.
      
      For stable, we should need only a one-line change to make sure we
      return an proper error code. It is very unlikely that anybody ever
      ran into the out-of-memory case here in practice, but the compiler
      is right in theory.
      
      Fixes: c81fc59b ("gadgetfs: use-after-free in ->aio_read()")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      279b8b78
    • Arnd Bergmann's avatar
      clk: at91: usb: fix determine_rate prototype again · f2d62e62
      Arnd Bergmann authored
      We had an incorrect backport of
      45912431 ("clk: at91: usb: propagate rate modification to the parent clk")
      that was fixed incorrectly in linux-3.18.y by
      76723e7e ("clk: at91: usb: fix determine_rate prototype")
      
      as shown by this warning:
      
      drivers/clk/at91/clk-usb.c:155:20: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
      drivers/clk/at91/clk-usb.c:193:20: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
      
      This should fix it properly.
      Acked-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2d62e62
    • Mark Rutland's avatar
      arm64: avoid returning from bad_mode · 21ffe52c
      Mark Rutland authored
      commit 7d9e8f71 upstream.
      
      Generally, taking an unexpected exception should be a fatal event, and
      bad_mode is intended to cater for this. However, it should be possible
      to contain unexpected synchronous exceptions from EL0 without bringing
      the kernel down, by sending a SIGILL to the task.
      
      We tried to apply this approach in commit 9955ac47 ("arm64:
      don't kill the kernel on a bad esr from el0"), by sending a signal for
      any bad_mode call resulting from an EL0 exception.
      
      However, this also applies to other unexpected exceptions, such as
      SError and FIQ. The entry paths for these exceptions branch to bad_mode
      without configuring the link register, and have no kernel_exit. Thus, if
      we take one of these exceptions from EL0, bad_mode will eventually
      return to the original user link register value.
      
      This patch fixes this by introducing a new bad_el0_sync handler to cater
      for the recoverable case, and restoring bad_mode to its original state,
      whereby it calls panic() and never returns. The recoverable case
      branches to bad_el0_sync with a bl, and returns to userspace via the
      usual ret_to_user mechanism.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Fixes: 9955ac47 ("arm64: don't kill the kernel on a bad esr from el0")
      Reported-by: default avatarMark Salter <msalter@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      21ffe52c
    • Suzuki K Poulose's avatar
      kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd · 2f68b351
      Suzuki K Poulose authored
      commit 8b3405e3 upstream.
      
      In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
      unmap_stage2_range() on the entire memory range for the guest. This could
      cause problems with other callers (e.g, munmap on a memslot) trying to
      unmap a range. And since we have to unmap the entire Guest memory range
      holding a spinlock, make sure we yield the lock if necessary, after we
      unmap each PUD range.
      
      Fixes: commit d5d8184d ("KVM: ARM: Memory virtualization setup")
      Cc: Paolo Bonzini <pbonzin@redhat.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      [ Avoid vCPU starvation and lockup detector warnings ]
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f68b351
    • Yazen Ghannam's avatar
      x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs · 0420e558
      Yazen Ghannam authored
      commit 29f72ce3 upstream.
      
      MCA bank 3 is reserved on systems pre-Fam17h, so it didn't have a name.
      However, MCA bank 3 is defined on Fam17h systems and can be accessed
      using legacy MSRs. Without a name we get a stack trace on Fam17h systems
      when trying to register sysfs files for bank 3 on kernels that don't
      recognize Scalable MCA.
      
      Call MCA bank 3 "decode_unit" since this is what it represents on
      Fam17h. This will allow kernels without SMCA support to see this bank on
      Fam17h+ and prevent the stack trace. This will not affect older systems
      since this bank is reserved on them, i.e. it'll be ignored.
      
      Tested on AMD Fam15h and Fam17h systems.
      
        WARNING: CPU: 26 PID: 1 at lib/kobject.c:210 kobject_add_internal
        kobject: (ffff88085bb256c0): attempted to be registered with empty name!
        ...
        Call Trace:
         kobject_add_internal
         kobject_add
         kobject_create_and_add
         threshold_create_device
         threshold_init_device
      Signed-off-by: default avatarYazen Ghannam <yazen.ghannam@amd.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/1490102285-3659-1-git-send-email-Yazen.Ghannam@amd.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0420e558
    • Ravi Bangoria's avatar
      powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction · d2221b78
      Ravi Bangoria authored
      commit 9e1ba4f2 upstream.
      
      If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel
      OOPS:
      
        Bad kernel stack pointer cd93c840 at c000000000009868
        Oops: Bad kernel stack pointer, sig: 6 [#1]
        ...
        GPR00: c000001fcd93cb30 00000000cd93c840 c0000000015c5e00 00000000cd93c840
        ...
        NIP [c000000000009868] resume_kernel+0x2c/0x58
        LR [c000000000006208] program_check_common+0x108/0x180
      
      On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does
      not emulate actual store in emulate_step() because it may corrupt the exception
      frame. So the kernel does the actual store operation in exception return code
      i.e. resume_kernel().
      
      resume_kernel() loads the saved stack pointer from memory using lwz, which only
      loads the low 32-bits of the address, causing the kernel crash.
      
      Fix this by loading the 64-bit value instead.
      
      Fixes: be96f633 ("powerpc: Split out instruction analysis part of emulate_step()")
      Signed-off-by: default avatarRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Reviewed-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Reviewed-by: default avatarAnanth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      [mpe: Change log massage, add stable tag]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2221b78
    • Sebastian Siewior's avatar
      ubi/upd: Always flush after prepared for an update · ea1eeb93
      Sebastian Siewior authored
      commit 9cd9a21c upstream.
      
      In commit 6afaf8a4 ("UBI: flush wl before clearing update marker") I
      managed to trigger and fix a similar bug. Now here is another version of
      which I assumed it wouldn't matter back then but it turns out UBI has a
      check for it and will error out like this:
      
      |ubi0 warning: validate_vid_hdr: inconsistent used_ebs
      |ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592
      
      All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a
      powercut in the middle of the operation.
      ubi_start_update() sets the update-marker and puts all EBs on the erase
      list. After that userland can proceed to write new data while the old EB
      aren't erased completely. A powercut at this point is usually not that
      much of a tragedy. UBI won't give read access to the static volume
      because it has the update marker. It will most likely set the corrupted
      flag because it misses some EBs.
      So we are all good. Unless the size of the image that has been written
      differs from the old image in the magnitude of at least one EB. In that
      case UBI will find two different values for `used_ebs' and refuse to
      attach the image with the error message mentioned above.
      
      So in order not to get in the situation, the patch will ensure that we
      wait until everything is removed before it tries to write any data.
      The alternative would be to detect such a case and remove all EBs at the
      attached time after we processed the volume-table and see the
      update-marker set. The patch looks bigger and I doubt it is worth it
      since usually the write() will wait from time to time for a new EB since
      usually there not that many spare EB that can be used.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea1eeb93
    • Haibo Chen's avatar
      mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card · df5024c3
      Haibo Chen authored
      commit 9f327845 upstream.
      
      Currently for DDR50 card, it need tuning in default. We meet tuning fail
      issue for DDR50 card and some data CRC error when DDR50 sd card works.
      
      This is because the default pad I/O drive strength can't make sure DDR50
      card work stable. So increase the pad I/O drive strength for DDR50 card,
      and use pins_100mhz.
      
      This fixes DDR50 card support for IMX since DDR50 tuning was enabled from
      commit 9faac7b9 ("mmc: sdhci: enable tuning for DDR50")
      Tested-and-reported-by: default avatarTim Harvey <tharvey@gateworks.com>
      Signed-off-by: default avatarHaibo Chen <haibo.chen@nxp.com>
      Acked-by: default avatarDong Aisheng <aisheng.dong@nxp.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df5024c3
    • Arnd Bergmann's avatar
      ACPI / power: Avoid maybe-uninitialized warning · 53d2524d
      Arnd Bergmann authored
      commit fe8c470a upstream.
      
      gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state()
      is enterered at least once, so it assumes that cur_state might not get
      initialized:
      
      drivers/acpi/power.c: In function 'acpi_power_get_inferred_state':
      drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      This sets the variable to zero at the start of the loop, to ensure that
      there is well-defined behavior even for an empty list. This gets rid of
      the warning.
      
      The warning first showed up when the -Os flag got removed in a bug fix
      patch in linux-4.11-rc5.
      
      I would suggest merging this addon patch on top of that bug fix to avoid
      introducing a new warning in the stable kernels.
      
      Fixes: 61b79e16 (ACPI: Fix incompatibility with mcount-based function graph tracing)
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      53d2524d
    • Thorsten Leemhuis's avatar
      Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled · 3ca9c341
      Thorsten Leemhuis authored
      commit 704de489 upstream.
      
      Temporary got a Lifebook E547 into my hands and noticed the touchpad
      only works after running:
      
      	echo "1" > /sys/devices/platform/i8042/serio2/crc_enabled
      
      Add it to the list of machines that need this workaround.
      Signed-off-by: default avatarThorsten Leemhuis <linux@leemhuis.info>
      Reviewed-by: default avatarUlrik De Bie <ulrik.debie-os@e2big.org>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ca9c341
    • Christian Borntraeger's avatar
      s390/mm: fix CMMA vs KSM vs others · 2ac3f8b5
      Christian Borntraeger authored
      commit a8f60d1f upstream.
      
      On heavy paging with KSM I see guest data corruption. Turns out that
      KSM will add pages to its tree, where the mapping return true for
      pte_unused (or might become as such later).  KSM will unmap such pages
      and reinstantiate with different attributes (e.g. write protected or
      special, e.g. in replace_page or write_protect_page)). This uncovered
      a bug in our pagetable handling: We must remove the unused flag as
      soon as an entry becomes present again.
      Signed-of-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      2ac3f8b5
    • Germano Percossi's avatar
      CIFS: remove bad_network_name flag · 018a5fb6
      Germano Percossi authored
      commit a0918f1c upstream.
      
      STATUS_BAD_NETWORK_NAME can be received during node failover,
      causing the flag to be set and making the reconnect thread
      always unsuccessful, thereafter.
      
      Once the only place where it is set is removed, the remaining
      bits are rendered moot.
      
      Removing it does not prevent "mount" from failing when a non
      existent share is passed.
      
      What happens when the share really ceases to exist while the
      share is mounted is undefined now as much as it was before.
      Signed-off-by: default avatarGermano Percossi <germano.percossi@citrix.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      018a5fb6
    • Sachin Prabhu's avatar
      cifs: Do not send echoes before Negotiate is complete · af82fc7d
      Sachin Prabhu authored
      commit 62a6cfdd upstream.
      
      commit 4fcd1813 ("Fix reconnect to not defer smb3 session reconnect
      long after socket reconnect") added support for Negotiate requests to
      be initiated by echo calls.
      
      To avoid delays in calling echo after a reconnect, I added the patch
      introduced by the commit b8c60012 ("Call echo service immediately
      after socket reconnect").
      
      This has however caused a regression with cifs shares which do not have
      support for echo calls to trigger Negotiate requests. On connections
      which need to call Negotiation, the echo calls trigger an error which
      triggers a reconnect which in turn triggers another echo call. This
      results in a loop which is only broken when an operation is performed on
      the cifs share. For an idle share, it can DOS a server.
      
      The patch uses the smb_operation can_echo() for cifs so that it is
      called only if connection has been already been setup.
      
      kernel bz: 194531
      Signed-off-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      Tested-by: default avatarJonathan Liu <net147@gmail.com>
      Acked-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af82fc7d
    • Steven Rostedt (VMware)'s avatar
      ring-buffer: Have ring_buffer_iter_empty() return true when empty · 0b83d4b7
      Steven Rostedt (VMware) authored
      commit 78f7a45d upstream.
      
      I noticed that reading the snapshot file when it is empty no longer gives a
      status. It suppose to show the status of the snapshot buffer as well as how
      to allocate and use it. For example:
      
       ># cat snapshot
       # tracer: nop
       #
       #
       # * Snapshot is allocated *
       #
       # Snapshot commands:
       # echo 0 > snapshot : Clears and frees snapshot buffer
       # echo 1 > snapshot : Allocates snapshot buffer, if not already allocated.
       #                      Takes a snapshot of the main buffer.
       # echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free)
       #                      (Doesn't have to be '2' works with any number that
       #                       is not a '0' or '1')
      
      But instead it just showed an empty buffer:
      
       ># cat snapshot
       # tracer: nop
       #
       # entries-in-buffer/entries-written: 0/0   #P:4
       #
       #                              _-----=> irqs-off
       #                             / _----=> need-resched
       #                            | / _---=> hardirq/softirq
       #                            || / _--=> preempt-depth
       #                            ||| /     delay
       #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
       #              | |       |   ||||       |         |
      
      What happened was that it was using the ring_buffer_iter_empty() function to
      see if it was empty, and if it was, it showed the status. But that function
      was returning false when it was empty. The reason was that the iter header
      page was on the reader page, and the reader page was empty, but so was the
      buffer itself. The check only tested to see if the iter was on the commit
      page, but the commit page was no longer pointing to the reader page, but as
      all pages were empty, the buffer is also.
      
      Fixes: 651e22f2 ("ring-buffer: Always reset iterator to reader page")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b83d4b7
    • Steven Rostedt (VMware)'s avatar
      tracing: Allocate the snapshot buffer before enabling probe · be0ef33e
      Steven Rostedt (VMware) authored
      commit df62db5b upstream.
      
      Currently the snapshot trigger enables the probe and then allocates the
      snapshot. If the probe triggers before the allocation, it could cause the
      snapshot to fail and turn tracing off. It's best to allocate the snapshot
      buffer first, and then enable the trigger. If something goes wrong in the
      enabling of the trigger, the snapshot buffer is still allocated, but it can
      also be freed by the user by writting zero into the snapshot buffer file.
      
      Also add a check of the return status of alloc_snapshot().
      
      Fixes: 77fd5c15 ("tracing: Add snapshot trigger to function probes")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be0ef33e
    • Eric Biggers's avatar
      KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings · 6efda250
      Eric Biggers authored
      commit c9f838d1 upstream.
      
      This fixes CVE-2017-7472.
      
      Running the following program as an unprivileged user exhausts kernel
      memory by leaking thread keyrings:
      
      	#include <keyutils.h>
      
      	int main()
      	{
      		for (;;)
      			keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING);
      	}
      
      Fix it by only creating a new thread keyring if there wasn't one before.
      To make things more consistent, make install_thread_keyring_to_cred()
      and install_process_keyring_to_cred() both return 0 if the corresponding
      keyring is already present.
      
      Fixes: d84f4f99 ("CRED: Inaugurate COW credentials")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6efda250
    • David Howells's avatar
      KEYS: Change the name of the dead type to ".dead" to prevent user access · 44d6e10f
      David Howells authored
      commit c1644fe0 upstream.
      
      This fixes CVE-2017-6951.
      
      Userspace should not be able to do things with the "dead" key type as it
      doesn't have some of the helper functions set upon it that the kernel
      needs.  Attempting to use it may cause the kernel to crash.
      
      Fix this by changing the name of the type to ".dead" so that it's rejected
      up front on userspace syscalls by key_get_type_from_user().
      
      Though this doesn't seem to affect recent kernels, it does affect older
      ones, certainly those prior to:
      
      	commit c06cfb08
      	Author: David Howells <dhowells@redhat.com>
      	Date:   Tue Sep 16 17:36:06 2014 +0100
      	KEYS: Remove key_type::match in favour of overriding default by match_preparse
      
      which went in before 3.18-rc1.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44d6e10f
    • David Howells's avatar
      KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings · 44c03782
      David Howells authored
      commit ee8f844e upstream.
      
      This fixes CVE-2016-9604.
      
      Keyrings whose name begin with a '.' are special internal keyrings and so
      userspace isn't allowed to create keyrings by this name to prevent
      shadowing.  However, the patch that added the guard didn't fix
      KEYCTL_JOIN_SESSION_KEYRING.  Not only can that create dot-named keyrings,
      it can also subscribe to them as a session keyring if they grant SEARCH
      permission to the user.
      
      This, for example, allows a root process to set .builtin_trusted_keys as
      its session keyring, at which point it has full access because now the
      possessor permissions are added.  This permits root to add extra public
      keys, thereby bypassing module verification.
      
      This also affects kexec and IMA.
      
      This can be tested by (as root):
      
      	keyctl session .builtin_trusted_keys
      	keyctl add user a a @s
      	keyctl list @s
      
      which on my test box gives me:
      
      	2 keys in keyring:
      	180010936: ---lswrv     0     0 asymmetric: Build time autogenerated kernel key: ae3d4a31b82daa8e1a75b49dc2bba949fd992a05
      	801382539: --alswrv     0     0 user: a
      
      
      Fix this by rejecting names beginning with a '.' in the keyctl.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      cc: linux-ima-devel@lists.sourceforge.net
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44c03782
  2. 22 Apr, 2017 6 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.18.50 · 630b59cd
      Greg Kroah-Hartman authored
      630b59cd
    • Linus Torvalds's avatar
      give up on gcc ilog2() constant optimizations · 2143e71a
      Linus Torvalds authored
      commit 474c9015 upstream.
      
      gcc-7 has an "optimization" pass that completely screws up, and
      generates the code expansion for the (impossible) case of calling
      ilog2() with a zero constant, even when the code gcc compiles does not
      actually have a zero constant.
      
      And we try to generate a compile-time error for anybody doing ilog2() on
      a constant where that doesn't make sense (be it zero or negative).  So
      now gcc7 will fail the build due to our sanity checking, because it
      created that constant-zero case that didn't actually exist in the source
      code.
      
      There's a whole long discussion on the kernel mailing about how to work
      around this gcc bug.  The gcc people themselevs have discussed their
      "feature" in
      
         https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
      
      but it's all water under the bridge, because while it looked at one
      point like it would be solved by the time gcc7 was released, that was
      not to be.
      
      So now we have to deal with this compiler braindamage.
      
      And the only simple approach seems to be to just delete the code that
      tries to warn about bad uses of ilog2().
      
      So now "ilog2()" will just return 0 not just for the value 1, but for
      any non-positive value too.
      
      It's not like I can recall anybody having ever actually tried to use
      this function on any invalid value, but maybe the sanity check just
      meant that such code never made it out in public.
      Reported-by: default avatarLaura Abbott <labbott@redhat.com>
      Cc: John Stultz <john.stultz@linaro.org>,
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2143e71a
    • James Hogan's avatar
      metag/usercopy: Add missing fixups · 9e5397c7
      James Hogan authored
      commit b884a190 upstream.
      
      The rapf copy loops in the Meta usercopy code is missing some extable
      entries for HTP cores with unaligned access checking enabled, where
      faults occur on the instruction immediately after the faulting access.
      
      Add the fixup labels and extable entries for these cases so that corner
      case user copy failures don't cause kernel crashes.
      
      Fixes: 373cd784 ("metag: Memory handling")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-metag@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e5397c7
    • James Hogan's avatar
      metag/usercopy: Fix src fixup in from user rapf loops · 4740da3f
      James Hogan authored
      commit 2c0b1df8 upstream.
      
      The fixup code to rewind the source pointer in
      __asm_copy_from_user_{32,64}bit_rapf_loop() always rewound the source by
      a single unit (4 or 8 bytes), however this is insufficient if the fault
      didn't occur on the first load in the loop, as the source pointer will
      have been incremented but nothing will have been stored until all 4
      register [pairs] are loaded.
      
      Read the LSM_STEP field of TXSTATUS (which is already loaded into a
      register), a bit like the copy_to_user versions, to determine how many
      iterations of MGET[DL] have taken place, all of which need rewinding.
      
      Fixes: 373cd784 ("metag: Memory handling")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-metag@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4740da3f
    • James Hogan's avatar
      metag/usercopy: Set flags before ADDZ · 5620eb31
      James Hogan authored
      commit fd40eee1 upstream.
      
      The fixup code for the copy_to_user rapf loops reads TXStatus.LSM_STEP
      to decide how far to rewind the source pointer. There is a special case
      for the last execution of an MGETL/MGETD, since it leaves LSM_STEP=0
      even though the number of MGETLs/MGETDs attempted was 4. This uses ADDZ
      which is conditional upon the Z condition flag, but the AND instruction
      which masked the TXStatus.LSM_STEP field didn't set the condition flags
      based on the result.
      
      Fix that now by using ANDS which does set the flags, and also marking
      the condition codes as clobbered by the inline assembly.
      
      Fixes: 373cd784 ("metag: Memory handling")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-metag@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5620eb31
    • James Hogan's avatar
      metag/usercopy: Zero rest of buffer from copy_from_user · c02ee85c
      James Hogan authored
      commit 563ddc10 upstream.
      
      Currently we try to zero the destination for a failed read from userland
      in fixup code in the usercopy.c macros. The rest of the destination
      buffer is then zeroed from __copy_user_zeroing(), which is used for both
      copy_from_user() and __copy_from_user().
      
      Unfortunately we fail to zero in the fixup code as D1Ar1 is set to 0
      before the fixup code entry labels, and __copy_from_user() shouldn't even
      be zeroing the rest of the buffer.
      
      Move the zeroing out into copy_from_user() and rename
      __copy_user_zeroing() to raw_copy_from_user() since it no longer does
      any zeroing. This also conveniently matches the name needed for
      RAW_COPY_USER support in a later patch.
      
      Fixes: 373cd784 ("metag: Memory handling")
      Reported-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-metag@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c02ee85c