1. 08 Dec, 2018 26 commits
    • Martin Wilck's avatar
      scsi: scsi_devinfo: cleanly zero-pad devinfo strings · 6ea54af9
      Martin Wilck authored
      commit 81df022b upstream.
      
      Cleanly fill memory for "vendor" and "model" with 0-bytes for the
      "compatible" case rather than adding only a single 0 byte.  This
      simplifies the devinfo code a a bit, and avoids mistakes in other places
      of the code (not in current upstream, but we had one such mistake in the
      SUSE kernel).
      
      [mkp: applied by hand and added braces]
      Signed-off-by: default avatarMartin Wilck <mwilck@suse.com>
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@wdc.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ea54af9
    • Andrea Arcangeli's avatar
      userfaultfd: shmem: UFFDIO_COPY: set the page dirty if VM_WRITE is not set · 46466e23
      Andrea Arcangeli authored
      commit dcf7fe9d upstream.
      
      Set the page dirty if VM_WRITE is not set because in such case the pte
      won't be marked dirty and the page would be reclaimed without writepage
      (i.e.  swapout in the shmem case).
      
      This was found by source review.  Most apps (certainly including QEMU)
      only use UFFDIO_COPY on PROT_READ|PROT_WRITE mappings or the app can't
      modify the memory in the first place.  This is for correctness and it
      could help the non cooperative use case to avoid unexpected data loss.
      
      Link: http://lkml.kernel.org/r/20181126173452.26955-6-aarcange@redhat.comReviewed-by: default avatarHugh Dickins <hughd@google.com>
      Cc: stable@vger.kernel.org
      Fixes: 4c27fe4c ("userfaultfd: shmem: add shmem_mcopy_atomic_pte for userfaultfd support")
      Reported-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
      Cc: Jann Horn <jannh@google.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Mike Rapoport <rppt@linux.ibm.com>
      Cc: Peter Xu <peterx@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46466e23
    • Andrea Arcangeli's avatar
      userfaultfd: shmem: add i_size checks · af3edb30
      Andrea Arcangeli authored
      commit e2a50c1f upstream.
      
      With MAP_SHARED: recheck the i_size after taking the PT lock, to
      serialize against truncate with the PT lock.  Delete the page from the
      pagecache if the i_size_read check fails.
      
      With MAP_PRIVATE: check the i_size after the PT lock before mapping
      anonymous memory or zeropages into the MAP_PRIVATE shmem mapping.
      
      A mostly irrelevant cleanup: like we do the delete_from_page_cache()
      pagecache removal after dropping the PT lock, the PT lock is a spinlock
      so drop it before the sleepable page lock.
      
      Link: http://lkml.kernel.org/r/20181126173452.26955-5-aarcange@redhat.com
      Fixes: 4c27fe4c ("userfaultfd: shmem: add shmem_mcopy_atomic_pte for userfaultfd support")
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Reviewed-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Reviewed-by: default avatarHugh Dickins <hughd@google.com>
      Reported-by: default avatarJann Horn <jannh@google.com>
      Cc: <stable@vger.kernel.org>
      Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Peter Xu <peterx@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af3edb30
    • Andrea Arcangeli's avatar
      userfaultfd: shmem: allocate anonymous memory for MAP_PRIVATE shmem · 683b4733
      Andrea Arcangeli authored
      commit 5b51072e upstream.
      
      Userfaultfd did not create private memory when UFFDIO_COPY was invoked
      on a MAP_PRIVATE shmem mapping.  Instead it wrote to the shmem file,
      even when that had not been opened for writing.  Though, fortunately,
      that could only happen where there was a hole in the file.
      
      Fix the shmem-backed implementation of UFFDIO_COPY to create private
      memory for MAP_PRIVATE mappings.  The hugetlbfs-backed implementation
      was already correct.
      
      This change is visible to userland, if userfaultfd has been used in
      unintended ways: so it introduces a small risk of incompatibility, but
      is necessary in order to respect file permissions.
      
      An app that uses UFFDIO_COPY for anything like postcopy live migration
      won't notice the difference, and in fact it'll run faster because there
      will be no copy-on-write and memory waste in the tmpfs pagecache
      anymore.
      
      Userfaults on MAP_PRIVATE shmem keep triggering only on file holes like
      before.
      
      The real zeropage can also be built on a MAP_PRIVATE shmem mapping
      through UFFDIO_ZEROPAGE and that's safe because the zeropage pte is
      never dirty, in turn even an mprotect upgrading the vma permission from
      PROT_READ to PROT_READ|PROT_WRITE won't make the zeropage pte writable.
      
      Link: http://lkml.kernel.org/r/20181126173452.26955-3-aarcange@redhat.com
      Fixes: 4c27fe4c ("userfaultfd: shmem: add shmem_mcopy_atomic_pte for userfaultfd support")
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Reported-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Reviewed-by: default avatarHugh Dickins <hughd@google.com>
      Cc: <stable@vger.kernel.org>
      Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
      Cc: Jann Horn <jannh@google.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Peter Xu <peterx@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      683b4733
    • Andrea Arcangeli's avatar
      userfaultfd: use ENOENT instead of EFAULT if the atomic copy user fails · 82c5a8c0
      Andrea Arcangeli authored
      commit 9e368259 upstream.
      
      Patch series "userfaultfd shmem updates".
      
      Jann found two bugs in the userfaultfd shmem MAP_SHARED backend: the
      lack of the VM_MAYWRITE check and the lack of i_size checks.
      
      Then looking into the above we also fixed the MAP_PRIVATE case.
      
      Hugh by source review also found a data loss source if UFFDIO_COPY is
      used on shmem MAP_SHARED PROT_READ mappings (the production usages
      incidentally run with PROT_READ|PROT_WRITE, so the data loss couldn't
      happen in those production usages like with QEMU).
      
      The whole patchset is marked for stable.
      
      We verified QEMU postcopy live migration with guest running on shmem
      MAP_PRIVATE run as well as before after the fix of shmem MAP_PRIVATE.
      Regardless if it's shmem or hugetlbfs or MAP_PRIVATE or MAP_SHARED, QEMU
      unconditionally invokes a punch hole if the guest mapping is filebacked
      and a MADV_DONTNEED too (needed to get rid of the MAP_PRIVATE COWs and
      for the anon backend).
      
      This patch (of 5):
      
      We internally used EFAULT to communicate with the caller, switch to
      ENOENT, so EFAULT can be used as a non internal retval.
      
      Link: http://lkml.kernel.org/r/20181126173452.26955-2-aarcange@redhat.com
      Fixes: 4c27fe4c ("userfaultfd: shmem: add shmem_mcopy_atomic_pte for userfaultfd support")
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Reviewed-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Reviewed-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Jann Horn <jannh@google.com>
      Cc: Peter Xu <peterx@redhat.com>
      Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
      Cc: <stable@vger.kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      82c5a8c0
    • Lyude Paul's avatar
      drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut() · a88a1b3c
      Lyude Paul authored
      commit 97b2a318 upstream.
      
      Currently on driver bringup with KASAN enabled, meson triggers an OOB
      memory access as shown below:
      
      [  117.904528] ==================================================================
      [  117.904560] BUG: KASAN: global-out-of-bounds in meson_viu_set_osd_lut+0x7a0/0x890
      [  117.904588] Read of size 4 at addr ffff20000a63ce24 by task systemd-udevd/498
      [  117.904601]
      [  118.083372] CPU: 4 PID: 498 Comm: systemd-udevd Not tainted 4.20.0-rc3Lyude-Test+ #20
      [  118.091143] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
      [  118.099768] Call trace:
      [  118.102181]  dump_backtrace+0x0/0x3e8
      [  118.105796]  show_stack+0x14/0x20
      [  118.109083]  dump_stack+0x130/0x1c4
      [  118.112539]  print_address_description+0x60/0x25c
      [  118.117214]  kasan_report+0x1b4/0x368
      [  118.120851]  __asan_report_load4_noabort+0x18/0x20
      [  118.125566]  meson_viu_set_osd_lut+0x7a0/0x890
      [  118.129953]  meson_viu_init+0x10c/0x290
      [  118.133741]  meson_drv_bind_master+0x474/0x748
      [  118.138141]  meson_drv_bind+0x10/0x18
      [  118.141760]  try_to_bring_up_master+0x3d8/0x768
      [  118.146249]  component_add+0x214/0x570
      [  118.149978]  meson_dw_hdmi_probe+0x18/0x20 [meson_dw_hdmi]
      [  118.155404]  platform_drv_probe+0x98/0x138
      [  118.159455]  really_probe+0x2a0/0xa70
      [  118.163070]  driver_probe_device+0x1b4/0x2d8
      [  118.167299]  __driver_attach+0x200/0x280
      [  118.171189]  bus_for_each_dev+0x10c/0x1a8
      [  118.175144]  driver_attach+0x38/0x50
      [  118.178681]  bus_add_driver+0x330/0x608
      [  118.182471]  driver_register+0x140/0x388
      [  118.186361]  __platform_driver_register+0xc8/0x108
      [  118.191117]  meson_dw_hdmi_platform_driver_init+0x1c/0x1000 [meson_dw_hdmi]
      [  118.198022]  do_one_initcall+0x12c/0x3bc
      [  118.201883]  do_init_module+0x1fc/0x638
      [  118.205673]  load_module+0x4b4c/0x6808
      [  118.209387]  __se_sys_init_module+0x2e8/0x3c0
      [  118.213699]  __arm64_sys_init_module+0x68/0x98
      [  118.218100]  el0_svc_common+0x104/0x210
      [  118.221893]  el0_svc_handler+0x48/0xb8
      [  118.225594]  el0_svc+0x8/0xc
      [  118.228429]
      [  118.229887] The buggy address belongs to the variable:
      [  118.235007]  eotf_33_linear_mapping+0x84/0xc0
      [  118.239301]
      [  118.240752] Memory state around the buggy address:
      [  118.245522]  ffff20000a63cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  118.252695]  ffff20000a63cd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  118.259850] >ffff20000a63ce00: 00 00 00 00 04 fa fa fa fa fa fa fa 00 00 00 00
      [  118.267000]                                ^
      [  118.271222]  ffff20000a63ce80: 00 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      [  118.278393]  ffff20000a63cf00: 00 00 00 00 00 00 00 00 00 00 00 00 04 fa fa fa
      [  118.285542] ==================================================================
      [  118.292699] Disabling lock debugging due to kernel taint
      
      It seems that when looping through the OSD EOTF LUT maps, we use the
      same max iterator for OETF: 20. This is wrong though, since 20*2 is 40,
      which means that we'll stop out of bounds on the EOTF maps.
      
      But, this whole thing is already confusing enough to read through as-is,
      so let's just replace all of the hardcoded sizes with
      OSD_(OETF/EOTF)_LUT_SIZE / 2.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller")
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Maxime Ripard <maxime.ripard@bootlin.com>
      Cc: Carlo Caione <carlo@caione.org>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: linux-amlogic@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: <stable@vger.kernel.org> # v4.10+
      Acked-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181125012117.31915-1-lyude@redhat.comSigned-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a88a1b3c
    • Lyude Paul's avatar
      drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config · 9576f521
      Lyude Paul authored
      commit 995b278e upstream.
      
      Seeing as we use this registermap in the context of our IRQ handlers, we
      need to be using spinlocks for reading/writing registers so that we can
      still read them from IRQ handlers without having to grab any mutexes and
      accidentally sleep. We don't currently do this, as pointed out by
      lockdep:
      
      [   18.403770] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
      [   18.406744] in_atomic(): 1, irqs_disabled(): 128, pid: 68, name: kworker/u17:0
      [   18.413864] INFO: lockdep is turned off.
      [   18.417675] irq event stamp: 12
      [   18.420778] hardirqs last  enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
      [   18.429510] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
      [   18.437345] softirqs last  enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
      [   18.446684] softirqs last disabled at (0): [<0000000000000000>]           (null)
      [   18.453979] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G        W  O      4.20.0-rc3Lyude-Test+ #9
      [   18.469839] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
      [   18.480037] Workqueue: hci0 hci_power_on [bluetooth]
      [   18.487138] Call trace:
      [   18.494192]  dump_backtrace+0x0/0x1b8
      [   18.501280]  show_stack+0x14/0x20
      [   18.508361]  dump_stack+0xbc/0xf4
      [   18.515427]  ___might_sleep+0x140/0x1d8
      [   18.522515]  __might_sleep+0x50/0x88
      [   18.529582]  __mutex_lock+0x60/0x870
      [   18.536621]  mutex_lock_nested+0x1c/0x28
      [   18.543660]  regmap_lock_mutex+0x10/0x18
      [   18.550696]  regmap_read+0x38/0x70
      [   18.557727]  dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
      [   18.564804]  __handle_irq_event_percpu+0xac/0x410
      [   18.571891]  handle_irq_event_percpu+0x34/0x88
      [   18.578982]  handle_irq_event+0x48/0x78
      [   18.586051]  handle_fasteoi_irq+0xac/0x160
      [   18.593061]  generic_handle_irq+0x24/0x38
      [   18.599989]  __handle_domain_irq+0x60/0xb8
      [   18.606857]  gic_handle_irq+0x50/0xa0
      [   18.613659]  el1_irq+0xb4/0x130
      [   18.620394]  debug_lockdep_rcu_enabled+0x2c/0x30
      [   18.627111]  schedule+0x38/0xa0
      [   18.633781]  schedule_timeout+0x3a8/0x510
      [   18.640389]  wait_for_common+0x15c/0x180
      [   18.646905]  wait_for_completion+0x14/0x20
      [   18.653319]  mmc_wait_for_req_done+0x28/0x168
      [   18.659693]  mmc_wait_for_req+0xa8/0xe8
      [   18.665978]  mmc_wait_for_cmd+0x64/0x98
      [   18.672180]  mmc_io_rw_direct_host+0x94/0x130
      [   18.678385]  mmc_io_rw_direct+0x10/0x18
      [   18.684516]  sdio_enable_func+0xe8/0x1d0
      [   18.690627]  btsdio_open+0x24/0xc0 [btsdio]
      [   18.696821]  hci_dev_do_open+0x64/0x598 [bluetooth]
      [   18.703025]  hci_power_on+0x50/0x270 [bluetooth]
      [   18.709163]  process_one_work+0x2a0/0x6e0
      [   18.715252]  worker_thread+0x40/0x448
      [   18.721310]  kthread+0x12c/0x130
      [   18.727326]  ret_from_fork+0x10/0x1c
      [   18.735555] ------------[ cut here ]------------
      [   18.741430] do not call blocking ops when !TASK_RUNNING; state=2 set at [<000000006265ec59>] wait_for_common+0x140/0x180
      [   18.752417] WARNING: CPU: 0 PID: 68 at kernel/sched/core.c:6096 __might_sleep+0x7c/0x88
      [   18.760553] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod
      btsdio bluetooth snd_soc_hdmi_codec dw_hdmi_i2s_audio ecdh_generic
      brcmfmac brcmutil cfg80211 rfkill ir_nec_decoder meson_dw_hdmi(O)
      dw_hdmi rc_geekbox meson_rng meson_ir ao_cec rng_core rc_core cec
      leds_pwm efivars nfsd ip_tables x_tables crc32_generic f2fs uas
      meson_gxbb_wdt pwm_meson efivarfs ipv6
      [   18.799469] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G        W  O      4.20.0-rc3Lyude-Test+ #9
      [   18.808858] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
      [   18.818045] Workqueue: hci0 hci_power_on [bluetooth]
      [   18.824088] pstate: 80000085 (Nzcv daIf -PAN -UAO)
      [   18.829891] pc : __might_sleep+0x7c/0x88
      [   18.835722] lr : __might_sleep+0x7c/0x88
      [   18.841256] sp : ffff000008003cb0
      [   18.846751] x29: ffff000008003cb0 x28: 0000000000000000
      [   18.852269] x27: ffff00000938e000 x26: ffff800010283000
      [   18.857726] x25: ffff800010353280 x24: ffff00000868ef50
      [   18.863166] x23: 0000000000000000 x22: 0000000000000000
      [   18.868551] x21: 0000000000000000 x20: 000000000000038c
      [   18.873850] x19: ffff000008cd08c0 x18: 0000000000000010
      [   18.879081] x17: ffff000008a68cb0 x16: 0000000000000000
      [   18.884197] x15: 0000000000aaaaaa x14: 0e200e200e200e20
      [   18.889239] x13: 0000000000000001 x12: 00000000ffffffff
      [   18.894261] x11: ffff000008adfa48 x10: 0000000000000001
      [   18.899517] x9 : ffff0000092a0158 x8 : 0000000000000000
      [   18.904674] x7 : ffff00000812136c x6 : 0000000000000000
      [   18.909895] x5 : 0000000000000000 x4 : 0000000000000001
      [   18.915080] x3 : 0000000000000007 x2 : 0000000000000007
      [   18.920269] x1 : 99ab8e9ebb6c8500 x0 : 0000000000000000
      [   18.925443] Call trace:
      [   18.929904]  __might_sleep+0x7c/0x88
      [   18.934311]  __mutex_lock+0x60/0x870
      [   18.938687]  mutex_lock_nested+0x1c/0x28
      [   18.943076]  regmap_lock_mutex+0x10/0x18
      [   18.947453]  regmap_read+0x38/0x70
      [   18.951842]  dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
      [   18.956269]  __handle_irq_event_percpu+0xac/0x410
      [   18.960712]  handle_irq_event_percpu+0x34/0x88
      [   18.965176]  handle_irq_event+0x48/0x78
      [   18.969612]  handle_fasteoi_irq+0xac/0x160
      [   18.974058]  generic_handle_irq+0x24/0x38
      [   18.978501]  __handle_domain_irq+0x60/0xb8
      [   18.982938]  gic_handle_irq+0x50/0xa0
      [   18.987351]  el1_irq+0xb4/0x130
      [   18.991734]  debug_lockdep_rcu_enabled+0x2c/0x30
      [   18.996180]  schedule+0x38/0xa0
      [   19.000609]  schedule_timeout+0x3a8/0x510
      [   19.005064]  wait_for_common+0x15c/0x180
      [   19.009513]  wait_for_completion+0x14/0x20
      [   19.013951]  mmc_wait_for_req_done+0x28/0x168
      [   19.018402]  mmc_wait_for_req+0xa8/0xe8
      [   19.022809]  mmc_wait_for_cmd+0x64/0x98
      [   19.027177]  mmc_io_rw_direct_host+0x94/0x130
      [   19.031563]  mmc_io_rw_direct+0x10/0x18
      [   19.035922]  sdio_enable_func+0xe8/0x1d0
      [   19.040294]  btsdio_open+0x24/0xc0 [btsdio]
      [   19.044742]  hci_dev_do_open+0x64/0x598 [bluetooth]
      [   19.049228]  hci_power_on+0x50/0x270 [bluetooth]
      [   19.053687]  process_one_work+0x2a0/0x6e0
      [   19.058143]  worker_thread+0x40/0x448
      [   19.062608]  kthread+0x12c/0x130
      [   19.067064]  ret_from_fork+0x10/0x1c
      [   19.071513] irq event stamp: 12
      [   19.075937] hardirqs last  enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
      [   19.083560] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
      [   19.091401] softirqs last  enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
      [   19.100801] softirqs last disabled at (0): [<0000000000000000>]           (null)
      [   19.108135] ---[ end trace 38c4920787b88c75 ]---
      
      So, fix this by enabling the fast_io option in our regmap config so that
      regmap uses spinlocks for locking instead of mutexes.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Fixes: 3f68be7d ("drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY")
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Carlo Caione <carlo@caione.org>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: linux-amlogic@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: <stable@vger.kernel.org> # v4.12+
      Acked-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181124191238.28276-1-lyude@redhat.comSigned-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9576f521
    • Sergio Correia's avatar
      drm: set is_master to 0 upon drm_new_set_master() failure · 4e97ad08
      Sergio Correia authored
      commit 23a336b3 upstream.
      
      When drm_new_set_master() fails, set is_master to 0, to prevent a
      possible NULL pointer deref.
      
      Here is a problematic flow: we check is_master in drm_is_current_master(),
      then proceed to call drm_lease_owner() passing master. If we do not restore
      is_master status when drm_new_set_master() fails, we may have a situation
      in which is_master will be 1 and master itself, NULL, leading to the deref
      of a NULL pointer in drm_lease_owner().
      
      This fixes the following OOPS, observed on an ArchLinux running a 4.19.2
      kernel:
      
      [   97.804282] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
      [   97.807224] PGD 0 P4D 0
      [   97.807224] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [   97.807224] CPU: 0 PID: 1348 Comm: xfwm4 Tainted: P           OE     4.19.2-arch1-1-ARCH #1
      [   97.807224] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./AB350 Pro4, BIOS P5.10 10/16/2018
      [   97.807224] RIP: 0010:drm_lease_owner+0xd/0x20 [drm]
      [   97.807224] Code: 83 c4 18 5b 5d c3 b8 ea ff ff ff eb e2 b8 ed ff ff ff eb db e8 b4 ca 68 fb 0f 1f 40 00 0f 1f 44 00 00 48 89 f8 eb 03 48 89 d0 <48> 8b 90 80 00 00 00 48 85 d2 75 f1 c3 66 0f 1f 44 00 00 0f 1f 44
      [   97.807224] RSP: 0018:ffffb8cf08e07bb0 EFLAGS: 00010202
      [   97.807224] RAX: 0000000000000000 RBX: ffff9cf0f2586c00 RCX: ffff9cf0f2586c88
      [   97.807224] RDX: ffff9cf0ddbd8000 RSI: 0000000000000000 RDI: 0000000000000000
      [   97.807224] RBP: ffff9cf1040e9800 R08: 0000000000000000 R09: 0000000000000000
      [   97.807224] R10: ffffdeb30fd5d680 R11: ffffdeb30f5d6808 R12: ffff9cf1040e9888
      [   97.807224] R13: 0000000000000000 R14: dead000000000200 R15: ffff9cf0f2586cc8
      [   97.807224] FS:  00007f4145513180(0000) GS:ffff9cf10ea00000(0000) knlGS:0000000000000000
      [   97.807224] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   97.807224] CR2: 0000000000000080 CR3: 00000003d7548000 CR4: 00000000003406f0
      [   97.807224] Call Trace:
      [   97.807224]  drm_is_current_master+0x1a/0x30 [drm]
      [   97.807224]  drm_master_release+0x3e/0x130 [drm]
      [   97.807224]  drm_file_free.part.0+0x2be/0x2d0 [drm]
      [   97.807224]  drm_open+0x1ba/0x1e0 [drm]
      [   97.807224]  drm_stub_open+0xaf/0xe0 [drm]
      [   97.807224]  chrdev_open+0xa3/0x1b0
      [   97.807224]  ? cdev_put.part.0+0x20/0x20
      [   97.807224]  do_dentry_open+0x132/0x340
      [   97.807224]  path_openat+0x2d1/0x14e0
      [   97.807224]  ? mem_cgroup_commit_charge+0x7a/0x520
      [   97.807224]  do_filp_open+0x93/0x100
      [   97.807224]  ? __check_object_size+0x102/0x189
      [   97.807224]  ? _raw_spin_unlock+0x16/0x30
      [   97.807224]  do_sys_open+0x186/0x210
      [   97.807224]  do_syscall_64+0x5b/0x170
      [   97.807224]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [   97.807224] RIP: 0033:0x7f4147b07976
      [   97.807224] Code: 89 54 24 08 e8 7b f4 ff ff 8b 74 24 0c 48 8b 3c 24 41 89 c0 44 8b 54 24 08 b8 01 01 00 00 89 f2 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 77 30 44 89 c7 89 44 24 08 e8 a6 f4 ff ff 8b 44
      [   97.807224] RSP: 002b:00007ffcced96ca0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
      [   97.807224] RAX: ffffffffffffffda RBX: 00005619d5037f80 RCX: 00007f4147b07976
      [   97.807224] RDX: 0000000000000002 RSI: 00005619d46b969c RDI: 00000000ffffff9c
      [   98.040039] RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000000
      [   98.040039] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000024
      [   98.040039] R13: 0000000000000012 R14: 00005619d5035950 R15: 0000000000000012
      [   98.040039] Modules linked in: nct6775 hwmon_vid algif_skcipher af_alg nls_iso8859_1 nls_cp437 vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common arc4 videodev media snd_usb_audio snd_hda_codec_hdmi snd_usbmidi_lib snd_rawmidi snd_seq_device mousedev input_leds iwlmvm mac80211 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec edac_mce_amd kvm_amd snd_hda_core kvm iwlwifi snd_hwdep r8169 wmi_bmof cfg80211 snd_pcm irqbypass snd_timer snd libphy soundcore pinctrl_amd rfkill pcspkr sp5100_tco evdev gpio_amdpt k10temp mac_hid i2c_piix4 wmi pcc_cpufreq acpi_cpufreq vboxnetflt(OE) vboxnetadp(OE) vboxpci(OE) vboxdrv(OE) msr sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto uas usb_storage dm_crypt hid_generic usbhid hid
      [   98.040039]  dm_mod raid1 md_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc ahci libahci aesni_intel aes_x86_64 libata crypto_simd cryptd glue_helper ccp xhci_pci rng_core scsi_mod xhci_hcd nvidia_drm(POE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpgart nvidia_uvm(POE) nvidia_modeset(POE) nvidia(POE) ipmi_devintf ipmi_msghandler
      [   98.040039] CR2: 0000000000000080
      [   98.040039] ---[ end trace 3b65093b6fe62b2f ]---
      [   98.040039] RIP: 0010:drm_lease_owner+0xd/0x20 [drm]
      [   98.040039] Code: 83 c4 18 5b 5d c3 b8 ea ff ff ff eb e2 b8 ed ff ff ff eb db e8 b4 ca 68 fb 0f 1f 40 00 0f 1f 44 00 00 48 89 f8 eb 03 48 89 d0 <48> 8b 90 80 00 00 00 48 85 d2 75 f1 c3 66 0f 1f 44 00 00 0f 1f 44
      [   98.040039] RSP: 0018:ffffb8cf08e07bb0 EFLAGS: 00010202
      [   98.040039] RAX: 0000000000000000 RBX: ffff9cf0f2586c00 RCX: ffff9cf0f2586c88
      [   98.040039] RDX: ffff9cf0ddbd8000 RSI: 0000000000000000 RDI: 0000000000000000
      [   98.040039] RBP: ffff9cf1040e9800 R08: 0000000000000000 R09: 0000000000000000
      [   98.040039] R10: ffffdeb30fd5d680 R11: ffffdeb30f5d6808 R12: ffff9cf1040e9888
      [   98.040039] R13: 0000000000000000 R14: dead000000000200 R15: ffff9cf0f2586cc8
      [   98.040039] FS:  00007f4145513180(0000) GS:ffff9cf10ea00000(0000) knlGS:0000000000000000
      [   98.040039] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   98.040039] CR2: 0000000000000080 CR3: 00000003d7548000 CR4: 00000000003406f0
      Signed-off-by: default avatarSergio Correia <sergio@correia.cc>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181122053329.2692-1-sergio@correia.ccSigned-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e97ad08
    • Sam Bobroff's avatar
      drm/ast: Fix incorrect free on ioregs · 37b92730
      Sam Bobroff authored
      commit dc25ab06 upstream.
      
      If the platform has no IO space, ioregs is placed next to the already
      allocated regs. In this case, it should not be separately freed.
      
      This prevents a kernel warning from __vunmap "Trying to vfree()
      nonexistent vm area" when unloading the driver.
      
      Fixes: 0dd68309 ("drm/ast: Try to use MMIO registers when PIO isn't supported")
      Signed-off-by: default avatarSam Bobroff <sbobroff@linux.ibm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37b92730
    • Michael Guralnik's avatar
      IB/mlx5: Avoid load failure due to unknown link width · 53f6341a
      Michael Guralnik authored
      commit db7a691a upstream.
      
      If the firmware reports a connection width that is not 1x, 4x, 8x or 12x
      it causes the driver to fail during initialization.
      
      To prevent this failure every time a new width is introduced to the RDMA
      stack, we will set a default 4x width for these widths which ar unknown to
      the driver.
      
      This is needed to allow to run old kernels with new firmware.
      
      Cc: <stable@vger.kernel.org> # 4.1
      Fixes: 1b5daf11 ("IB/mlx5: Avoid using the MAD_IFC command under ISSI > 0 mode")
      Signed-off-by: default avatarMichael Guralnik <michaelgur@mellanox.com>
      Reviewed-by: default avatarMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      53f6341a
    • Dmitry V. Levin's avatar
      mips: fix mips_get_syscall_arg o32 check · d3c09994
      Dmitry V. Levin authored
      commit c50cbd85 upstream.
      
      When checking for TIF_32BIT_REGS flag, mips_get_syscall_arg() should
      use the task specified as its argument instead of the current task.
      
      This potentially affects all syscall_get_arguments() users
      who specify tasks different from the current.
      
      Fixes: c0ff3c53 ("MIPS: Enable HAVE_ARCH_TRACEHOOK.")
      Signed-off-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21185/
      Cc: Elvira Khabirova <lineprinter@altlinux.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v3.13+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3c09994
    • Mathias Kresin's avatar
      MIPS: ralink: Fix mt7620 nd_sd pinmux · 9aab50ae
      Mathias Kresin authored
      commit 7d35baa4 upstream.
      
      In case the nd_sd group is set to the sd-card function, Pins 45 + 46 are
      configured as GPIOs. If they are blocked by the sd function, they can't
      be used as GPIOs.
      Reported-by: default avatarKristian Evensen <kristian.evensen@gmail.com>
      Signed-off-by: default avatarMathias Kresin <dev@kresin.me>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: f576fb6a ("MIPS: ralink: cleanup the soc specific pinmux data")
      Patchwork: https://patchwork.linux-mips.org/patch/21220/
      Cc: John Crispin <john@phrozen.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v3.18+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9aab50ae
    • Andrea Parri's avatar
      uprobes: Fix handle_swbp() vs. unregister() + register() race once more · 8d3ab1cc
      Andrea Parri authored
      commit 09d3f015 upstream.
      
      Commit:
      
        142b18dd ("uprobes: Fix handle_swbp() vs unregister() + register() race")
      
      added the UPROBE_COPY_INSN flag, and corresponding smp_wmb() and smp_rmb()
      memory barriers, to ensure that handle_swbp() uses fully-initialized
      uprobes only.
      
      However, the smp_rmb() is mis-placed: this barrier should be placed
      after handle_swbp() has tested for the flag, thus guaranteeing that
      (program-order) subsequent loads from the uprobe can see the initial
      stores performed by prepare_uprobe().
      
      Move the smp_rmb() accordingly.  Also amend the comments associated
      to the two memory barriers to indicate their actual locations.
      Signed-off-by: default avatarAndrea Parri <andrea.parri@amarulasolutions.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: stable@kernel.org
      Fixes: 142b18dd ("uprobes: Fix handle_swbp() vs unregister() + register() race")
      Link: http://lkml.kernel.org/r/20181122161031.15179-1-andrea.parri@amarulasolutions.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8d3ab1cc
    • Sagi Grimberg's avatar
      iser: set sector for ambiguous mr status errors · 48c11537
      Sagi Grimberg authored
      commit 24c3456c upstream.
      
      If for some reason we failed to query the mr status, we need to make sure
      to provide sufficient information for an ambiguous error (guard error on
      sector 0).
      
      Fixes: 0a7a08ad ("IB/iser: Implement check_protection")
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48c11537
    • Arnd Bergmann's avatar
      kdb: use memmove instead of overlapping memcpy · 184adf40
      Arnd Bergmann authored
      commit 2cf2f0d5 upstream.
      
      gcc discovered that the memcpy() arguments in kdbnearsym() overlap, so
      we should really use memmove(), which is defined to handle that correctly:
      
      In function 'memcpy',
          inlined from 'kdbnearsym' at /git/arm-soc/kernel/debug/kdb/kdb_support.c:132:4:
      /git/arm-soc/include/linux/string.h:353:9: error: '__builtin_memcpy' accessing 792 bytes at offsets 0 and 8 overlaps 784 bytes at offset 8 [-Werror=restrict]
        return __builtin_memcpy(p, q, size);
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      184adf40
    • Arnd Bergmann's avatar
      staging: rts5208: fix gcc-8 logic error warning · 46762a64
      Arnd Bergmann authored
      commit 58930cce upstream.
      
      As gcc-8 points out, the bit mask check makes no sense here:
      
      drivers/staging/rts5208/sd.c: In function 'ext_sd_send_cmd_get_rsp':
      drivers/staging/rts5208/sd.c:4130:25: error: bitwise comparison always evaluates to true [-Werror=tautological-compare]
      
      However, the code is even more bogus, as we have already
      checked for the SD_RSP_TYPE_R0 case earlier in the function
      and returned success. As seen in the mmc/sd driver core,
      SD_RSP_TYPE_R0 means "no response" anyway, so checking for
      a particular response would not help either.
      
      This just removes the nonsensical code to get rid of the
      warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46762a64
    • Arnd Bergmann's avatar
      scsi: bfa: convert to strlcpy/strlcat · 94d6d9e5
      Arnd Bergmann authored
      commit 8c5a50e8 upstream.
      
      The bfa driver has a number of real issues with string termination
      that gcc-8 now points out:
      
      drivers/scsi/bfa/bfad_bsg.c: In function 'bfad_iocmd_port_get_attr':
      drivers/scsi/bfa/bfad_bsg.c:320:9: error: argument to 'sizeof' in 'strncpy' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c: In function 'bfa_fcs_fabric_psymb_init':
      drivers/scsi/bfa/bfa_fcs.c:775:9: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:781:9: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:788:9: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:801:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:808:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c: In function 'bfa_fcs_fabric_nsymb_init':
      drivers/scsi/bfa/bfa_fcs.c:837:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:844:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c:852:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs.c: In function 'bfa_fcs_fabric_psymb_init':
      drivers/scsi/bfa/bfa_fcs.c:778:2: error: 'strncat' output may be truncated copying 10 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs.c:784:2: error: 'strncat' output may be truncated copying 30 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs.c:803:3: error: 'strncat' output may be truncated copying 44 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs.c:811:3: error: 'strncat' output may be truncated copying 16 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs.c: In function 'bfa_fcs_fabric_nsymb_init':
      drivers/scsi/bfa/bfa_fcs.c:840:2: error: 'strncat' output may be truncated copying 10 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs.c:847:2: error: 'strncat' output may be truncated copying 30 bytes from a string of length 63 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c: In function 'bfa_fcs_fdmi_get_hbaattr':
      drivers/scsi/bfa/bfa_fcs_lport.c:2657:10: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs_lport.c:2659:11: error: argument to 'sizeof' in 'strncat' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
      drivers/scsi/bfa/bfa_fcs_lport.c: In function 'bfa_fcs_lport_ms_gmal_response':
      drivers/scsi/bfa/bfa_fcs_lport.c:3232:5: error: 'strncpy' output may be truncated copying 16 bytes from a string of length 247 [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c: In function 'bfa_fcs_lport_ns_send_rspn_id':
      drivers/scsi/bfa/bfa_fcs_lport.c:4670:3: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c:4682:3: error: 'strncat' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c: In function 'bfa_fcs_lport_ns_util_send_rspn_id':
      drivers/scsi/bfa/bfa_fcs_lport.c:5206:3: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c:5215:3: error: 'strncat' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcs_lport.c: In function 'bfa_fcs_fdmi_get_portattr':
      drivers/scsi/bfa/bfa_fcs_lport.c:2751:2: error: 'strncpy' specified bound 128 equals destination size [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcbuild.c: In function 'fc_rspnid_build':
      drivers/scsi/bfa/bfa_fcbuild.c:1254:2: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      drivers/scsi/bfa/bfa_fcbuild.c:1253:25: note: length computed here
      drivers/scsi/bfa/bfa_fcbuild.c: In function 'fc_rsnn_nn_build':
      drivers/scsi/bfa/bfa_fcbuild.c:1275:2: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      
      In most cases, this can be addressed by correctly calling strlcpy and
      strlcat instead of strncpy/strncat, with the size of the destination
      buffer as the last argument.
      
      For consistency, I'm changing the other callers of strncpy() in this
      driver the same way.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Acked-by: default avatarSudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94d6d9e5
    • Arnd Bergmann's avatar
      drm: gma500: fix logic error · 4e4b875e
      Arnd Bergmann authored
      commit 67a3b63a upstream.
      
      gcc-8 points out a condition that almost certainly doesn't
      do what the author had in mind:
      
      drivers/gpu/drm/gma500/mdfld_intel_display.c: In function 'mdfldWaitForPipeEnable':
      drivers/gpu/drm/gma500/mdfld_intel_display.c:102:37: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
      
      This changes it to a simple bit mask operation to check
      whether the bit is set.
      
      Fixes: 026abc33 ("gma500: initial medfield merge")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170905074741.435324-1-arnd@arndb.deSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e4b875e
    • Sultan Alsawaf's avatar
      ip_tunnel: Fix name string concatenate in __ip_tunnel_create() · bb1d0ac3
      Sultan Alsawaf authored
      commit 000ade80 upstream.
      
      By passing a limit of 2 bytes to strncat, strncat is limited to writing
      fewer bytes than what it's supposed to append to the name here.
      
      Since the bounds are checked on the line above this, just remove the string
      bounds checks entirely since they're unneeded.
      Signed-off-by: default avatarSultan Alsawaf <sultanxda@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb1d0ac3
    • Guenter Roeck's avatar
      kernfs: Replace strncpy with memcpy · e26457da
      Guenter Roeck authored
      commit 166126c1 upstream.
      
      gcc 8.1.0 complains:
      
      fs/kernfs/symlink.c:91:3: warning:
      	'strncpy' output truncated before terminating nul copying
      	as many bytes from a string as its length
      fs/kernfs/symlink.c: In function 'kernfs_iop_get_link':
      fs/kernfs/symlink.c:88:14: note: length computed here
      
      Using strncpy() is indeed less than perfect since the length of data to
      be copied has already been determined with strlen(). Replace strncpy()
      with memcpy() to address the warning and optimize the code a little.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e26457da
    • Linus Torvalds's avatar
      unifdef: use memcpy instead of strncpy · f5028606
      Linus Torvalds authored
      commit 38c7b224 upstream.
      
      New versions of gcc reasonably warn about the odd pattern of
      
      	strncpy(p, q, strlen(q));
      
      which really doesn't make sense: the strncpy() ends up being just a slow
      and odd way to write memcpy() in this case.
      
      There was a comment about _why_ the code used strncpy - to avoid the
      terminating NUL byte, but memcpy does the same and avoids the warning.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5028606
    • Takashi Iwai's avatar
      ALSA: intel_hdmi: Use strlcpy() instead of strncpy() · 23df6300
      Takashi Iwai authored
      commit c288248f upstream.
      
      hdmi_lpe_audio_probe() copies the pcm name string via strncpy(), but
      as a gcc8 warning suggests, it misses a NUL terminator, and unlikely
      the expected result.
      
      Use the proper one, strlcpy() instead.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      23df6300
    • Guenter Roeck's avatar
      kobject: Replace strncpy with memcpy · af882cb0
      Guenter Roeck authored
      commit 77d2a24b upstream.
      
      gcc 8.1.0 complains:
      
      lib/kobject.c:128:3: warning:
      	'strncpy' output truncated before terminating nul copying as many
      	bytes from a string as its length [-Wstringop-truncation]
      lib/kobject.c: In function 'kobject_get_path':
      lib/kobject.c:125:13: note: length computed here
      
      Using strncpy() is indeed less than perfect since the length of data to
      be copied has already been determined with strlen(). Replace strncpy()
      with memcpy() to address the warning and optimize the code a little.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af882cb0
    • Linus Torvalds's avatar
      test_hexdump: use memcpy instead of strncpy · 337f2837
      Linus Torvalds authored
      commit b1286ed7 upstream.
      
      New versions of gcc reasonably warn about the odd pattern of
      
      	strncpy(p, q, strlen(q));
      
      which really doesn't make sense: the strncpy() ends up being just a slow
      and odd way to write memcpy() in this case.
      
      Apparently there was a patch for this floating around earlier, but it
      got lost.
      Acked-again-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      337f2837
    • Stephen Rothwell's avatar
      disable stringop truncation warnings for now · 9f8d1097
      Stephen Rothwell authored
      commit 217c3e01 upstream.
      
      They are too noisy
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f8d1097
    • Xiongfeng Wang's avatar
      Kbuild: suppress packed-not-aligned warning for default setting only · f5ec9987
      Xiongfeng Wang authored
      commit 321cb030 upstream.
      
      gcc-8 reports many -Wpacked-not-aligned warnings. The below are some
      examples.
      
      ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
      ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
       } __attribute__ ((packed));
      
      ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
      ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
       } __attribute__ ((packed));
      
      ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
      ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
       } __attribute__ ((packed));
      
      This patch suppresses this kind of warnings for default setting.
      Signed-off-by: default avatarXiongfeng Wang <xiongfeng.wang@linaro.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5ec9987
  2. 05 Dec, 2018 14 commits