1. 15 Jan, 2019 1 commit
  2. 07 Jan, 2019 1 commit
  3. 04 Jan, 2019 7 commits
    • Qian Cai's avatar
      drivers/base/platform.c: kmemleak ignore a known leak · 967d3010
      Qian Cai authored
      unreferenced object 0xffff808ec6dc5a80 (size 128):
        comm "swapper/0", pid 1, jiffies 4294938063 (age 2560.530s)
        hex dump (first 32 bytes):
          ff ff ff ff 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b  ........kkkkkkkk
          6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
          [<00000000476dcf8c>] kmem_cache_alloc_trace+0x430/0x500
          [<000000004f708d37>] platform_device_register_full+0xbc/0x1e8
          [<000000006c2a7ec7>] acpi_create_platform_device+0x370/0x450
          [<00000000ef135642>] acpi_default_enumeration+0x34/0x78
          [<000000003bd9a052>] acpi_bus_attach+0x2dc/0x3e0
          [<000000003cf4f7f2>] acpi_bus_attach+0x108/0x3e0
          [<000000003cf4f7f2>] acpi_bus_attach+0x108/0x3e0
          [<000000002968643e>] acpi_bus_scan+0xb0/0x110
          [<0000000010dd0bd7>] acpi_scan_init+0x1a8/0x410
          [<00000000965b3c5a>] acpi_init+0x408/0x49c
          [<00000000ed4b9fe2>] do_one_initcall+0x178/0x7f4
          [<00000000a5ac5a74>] kernel_init_freeable+0x9d4/0xa9c
          [<0000000070ea6c15>] kernel_init+0x18/0x138
          [<00000000fb8fff06>] ret_from_fork+0x10/0x1c
          [<0000000041273a0d>] 0xffffffffffffffff
      Then, faddr2line pointed out this line,
       * This memory isn't freed when the device is put,
       * I don't have a nice idea for that though.  Conceptually
       * dma_mask in struct device should not be a pointer.
       * See http://thread.gmane.org/gmane.linux.kernel.pci/9081
      pdev->dev.dma_mask =
      	kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
      Since this leak has existed for more than 8 years and it does not
      reference other parts of the memory, let kmemleak ignore it, so users
      don't need to waste time reporting this in the future.
      Link: http://lkml.kernel.org/r/20181206160751.36211-1-cai@gmx.usSigned-off-by: default avatarQian Cai <cai@gmx.us>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • huang.zijiang's avatar
      drivers/firmware/memmap.c: modify memblock_alloc to memblock_alloc_nopanic · 05391772
      huang.zijiang authored
      memblock_alloc() never returns NULL because panic never returns.
      Link: http://lkml.kernel.org/r/1545640882-42009-1-git-send-email-huang.zijiang@zte.com.cnSigned-off-by: default avatarhuang.zijiang <huang.zijiang@zte.com.cn>
      Acked-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Yi Wang <wang.yi59@zte.com.cn>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Souptick Joarder's avatar
      drivers/dma-buf/udmabuf.c: convert to use vm_fault_t · 300133d3
      Souptick Joarder authored
      Use new return type vm_fault_t for fault handler.
      Link: http://lkml.kernel.org/r/20181106173628.GA12989@jordon-HP-15-Notebook-PCSigned-off-by: default avatarSouptick Joarder <jrdr.linux@gmail.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Linus Torvalds's avatar
      make 'user_access_begin()' do 'access_ok()' · 594cc251
      Linus Torvalds authored
      Originally, the rule used to be that you'd have to do access_ok()
      separately, and then user_access_begin() before actually doing the
      direct (optimized) user access.
      But experience has shown that people then decide not to do access_ok()
      at all, and instead rely on it being implied by other operations or
      similar.  Which makes it very hard to verify that the access has
      actually been range-checked.
      If you use the unsafe direct user accesses, hardware features (either
      SMAP - Supervisor Mode Access Protection - on x86, or PAN - Privileged
      Access Never - on ARM) do force you to use user_access_begin().  But
      nothing really forces the range check.
      By putting the range check into user_access_begin(), we actually force
      people to do the right thing (tm), and the range check vill be visible
      near the actual accesses.  We have way too long a history of people
      trying to avoid them.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Linus Torvalds's avatar
      i915: fix missing user_access_end() in page fault exception case · 0b2c8f8b
      Linus Torvalds authored
      When commit fddcd00a ("drm/i915: Force the slow path after a
      user-write error") unified the error handling for various user access
      problems, it didn't do the user_access_end() that is needed for the
      unsafe_put_user() case.
      It's not a huge deal: a missed user_access_end() will only mean that
      SMAP protection isn't active afterwards, and for the error case we'll be
      returning to user mode soon enough anyway.  But it's wrong, and adding
      the proper user_access_end() is trivial enough (and doing it for the
      other error cases where it isn't needed doesn't hurt).
      I noticed it while doing the same prep-work for changing
      user_access_begin() that precipitated the access_ok() changes in commit
      96d4f267 ("Remove 'type' argument from access_ok() function").
      Fixes: fddcd00a ("drm/i915: Force the slow path after a user-write error")
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: stable@kernel.org # v4.20
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Shaokun Zhang's avatar
      drivers/perf: hisi: Fixup one DDRC PMU register offset · eb4f5213
      Shaokun Zhang authored
      For DDRC PMU, each PMU counter is fixed-purpose. There is a mismatch
      between perf list and driver definition on rw_chg event.
      # perf list | grep chg
        hisi_sccl1_ddrc0/rnk_chg/                          [Kernel PMU event]
        hisi_sccl1_ddrc0/rw_chg/                           [Kernel PMU event]
      But the register offset of rw_chg event is not defined in the driver,
      meanwhile bnk_chg register offset is mis-defined, let's fixup it.
      Fixes: 904dcf03 ("perf: hisi: Add support for HiSilicon SoC DDRC PMU driver")
      Cc: stable@vger.kernel.org
      Cc: John Garry <john.garry@huawei.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarWeijian Huang <huangweijian4@hisilicon.com>
      Signed-off-by: default avatarShaokun Zhang <zhangshaokun@hisilicon.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Linus Torvalds's avatar
      Remove 'type' argument from access_ok() function · 96d4f267
      Linus Torvalds authored
      Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
      of the user address range verification function since we got rid of the
      old racy i386-only code to walk page tables by hand.
      It existed because the original 80386 would not honor the write protect
      bit when in kernel mode, so you had to do COW by hand before doing any
      user access.  But we haven't supported that in a long time, and these
      days the 'type' argument is a purely historical artifact.
      A discussion about extending 'user_access_begin()' to do the range
      checking resulted this patch, because there is no way we're going to
      move the old VERIFY_xyz interface to that model.  And it's best done at
      the end of the merge window when I've done most of my merges, so let's
      just get this done once and for all.
      This patch was mostly done with a sed-script, with manual fix-ups for
      the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
      There were a couple of notable cases:
       - csky still had the old "verify_area()" name as an alias.
       - the iter_iov code had magical hardcoded knowledge of the actual
         values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
         really used it)
       - microblaze used the type argument for a debug printout
      but other than those oddities this should be a total no-op patch.
      I tried to fix up all architectures, did fairly extensive grepping for
      access_ok() uses, and the changes are trivial, but I may have missed
      something.  Any missed conversion should be trivially fixable, though.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  4. 03 Jan, 2019 9 commits
  5. 02 Jan, 2019 22 commits