commit 760b5f93bd0b5c735ae53b29a2d63d98c34f4050
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Tue Apr 4 22:21:58 2017 +0100

    Linux 3.16.43

commit c53ee259ad3da891e191dee7af119af340f9c01b
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Apr 1 04:55:18 2017 +0100

    keys: Guard against null match function in keyring_search_aux()
    
    The "dead" key type has no match operation, and a search for keys of
    this type can cause a null dereference in keyring_search_iterator().
    keyring_search() has a check for this, but request_keyring_and_link()
    does not.  Move the check into keyring_search_aux(), covering both of
    them.
    
    This was fixed upstream by commit c06cfb08b88d ("KEYS: Remove
    key_type::match in favour of overriding default by match_preparse"),
    part of a series of large changes that are not suitable for
    backporting.
    
    CVE-2017-2647 / CVE-2017-6951
    
    Reported-by: Igor Redko <redkoi@virtuozzo.com>
    Reported-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    References: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2647
    Reported-by: idl3r <idler1984@gmail.com>
    References: https://www.spinics.net/lists/keyrings/msg01845.html
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: David Howells <dhowells@redhat.com>

commit 880366a6e2ef182c37b7c7317dc6d449f625b97d
Author: Jann Horn <jann@thejh.net>
Date:   Fri Sep 16 00:31:22 2016 +0200

    aio: mark AIO pseudo-fs noexec
    
    commit 22f6b4d34fcf039c63a94e7670e0da24f8575a5a upstream.
    
    This ensures that do_mmap() won't implicitly make AIO memory mappings
    executable if the READ_IMPLIES_EXEC personality flag is set.  Such
    behavior is problematic because the security_mmap_file LSM hook doesn't
    catch this case, potentially permitting an attacker to bypass a W^X
    policy enforced by SELinux.
    
    I have tested the patch on my machine.
    
    To test the behavior, compile and run this:
    
        #define _GNU_SOURCE
        #include <unistd.h>
        #include <sys/personality.h>
        #include <linux/aio_abi.h>
        #include <err.h>
        #include <stdlib.h>
        #include <stdio.h>
        #include <sys/syscall.h>
    
        int main(void) {
            personality(READ_IMPLIES_EXEC);
            aio_context_t ctx = 0;
            if (syscall(__NR_io_setup, 1, &ctx))
                err(1, "io_setup");
    
            char cmd[1000];
            sprintf(cmd, "cat /proc/%d/maps | grep -F '/[aio]'",
                (int)getpid());
            system(cmd);
            return 0;
        }
    
    In the output, "rw-s" is good, "rwxs" is bad.
    
    Signed-off-by: Jann Horn <jann@thejh.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16: we don't have super_block::s_iflags; use
     file_system_type::fs_flags instead]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 495d1af4041fcb3cb726ca414d3c09cbb251fefa
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Jun 29 14:42:03 2015 -0500

    vfs: Commit to never having exectuables on proc and sysfs.
    
    commit 22f6b4d34fcf039c63a94e7670e0da24f8575a5a upstream.
    
    Today proc and sysfs do not contain any executable files.  Several
    applications today mount proc or sysfs without noexec and nosuid and
    then depend on there being no exectuables files on proc or sysfs.
    Having any executable files show on proc or sysfs would cause
    a user space visible regression, and most likely security problems.
    
    Therefore commit to never allowing executables on proc and sysfs by
    adding a new flag to mark them as filesystems without executables and
    enforce that flag.
    
    Test the flag where MNT_NOEXEC is tested today, so that the only user
    visible effect will be that exectuables will be treated as if the
    execute bit is cleared.
    
    The filesystems proc and sysfs do not currently incoporate any
    executable files so this does not result in any user visible effects.
    
    This makes it unnecessary to vet changes to proc and sysfs tightly for
    adding exectuable files or changes to chattr that would modify
    existing files, as no matter what the individual file say they will
    not be treated as exectuable files by the vfs.
    
    Not having to vet changes to closely is important as without this we
    are only one proc_create call (or another goof up in the
    implementation of notify_change) from having problematic executables
    on proc.  Those mistakes are all too easy to make and would create
    a situation where there are security issues or the assumptions of
    some program having to be broken (and cause userspace regressions).
    
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    [bwh: Backported to 3.16: we don't have super_block::s_iflags; use
     file_system_type::fs_flags instead]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 07a365dd69b520758dd85d215b1a6e2cffb8168f
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Feb 18 15:03:24 2016 +0100

    netlink: remove mmapped netlink support
    
    commit d1b4c689d4130bcfd3532680b64db562300716b6 upstream.
    
    mmapped netlink has a number of unresolved issues:
    
    - TX zerocopy support had to be disabled more than a year ago via
      commit 4682a0358639b29cf ("netlink: Always copy on mmap TX.")
      because the content of the mmapped area can change after netlink
      attribute validation but before message processing.
    
    - RX support was implemented mainly to speed up nfqueue dumping packet
      payload to userspace.  However, since commit ae08ce0021087a5d812d2
      ("netfilter: nfnetlink_queue: zero copy support") we avoid one copy
      with the socket-based interface too (via the skb_zerocopy helper).
    
    The other problem is that skbs attached to mmaped netlink socket
    behave different from normal skbs:
    
    - they don't have a shinfo area, so all functions that use skb_shinfo()
    (e.g. skb_clone) cannot be used.
    
    - reserving headroom prevents userspace from seeing the content as
    it expects message to start at skb->head.
    See for instance
    commit aa3a022094fa ("netlink: not trim skb for mmaped socket when dump").
    
    - skbs handed e.g. to netlink_ack must have non-NULL skb->sk, else we
    crash because it needs the sk to check if a tx ring is attached.
    
    Also not obvious, leads to non-intuitive bug fixes such as 7c7bdf359
    ("netfilter: nfnetlink: use original skbuff when acking batches").
    
    mmaped netlink also didn't play nicely with the skb_zerocopy helper
    used by nfqueue and openvswitch.  Daniel Borkmann fixed this via
    commit 6bb0fef489f6 ("netlink, mmap: fix edge-case leakages in nf queue
    zero-copy")' but at the cost of also needing to provide remaining
    length to the allocation function.
    
    nfqueue also has problems when used with mmaped rx netlink:
    - mmaped netlink doesn't allow use of nfqueue batch verdict messages.
      Problem is that in the mmap case, the allocation time also determines
      the ordering in which the frame will be seen by userspace (A
      allocating before B means that A is located in earlier ring slot,
      but this also means that B might get a lower sequence number then A
      since seqno is decided later.  To fix this we would need to extend the
      spinlocked region to also cover the allocation and message setup which
      isn't desirable.
    - nfqueue can now be configured to queue large (GSO) skbs to userspace.
      Queing GSO packets is faster than having to force a software segmentation
      in the kernel, so this is a desirable option.  However, with a mmap based
      ring one has to use 64kb per ring slot element, else mmap has to fall back
      to the socket path (NL_MMAP_STATUS_COPY) for all large packets.
    
    To use the mmap interface, userspace not only has to probe for mmap netlink
    support, it also has to implement a recv/socket receive path in order to
    handle messages that exceed the size of an rx ring element.
    
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Ken-ichirou MATSUZAWA <chamaken@gmail.com>
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: deleted code and documentation is different in places]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Shi Yuejie <shiyuejie@outlook.com>

commit 4e54d5d95fc4156cedebb7286abc932ad628690c
Author: James C Boyd <jcboyd.dev@gmail.com>
Date:   Wed May 27 17:09:06 2015 -0500

    HID: hid-input: Add parentheses to quell gcc warning
    
    commit 09a5c34e8d6b05663ec4c3d22b1fbd9fec89aaf9 upstream.
    
    GCC reports a -Wlogical-not-parentheses warning here; therefore
    add parentheses to shut it up and to express our intent more.
    
    Signed-off-by: James C Boyd <jcboyd.dev@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit 4c125b48deacb51dbe5618ba5c1cfec9bcc41e6e
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Tue Nov 18 18:47:13 2014 +0100

    MIPS: Zero variable read by get_user / __get_user in case of an error.
    
    commit 640465bda58c7078725201be7430c31a349121e9 upstream.
    
    This wasn't happening in all cases.
    
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit cfe5ef4021ed81be0a3117a956f31fc545d0df8d
Author: John Crispin <john@phrozen.org>
Date:   Tue Dec 20 19:12:46 2016 +0100

    MIPS: ralink: Cosmetic change to prom_init().
    
    commit 9c48568b3692f1a56cbf1935e4eea835e6b185b1 upstream.
    
    Over the years the code has been changed various times leading to
    argc/argv being defined in a different function to where we actually
    use the variables. Clean this up by moving them to prom_init_cmdline().
    
    Signed-off-by: John Crispin <john@phrozen.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/14902/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit e5de64180ba0ead57e79d5bd325e993f9c73746e
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Wed Jun 4 20:06:41 2014 -0300

    serial: samsung: Use %pa to print 'resource_size_t' type
    
    commit 1ff5b64dccbf23acfe7993b9132b6992922a4756 upstream.
    
    When building multi_v7_defconfig with CONFIG_ARM_LPAE=y the following warning
    is seen:
    
    drivers/tty/serial/samsung.c: In function 's3c24xx_serial_init_port':
    drivers/tty/serial/samsung.c:1229:2: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'resource_size_t' [-Wformat]
    
    Use %pa to print 'resource_size_t' type to fix the warning.
    
    Reported-by: Olof's autobuilder <build@lixom.net>
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Reviewed-by: Jingoo Han <jg1.han@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit 24c2431e0be6966fec1c66e32965595e69e945a5
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Feb 24 10:47:27 2015 +0100

    mmc: sunxi: avoid invalid pointer calculation
    
    commit d34712d2e3db9b241d0484a6e3839c6b7ef9df78 upstream.
    
    The sunxi mmc driver tries to calculate a dma address by using pointer
    arithmetic, which causes a warning when dma_addr_t is wider than a pointer:
    
    drivers/mmc/host/sunxi-mmc.c: In function 'sunxi_mmc_init_idma_des':
    drivers/mmc/host/sunxi-mmc.c:296:35: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      struct sunxi_idma_des *pdes_pa = (struct sunxi_idma_des *)host->sg_dma;
                                       ^
    
    To avoid this warning and to simplify the logic, this changes
    the code to avoid the cast and calculate the correct address
    manually. The behavior should be unchanged.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: David Lanzendörfer <david.lanzendoerfer@o2s.ch>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1fcb247a6bca1e37f25b8bcba7c8c409e0eb11d0
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Thu Apr 23 17:17:40 2015 +0100

    fs/nfs: fix new compiler warning about boolean in switch
    
    commit c7757074839f2cd440521482d76ea180d0d4bdac 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: Andre Przywara <andre.przywara@arm.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit fa5c761a1d5ec1614268cf74bbe8fa5b63b280de
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 3 23:33:23 2017 +0100

    crypto: improve gcc optimization flags for serpent and wp512
    
    commit 7d6e9105026788c497f0ab32fa16c82f4ab5ff61 upstream.
    
    An ancient gcc bug (first reported in 2003) has apparently resurfaced
    on MIPS, where kernelci.org reports an overly large stack frame in the
    whirlpool hash algorithm:
    
    crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than 1024 bytes [-Wframe-larger-than=]
    
    With some testing in different configurations, I'm seeing large
    variations in stack frames size up to 1500 bytes for what should have
    around 300 bytes at most. I also checked the reference implementation,
    which is essentially the same code but also comes with some test and
    benchmarking infrastructure.
    
    It seems that recent compiler versions on at least arm, arm64 and powerpc
    have a partial fix for this problem, but enabling "-fsched-pressure", but
    even with that fix they suffer from the issue to a certain degree. Some
    testing on arm64 shows that the time needed to hash a given amount of
    data is roughly proportional to the stack frame size here, which makes
    sense given that the wp512 implementation is doing lots of loads for
    table lookups, and the problem with the overly large stack is a result
    of doing a lot more loads and stores for spilled registers (as seen from
    inspecting the object code).
    
    Disabling -fschedule-insns consistently fixes the problem for wp512,
    in my collection of cross-compilers, the results are consistently better
    or identical when comparing the stack sizes in this function, though
    some architectures (notable x86) have schedule-insns disabled by
    default.
    
    The four columns are:
    default: -O2
    press:   -O2 -fsched-pressure
    nopress: -O2 -fschedule-insns -fno-sched-pressure
    nosched: -O2 -no-schedule-insns (disables sched-pressure)
    
                                    default press   nopress nosched
    alpha-linux-gcc-4.9.3           1136    848     1136    176
    am33_2.0-linux-gcc-4.9.3        2100    2076    2100    2104
    arm-linux-gnueabi-gcc-4.9.3     848     848     1048    352
    cris-linux-gcc-4.9.3            272     272     272     272
    frv-linux-gcc-4.9.3             1128    1000    1128    280
    hppa64-linux-gcc-4.9.3          1128    336     1128    184
    hppa-linux-gcc-4.9.3            644     308     644     276
    i386-linux-gcc-4.9.3            352     352     352     352
    m32r-linux-gcc-4.9.3            720     656     720     268
    microblaze-linux-gcc-4.9.3      1108    604     1108    256
    mips64-linux-gcc-4.9.3          1328    592     1328    208
    mips-linux-gcc-4.9.3            1096    624     1096    240
    powerpc64-linux-gcc-4.9.3       1088    432     1088    160
    powerpc-linux-gcc-4.9.3         1080    584     1080    224
    s390-linux-gcc-4.9.3            456     456     624     360
    sh3-linux-gcc-4.9.3             292     292     292     292
    sparc64-linux-gcc-4.9.3         992     240     992     208
    sparc-linux-gcc-4.9.3           680     592     680     312
    x86_64-linux-gcc-4.9.3          224     240     272     224
    xtensa-linux-gcc-4.9.3          1152    704     1152    304
    
    aarch64-linux-gcc-7.0.0         224     224     1104    208
    arm-linux-gnueabi-gcc-7.0.1     824     824     1048    352
    mips-linux-gcc-7.0.0            1120    648     1120    272
    x86_64-linux-gcc-7.0.1          240     240     304     240
    
    arm-linux-gnueabi-gcc-4.4.7     840                     392
    arm-linux-gnueabi-gcc-4.5.4     784     728     784     320
    arm-linux-gnueabi-gcc-4.6.4     736     728     736     304
    arm-linux-gnueabi-gcc-4.7.4     944     784     944     352
    arm-linux-gnueabi-gcc-4.8.5     464     464     760     352
    arm-linux-gnueabi-gcc-4.9.3     848     848     1048    352
    arm-linux-gnueabi-gcc-5.3.1     824     824     1064    336
    arm-linux-gnueabi-gcc-6.1.1     808     808     1056    344
    arm-linux-gnueabi-gcc-7.0.1     824     824     1048    352
    
    Trying the same test for serpent-generic, the picture is a bit different,
    and while -fno-schedule-insns is generally better here than the default,
    -fsched-pressure wins overall, so I picked that instead.
    
                                    default press   nopress nosched
    alpha-linux-gcc-4.9.3           1392    864     1392    960
    am33_2.0-linux-gcc-4.9.3        536     524     536     528
    arm-linux-gnueabi-gcc-4.9.3     552     552     776     536
    cris-linux-gcc-4.9.3            528     528     528     528
    frv-linux-gcc-4.9.3             536     400     536     504
    hppa64-linux-gcc-4.9.3          524     208     524     480
    hppa-linux-gcc-4.9.3            768     472     768     508
    i386-linux-gcc-4.9.3            564     564     564     564
    m32r-linux-gcc-4.9.3            712     576     712     532
    microblaze-linux-gcc-4.9.3      724     392     724     512
    mips64-linux-gcc-4.9.3          720     384     720     496
    mips-linux-gcc-4.9.3            728     384     728     496
    powerpc64-linux-gcc-4.9.3       704     304     704     480
    powerpc-linux-gcc-4.9.3         704     296     704     480
    s390-linux-gcc-4.9.3            560     560     592     536
    sh3-linux-gcc-4.9.3             540     540     540     540
    sparc64-linux-gcc-4.9.3         544     352     544     496
    sparc-linux-gcc-4.9.3           544     344     544     496
    x86_64-linux-gcc-4.9.3          528     536     576     528
    xtensa-linux-gcc-4.9.3          752     544     752     544
    
    aarch64-linux-gcc-7.0.0         432     432     656     480
    arm-linux-gnueabi-gcc-7.0.1     616     616     808     536
    mips-linux-gcc-7.0.0            720     464     720     488
    x86_64-linux-gcc-7.0.1          536     528     600     536
    
    arm-linux-gnueabi-gcc-4.4.7     592                     440
    arm-linux-gnueabi-gcc-4.5.4     776     448     776     544
    arm-linux-gnueabi-gcc-4.6.4     776     448     776     544
    arm-linux-gnueabi-gcc-4.7.4     768     448     768     544
    arm-linux-gnueabi-gcc-4.8.5     488     488     776     544
    arm-linux-gnueabi-gcc-4.9.3     552     552     776     536
    arm-linux-gnueabi-gcc-5.3.1     552     552     776     536
    arm-linux-gnueabi-gcc-6.1.1     560     560     776     536
    arm-linux-gnueabi-gcc-7.0.1     616     616     808     536
    
    I did not do any runtime tests with serpent, so it is possible that stack
    frame size does not directly correlate with runtime performance here and
    it actually makes things worse, but it's more likely to help here, and
    the reduced stack frame size is probably enough reason to apply the patch,
    especially given that the crypto code is often used in deep call chains.
    
    Link: https://kernelci.org/build/id/58797d7559b5149efdf6c3a9/logs/
    Link: http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11488
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1964b12e89acdcd315ccc23da558ff34176f5f5b
Author: Tillmann Heidsieck <theidsieck@leenox.de>
Date:   Sat Oct 10 21:47:19 2015 +0200

    atm: iphase: fix misleading indention
    
    commit cbb41b91e68a302087762823136c9067138cff7c upstream.
    
    Fix a smatch warning:
    drivers/atm/iphase.c:1178 rx_pkt() warn: curly braces intended?
    
    The code is correct, the indention is misleading. In case the allocation
    of skb fails, we want to skip to the end.
    
    Signed-off-by: Tillmann Heidsieck <theidsieck@leenox.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit 3831477bd41af9f48225a6a80224e19f631c191c
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Fri Jan 30 12:09:33 2015 +0000

    MIPS: wrap cfcmsa & ctcmsa accesses for toolchains with MSA support
    
    commit e1bebbab1eaecac77d77033010b5e0f51b737e64 upstream.
    
    Uses of the cfcmsa & ctcmsa instructions were not being wrapped by a
    macro in the case where the toolchain supports MSA, since the arguments
    exactly match a typical use of the instructions. However using current
    toolchains this leads to errors such as:
    
      arch/mips/kernel/genex.S:437: Error: opcode not supported on this processor: mips32r2 (mips32r2) `cfcmsa $5,1'
    
    Thus uses of the instructions must be in the context of a ".set msa"
    directive, however doing that from the users of the instructions would
    be messy due to the possibility that the toolchain does not support
    MSA. Fix this by renaming the macros (prepending an underscore) in order
    to avoid recursion when attempting to emit the instructions, and provide
    implementations for the TOOLCHAIN_SUPPORTS_MSA case which ".set msa" as
    appropriate.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/9163/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5c57237ea9e2f0b1fdcec3303953d7239f2fa389
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Fri Jan 30 12:09:32 2015 +0000

    MIPS: remove MSA macro recursion
    
    commit a3a49810c55e3489dfb5d72a9b2e41ab1db9ffb9 upstream.
    
    Recursive macros made the code more concise & worked great for the
    case where the toolchain doesn't support MSA. However, with toolchains
    which do support MSA they lead to build failures such as:
    
      arch/mips/kernel/r4k_switch.S: Assembler messages:
      arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w(0+1)[2],$1'
      arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w(0+1)[3],$1'
      arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w((0+1)+1)[2],$1'
      arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w((0+1)+1)[3],$1'
      ...
    
    Drop the recursion from msa_init_all_upper invoking the msa_init_upper
    macro explicitly for each vector register.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/9162/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7478d34246281da3a6b9ba33a07217add19565b1
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Fri Jan 30 12:09:31 2015 +0000

    MIPS: assume at as source/dest of MSA copy/insert instructions
    
    commit f23ce3883a30743a5b779dc6fb90ca8620688a23 upstream.
    
    Assuming at ($1) as the source or destination register of copy or
    insert instructions:
    
      - Simplifies the macros providing those instructions for toolchains
        without MSA support.
    
      - Avoids an unnecessary move instruction when at is used as the source
        or destination register anyway.
    
      - Is sufficient for the uses to be introduced in the kernel by a
        subsequent patch.
    
    Note that due to a patch ordering snafu on my part this also fixes the
    currently broken build with MSA support enabled. The build has been
    broken since commit c9017757c532 "MIPS: init upper 64b of vector
    registers when MSA is first used", which this patch should have
    preceeded.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/9161/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1a68ee723bfdee1b3030e3c17a5ba01db78cf276
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Fri Mar 27 17:00:03 2015 +0000

    MIPS: Push .set mips64r* into the functions needing it
    
    commit 631afc65e8f4f845945ef9e90236d10cee601498 upstream.
    
    The {save,restore}_fp_context{,32} functions require that the assembler
    allows the use of sdc instructions on any FP register, and this is
    acomplished by setting the arch to mips64r2 or mips64r6
    (using MIPS_ISA_ARCH_LEVEL_RAW).
    
    However this has the effect of enabling the assembler to use mips64
    instructions in the expansion of pseudo-instructions. This was done in
    the (now-reverted) commit eec43a224cf1 "MIPS: Save/restore MSA context
    around signals" which led to my mistakenly believing that there was an
    assembler bug, when in reality the assembler was just emitting mips64
    instructions. Avoid the issue for future commits which will add code to
    r4k_fpu.S by pushing the .set MIPS_ISA_ARCH_LEVEL_RAW directives into
    the functions that require it, and remove the spurious assertion
    declaring the assembler bug.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    [james.hogan@imgtec.com: Rebase on v4.0-rc1 and reword commit message to
     reflect use of MIPS_ISA_ARCH_LEVEL_RAW]
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/9612/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    [bwh: Backported to 3.16: in r4k_fpu.S, keep using arch=r4000]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8deb4d7c79bc43121c2f07b71e4265396949e926
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Jan 30 15:40:20 2015 +0000

    MIPS: traps: Fix inline asm ctc1 missing .set hardfloat
    
    commit d76e9b9fc5de7e8fc4fd0e72a94e8c723929ffea upstream.
    
    Commit 842dfc11ea9a ("MIPS: Fix build with binutils 2.24.51+") in v3.18
    enabled -msoft-float and sprinkled ".set hardfloat" where necessary to
    use FP instructions. However it missed enable_restore_fp_context() which
    since v3.17 does a ctc1 with inline assembly, causing the following
    assembler errors on Mentor's 2014.05 toolchain:
    
    {standard input}: Assembler messages:
    {standard input}:2913: Error: opcode not supported on this processor: mips32r2 (mips32r2) `ctc1 $2,$31'
    scripts/Makefile.build:257: recipe for target 'arch/mips/kernel/traps.o' failed
    
    Fix that to use the new write_32bit_cp1_register() macro so that ".set
    hardfloat" is automatically added when -msoft-float is in use.
    
    Fixes 842dfc11ea9a ("MIPS: Fix build with binutils 2.24.51+")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/9173/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 35dd58f316b271806815b5ee605d19b54648394e
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Jan 30 15:40:19 2015 +0000

    MIPS: mipsregs.h: Add write_32bit_cp1_register()
    
    commit 5e32033e14ca9c7f7341cb383f5a05699b0b5382 upstream.
    
    Add a write_32bit_cp1_register() macro to compliment the
    read_32bit_cp1_register() macro. This is to abstract whether .set
    hardfloat needs to be used based on GAS_HAS_SET_HARDFLOAT.
    
    The implementation of _read_32bit_cp1_register() .sets mips1 due to
    failure of gas v2.19 to assemble cfc1 for Octeon (see commit
    25c300030016 ("MIPS: Override assembler target architecture for
    octeon.")). I haven't copied this over to _write_32bit_cp1_register() as
    I'm uncertain whether it applies to ctc1 too, or whether anybody cares
    about that version of binutils any longer.
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Paul Burton <paul.burton@imgtec.com>
    Cc: David Daney <david.daney@cavium.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/9172/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1e7276ac0cf61d026e7fa93fed2e3594019e2f56
Author: Manuel Lauss <manuel.lauss@gmail.com>
Date:   Fri Nov 7 14:13:54 2014 +0100

    MIPS: Fix build with binutils 2.24.51+
    
    commit 842dfc11ea9a21f9825167c8a4f2834b205b0a79 upstream.
    
    Starting with version 2.24.51.20140728 MIPS binutils complain loudly
    about mixing soft-float and hard-float object files, leading to this
    build failure since GCC is invoked with "-msoft-float" on MIPS:
    
    {standard input}: Warning: .gnu_attribute 4,3 requires `softfloat'
      LD      arch/mips/alchemy/common/built-in.o
    mipsel-softfloat-linux-gnu-ld: Warning: arch/mips/alchemy/common/built-in.o
     uses -msoft-float (set by arch/mips/alchemy/common/prom.o),
     arch/mips/alchemy/common/sleeper.o uses -mhard-float
    
    To fix this, we detect if GAS is new enough to support "-msoft-float" command
    option, and if it does, we can let GCC pass it to GAS;  but then we also need
    to sprinkle the files which make use of floating point registers with the
    necessary ".set hardfloat" directives.
    
    Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
    Cc: Linux-MIPS <linux-mips@linux-mips.org>
    Cc: Matthew Fortune <Matthew.Fortune@imgtec.com>
    Cc: Markos Chandras <Markos.Chandras@imgtec.com>
    Cc: Maciej W. Rozycki <macro@linux-mips.org>
    Patchwork: https://patchwork.linux-mips.org/patch/8355/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit 2c627f990c564fb99a70cf9a044db0edeca802fc
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Wed Jul 30 08:53:20 2014 +0100

    MIPS: init upper 64b of vector registers when MSA is first used
    
    commit c9017757c532d48bf43d6e7d3b7282443ad4207b upstream.
    
    When a task first makes use of MSA we need to ensure that the upper
    64b of the vector registers are set to some value such that no
    information can be leaked to it from the previous task to use MSA
    context on the CPU. The architecture formerly specified that these
    bits would be cleared to 0 when a scalar FP instructions wrote to the
    aliased FP registers, which would have implicitly handled this as the
    kernel restored scalar FP context. However more recent versions of the
    specification now state that the value of the bits in such cases is
    unpredictable. Initialise them explictly to be sure, and set all the
    bits to 1 rather than 0 for consistency with the least significant
    64b.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/7497/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit 13acbb17b0de3d32d232d512162c9f7a76136234
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Fri Jul 11 16:44:30 2014 +0100

    MIPS: save/disable MSA in lose_fpu
    
    commit 33c771ba5c5d067f85a5a6c4b11047219b5b8f4e upstream.
    
    The kernel depends upon MSA never being enabled when the FPU is not, a
    condition which is currently violated in a few places (whilst saving
    sigcontext, following mips_cpu_save). Catch all the problem cases by
    disabling MSA in lose_fpu, after saving context if necessary.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/7302/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit 5ff2ed33048d3d45cce81b05f96f80afdae1abc3
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Fri Jul 11 16:44:29 2014 +0100

    MIPS: preserve scalar FP CSR when switching vector context
    
    commit b83406735a4ae0aff4b614664d6a64a0fd6b9917 upstream.
    
    Switching the vector context implicitly saves & restores the state of
    the aliased scalar FP data registers, however the scalar FP control
    & status register is distinct from the MSA control & status register.
    In order to allow scalar FP to function correctly in programs using
    MSA, the scalar CSR needs to be saved & restored along with the MSA
    vector context.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/7301/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit 249dbf6c26461f52397bd5ab782970e2f0c62fcb
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Fri Jul 11 16:44:28 2014 +0100

    MIPS: save/restore MSACSR register on context switch
    
    commit f7a46fa7bb0047d3e226702a0c4b786862fe6843 upstream.
    
    I added a field for the MSACSR register in struct mips_fpu_struct, but
    never actually made use of it... This is a clear bug. Save and restore
    the MSACSR register along with the vector registers.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/7300/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit f251957b9ff32af7fe610787988a1a1f09b7d32d
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Fri Jul 11 16:44:27 2014 +0100

    MIPS: allow msa.h to be included in assembly files
    
    commit 558155a0a731b4f56846559a57ca7ca921230497 upstream.
    
    Just #ifdef away the C functions when included from an assembly file,
    as will be done in a following commit.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/7299/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5b9e032567e1a762bd86d1c7d4d6cf325b024c33
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed May 27 15:32:15 2015 -0700

    blk: rq_data_dir() should not return a boolean
    
    commit 10fbd36e362a0f367e34a7cd876a81295d8fc5ca upstream.
    
    rq_data_dir() returns either READ or WRITE (0 == READ, 1 == WRITE), not
    a boolean value.
    
    Now, admittedly the "!= 0" doesn't really change the value (0 stays as
    zero, 1 stays as one), but it's not only redundant, it confuses gcc, and
    causes gcc to warn about the construct
    
        switch (rq_data_dir(req)) {
            case READ:
                ...
            case WRITE:
                ...
    
    that we have in a few drivers.
    
    Now, the gcc warning is silly and stupid (it seems to warn not about the
    switch value having a different type from the case statements, but about
    _any_ boolean switch value), but in this case the code itself is silly
    and stupid too, so let's just change it, and get rid of warnings like
    this:
    
      drivers/block/hd.c: In function ‘hd_request’:
      drivers/block/hd.c:630:11: warning: switch condition has boolean value [-Wswitch-bool]
         switch (rq_data_dir(req)) {
    
    The odd '!= 0' came in when "cmd_flags" got turned into a "u64" in
    commit 5953316dbf90 ("block: make rq->cmd_flags be 64-bit") and is
    presumably because the old code (that just did a logical 'and' with 1)
    would then end up making the type of rq_data_dir() be u64 too.
    
    But if we want to retain the old regular integer type, let's just cast
    the result to 'int' rather than use that rather odd '!= 0'.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>

commit 0ffcf69c1afee1cbe7c34f473e04e8526638295f
Author: Tim Gardner <tim.gardner@canonical.com>
Date:   Thu Aug 28 11:26:03 2014 -0600

    fs: namespace: suppress 'may be used uninitialized' warnings
    
    commit b8850d1fa8e2f6653e57daf6d08e58c5f5eb2c85 upstream.
    
    The gcc version 4.9.1 compiler complains Even though it isn't possible for
    these variables to not get initialized before they are used.
    
    fs/namespace.c: In function ‘SyS_mount’:
    fs/namespace.c:2720:8: warning: ‘kernel_dev’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      ret = do_mount(kernel_dev, kernel_dir->name, kernel_type, flags,
            ^
    fs/namespace.c:2699:8: note: ‘kernel_dev’ was declared here
      char *kernel_dev;
            ^
    fs/namespace.c:2720:8: warning: ‘kernel_type’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      ret = do_mount(kernel_dev, kernel_dir->name, kernel_type, flags,
            ^
    fs/namespace.c:2697:8: note: ‘kernel_type’ was declared here
      char *kernel_type;
            ^
    
    Fix the warnings by simplifying copy_mount_string() as suggested by Al Viro.
    
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Arnd Bergmann <arnd@arndb.de>