Skip to content
Snippets Groups Projects
  1. Jan 09, 2019
    • Linus Walleij's avatar
      spi: ath79: Convert to use CS GPIO descriptors · 8db79547
      Linus Walleij authored
      
      This converts the ATH79 SPI master driver to use GPIO descriptors
      for chip select handling.
      
      The ATH79 driver was requesting the GPIO and driving it from the
      bitbang .chipselect callback. Do not request it anymore as the SPI
      core will request it, remove the line inversion semantics for the
      GPIO case (handled by gpiolib) and let the SPI core deal with
      requesting the GPIO line from the device tree node of the controller.
      
      This driver can be instantiated from a board file (no device tree)
      but the board files only use native CS (no GPIO lines) so we should
      be fine just letting the SPI core grab the GPIO from the device.
      
      The fact that the driver is actively driving the GPIO in the
      ath79_spi_chipselect() callback is confusing since the host does
      not set SPI_MASTER_GPIO_SS so this should not ever get called when
      using GPIO CS. I put in a comment about this.
      
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: Alban Bedel <albeu@free.fr>
      Cc: Linuxarm <linuxarm@huawei.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
    • Linus Walleij's avatar
      spi: Optionally use GPIO descriptors for CS GPIOs · f3186dd8
      Linus Walleij authored
      
      This augments the SPI core to optionally use GPIO descriptors
      for chip select on a per-master-driver opt-in basis.
      
      Drivers using this will rely on the SPI core to look up
      GPIO descriptors associated with the device, such as
      when using device tree or board files with GPIO descriptor
      tables.
      
      When getting descriptors from the device tree, this will in
      turn activate the code in gpiolib that was
      added in commit 6953c57a
      ("gpio: of: Handle SPI chipselect legacy bindings")
      which means that these descriptors are aware of the active
      low semantics that is the default for SPI CS GPIO lines
      and we can assume that all of these are "active high" and
      thus assign SPI_CS_HIGH to all CS lines on the DT path.
      
      The previously used gpio_set_value() would call down into
      gpiod_set_raw_value() and ignore the polarity inversion
      semantics.
      
      It seems like many drivers go to great lengths to set up the
      CS GPIO line as non-asserted, respecting SPI_CS_HIGH. We pull
      this out of the SPI drivers and into the core, and by simply
      requesting the line as GPIOD_OUT_LOW when retrieveing it from
      the device and relying on the gpiolib to handle any inversion
      semantics. This way a lot of code can be simplified and
      removed in each converted driver.
      
      The end goal after dealing with each driver in turn, is to
      delete the non-descriptor path (of_spi_register_master() for
      example) and let the core deal with only descriptors.
      
      The different SPI drivers have complex interactions with the
      core so we cannot simply change them all over, we need to use
      a stepwise, bisectable approach so that each driver can be
      converted and fixed in isolation.
      
      This patch has the intended side effect of adding support for
      ACPI GPIOs as it starts relying on gpiod_get_*() to get
      the GPIO handle associated with the device.
      
      Cc: Linuxarm <linuxarm@huawei.com>
      Acked-by: default avatarJonathan Cameron <jonathan.cameron@huawei.com>
      Tested-by: default avatarFangjian (Turing) <f.fangjian@huawei.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
  2. Jan 07, 2019
  3. Jan 04, 2019
    • 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
        backtrace:
          [<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.us
      
      
      Signed-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>
      967d3010
    • 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.cn
      
      
      Signed-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>
      05391772
    • 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-PC
      
      
      Signed-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>
      300133d3
    • 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>
      594cc251
    • 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>
      0b2c8f8b
    • 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>
      eb4f5213
    • 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>
      96d4f267
  4. Jan 03, 2019
  5. Jan 02, 2019
    • Aditya Pakki's avatar
      infiniband/qedr: Potential null ptr dereference of qp · 9c6260de
      Aditya Pakki authored
      
      idr_find() may fail and return a NULL pointer. The fix checks the return
      value of the function and returns an error in case of NULL.
      
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Acked-by: default avatarMichal Kalderon <michal.kalderon@marvell.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      9c6260de
    • Aditya Pakki's avatar
      infiniband: bnxt_re: qplib: Check the return value of send_message · 94edd87a
      Aditya Pakki authored
      
      In bnxt_qplib_map_tc2cos(), bnxt_qplib_rcfw_send_message() can return an
      error value but it is lost. Propagate this error to the callers.
      
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Acked-By: default avatarDevesh Sharma <devesh.sharma@broadcom.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      94edd87a
    • Julia Lawall's avatar
      IB/ipoib: drop useless LIST_HEAD · 2fb45895
      Julia Lawall authored
      Drop LIST_HEAD where the variable it declares is never used.
      
      Commit 31c02e21 ("IPoIB: Avoid using stale last_send counter
      when reaping AHs") removed the uses, but not the declaration.
      
      The semantic patch that fixes this problem is as follows:
      (http://coccinelle.lip6.fr/
      
      )
      
      // <smpl>
      @@
      identifier x;
      @@
      - LIST_HEAD(x);
        ... when != x
      // </smpl>
      
      Fixes: 31c02e21 ("IPoIB: Avoid using stale last_send counter when reaping AHs")
      Signed-off-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      2fb45895
    • Eric Dumazet's avatar
      isdn: fix kernel-infoleak in capi_unlocked_ioctl · d63967e4
      Eric Dumazet authored
      
      Since capi_ioctl() copies 64 bytes after calling
      capi20_get_manufacturer() we need to ensure to not leak
      information to user.
      
      BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
      CPU: 0 PID: 11245 Comm: syz-executor633 Not tainted 4.20.0-rc7+ #2
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x173/0x1d0 lib/dump_stack.c:113
       kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
       kmsan_internal_check_memory+0x9d4/0xb00 mm/kmsan/kmsan.c:704
       kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:601
       _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
       capi_ioctl include/linux/uaccess.h:177 [inline]
       capi_unlocked_ioctl+0x1a0b/0x1bf0 drivers/isdn/capi/capi.c:939
       do_vfs_ioctl+0xebd/0x2bf0 fs/ioctl.c:46
       ksys_ioctl fs/ioctl.c:713 [inline]
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl+0x1da/0x270 fs/ioctl.c:718
       __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:718
       do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x440019
      Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ffdd4659fb8 EFLAGS: 00000213 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440019
      RDX: 0000000020000080 RSI: 00000000c0044306 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
      R10: 0000000000000000 R11: 0000000000000213 R12: 00000000004018a0
      R13: 0000000000401930 R14: 0000000000000000 R15: 0000000000000000
      
      Local variable description: ----data.i@capi_unlocked_ioctl
      Variable was created at:
       capi_ioctl drivers/isdn/capi/capi.c:747 [inline]
       capi_unlocked_ioctl+0x82/0x1bf0 drivers/isdn/capi/capi.c:939
       do_vfs_ioctl+0xebd/0x2bf0 fs/ioctl.c:46
      
      Bytes 12-63 of 64 are uninitialized
      Memory access of size 64 starts at ffff88807ac5fce8
      Data copied to user address 0000000020000080
      
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d63967e4
    • Eric Dumazet's avatar
      net/hamradio/6pack: use mod_timer() to rearm timers · 202700e3
      Eric Dumazet authored
      
      Using del_timer() + add_timer() is generally unsafe on SMP,
      as noticed by syzbot. Use mod_timer() instead.
      
      kernel BUG at kernel/time/timer.c:1136!
      invalid opcode: 0000 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 1026 Comm: kworker/u4:4 Not tainted 4.20.0+ #2
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: events_unbound flush_to_ldisc
      RIP: 0010:add_timer kernel/time/timer.c:1136 [inline]
      RIP: 0010:add_timer+0xa81/0x1470 kernel/time/timer.c:1134
      Code: 4d 89 7d 40 48 c7 85 70 fe ff ff 00 00 00 00 c7 85 7c fe ff ff ff ff ff ff 48 89 85 90 fe ff ff e9 e6 f7 ff ff e8 cf 42 12 00 <0f> 0b e8 c8 42 12 00 0f 0b e8 c1 42 12 00 4c 89 bd 60 fe ff ff e9
      RSP: 0018:ffff8880a7fdf5a8 EFLAGS: 00010293
      RAX: ffff8880a7846340 RBX: dffffc0000000000 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: ffffffff816f3ee1 RDI: ffff88808a514ff8
      RBP: ffff8880a7fdf760 R08: 0000000000000007 R09: ffff8880a7846c58
      R10: ffff8880a7846340 R11: 0000000000000000 R12: ffff88808a514ff8
      R13: ffff88808a514ff8 R14: ffff88808a514dc0 R15: 0000000000000030
      FS:  0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000000061c500 CR3: 00000000994d9000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       decode_prio_command drivers/net/hamradio/6pack.c:903 [inline]
       sixpack_decode drivers/net/hamradio/6pack.c:971 [inline]
       sixpack_receive_buf drivers/net/hamradio/6pack.c:457 [inline]
       sixpack_receive_buf+0xf9c/0x1470 drivers/net/hamradio/6pack.c:434
       tty_ldisc_receive_buf+0x164/0x1c0 drivers/tty/tty_buffer.c:465
       tty_port_default_receive_buf+0x114/0x190 drivers/tty/tty_port.c:38
       receive_buf drivers/tty/tty_buffer.c:481 [inline]
       flush_to_ldisc+0x3b2/0x590 drivers/tty/tty_buffer.c:533
       process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
       worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
       kthread+0x357/0x430 kernel/kthread.c:246
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Andreas Koensgen <ajk@comnets.uni-bremen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      202700e3
    • Xue Chaojing's avatar
      net-next/hinic:add shutdown callback · 53fe3ed1
      Xue Chaojing authored
      
      If there is no shutdown callback, our board will report pcie UNF errors
      after restarting. This patch add shutdown callback for hinic.
      
      Signed-off-by: default avatarXue Chaojing <xuechaojing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      53fe3ed1
Loading