1. 11 Aug, 2017 28 commits
    • Daniel Borkmann's avatar
      net: sctp: fix race for one-to-many sockets in sendmsg's auto associate · 0c59f879
      Daniel Borkmann authored
      commit 2061dcd6 upstream.
      
      I.e. one-to-many sockets in SCTP are not required to explicitly
      call into connect(2) or sctp_connectx(2) prior to data exchange.
      Instead, they can directly invoke sendmsg(2) and the SCTP stack
      will automatically trigger connection establishment through 4WHS
      via sctp_primitive_ASSOCIATE(). However, this in its current
      implementation is racy: INIT is being sent out immediately (as
      it cannot be bundled anyway) and the rest of the DATA chunks are
      queued up for later xmit when connection is established, meaning
      sendmsg(2) will return successfully. This behaviour can result
      in an undesired side-effect that the kernel made the application
      think the data has already been transmitted, although none of it
      has actually left the machine, worst case even after close(2)'ing
      the socket.
      
      Instead, when the association from client side has been shut down
      e.g. first gracefully through SCTP_EOF and then close(2), the
      client could afterwards still receive the server's INIT_ACK due
      to a connection with higher latency. This INIT_ACK is then considered
      out of the blue and hence responded with ABORT as there was no
      alive assoc found anymore. This can be easily reproduced f.e.
      with sctp_test application from lksctp. One way to fix this race
      is to wait for the handshake to actually complete.
      
      The fix defers waiting after sctp_primitive_ASSOCIATE() and
      sctp_primitive_SEND() succeeded, so that DATA chunks cooked up
      from sctp_sendmsg() have already been placed into the output
      queue through the side-effect interpreter, and therefore can then
      be bundeled together with COOKIE_ECHO control chunks.
      
      strace from example application (shortened):
      
      socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP) = 3
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(0)=[], msg_controllen=48, {cmsg_len=48, cmsg_level=0x84 /* SOL_??? */, cmsg_type=, ...},
                 msg_flags=0}, 0) = 0 // graceful shutdown for SOCK_SEQPACKET via SCTP_EOF
      close(3) = 0
      
      tcpdump before patch (fooling the application):
      
      22:33:36.306142 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 3879023686] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3139201684]
      22:33:36.316619 IP 192.168.1.115.8888 > 192.168.1.114.41462: sctp (1) [INIT ACK] [init tag: 3345394793] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 3380109591]
      22:33:36.317600 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [ABORT]
      
      tcpdump after patch:
      
      14:28:58.884116 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 438593213] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3092969729]
      14:28:58.888414 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [INIT ACK] [init tag: 381429855] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 2141904492]
      14:28:58.888638 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [COOKIE ECHO] , (2) [DATA] (B)(E) [TSN: 3092969729] [...]
      14:28:58.893278 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [COOKIE ACK] , (2) [SACK] [cum ack 3092969729] [a_rwnd 106491] [#gap acks 0] [#dup tsns 0]
      14:28:58.893591 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969730] [...]
      14:28:59.096963 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969730] [a_rwnd 106496] [#gap acks 0] [#dup tsns 0]
      14:28:59.097086 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969731] [...] , (2) [DATA] (B)(E) [TSN: 3092969732] [...]
      14:28:59.103218 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969732] [a_rwnd 106486] [#gap acks 0] [#dup tsns 0]
      14:28:59.103330 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN]
      14:28:59.107793 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SHUTDOWN ACK]
      14:28:59.107890 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN COMPLETE]
      
      Looks like this bug is from the pre-git history museum. ;)
      
      Fixes: 08707d54 ("lksctp-2_5_31-0_5_1.patch")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c59f879
    • Jan Stancek's avatar
      ipv6: fix possible deadlock in ip6_fl_purge / ip6_fl_gc · c2e8037c
      Jan Stancek authored
      commit 4762fb98 upstream.
      
      Use spin_lock_bh in ip6_fl_purge() to prevent following potentially
      deadlock scenario between ip6_fl_purge() and ip6_fl_gc() timer.
      
        =================================
        [ INFO: inconsistent lock state ]
        3.19.0 #1 Not tainted
        ---------------------------------
        inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
        swapper/5/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
         (ip6_fl_lock){+.?...}, at: [<ffffffff8171155d>] ip6_fl_gc+0x2d/0x180
        {SOFTIRQ-ON-W} state was registered at:
          [<ffffffff810ee9a0>] __lock_acquire+0x4a0/0x10b0
          [<ffffffff810efd54>] lock_acquire+0xc4/0x2b0
          [<ffffffff81751d2d>] _raw_spin_lock+0x3d/0x80
          [<ffffffff81711798>] ip6_flowlabel_net_exit+0x28/0x110
          [<ffffffff815f9759>] ops_exit_list.isra.1+0x39/0x60
          [<ffffffff815fa320>] cleanup_net+0x100/0x1e0
          [<ffffffff810ad80a>] process_one_work+0x20a/0x830
          [<ffffffff810adf4b>] worker_thread+0x11b/0x460
          [<ffffffff810b42f4>] kthread+0x104/0x120
          [<ffffffff81752bfc>] ret_from_fork+0x7c/0xb0
        irq event stamp: 84640
        hardirqs last  enabled at (84640): [<ffffffff81752080>] _raw_spin_unlock_irq+0x30/0x50
        hardirqs last disabled at (84639): [<ffffffff81751eff>] _raw_spin_lock_irq+0x1f/0x80
        softirqs last  enabled at (84628): [<ffffffff81091ad1>] _local_bh_enable+0x21/0x50
        softirqs last disabled at (84629): [<ffffffff81093b7d>] irq_exit+0x12d/0x150
      
        other info that might help us debug this:
         Possible unsafe locking scenario:
      
               CPU0
               ----
          lock(ip6_fl_lock);
          <Interrupt>
            lock(ip6_fl_lock);
      
         *** DEADLOCK ***
      Signed-off-by: default avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2e8037c
    • Oliver Neukum's avatar
      kaweth: fix oops upon failed memory allocation · 88c03bd0
      Oliver Neukum authored
      commit 575ced7f upstream.
      
      Just return an error upon failure.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88c03bd0
    • Oliver Neukum's avatar
      kaweth: fix firmware download · 34d28e0e
      Oliver Neukum authored
      commit 60bcabd0 upstream.
      
      This fixes the oops discovered by the Umap2 project and Alan Stern.
      The intf member needs to be set before the firmware is downloaded.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      34d28e0e
    • Calvin Owens's avatar
      mpt3sas: Don't overreach ioc->reply_post[] during initialization · c5c94ca0
      Calvin Owens authored
      commit 5ec8a175 upstream.
      
      In _base_make_ioc_operational(), we walk ioc->reply_queue_list and pull
      a pointer out of successive elements of ioc->reply_post[] for each entry
      in that list if RDPQ is enabled.
      
      Since the code pulls the pointer for the next iteration at the bottom of
      the loop, it triggers the a KASAN dump on the final iteration:
      
          BUG: KASAN: slab-out-of-bounds in _base_make_ioc_operational+0x47b7/0x47e0 [mpt3sas] at addr ffff880754816ab0
          Read of size 8 by task modprobe/305
          <snip>
          Call Trace:
           [<ffffffff81dfc591>] dump_stack+0x4d/0x6c
           [<ffffffff814c9689>] print_trailer+0xf9/0x150
           [<ffffffff814ceda4>] object_err+0x34/0x40
           [<ffffffff814d1231>] kasan_report_error+0x221/0x530
           [<ffffffff814d1673>] __asan_report_load8_noabort+0x43/0x50
           [<ffffffffa0043637>] _base_make_ioc_operational+0x47b7/0x47e0 [mpt3sas]
           [<ffffffffa0049a51>] mpt3sas_base_attach+0x1991/0x2120 [mpt3sas]
           [<ffffffffa0053c93>] _scsih_probe+0xeb3/0x16b0 [mpt3sas]
           [<ffffffff81ebd047>] local_pci_probe+0xc7/0x170
           [<ffffffff81ebf2cf>] pci_device_probe+0x20f/0x290
           [<ffffffff820d50cd>] really_probe+0x17d/0x600
           [<ffffffff820d56a3>] __driver_attach+0x153/0x190
           [<ffffffff820cffac>] bus_for_each_dev+0x11c/0x1a0
           [<ffffffff820d421d>] driver_attach+0x3d/0x50
           [<ffffffff820d378a>] bus_add_driver+0x44a/0x5f0
           [<ffffffff820d666c>] driver_register+0x18c/0x3b0
           [<ffffffff81ebcb76>] __pci_register_driver+0x156/0x200
           [<ffffffffa00c8135>] _mpt3sas_init+0x135/0x1000 [mpt3sas]
           [<ffffffff81000423>] do_one_initcall+0x113/0x2b0
           [<ffffffff813caa5a>] do_init_module+0x1d0/0x4d8
           [<ffffffff81273909>] load_module+0x6729/0x8dc0
           [<ffffffff81276123>] SYSC_init_module+0x183/0x1a0
           [<ffffffff8127625e>] SyS_init_module+0xe/0x10
           [<ffffffff828fe7d7>] entry_SYSCALL_64_fastpath+0x12/0x6a
      
      Fix this by pulling the value at the beginning of the loop.
      Signed-off-by: default avatarCalvin Owens <calvinowens@fb.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarJens Axboe <axboe@fb.com>
      Acked-by: default avatarChaitra Basappa <chaitra.basappa@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5c94ca0
    • Sudeep Holla's avatar
      mailbox: handle empty message in tx_tick · 37611b57
      Sudeep Holla authored
      commit cb710ab1 upstream.
      
      We already check if the message is empty before calling the client
      tx_done callback. Calling completion on a wait event is also invalid
      if the message is empty.
      
      This patch moves the existing empty message check earlier.
      
      Fixes: 2b6d83e2 ("mailbox: Introduce framework for mailbox")
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarJassi Brar <jaswinder.singh@linaro.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37611b57
    • Sudeep Holla's avatar
      mailbox: skip complete wait event if timer expired · 3b2d738b
      Sudeep Holla authored
      commit cc6eeaa3 upstream.
      
      If a wait_for_completion_timeout() call returns due to a timeout,
      complete() can get called after returning from the wait which is
      incorrect and can cause subsequent transmissions on a channel to fail.
      Since the wait_for_completion_timeout() sees the completion variable
      is non-zero caused by the erroneous/spurious complete() call, and
      it immediately returns without waiting for the time as expected by the
      client.
      
      This patch fixes the issue by skipping complete() call for the timer
      expiry.
      
      Fixes: 2b6d83e2 ("mailbox: Introduce framework for mailbox")
      Reported-by: default avatarAlexey Klimov <alexey.klimov@arm.com>
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarJassi Brar <jaswinder.singh@linaro.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b2d738b
    • Sudeep Holla's avatar
      mailbox: always wait in mbox_send_message for blocking Tx mode · 675c4213
      Sudeep Holla authored
      commit c61b781e upstream.
      
      There exists a race when msg_submit return immediately as there was an
      active request being processed which may have completed just before it's
      checked again in mbox_send_message. This will result in return to the
      caller without waiting in mbox_send_message even when it's blocking Tx.
      
      This patch fixes the issue by waiting for the completion always if Tx
      is in blocking mode.
      
      Fixes: 2b6d83e2 ("mailbox: Introduce framework for mailbox")
      Reported-by: default avatarAlexey Klimov <alexey.klimov@arm.com>
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Reviewed-by: default avatarAlexey Klimov <alexey.klimov@arm.com>
      Signed-off-by: default avatarJassi Brar <jaswinder.singh@linaro.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      675c4213
    • Lior David's avatar
      wil6210: fix deadlock when using fw_no_recovery option · 60866c07
      Lior David authored
      commit dfb5b098 upstream.
      
      When FW crashes with no_fw_recovery option, driver
      waits for manual recovery with wil->mutex held, this
      can easily create deadlocks.
      Fix the problem by moving the wait outside the lock.
      Signed-off-by: default avatarLior David <qca_liord@qca.qualcomm.com>
      Signed-off-by: default avatarMaya Erez <qca_merez@qca.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      60866c07
    • Annie Cherkaev's avatar
      isdn/i4l: fix buffer overflow · 4cb1585c
      Annie Cherkaev authored
      commit 9f5af546 upstream.
      
      This fixes a potential buffer overflow in isdn_net.c caused by an
      unbounded strcpy.
      
      [ ISDN seems to be effectively unmaintained, and the I4L driver in
        particular is long deprecated, but in case somebody uses this..
          - Linus ]
      Signed-off-by: default avatarJiten Thakkar <jitenmt@gmail.com>
      Signed-off-by: default avatarAnnie Cherkaev <annie.cherk@gmail.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4cb1585c
    • Chris Metcalf's avatar
      strscpy: zero any trailing garbage bytes in the destination · 588b2464
      Chris Metcalf authored
      commit 990486c8 upstream.
      
      It's possible that the destination can be shadowed in userspace
      (as, for example, the perf buffers are now).  So we should take
      care not to leak data that could be inspected by userspace.
      Signed-off-by: default avatarChris Metcalf <cmetcalf@ezchip.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      588b2464
    • Chris Metcalf's avatar
      string: provide strscpy() · a7191e90
      Chris Metcalf authored
      commit 30035e45 upstream.
      
      The strscpy() API is intended to be used instead of strlcpy(),
      and instead of most uses of strncpy().
      
      - Unlike strlcpy(), it doesn't read from memory beyond (src + size).
      
      - Unlike strlcpy() or strncpy(), the API provides an easy way to check
        for destination buffer overflow: an -E2BIG error return value.
      
      - The provided implementation is robust in the face of the source
        buffer being asynchronously changed during the copy, unlike the
        current implementation of strlcpy().
      
      - Unlike strncpy(), the destination buffer will be NUL-terminated
        if the string in the source buffer is too long.
      
      - Also unlike strncpy(), the destination buffer will not be updated
        beyond the NUL termination, avoiding strncpy's behavior of zeroing
        the entire tail end of the destination buffer.  (A memset() after
        the strscpy() can be used if this behavior is desired.)
      
      - The implementation should be reasonably performant on all
        platforms since it uses the asm/word-at-a-time.h API rather than
        simple byte copy.  Kernel-to-kernel string copy is not considered
        to be performance critical in any case.
      Signed-off-by: default avatarChris Metcalf <cmetcalf@ezchip.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7191e90
    • Jia-Ju Bai's avatar
      isdn: Fix a sleep-in-atomic bug · 906e2977
      Jia-Ju Bai authored
      commit e8f4ae85 upstream.
      
      The driver may sleep under a spin lock, the function call path is:
      isdn_ppp_mp_receive (acquire the lock)
        isdn_ppp_mp_reassembly
          isdn_ppp_push_higher
            isdn_ppp_decompress
              isdn_ppp_ccp_reset_trans
                isdn_ppp_ccp_reset_alloc_state
                  kzalloc(GFP_KERNEL) --> may sleep
      
      To fixed it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".
      Signed-off-by: default avatarJia-Ju Bai <baijiaju1990@163.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      906e2977
    • Florian Fainelli's avatar
      net: phy: Do not perform software reset for Generic PHY · aa3a735d
      Florian Fainelli authored
      commit 0878fff1 upstream.
      
      The Generic PHY driver is a catch-all PHY driver and it should preserve
      whatever prior initialization has been done by boot loader or firmware
      agents. For specific PHY device configuration it is expected that a
      specialized PHY driver would take over that role.
      
      Resetting the generic PHY was a bad idea that has lead to several
      complaints and downstream workarounds e.g: in OpenWrt/LEDE so restore
      the behavior prior to 87aa9f9c ("net: phy: consolidate PHY
      reset in phy_init_hw()").
      Reported-by: default avatarFelix Fietkau <nbd@nbd.name>
      Fixes: 87aa9f9c ("net: phy: consolidate PHY reset in phy_init_hw()")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa3a735d
    • Al Viro's avatar
      Bluetooth: cmtp: cmtp_add_connection() should verify that it's dealing with l2cap socket · bd6409bb
      Al Viro authored
      commit 96c26653 upstream.
      
      ... rather than relying on ciptool(8) never passing it anything else.  Give
      it e.g. an AF_UNIX connected socket (from socketpair(2)) and it'll oops,
      trying to evaluate &l2cap_pi(sock->sk)->chan->dst...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bd6409bb
    • Johan Hedberg's avatar
      Bluetooth: Fix potential NULL dereference · be7c0da3
      Johan Hedberg authored
      commit 88d9077c upstream.
      
      The bnep_get_device function may be triggered by an ioctl just after a
      connection has gone down. In such a case the respective L2CAP chan->conn
      pointer will get set to NULL (by l2cap_chan_del). This patch adds a
      missing NULL check for this case in the bnep_get_device() function.
      Reported-by: default avatarPatrik Flykt <patrik.flykt@linux.intel.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be7c0da3
    • Al Viro's avatar
    • Cheah Kok Cheong's avatar
      Staging: comedi: comedi_fops: Avoid orphaned proc entry · 354ff804
      Cheah Kok Cheong authored
      commit bf279ece upstream.
      
      Move comedi_proc_init to the end to avoid orphaned proc entry
      if module loading failed.
      Signed-off-by: default avatarCheah Kok Cheong <thrust73@gmail.com>
      Reviewed-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      354ff804
    • Greg Kroah-Hartman's avatar
      Revert "powerpc/numa: Fix percpu allocations to be NUMA aware" · 339b04fb
      Greg Kroah-Hartman authored
      This reverts commit 138bb148 which is
      commit ba4a648f upstream.
      
      Michal Hocko writes:
      
      JFYI. We have encountered a regression after applying this patch on a
      large ppc machine. While the patch is the right thing to do it doesn't
      work well with the current vmalloc area size on ppc and large machines
      where NUMA nodes are very far from each other. Just for the reference
      the boot fails on such a machine with bunch of warning preceeding it.
      See http://lkml.kernel.org/r/20170724134240.GL25221@dhcp22.suse.cz
      
      It seems the right thing to do is to enlarge the vmalloc space on ppc
      but this is not the case in the upstream kernel yet AFAIK. It is also
      questionable whether that is a stable material but I will decision on
      you here.
      
      We have reverted this patch from our 4.4 based kernel.
      
      Newer kernels do not have enlarged vmalloc space yet AFAIK so they won't
      work properly eiter. This bug is quite rare though because you need a
      specific HW configuration to trigger the issue - namely NUMA nodes have
      to be far away from each other in the physical memory space.
      
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      339b04fb
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Save/restore host values of debug registers · 94f743e4
      Paul Mackerras authored
      commit 7ceaa6dc upstream.
      
      At present, HV KVM on POWER8 and POWER9 machines loses any instruction
      or data breakpoint set in the host whenever a guest is run.
      Instruction breakpoints are currently only used by xmon, but ptrace
      and the perf_event subsystem can set data breakpoints as well as xmon.
      
      To fix this, we save the host values of the debug registers (CIABR,
      DAWR and DAWRX) before entering the guest and restore them on exit.
      To provide space to save them in the stack frame, we expand the stack
      frame allocated by kvmppc_hv_entry() from 112 to 144 bytes.
      
      [paulus@ozlabs.org - Adjusted stack offsets since we aren't saving
       POWER9-specific registers.]
      
      Fixes: b005255e ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94f743e4
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Reload HTM registers explicitly · 1c3ab876
      Paul Mackerras authored
      Commit 46a704f8 ("KVM: PPC: Book3S HV: Preserve userspace HTM
      state properly", 2017-06-15) added code which assumes that the kernel
      is able to handle a TM (transactional memory) unavailable interrupt
      from userspace by reloading the TM-related registers and enabling TM
      for the process.  That ability was added in the 4.9 kernel; earlier
      kernel versions simply panic on getting the TM unavailable interrupt.
      
      Since commit 46a704f8 has been backported to the 3.18 stable tree
      as commit 0b423dab, 3.18.59 and subsequent versions are vulnerable
      to a userspace-triggerable panic.
      
      This patch fixes the problem by explicitly reloading the TM-related
      registers before returning to userspace, rather than disabling TM
      for the process.
      
      Commit 46a704f8 also failed to enable TM for the kernel, leading
      to a TM unavailable interrupt in the kernel, causing an oops.  This
      fixes that problem too, by enabling TM before accessing the TM
      registers.  That problem is fixed upstream by the patch "KVM: PPC:
      Book3S HV: Enable TM before accessing TM registers".
      
      Fixes: 0b423dab ("KVM: PPC: Book3S HV: Preserve userspace HTM state properly")
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1c3ab876
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Restore critical SPRs to host values on guest exit · 901aae4f
      Paul Mackerras authored
      commit 4c3bb4cc upstream.
      
      This restores several special-purpose registers (SPRs) to sane values
      on guest exit that were missed before.
      
      TAR and VRSAVE are readable and writable by userspace, and we need to
      save and restore them to prevent the guest from potentially affecting
      userspace execution (not that TAR or VRSAVE are used by any known
      program that run uses the KVM_RUN ioctl).  We save/restore these
      in kvmppc_vcpu_run_hv() rather than on every guest entry/exit.
      
      FSCR affects userspace execution in that it can prohibit access to
      certain facilities by userspace.  We restore it to the normal value
      for the task on exit from the KVM_RUN ioctl.
      
      IAMR is normally 0, and is restored to 0 on guest exit.  However,
      with a radix host on POWER9, it is set to a value that prevents the
      kernel from executing user-accessible memory.  On POWER9, we save
      IAMR on guest entry and restore it on guest exit to the saved value
      rather than 0.  On POWER8 we continue to set it to 0 on guest exit.
      
      PSPB is normally 0.  We restore it to 0 on guest exit to prevent
      userspace taking advantage of the guest having set it non-zero
      (which would allow userspace to set its SMT priority to high).
      
      UAMOR is normally 0.  We restore it to 0 on guest exit to prevent
      the AMR from being used as a covert channel between userspace
      processes, since the AMR is not context-switched at present.
      
      [paulus@ozlabs.org - removed IAMR bits that are only needed on POWER9;
       adjusted FSCR save/restore for lack of fscr field in thread_struct.]
      
      Fixes: b005255e ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
      Cc: stable@vger.kernel.org # v3.14+
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      901aae4f
    • Sinclair Yeh's avatar
      drm/vmwgfx: Fix gcc-7.1.1 warning · 7f1957f2
      Sinclair Yeh authored
      commit fcfffdd8 upstream.
      
      The current code does not look correct, and the reason for it is
      probably lost.  Since this now generates a compiler warning,
      fix it to what makes sense.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSinclair Yeh <syeh@vmware.com>
      Reviewed-by: default avatarBrian Paul <brianp@vmware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f1957f2
    • Ofer Heifetz's avatar
      md/raid5: add thread_group worker async_tx_issue_pending_all · c81489cc
      Ofer Heifetz authored
      commit 7e96d559 upstream.
      
      Since thread_group worker and raid5d kthread are not in sync, if
      worker writes stripe before raid5d then requests will be waiting
      for issue_pendig.
      
      Issue observed when building raid5 with ext4, in some build runs
      jbd2 would get hung and requests were waiting in the HW engine
      waiting to be issued.
      
      Fix this by adding a call to async_tx_issue_pending_all in the
      raid5_do_work.
      Signed-off-by: default avatarOfer Heifetz <oferh@marvell.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c81489cc
    • Laurent Vivier's avatar
      powerpc/pseries: Fix of_node_put() underflow during reconfig remove · 716c82ac
      Laurent Vivier authored
      commit 4fd1bd44 upstream.
      
      As for commit 68baf692 ("powerpc/pseries: Fix of_node_put()
      underflow during DLPAR remove"), the call to of_node_put() must be
      removed from pSeries_reconfig_remove_node().
      
      dlpar_detach_node() and pSeries_reconfig_remove_node() both call
      of_detach_node(), and thus the node should not be released in both
      cases.
      
      Fixes: 0829f6d1 ("of: device_node kobject lifecycle fixes")
      Signed-off-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      716c82ac
    • Eric Dumazet's avatar
      net: reduce skb_warn_bad_offload() noise · d85f4de8
      Eric Dumazet authored
      commit b2504a5d upstream.
      
      Dmitry reported warnings occurring in __skb_gso_segment() [1]
      
      All SKB_GSO_DODGY producers can allow user space to feed
      packets that trigger the current check.
      
      We could prevent them from doing so, rejecting packets, but
      this might add regressions to existing programs.
      
      It turns out our SKB_GSO_DODGY handlers properly set up checksum
      information that is needed anyway when packets needs to be segmented.
      
      By checking again skb_needs_check() after skb_mac_gso_segment(),
      we should remove these pesky warnings, at a very minor cost.
      
      With help from Willem de Bruijn
      
      [1]
      WARNING: CPU: 1 PID: 6768 at net/core/dev.c:2439 skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
      lo: caps=(0x000000a2803b7c69, 0x0000000000000000) len=138 data_len=0 gso_size=15883 gso_type=4 ip_summed=0
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 1 PID: 6768 Comm: syz-executor1 Not tainted 4.9.0 #5
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
       ffff8801c063ecd8 ffffffff82346bdf ffffffff00000001 1ffff100380c7d2e
       ffffed00380c7d26 0000000041b58ab3 ffffffff84b37e38 ffffffff823468f1
       ffffffff84820740 ffffffff84f289c0 dffffc0000000000 ffff8801c063ee20
      Call Trace:
       [<ffffffff82346bdf>] __dump_stack lib/dump_stack.c:15 [inline]
       [<ffffffff82346bdf>] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
       [<ffffffff81827e34>] panic+0x1fb/0x412 kernel/panic.c:179
       [<ffffffff8141f704>] __warn+0x1c4/0x1e0 kernel/panic.c:542
       [<ffffffff8141f7e5>] warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:565
       [<ffffffff8356cbaf>] skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
       [<ffffffff83585cd2>] __skb_gso_segment+0x482/0x780 net/core/dev.c:2706
       [<ffffffff83586f19>] skb_gso_segment include/linux/netdevice.h:3985 [inline]
       [<ffffffff83586f19>] validate_xmit_skb+0x5c9/0xc20 net/core/dev.c:2969
       [<ffffffff835892bb>] __dev_queue_xmit+0xe6b/0x1e70 net/core/dev.c:3383
       [<ffffffff8358a2d7>] dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
       [<ffffffff83ad161d>] packet_snd net/packet/af_packet.c:2930 [inline]
       [<ffffffff83ad161d>] packet_sendmsg+0x32ed/0x4d30 net/packet/af_packet.c:2955
       [<ffffffff834f0aaa>] sock_sendmsg_nosec net/socket.c:621 [inline]
       [<ffffffff834f0aaa>] sock_sendmsg+0xca/0x110 net/socket.c:631
       [<ffffffff834f329a>] ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1954
       [<ffffffff834f5e58>] __sys_sendmsg+0x138/0x300 net/socket.c:1988
       [<ffffffff834f604d>] SYSC_sendmsg net/socket.c:1999 [inline]
       [<ffffffff834f604d>] SyS_sendmsg+0x2d/0x50 net/socket.c:1995
       [<ffffffff84371941>] entry_SYSCALL_64_fastpath+0x1f/0xc2
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov  <dvyukov@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Mark Salyzyn <salyzyn@android.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d85f4de8
    • Joel Fernandes's avatar
      pstore: Make spinlock per zone instead of global · 2d0abb7b
      Joel Fernandes authored
      commit 10970449 upstream.
      
      Currently pstore has a global spinlock for all zones. Since the zones
      are independent and modify different areas of memory, there's no need
      to have a global lock, so we should use a per-zone lock as introduced
      here. Also, when ramoops's ftrace use-case has a FTRACE_PER_CPU flag
      introduced later, which splits the ftrace memory area into a single zone
      per CPU, it will eliminate the need for locking. In preparation for this,
      make the locking optional.
      Signed-off-by: default avatarJoel Fernandes <joelaf@google.com>
      [kees: updated commit message]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Leo Yan <leo.yan@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d0abb7b
    • Yuejie Shi's avatar
      af_key: Add lock to key dump · c64a196b
      Yuejie Shi authored
      commit 89e357d8 upstream.
      
      A dump may come in the middle of another dump, modifying its dump
      structure members. This race condition will result in NULL pointer
      dereference in kernel. So add a lock to prevent that race.
      
      Fixes: 83321d6b ("[AF_KEY]: Dump SA/SP entries non-atomically")
      Signed-off-by: default avatarYuejie Shi <syjcnss@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarMark Salyzyn <salyzyn@android.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c64a196b
  2. 27 Jul, 2017 12 commits