1. 27 Mar, 2019 24 commits
    • Florian Westphal's avatar
      netfilter: ebtables: remove BUGPRINT messages · b763bd26
      Florian Westphal authored
      commit d824548dae220820bdf69b2d1561b7c4b072783f upstream.
      
      They are however frequently triggered by syzkaller, so remove them.
      
      ebtables userspace should never trigger any of these, so there is little
      value in making them pr_debug (or ratelimited).
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b763bd26
    • Chris Wilson's avatar
      drm: Reorder set_property_atomic to avoid returning with an active ww_ctx · 4f160d8d
      Chris Wilson authored
      commit 227ad6d957898a88b1746e30234ece64d305f066 upstream.
      
      Delay the drm_modeset_acquire_init() until after we check for an
      allocation failure so that we can return immediately upon error without
      having to unwind.
      
      WARNING: lock held when returning to user space!
      4.20.0+ #174 Not tainted
      ------------------------------------------------
      syz-executor556/8153 is leaving the kernel with locks still held!
      1 lock held by syz-executor556/8153:
        #0: 000000005100c85c (crtc_ww_class_acquire){+.+.}, at:
      set_property_atomic+0xb3/0x330 drivers/gpu/drm/drm_mode_object.c:462
      
      Reported-by: syzbot+6ea337c427f5083ebdf2@syzkaller.appspotmail.com
      Fixes: 144a7999 ("drm: Handle properties in the core for atomic drivers")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Sean Paul <sean@poorly.run>
      Cc: David Airlie <airlied@linux.ie>
      Cc: <stable@vger.kernel.org> # v4.14+
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181230122842.21917-1-chris@chris-wilson.co.ukSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f160d8d
    • Kefeng Wang's avatar
      Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set_proto() · a1dbb34d
      Kefeng Wang authored
      commit 56897b217a1d0a91c9920cb418d6b3fe922f590a upstream.
      
      task A:                                task B:
      hci_uart_set_proto                     flush_to_ldisc
       - p->open(hu) -> h5_open  //alloc h5  - receive_buf
       - set_bit HCI_UART_PROTO_READY         - tty_port_default_receive_buf
       - hci_uart_register_dev                 - tty_ldisc_receive_buf
                                                - hci_uart_tty_receive
      				           - test_bit HCI_UART_PROTO_READY
      				            - h5_recv
       - clear_bit HCI_UART_PROTO_READY             while() {
       - p->open(hu) -> h5_close //free h5
      				              - h5_rx_3wire_hdr
      				               - h5_reset()  //use-after-free
                                                    }
      
      It could use ioctl to set hci uart proto, but there is
      a use-after-free issue when hci_uart_register_dev() fail in
      hci_uart_set_proto(), see stack above, fix this by setting
      HCI_UART_PROTO_READY bit only when hci_uart_register_dev()
      return success.
      
      Reported-by: syzbot+899a33dc0fa0dbaf06a6@syzkaller.appspotmail.com
      Signed-off-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Reviewed-by: default avatarJeremy Cline <jcline@redhat.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1dbb34d
    • Jeremy Cline's avatar
      Bluetooth: hci_ldisc: Initialize hci_dev before open() · 6ea83d93
      Jeremy Cline authored
      commit 32a7b4cbe93b0a0ef7e63d31ca69ce54736c4412 upstream.
      
      The hci_dev struct hdev is referenced in work queues and timers started
      by open() in some protocols. This creates a race between the
      initialization function and the work or timer which can result hdev
      being dereferenced while it is still null.
      
      The syzbot report contains a reliable reproducer which causes a null
      pointer dereference of hdev in hci_uart_write_work() by making the
      memory allocation for hdev fail.
      
      To fix this, ensure hdev is valid from before calling a protocol's
      open() until after calling a protocol's close().
      
      Reported-by: syzbot+257790c15bcdef6fe00c@syzkaller.appspotmail.com
      Signed-off-by: default avatarJeremy Cline <jcline@redhat.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ea83d93
    • Myungho Jung's avatar
      Bluetooth: Fix decrementing reference count twice in releasing socket · 3df00eb8
      Myungho Jung authored
      commit e20a2e9c42c9e4002d9e338d74e7819e88d77162 upstream.
      
      When releasing socket, it is possible to enter hci_sock_release() and
      hci_sock_dev_event(HCI_DEV_UNREG) at the same time in different thread.
      The reference count of hdev should be decremented only once from one of
      them but if storing hdev to local variable in hci_sock_release() before
      detached from socket and setting to NULL in hci_sock_dev_event(),
      hci_dev_put(hdev) is unexpectedly called twice. This is resolved by
      referencing hdev from socket after bt_sock_unlink() in
      hci_sock_release().
      
      Reported-by: syzbot+fdc00003f4efff43bc5b@syzkaller.appspotmail.com
      Signed-off-by: default avatarMyungho Jung <mhjungk@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3df00eb8
    • Myungho Jung's avatar
      Bluetooth: hci_uart: Check if socket buffer is ERR_PTR in h4_recv_buf() · 86384a1f
      Myungho Jung authored
      commit 1dc2d785156cbdc80806c32e8d2c7c735d0b4721 upstream.
      
      h4_recv_buf() callers store the return value to socket buffer and
      recursively pass the buffer to h4_recv_buf() without protection. So,
      ERR_PTR returned from h4_recv_buf() can be dereferenced, if called again
      before setting the socket buffer to NULL from previous error. Check if
      skb is ERR_PTR in h4_recv_buf().
      
      Reported-by: syzbot+017a32f149406df32703@syzkaller.appspotmail.com
      Signed-off-by: default avatarMyungho Jung <mhjungk@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86384a1f
    • Hans Verkuil's avatar
      media: v4l2-ctrls.c/uvc: zero v4l2_event · 3616a46e
      Hans Verkuil authored
      commit f45f3f753b0a3d739acda8e311b4f744d82dc52a upstream.
      
      Control events can leak kernel memory since they do not fully zero the
      event. The same code is present in both v4l2-ctrls.c and uvc_ctrl.c, so
      fix both.
      
      It appears that all other event code is properly zeroing the structure,
      it's these two places.
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Reported-by: syzbot+4f021cf3697781dbd9fb@syzkaller.appspotmail.com
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3616a46e
    • zhangyi (F)'s avatar
      ext4: brelse all indirect buffer in ext4_ind_remove_space() · 33fb4996
      zhangyi (F) authored
      commit 674a2b27234d1b7afcb0a9162e81b2e53aeef217 upstream.
      
      All indirect buffers get by ext4_find_shared() should be released no
      mater the branch should be freed or not. But now, we forget to release
      the lower depth indirect buffers when removing space from the same
      higher depth indirect block. It will lead to buffer leak and futher
      more, it may lead to quota information corruption when using old quota,
      consider the following case.
      
       - Create and mount an empty ext4 filesystem without extent and quota
         features,
       - quotacheck and enable the user & group quota,
       - Create some files and write some data to them, and then punch hole
         to some files of them, it may trigger the buffer leak problem
         mentioned above.
       - Disable quota and run quotacheck again, it will create two new
         aquota files and write the checked quota information to them, which
         probably may reuse the freed indirect block(the buffer and page
         cache was not freed) as data block.
       - Enable quota again, it will invoke
         vfs_load_quota_inode()->invalidate_bdev() to try to clean unused
         buffers and pagecache. Unfortunately, because of the buffer of quota
         data block is still referenced, quota code cannot read the up to date
         quota info from the device and lead to quota information corruption.
      
      This problem can be reproduced by xfstests generic/231 on ext3 file
      system or ext4 file system without extent and quota features.
      
      This patch fix this problem by releasing the missing indirect buffers,
      in ext4_ind_remove_space().
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarzhangyi (F) <yi.zhang@huawei.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Cc: stable@kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33fb4996
    • Lukas Czerner's avatar
      ext4: fix data corruption caused by unaligned direct AIO · 766b823e
      Lukas Czerner authored
      commit 372a03e01853f860560eade508794dd274e9b390 upstream.
      
      Ext4 needs to serialize unaligned direct AIO because the zeroing of
      partial blocks of two competing unaligned AIOs can result in data
      corruption.
      
      However it decides not to serialize if the potentially unaligned aio is
      past i_size with the rationale that no pending writes are possible past
      i_size. Unfortunately if the i_size is not block aligned and the second
      unaligned write lands past i_size, but still into the same block, it has
      the potential of corrupting the previous unaligned write to the same
      block.
      
      This is (very simplified) reproducer from Frank
      
          // 41472 = (10 * 4096) + 512
          // 37376 = 41472 - 4096
      
          ftruncate(fd, 41472);
          io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376);
          io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472);
      
          io_submit(io_ctx, 1, &iocbs[1]);
          io_submit(io_ctx, 1, &iocbs[2]);
      
          io_getevents(io_ctx, 2, 2, events, NULL);
      
      Without this patch the 512B range from 40960 up to the start of the
      second unaligned write (41472) is going to be zeroed overwriting the data
      written by the first write. This is a data corruption.
      
      00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
      *
      00009200  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30
      *
      0000a000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
      *
      0000a200  31 31 31 31 31 31 31 31  31 31 31 31 31 31 31 31
      
      With this patch the data corruption is avoided because we will recognize
      the unaligned_aio and wait for the unwritten extent conversion.
      
      00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
      *
      00009200  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30
      *
      0000a200  31 31 31 31 31 31 31 31  31 31 31 31 31 31 31 31
      *
      0000b200
      Reported-by: default avatarFrank Sorenson <fsorenso@redhat.com>
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Fixes: e9e3bcec ("ext4: serialize unaligned asynchronous DIO")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      766b823e
    • Jiufei Xue's avatar
      ext4: fix NULL pointer dereference while journal is aborted · 03c5cdb6
      Jiufei Xue authored
      commit fa30dde38aa8628c73a6dded7cb0bba38c27b576 upstream.
      
      We see the following NULL pointer dereference while running xfstests
      generic/475:
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      PGD 8000000c84bad067 P4D 8000000c84bad067 PUD c84e62067 PMD 0
      Oops: 0000 [#1] SMP PTI
      CPU: 7 PID: 9886 Comm: fsstress Kdump: loaded Not tainted 5.0.0-rc8 #10
      RIP: 0010:ext4_do_update_inode+0x4ec/0x760
      ...
      Call Trace:
      ? jbd2_journal_get_write_access+0x42/0x50
      ? __ext4_journal_get_write_access+0x2c/0x70
      ? ext4_truncate+0x186/0x3f0
      ext4_mark_iloc_dirty+0x61/0x80
      ext4_mark_inode_dirty+0x62/0x1b0
      ext4_truncate+0x186/0x3f0
      ? unmap_mapping_pages+0x56/0x100
      ext4_setattr+0x817/0x8b0
      notify_change+0x1df/0x430
      do_truncate+0x5e/0x90
      ? generic_permission+0x12b/0x1a0
      
      This is triggered because the NULL pointer handle->h_transaction was
      dereferenced in function ext4_update_inode_fsync_trans().
      I found that the h_transaction was set to NULL in jbd2__journal_restart
      but failed to attached to a new transaction while the journal is aborted.
      
      Fix this by checking the handle before updating the inode.
      
      Fixes: b436b9be ("ext4: Wait for proper transaction commit on fsync")
      Signed-off-by: default avatarJiufei Xue <jiufei.xue@linux.alibaba.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@linux.alibaba.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03c5cdb6
    • Ville Syrjälä's avatar
      ALSA: x86: Fix runtime PM for hdmi-lpe-audio · a37fe2be
      Ville Syrjälä authored
      commit 8dfb839cfe737a17def8e5f88ee13c295230364a upstream.
      
      Commit 46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as
      "no callbacks"") broke runtime PM with lpe audio. We can no longer
      runtime suspend the GPU since the sysfs  power/control for the
      lpe-audio device no longer exists and the device is considered
      always active. We can fix this by not marking the device as
      active.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Fixes: 46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as "no callbacks"")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181024154825.18185-1-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a37fe2be
    • Josh Poimboeuf's avatar
      objtool: Move objtool_file struct off the stack · d431ba69
      Josh Poimboeuf authored
      commit 0c671812f152b628bd87c0af49da032cc2a2c319 upstream.
      
      Objtool uses over 512k of stack, thanks to the hash table embedded in
      the objtool_file struct.  This causes an unnecessarily large stack
      allocation and breaks users with low stack limits.
      
      Move the struct off the stack.
      
      Fixes: 042ba73f ("objtool: Add several performance improvements")
      Reported-by: default avatarVassili Karpov <moosotc@gmail.com>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/df92dcbc4b84b02ffa252f46876df125fb56e2d7.1552954176.git.jpoimboe@redhat.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d431ba69
    • Adrian Hunter's avatar
      perf probe: Fix getting the kernel map · 060c8899
      Adrian Hunter authored
      commit eaeffeb9838a7c0dec981d258666bfcc0fa6a947 upstream.
      
      Since commit 4d99e413 ("perf machine: Workaround missing maps for
      x86 PTI entry trampolines"), perf tools has been creating more than one
      kernel map, however 'perf probe' assumed there could be only one.
      
      Fix by using machine__kernel_map() to get the main kernel map.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: default avatarJoseph Qi <joseph.qi@linux.alibaba.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jiufei Xue <jiufei.xue@linux.alibaba.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Cc: Xu Yu <xuyu@linux.alibaba.com>
      Fixes: 4d99e413 ("perf machine: Workaround missing maps for x86 PTI entry trampolines")
      Fixes: d83212d5 ("kallsyms, x86: Export addresses of PTI entry trampolines")
      Link: http://lkml.kernel.org/r/2ed432de-e904-85d2-5c36-5897ddc5b23b@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      060c8899
    • Chen Jie's avatar
      futex: Ensure that futex address is aligned in handle_futex_death() · a7e83004
      Chen Jie authored
      commit 5a07168d8d89b00fe1760120714378175b3ef992 upstream.
      
      The futex code requires that the user space addresses of futexes are 32bit
      aligned. sys_futex() checks this in futex_get_keys() but the robust list
      code has no alignment check in place.
      
      As a consequence the kernel crashes on architectures with strict alignment
      requirements in handle_futex_death() when trying to cmpxchg() on an
      unaligned futex address which was retrieved from the robust list.
      
      [ tglx: Rewrote changelog, proper sizeof() based alignement check and add
        	comment ]
      
      Fixes: 0771dfef ("[PATCH] lightweight robust futexes: core")
      Signed-off-by: default avatarChen Jie <chenjie6@huawei.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: <dvhart@infradead.org>
      Cc: <peterz@infradead.org>
      Cc: <zengweilin@huawei.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/1552621478-119787-1-git-send-email-chenjie6@huawei.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7e83004
    • Tyrel Datwyler's avatar
      scsi: ibmvscsi: Fix empty event pool access during host removal · 95712a19
      Tyrel Datwyler authored
      commit 7f5203c13ba8a7b7f9f6ecfe5a4d5567188d7835 upstream.
      
      The event pool used for queueing commands is destroyed fairly early in the
      ibmvscsi_remove() code path. Since, this happens prior to the call so
      scsi_remove_host() it is possible for further calls to queuecommand to be
      processed which manifest as a panic due to a NULL pointer dereference as
      seen here:
      
      PANIC: "Unable to handle kernel paging request for data at address
      0x00000000"
      
      Context process backtrace:
      
      DSISR: 0000000042000000 ????Syscall Result: 0000000000000000
      4 [c000000002cb3820] memcpy_power7 at c000000000064204
      [Link Register] [c000000002cb3820] ibmvscsi_send_srp_event at d000000003ed14a4
      5 [c000000002cb3920] ibmvscsi_send_srp_event at d000000003ed14a4 [ibmvscsi] ?(unreliable)
      6 [c000000002cb39c0] ibmvscsi_queuecommand at d000000003ed2388 [ibmvscsi]
      7 [c000000002cb3a70] scsi_dispatch_cmd at d00000000395c2d8 [scsi_mod]
      8 [c000000002cb3af0] scsi_request_fn at d00000000395ef88 [scsi_mod]
      9 [c000000002cb3be0] __blk_run_queue at c000000000429860
      10 [c000000002cb3c10] blk_delay_work at c00000000042a0ec
      11 [c000000002cb3c40] process_one_work at c0000000000dac30
      12 [c000000002cb3cd0] worker_thread at c0000000000db110
      13 [c000000002cb3d80] kthread at c0000000000e3378
      14 [c000000002cb3e30] ret_from_kernel_thread at c00000000000982c
      
      The kernel buffer log is overfilled with this log:
      
      [11261.952732] ibmvscsi: found no event struct in pool!
      
      This patch reorders the operations during host teardown. Start by calling
      the SRP transport and Scsi_Host remove functions to flush any outstanding
      work and set the host offline. LLDD teardown follows including destruction
      of the event pool, freeing the Command Response Queue (CRQ), and unmapping
      any persistent buffers. The event pool destruction is protected by the
      scsi_host lock, and the pool is purged prior of any requests for which we
      never received a response. Finally, move the removal of the scsi host from
      our global list to the end so that the host is easily locatable for
      debugging purposes during teardown.
      
      Cc: <stable@vger.kernel.org> # v2.6.12+
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      95712a19
    • Tyrel Datwyler's avatar
      scsi: ibmvscsi: Protect ibmvscsi_head from concurrent modificaiton · 9d00ccc5
      Tyrel Datwyler authored
      commit 7205981e045e752ccf96cf6ddd703a98c59d4339 upstream.
      
      For each ibmvscsi host created during a probe or destroyed during a remove
      we either add or remove that host to/from the global ibmvscsi_head
      list. This runs the risk of concurrent modification.
      
      This patch adds a simple spinlock around the list modification calls to
      prevent concurrent updates as is done similarly in the ibmvfc driver and
      ipr driver.
      
      Fixes: 32d6e4b6 ("scsi: ibmvscsi: add vscsi hosts to global list_head")
      Cc: <stable@vger.kernel.org> # v4.10+
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d00ccc5
    • Archer Yan's avatar
      MIPS: Fix kernel crash for R6 in jump label branch function · 88870813
      Archer Yan authored
      commit 47c25036b60f27b86ab44b66a8861bcf81cde39b upstream.
      
      Insert Branch instruction instead of NOP to make sure assembler don't
      patch code in forbidden slot. In jump label function, it might
      be possible to patch Control Transfer Instructions(CTIs) into
      forbidden slot, which will generate Reserved Instruction exception
      in MIPS release 6.
      Signed-off-by: default avatarArcher Yan <ayan@wavecomp.com>
      Reviewed-by: default avatarPaul Burton <paul.burton@mips.com>
      [paul.burton@mips.com:
        - Add MIPS prefix to subject.
        - Mark for stable from v4.0, which introduced r6 support, onwards.]
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.0+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88870813
    • Yasha Cherikovsky's avatar
      MIPS: Ensure ELF appended dtb is relocated · 005b0a33
      Yasha Cherikovsky authored
      commit 3f0a53bc6482fb09770982a8447981260ea258dc upstream.
      
      This fixes booting with the combination of CONFIG_RELOCATABLE=y
      and CONFIG_MIPS_ELF_APPENDED_DTB=y.
      
      Sections that appear after the relocation table are not relocated
      on system boot (except .bss, which has special handling).
      
      With CONFIG_MIPS_ELF_APPENDED_DTB, the dtb is part of the
      vmlinux ELF, so it must be relocated together with everything else.
      
      Fixes: 069fd766 ("MIPS: Reserve space for relocation table")
      Signed-off-by: default avatarYasha Cherikovsky <yasha.che3@gmail.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.7+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      005b0a33
    • Yifeng Li's avatar
      mips: loongson64: lemote-2f: Add IRQF_NO_SUSPEND to "cascade" irqaction. · a3c6248c
      Yifeng Li authored
      commit 5f5f67da9781770df0403269bc57d7aae608fecd upstream.
      
      Timekeeping IRQs from CS5536 MFGPT are routed to i8259, which then
      triggers the "cascade" IRQ on MIPS CPU. Without IRQF_NO_SUSPEND in
      cascade_irqaction, MFGPT interrupts will be masked in suspend mode,
      and the machine would be unable to resume once suspended.
      
      Previously, MIPS IRQs were not disabled properly, so the original
      code appeared to work. Commit a3e6c1ef ("MIPS: IRQ: Fix disable_irq on
      CPU IRQs") uncovers the bug. To fix it, add IRQF_NO_SUSPEND to
      cascade_irqaction.
      
      This commit is functionally identical to 0add9c2f ("MIPS:
      Loongson-3: Add IRQF_NO_SUSPEND to Cascade irqaction"), but it forgot
      to apply the same fix to Loongson2.
      Signed-off-by: default avatarYifeng Li <tomli@tomli.me>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v3.19+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3c6248c
    • Jan Kara's avatar
      udf: Fix crash on IO error during truncate · 6a502107
      Jan Kara authored
      commit d3ca4651d05c0ff7259d087d8c949bcf3e14fb46 upstream.
      
      When truncate(2) hits IO error when reading indirect extent block the
      code just bugs with:
      
      kernel BUG at linux-4.15.0/fs/udf/truncate.c:249!
      ...
      
      Fix the problem by bailing out cleanly in case of IO error.
      
      CC: stable@vger.kernel.org
      Reported-by: default avatarjean-luc malet <jeanluc.malet@gmail.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a502107
    • Ilya Dryomov's avatar
      libceph: wait for latest osdmap in ceph_monc_blacklist_add() · 2e5522ad
      Ilya Dryomov authored
      commit bb229bbb3bf63d23128e851a1f3b85c083178fa1 upstream.
      
      Because map updates are distributed lazily, an OSD may not know about
      the new blacklist for quite some time after "osd blacklist add" command
      is completed.  This makes it possible for a blacklisted but still alive
      client to overwrite a post-blacklist update, resulting in data
      corruption.
      
      Waiting for latest osdmap in ceph_monc_blacklist_add() and thus using
      the post-blacklist epoch for all post-blacklist requests ensures that
      all such requests "wait" for the blacklist to come into force on their
      respective OSDs.
      
      Cc: stable@vger.kernel.org
      Fixes: 6305a3b4 ("libceph: support for blacklisting clients")
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarJason Dillaman <dillaman@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e5522ad
    • Stanislaw Gruszka's avatar
      iommu/amd: fix sg->dma_address for sg->offset bigger than PAGE_SIZE · 1e7b9a31
      Stanislaw Gruszka authored
      commit 4e50ce03976fbc8ae995a000c4b10c737467beaa upstream.
      
      Take into account that sg->offset can be bigger than PAGE_SIZE when
      setting segment sg->dma_address. Otherwise sg->dma_address will point
      at diffrent page, what makes DMA not possible with erros like this:
      
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa70c0 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7040 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7080 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7100 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7000 flags=0x0020]
      
      Additinally with wrong sg->dma_address unmap_sg will free wrong pages,
      what what can cause crashes like this:
      
      Feb 28 19:27:45 kernel: BUG: Bad page state in process cinnamon  pfn:39e8b1
      Feb 28 19:27:45 kernel: Disabling lock debugging due to kernel taint
      Feb 28 19:27:45 kernel: flags: 0x2ffff0000000000()
      Feb 28 19:27:45 kernel: raw: 02ffff0000000000 0000000000000000 ffffffff00000301 0000000000000000
      Feb 28 19:27:45 kernel: raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
      Feb 28 19:27:45 kernel: page dumped because: nonzero _refcount
      Feb 28 19:27:45 kernel: Modules linked in: ccm fuse arc4 nct6775 hwmon_vid amdgpu nls_iso8859_1 nls_cp437 edac_mce_amd vfat fat kvm_amd ccp rng_core kvm mt76x0u mt76x0_common mt76x02_usb irqbypass mt76_usb mt76x02_lib mt76 crct10dif_pclmul crc32_pclmul chash mac80211 amd_iommu_v2 ghash_clmulni_intel gpu_sched i2c_algo_bit ttm wmi_bmof snd_hda_codec_realtek snd_hda_codec_generic drm_kms_helper snd_hda_codec_hdmi snd_hda_intel drm snd_hda_codec aesni_intel snd_hda_core snd_hwdep aes_x86_64 crypto_simd snd_pcm cfg80211 cryptd mousedev snd_timer glue_helper pcspkr r8169 input_leds realtek agpgart libphy rfkill snd syscopyarea sysfillrect sysimgblt fb_sys_fops soundcore sp5100_tco k10temp i2c_piix4 wmi evdev gpio_amdpt pinctrl_amd mac_hid pcc_cpufreq acpi_cpufreq sg ip_tables x_tables ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) sd_mod(E) hid_generic(E) usbhid(E) hid(E) dm_mod(E) serio_raw(E) atkbd(E) libps2(E) crc32c_intel(E) ahci(E) libahci(E) libata(E) xhci_pci(E) xhci_hcd(E)
      Feb 28 19:27:45 kernel:  scsi_mod(E) i8042(E) serio(E) bcache(E) crc64(E)
      Feb 28 19:27:45 kernel: CPU: 2 PID: 896 Comm: cinnamon Tainted: G    B   W   E     4.20.12-arch1-1-custom #1
      Feb 28 19:27:45 kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P1.20 06/26/2018
      Feb 28 19:27:45 kernel: Call Trace:
      Feb 28 19:27:45 kernel:  dump_stack+0x5c/0x80
      Feb 28 19:27:45 kernel:  bad_page.cold.29+0x7f/0xb2
      Feb 28 19:27:45 kernel:  __free_pages_ok+0x2c0/0x2d0
      Feb 28 19:27:45 kernel:  skb_release_data+0x96/0x180
      Feb 28 19:27:45 kernel:  __kfree_skb+0xe/0x20
      Feb 28 19:27:45 kernel:  tcp_recvmsg+0x894/0xc60
      Feb 28 19:27:45 kernel:  ? reuse_swap_page+0x120/0x340
      Feb 28 19:27:45 kernel:  ? ptep_set_access_flags+0x23/0x30
      Feb 28 19:27:45 kernel:  inet_recvmsg+0x5b/0x100
      Feb 28 19:27:45 kernel:  __sys_recvfrom+0xc3/0x180
      Feb 28 19:27:45 kernel:  ? handle_mm_fault+0x10a/0x250
      Feb 28 19:27:45 kernel:  ? syscall_trace_enter+0x1d3/0x2d0
      Feb 28 19:27:45 kernel:  ? __audit_syscall_exit+0x22a/0x290
      Feb 28 19:27:45 kernel:  __x64_sys_recvfrom+0x24/0x30
      Feb 28 19:27:45 kernel:  do_syscall_64+0x5b/0x170
      Feb 28 19:27:45 kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: default avatarJan Viktorin <jan.viktorin@gmail.com>
      Reviewed-by: default avatarAlexander Duyck <alexander.h.duyck@linux.intel.com>
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Fixes: 80187fd3 ('iommu/amd: Optimize map_sg and unmap_sg')
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e7b9a31
    • Thomas Zimmermann's avatar
      drm/vmwgfx: Don't double-free the mode stored in par->set_mode · 47248fde
      Thomas Zimmermann authored
      commit c2d311553855395764e2e5bf401d987ba65c2056 upstream.
      
      When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
      twice. The first free is in vmw_fb_kms_detach(), the second is near the
      end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
      only works correctly if the mode doesn't actually change. Removing
      'old_mode' in favor of using par->set_mode directly fixes the problem.
      
      Cc: <stable@vger.kernel.org>
      Fixes: a278724a ("drm/vmwgfx: Implement fbdev on kms v2")
      Signed-off-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
      Reviewed-by: default avatarDeepak Rawat <drawat@vmware.com>
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47248fde
    • Arnd Bergmann's avatar
      mmc: pxamci: fix enum type confusion · 3ce190bb
      Arnd Bergmann authored
      commit e60a582bcde01158a64ff948fb799f21f5d31a11 upstream.
      
      clang points out several instances of mismatched types in this drivers,
      all coming from a single declaration:
      
      drivers/mmc/host/pxamci.c:193:15: error: implicit conversion from enumeration type 'enum dma_transfer_direction' to
            different enumeration type 'enum dma_data_direction' [-Werror,-Wenum-conversion]
                      direction = DMA_DEV_TO_MEM;
                                ~ ^~~~~~~~~~~~~~
      drivers/mmc/host/pxamci.c:212:62: error: implicit conversion from enumeration type 'enum dma_data_direction' to
            different enumeration type 'enum dma_transfer_direction' [-Werror,-Wenum-conversion]
              tx = dmaengine_prep_slave_sg(chan, data->sg, host->dma_len, direction,
      
      The behavior is correct, so this must be a simply typo from
      dma_data_direction and dma_transfer_direction being similarly named
      types with a similar purpose.
      
      Fixes: 6464b714 ("mmc: pxamci: switch over to dmaengine use")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Acked-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ce190bb
  2. 23 Mar, 2019 16 commits