1. 17 Dec, 2018 1 commit
    • Stefano Brivio's avatar
      neighbour: Avoid writing before skb->head in neigh_hh_output() · 5873b2c7
      Stefano Brivio authored
      [ Upstream commit e6ac64d4c4d095085d7dd71cbd05704ac99829b2 ]
      While skb_push() makes the kernel panic if the skb headroom is less than
      the unaligned hardware header size, it will proceed normally in case we
      copy more than that because of alignment, and we'll silently corrupt
      adjacent slabs.
      In the case fixed by the previous patch,
      "ipv6: Check available headroom in ip6_xmit() even without options", we
      end up in neigh_hh_output() with 14 bytes headroom, 14 bytes hardware
      header and write 16 bytes, starting 2 bytes before the allocated buffer.
      Always check we're not writing before skb->head and, if the headroom is
      not enough, warn and drop the packet.
       - instead of panicking with BUG_ON(), WARN_ON_ONCE() and drop the packet
         (Eric Dumazet)
       - if we avoid the panic, though, we need to explicitly check the headroom
         before the memcpy(), otherwise we'll have corrupted slabs on a running
         kernel, after we warn
       - use __skb_push() instead of skb_push(), as the headroom check is
         already implemented here explicitly (Eric Dumazet)
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 13 Dec, 2018 2 commits
  3. 08 Dec, 2018 11 commits
  4. 05 Dec, 2018 1 commit
    • Arnd Bergmann's avatar
      workqueue: avoid clang warning · 6f35b5bd
      Arnd Bergmann authored
      (commit a45463cb upstream)
      Building with clang shows lots of warning like:
      drivers/amba/bus.c:447:8: warning: implicit conversion from 'long long' to 'int' changes value from 4294967248 to -48
      static DECLARE_DELAYED_WORK(deferred_retry_work, amba_deferred_retry_func);
      include/linux/workqueue.h:187:26: note: expanded from macro 'DECLARE_DELAYED_WORK'
              struct delayed_work n = __DELAYED_WORK_INITIALIZER(n, f, 0)
      include/linux/workqueue.h:177:10: note: expanded from macro '__DELAYED_WORK_INITIALIZER'
              .work = __WORK_INITIALIZER((n).work, (f)),                      \
      include/linux/workqueue.h:170:10: note: expanded from macro '__WORK_INITIALIZER'
              .data = WORK_DATA_STATIC_INIT(),                                \
      include/linux/workqueue.h:111:39: note: expanded from macro 'WORK_DATA_STATIC_INIT'
      include/asm-generic/atomic-long.h:32:41: note: expanded from macro 'ATOMIC_LONG_INIT'
       #define ATOMIC_LONG_INIT(i)     ATOMIC_INIT(i)
      arch/arm/include/asm/atomic.h:21:27: note: expanded from macro 'ATOMIC_INIT'
       #define ATOMIC_INIT(i)  { (i) }
                              ~  ^
      This makes the type cast explicit, which shuts up the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 01 Dec, 2018 5 commits
  6. 27 Nov, 2018 2 commits
  7. 23 Nov, 2018 2 commits
  8. 21 Nov, 2018 3 commits
    • Mike Kravetz's avatar
      mm: migration: fix migration of huge PMD shared pages · 9c34ad0c
      Mike Kravetz authored
      commit 017b1660df89f5fb4bfe66c34e35f7d2031100c7 upstream.
      The page migration code employs try_to_unmap() to try and unmap the source
      page.  This is accomplished by using rmap_walk to find all vmas where the
      page is mapped.  This search stops when page mapcount is zero.  For shared
      PMD huge pages, the page map count is always 1 no matter the number of
      mappings.  Shared mappings are tracked via the reference count of the PMD
      page.  Therefore, try_to_unmap stops prematurely and does not completely
      unmap all mappings of the source page.
      This problem can result is data corruption as writes to the original
      source page can happen after contents of the page are copied to the target
      page.  Hence, data is lost.
      This problem was originally seen as DB corruption of shared global areas
      after a huge page was soft offlined due to ECC memory errors.  DB
      developers noticed they could reproduce the issue by (hotplug) offlining
      memory used to back huge pages.  A simple testcase can reproduce the
      problem by creating a shared PMD mapping (note that this must be at least
      PUD_SIZE in size and PUD_SIZE aligned (1GB on x86)), and using
      migrate_pages() to migrate process pages between nodes while continually
      writing to the huge pages being migrated.
      To fix, have the try_to_unmap_one routine check for huge PMD sharing by
      calling huge_pmd_unshare for hugetlbfs huge pages.  If it is a shared
      mapping it will be 'unshared' which removes the page table entry and drops
      the reference on the PMD page.  After this, flush caches and TLB.
      mmu notifiers are called before locking page tables, but we can not be
      sure of PMD sharing until page tables are locked.  Therefore, check for
      the possibility of PMD sharing before locking so that notifiers can
      prepare for the worst possible case.
      Link: http://lkml.kernel.org/r/20180823205917.16297-2-mike.kravetz@oracle.com
      [mike.kravetz@oracle.com: make _range_in_vma() a static inline]
        Link: http://lkml.kernel.org/r/6063f215-a5c8-2f0c-465a-2c515ddc952d@oracle.com
      Fixes: 39dde65c ("shared page table for hugetlb page")
      Signed-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reviewed-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Reviewed-by: default avatarJérôme Glisse <jglisse@redhat.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Michael Kelley's avatar
      clockevents/drivers/i8253: Add support for PIT shutdown quirk · f6939dbd
      Michael Kelley authored
      commit 35b69a420bfb56b7b74cb635ea903db05e357bec upstream.
      Add support for platforms where pit_shutdown() doesn't work because of a
      quirk in the PIT emulation. On these platforms setting the counter register
      to zero causes the PIT to start running again, negating the shutdown.
      Provide a global variable that controls whether the counter register is
      zero'ed, which platform specific code can override.
      Signed-off-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
      Cc: "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>
      Cc: "daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>
      Cc: "virtualization@lists.linux-foundation.org" <virtualization@lists.linux-foundation.org>
      Cc: "jgross@suse.com" <jgross@suse.com>
      Cc: "akataria@vmware.com" <akataria@vmware.com>
      Cc: "olaf@aepfle.de" <olaf@aepfle.de>
      Cc: "apw@canonical.com" <apw@canonical.com>
      Cc: vkuznets <vkuznets@redhat.com>
      Cc: "jasowang@redhat.com" <jasowang@redhat.com>
      Cc: "marcelo.cerri@canonical.com" <marcelo.cerri@canonical.com>
      Cc: KY Srinivasan <kys@microsoft.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/1541303219-11142-2-git-send-email-mikelley@microsoft.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ilya Dryomov's avatar
      libceph: bump CEPH_MSG_MAX_DATA_LEN · 9efe0447
      Ilya Dryomov authored
      commit 94e6992bb560be8bffb47f287194adf070b57695 upstream.
      If the read is large enough, we end up spinning in the messenger:
        libceph: osd0 io error
        libceph: osd0 io error
        libceph: osd0 io error
      This is a receive side limit, so only reads were affected.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. 13 Nov, 2018 1 commit
    • Maciej W. Rozycki's avatar
      TC: Set DMA masks for devices · 5378c0ea
      Maciej W. Rozycki authored
      commit 3f2aa244ee1a0d17ed5b6c86564d2c1b24d1c96b upstream.
      Fix a TURBOchannel support regression with commit 205e1b7f
      ("dma-mapping: warn when there is no coherent_dma_mask") that caused
      coherent DMA allocations to produce a warning such as:
      defxx: v1.11 2014/07/01  Lawrence V. Stefani and others
      tc1: DEFTA at MMIO addr = 0x1e900000, IRQ = 20, Hardware addr = 08-00-2b-a3-a3-29
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dfx_dev_register+0x670/0x678
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc6 #2
      Stack : ffffffff8009ffc0 fffffffffffffec0 0000000000000000 ffffffff80647650
              0000000000000000 0000000000000000 ffffffff806f5f80 ffffffffffffffff
              0000000000000000 0000000000000000 0000000000000001 ffffffff8065d4e8
              98000000031b6300 ffffffff80563478 ffffffff805685b0 ffffffffffffffff
              0000000000000000 ffffffff805d6720 0000000000000204 ffffffff80388df8
              0000000000000000 0000000000000009 ffffffff8053efd0 ffffffff806657d0
              0000000000000000 ffffffff803177f8 0000000000000000 ffffffff806d0000
              9800000003078000 980000000307b9e0 000000001e900000 ffffffff80067940
              0000000000000000 ffffffff805d6720 0000000000000204 ffffffff80388df8
              ffffffff805176c0 ffffffff8004dc78 0000000000000000 ffffffff80067940
      Call Trace:
      [<ffffffff8004dc78>] show_stack+0xa0/0x130
      [<ffffffff80067940>] __warn+0x128/0x170
      ---[ end trace b1d1e094f67f3bb2 ]---
      This is because the TURBOchannel bus driver fails to set the coherent
      DMA mask for devices enumerated.
      Set the regular and coherent DMA masks for TURBOchannel devices then,
      observing that the bus protocol supports a 34-bit (16GiB) DMA address
      space, by interpreting the value presented in the address cycle across
      the 32 `ad' lines as a 32-bit word rather than byte address[1].  The
      architectural size of the TURBOchannel DMA address space exceeds the
      maximum amount of RAM any actual TURBOchannel system in existence may
      have, hence both masks are the same.
      This removes the warning shown above.
      [1] "TURBOchannel Hardware Specification", EK-369AA-OD-007B, Digital
          Equipment Corporation, January 1993, Section "DMA", pp. 1-15 -- 1-17
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20835/
      Fixes: 205e1b7f ("dma-mapping: warn when there is no coherent_dma_mask")
      Cc: stable@vger.kernel.org # 4.16+
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. 10 Nov, 2018 3 commits
  11. 20 Oct, 2018 1 commit
  12. 18 Oct, 2018 8 commits