1. 31 5月, 2019 40 次提交
    • F
      iio: adc: stm32-dfsdm: fix unmet direct dependencies detected · 30f8da71
      Fabrice Gasnier 提交于
      [ Upstream commit ba7ecfe43d6bf12e2aa76705c45f7d187ae3d7c0 ]
      
      This fixes unmet direct dependencies seen when CONFIG_STM32_DFSDM_ADC
      is selected:
      
      WARNING: unmet direct dependencies detected for IIO_BUFFER_HW_CONSUMER
        Depends on [n]: IIO [=y] && IIO_BUFFER [=n]
        Selected by [y]:
        - STM32_DFSDM_ADC [=y] && IIO [=y] && (ARCH_STM32 [=y] && OF [=y] ||
          COMPILE_TEST [=n])
      
      Fixes: e2e6771c ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
      Signed-off-by: NFabrice Gasnier <fabrice.gasnier@st.com>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      30f8da71
    • D
      media: pvrusb2: Prevent a buffer overflow · 11ad5277
      Dan Carpenter 提交于
      [ Upstream commit c1ced46c7b49ad7bc064e68d966e0ad303f917fb ]
      
      The ctrl_check_input() function is called from pvr2_ctrl_range_check().
      It's supposed to validate user supplied input and return true or false
      depending on whether the input is valid or not.  The problem is that
      negative shifts or shifts greater than 31 are undefined in C.  In
      practice with GCC they result in shift wrapping so this function returns
      true for some inputs which are not valid and this could result in a
      buffer overflow:
      
          drivers/media/usb/pvrusb2/pvrusb2-ctrl.c:205 pvr2_ctrl_get_valname()
          warn: uncapped user index 'names[val]'
      
      The cptr->hdw->input_allowed_mask mask is configured in pvr2_hdw_create()
      and the highest valid bit is BIT(4).
      
      Fixes: 7fb20fa3 ("V4L/DVB (7299): pvrusb2: Improve logic which handles input choice availability")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      11ad5277
    • S
      media: au0828: Fix NULL pointer dereference in au0828_analog_stream_enable() · a90ce66a
      Shuah Khan 提交于
      [ Upstream commit 898bc40bfcc26abb6e06e960d6d4754c36c58b50 ]
      
      Fix au0828_analog_stream_enable() to check if device is in the right
      state first. When unbind happens while bind is in progress, usbdev
      pointer could be invalid in au0828_analog_stream_enable() and a call
      to usb_ifnum_to_if() will result in the null pointer dereference.
      
      This problem is found with the new media_dev_allocator.sh test.
      
      kernel: [  590.359623] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e8
      kernel: [  590.359627] #PF error: [normal kernel read fault]
      kernel: [  590.359629] PGD 0 P4D 0
      kernel: [  590.359632] Oops: 0000 [#1] SMP PTI
      kernel: [  590.359634] CPU: 3 PID: 1458 Comm: v4l_id Not tainted 5.1.0-rc2+ #30
      kernel: [  590.359636] Hardware name: Dell Inc. OptiPlex 7 90/0HY9JP, BIOS A18 09/24/2013
      kernel: [  590.359641] RIP: 0010:usb_ifnum_to_if+0x6/0x60
      kernel: [  590.359643] Code: 5d 41 5e 41 5f 5d c3 48 83 c4
       10 b8 fa ff ff ff 5b 41 5c 41 5d 41 5e 41 5f 5d c3 b8 fa ff ff ff c3 0f 1f 00 6
      6 66 66 66 90 55 <48> 8b 97 e8 04 00 00 48 89 e5 48 85 d2 74 41 0f b6 4a 04 84 c
      9 74
      kernel: [  590.359645] RSP: 0018:ffffad3cc3c1fc00 EFLAGS: 00010246
      kernel: [  590.359646] RAX: 0000000000000000 RBX: ffff8ded b1f3c000 RCX: 1f377e4500000000
      kernel: [  590.359648] RDX: ffff8dedfa3a6b50 RSI: 00000000 00000000 RDI: 0000000000000000
      kernel: [  590.359649] RBP: ffffad3cc3c1fc28 R08: 00000000 8574acc2 R09: ffff8dedfa3a6b50
      kernel: [  590.359650] R10: 0000000000000001 R11: 00000000 00000000 R12: 0000000000000000
      kernel: [  590.359652] R13: ffff8dedb1f3f0f0 R14: ffffffff adcf7ec0 R15: 0000000000000000
      kernel: [  590.359654] FS:  00007f7917198540(0000) GS:ffff 8dee258c0000(0000) knlGS:0000000000000000
      kernel: [  590.359655] CS:  0010 DS: 0000 ES: 0000 CR0: 00 00000080050033
      kernel: [  590.359657] CR2: 00000000000004e8 CR3: 00000001 a388e002 CR4: 00000000000606e0
      kernel: [  590.359658] Call Trace:
      kernel: [  590.359664]  ? au0828_analog_stream_enable+0x2c/0x180
      kernel: [  590.359666]  au0828_v4l2_open+0xa4/0x110
      kernel: [  590.359670]  v4l2_open+0x8b/0x120
      kernel: [  590.359674]  chrdev_open+0xa6/0x1c0
      kernel: [  590.359676]  ? cdev_put.part.3+0x20/0x20
      kernel: [  590.359678]  do_dentry_open+0x1f6/0x360
      kernel: [  590.359681]  vfs_open+0x2f/0x40
      kernel: [  590.359684]  path_openat+0x299/0xc20
      kernel: [  590.359688]  do_filp_open+0x9b/0x110
      kernel: [  590.359695]  ? _raw_spin_unlock+0x27/0x40
      kernel: [  590.359697]  ? __alloc_fd+0xb2/0x160
      kernel: [  590.359700]  do_sys_open+0x1ba/0x260
      kernel: [  590.359702]  ? do_sys_open+0x1ba/0x260
      kernel: [  590.359712]  __x64_sys_openat+0x20/0x30
      kernel: [  590.359715]  do_syscall_64+0x5a/0x120
      kernel: [  590.359718]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      Signed-off-by: NShuah Khan <shuah@kernel.org>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a90ce66a
    • H
      media: stm32-dcmi: fix crash when subdev do not expose any formats · 2096b3ba
      Hugues Fruchet 提交于
      [ Upstream commit 33dfeb62e23c31619d2197850f7e8b50e8cc5466 ]
      
      Do not access sd_formats[] if num_of_sd_formats is zero, ie
      subdev sensor didn't expose any formats.
      Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2096b3ba
    • W
      audit: fix a memory leak bug · 6c21fa84
      Wenwen Wang 提交于
      [ Upstream commit 70c4cf17e445264453bc5323db3e50aa0ac9e81f ]
      
      In audit_rule_change(), audit_data_to_entry() is firstly invoked to
      translate the payload data to the kernel's rule representation. In
      audit_data_to_entry(), depending on the audit field type, an audit tree may
      be created in audit_make_tree(), which eventually invokes kmalloc() to
      allocate the tree.  Since this tree is a temporary tree, it will be then
      freed in the following execution, e.g., audit_add_rule() if the message
      type is AUDIT_ADD_RULE or audit_del_rule() if the message type is
      AUDIT_DEL_RULE. However, if the message type is neither AUDIT_ADD_RULE nor
      AUDIT_DEL_RULE, i.e., the default case of the switch statement, this
      temporary tree is not freed.
      
      To fix this issue, only allocate the tree when the type is AUDIT_ADD_RULE
      or AUDIT_DEL_RULE.
      Signed-off-by: NWenwen Wang <wang6495@umn.edu>
      Reviewed-by: NRichard Guy Briggs <rgb@redhat.com>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6c21fa84
    • A
      media: ov2659: make S_FMT succeed even if requested format doesn't match · 9fcfaab6
      Akinobu Mita 提交于
      [ Upstream commit bccb89cf9cd07a0690d519696a00c00a973b3fe4 ]
      
      This driver returns an error if unsupported media bus pixel code is
      requested by VIDIOC_SUBDEV_S_FMT.
      
      But according to Documentation/media/uapi/v4l/vidioc-subdev-g-fmt.rst,
      
      Drivers must not return an error solely because the requested format
      doesn't match the device capabilities. They must instead modify the
      format to match what the hardware can provide.
      
      So select default format code and return success in that case.
      
      This is detected by v4l2-compliance.
      
      Cc: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Acked-by: NLad, Prabhakar <prabhakar.csengg@gmail.com>
      Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9fcfaab6
    • H
      media: au0828: stop video streaming only when last user stops · e3a9d646
      Hans Verkuil 提交于
      [ Upstream commit f604f0f5afb88045944567f604409951b5eb6af8 ]
      
      If the application was streaming from both videoX and vbiX, and streaming
      from videoX was stopped, then the vbi streaming also stopped.
      
      The cause being that stop_streaming for video stopped the subdevs as well,
      instead of only doing that if dev->streaming_users reached 0.
      
      au0828_stop_vbi_streaming was also wrong since it didn't stop the subdevs
      at all when dev->streaming_users reached 0.
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Tested-by: NShuah Khan <shuah@kernel.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e3a9d646
    • J
      media: ov6650: Move v4l2_clk_get() to ov6650_video_probe() helper · 3ccd8912
      Janusz Krzysztofik 提交于
      [ Upstream commit ccdd85d518d8b9320ace1d87271f0ba2175f21fa ]
      
      In preparation for adding asynchronous subdevice support to the driver,
      don't acquire v4l2_clk from the driver .probe() callback as that may
      fail if the clock is provided by a bridge driver which may be not yet
      initialized.  Move the v4l2_clk_get() to ov6650_video_probe() helper
      which is going to be converted to v4l2_subdev_internal_ops.registered()
      callback, executed only when the bridge driver is ready.
      Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
      Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3ccd8912
    • P
      media: coda: clear error return value before picture run · 81a0b6ff
      Philipp Zabel 提交于
      [ Upstream commit bbeefa7357a648afe70e7183914c87c3878d528d ]
      
      The error return value is not written by some firmware codecs, such as
      MPEG-2 decode on CodaHx4. Clear the error return value before starting
      the picture run to avoid misinterpreting unrelated values returned by
      sequence initialization as error return value.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      81a0b6ff
    • N
      dmaengine: at_xdmac: remove BUG_ON macro in tasklet · 83544b04
      Nicolas Ferre 提交于
      [ Upstream commit e2c114c06da2d9ffad5b16690abf008d6696f689 ]
      
      Even if this case shouldn't happen when controller is properly programmed,
      it's still better to avoid dumping a kernel Oops for this.
      As the sequence may happen only for debugging purposes, log the error and
      just finish the tasklet call.
      Signed-off-by: NNicolas Ferre <nicolas.ferre@microchip.com>
      Acked-by: NLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: NVinod Koul <vkoul@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      83544b04
    • R
      perf/arm-cci: Remove broken race mitigation · bfb9e836
      Robin Murphy 提交于
      [ Upstream commit 0d2e2a82d4de298d006bf8eddc86829e3c7da820 ]
      
      Uncore PMU drivers face an awkward cyclic dependency wherein:
      
       - They have to pick a valid online CPU to associate with before
         registering the PMU device, since it will get exposed to userspace
         immediately.
       - The PMU registration has to be be at least partly complete before
         hotplug events can be handled, since trying to migrate an
         uninitialised context would be bad.
       - The hotplug handler has to be ready as soon as a CPU is chosen, lest
         it go offline without the user-visible cpumask value getting updated.
      
      The arm-cci driver has tried to solve this by using get_cpu() to pick
      the current CPU and prevent it from disappearing while both
      registrations are performed, but that results in taking mutexes with
      preemption disabled, which makes certain configurations very unhappy:
      
      [ 1.983337] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:2004
      [ 1.983340] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
      [ 1.983342] Preemption disabled at:
      [ 1.983353] [<ffffff80089801f4>] cci_pmu_probe+0x1dc/0x488
      [ 1.983360] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.20-rt8-yocto-preempt-rt #1
      [ 1.983362] Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
      [ 1.983364] Call trace:
      [ 1.983369] dump_backtrace+0x0/0x158
      [ 1.983372] show_stack+0x24/0x30
      [ 1.983378] dump_stack+0x80/0xa4
      [ 1.983383] ___might_sleep+0x138/0x160
      [ 1.983386] __might_sleep+0x58/0x90
      [ 1.983391] __rt_mutex_lock_state+0x30/0xc0
      [ 1.983395] _mutex_lock+0x24/0x30
      [ 1.983400] perf_pmu_register+0x2c/0x388
      [ 1.983404] cci_pmu_probe+0x2bc/0x488
      [ 1.983409] platform_drv_probe+0x58/0xa8
      
      It is not feasible to resolve all the possible races outside of the perf
      core itself, so address the immediate bug by following the example of
      nearly every other PMU driver and not even trying to do so. Registering
      the hotplug notifier first should minimise the window in which things
      can go wrong, so that's about as much as we can reasonably do here. This
      also revealed an additional race in assigning the global pointer too
      late relative to the hotplug notifier, which gets fixed in the process.
      Reported-by: NLi, Meng <Meng.Li@windriver.com>
      Tested-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
      Reviewed-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bfb9e836
    • D
      clk: rockchip: undo several noc and special clocks as critical on rk3288 · 2d1df7fa
      Douglas Anderson 提交于
      [ Upstream commit f4033db5b84ebe4b32c25ba2ed65ab20b628996a ]
      
      This is mostly a revert of commit 55bb6a63 ("clk: rockchip: mark
      noc and some special clk as critical on rk3288") except that we're
      keeping "pmu_hclk_otg0" as critical still.
      
      NOTE: turning these clocks off doesn't seem to do a whole lot in terms
      of power savings (checking the power on the logic rail).  It appears
      to save maybe 1-2mW.  ...but still it seems like we should turn the
      clocks off if they aren't needed.
      
      About "pmu_hclk_otg0" (the one clock from the original commit we're
      still keeping critical) from an email thread:
      
      > pmu ahb clock
      >
      > Function: Clock to pmu module when hibernation and/or ADP is
      > enabled. Must be greater than or equal to 30 MHz.
      >
      > If the SOC design does not support hibernation/ADP function, only have
      > hclk_otg, this clk can be switched according to the usage of otg.
      > If the SOC design support hibernation/ADP, has two clocks, hclk_otg and
      > pmu_hclk_otg0.
      > Hclk_otg belongs to the closed part of otg logic, which can be switched
      > according to the use of otg.
      >
      > pmu_hclk_otg0 belongs to the always on part.
      >
      > As for whether pmu_hclk_otg0 can be turned off when otg is not in use,
      > we have not tested. IC suggest make pmu_hclk_otg0 always on.
      
      For the rest of the clocks:
      
      atclk: No documentation about this clock other than that it goes to
      the CPU.  CPU functions fine without it on.  Maybe needed for JTAG?
      
      jtag: Presumably this clock is only needed if you're debugging with
      JTAG.  It doesn't seem like it makes sense to waste power for every
      rk3288 user.  In any case to do JTAG you'd need private patches to
      adjust the pinctrl the mux the JTAG out anyway.
      
      pclk_dbg, pclk_core_niu: On veyron Chromebooks we turn these two
      clocks on only during kernel panics in order to access some coresight
      registers.  Since nothing in the upstream kernel does this we should
      be able to leave them off safely.  Maybe also needed for JTAG?
      
      hsicphy12m_xin12m: There is no indication of why this clock would need
      to be turned on for boards that don't use HSIC.
      
      pclk_ddrupctl[0-1], pclk_publ0[0-1]: On veyron Chromebooks we turn
      these 4 clocks on only when doing DDR transitions and they are off
      otherwise.  I see no reason why they'd need to be on in the upstream
      kernel which doesn't support DDRFreq.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Reviewed-by: NElaine Zhang <zhangqing@rock-chips.com>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2d1df7fa
    • W
      pinctrl: samsung: fix leaked of_node references · 86a1de9c
      Wen Yang 提交于
      [ Upstream commit 44b9f86cd41db6c522effa5aec251d664a52fbc0 ]
      
      The call to of_find_compatible_node returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/pinctrl/samsung/pinctrl-exynos-arm.c:76:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 66, but without a corresponding object release within this function.
      ./drivers/pinctrl/samsung/pinctrl-exynos-arm.c:82:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 66, but without a corresponding object release within this function.
      Signed-off-by: NWen Yang <wen.yang99@zte.com.cn>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Tomasz Figa <tomasz.figa@gmail.com>
      Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
      Cc: Kukjin Kim <kgene@kernel.org>
      Cc: linux-samsung-soc@vger.kernel.org
      Cc: linux-gpio@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      86a1de9c
    • W
      pinctrl: pistachio: fix leaked of_node references · c3933fd4
      Wen Yang 提交于
      [ Upstream commit 44a4455ac2c6b0981eace683a2b6eccf47689022 ]
      
      The call to of_get_child_by_name returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/pinctrl/pinctrl-pistachio.c:1422:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1360, but without a corresponding object release within this function.
      Signed-off-by: NWen Yang <wen.yang99@zte.com.cn>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: linux-gpio@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c3933fd4
    • H
      HID: logitech-hidpp: use RAP instead of FAP to get the protocol version · 12e7faac
      Hans de Goede 提交于
      [ Upstream commit 096377525cdb8251e4656085efc988bdf733fb4c ]
      
      According to the logitech_hidpp_2.0_specification_draft_2012-06-04.pdf doc:
      https://lekensteyn.nl/files/logitech/logitech_hidpp_2.0_specification_draft_2012-06-04.pdf
      
      We should use a register-access-protocol request using the short input /
      output report ids. This is necessary because 27MHz HID++ receivers have
      a max-packetsize on their HIP++ endpoint of 8, so they cannot support
      long reports. Using a feature-access-protocol request (which is always
      long or very-long) with these will cause a timeout error, followed by
      the hidpp driver treating the device as not being HID++ capable.
      
      This commit fixes this by switching to using a rap request to get the
      protocol version.
      
      Besides being tested with a (046d:c517) 27MHz receiver with various
      27MHz keyboards and mice, this has also been tested to not cause
      regressions on a non-unifying dual-HID++ nano receiver (046d:c534) with
      k270 and m185 HID++-2.0 devices connected and on a unifying/dj receiver
      (046d:c52b) with a HID++-2.0 Logitech Rechargeable Touchpad T650.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      12e7faac
    • B
      Bluetooth: hci_qca: Give enough time to ROME controller to bootup. · 1eafabe1
      Balakrishna Godavarthi 提交于
      [ Upstream commit 7f09d5a6c33be66a5ca19bf9dd1c2d90c5dfcf0d ]
      
      This patch enables enough time to ROME controller to bootup
      after we bring the enable pin out of reset.
      
      Fixes: 05ba533c ("Bluetooth: hci_qca: Add serdev support").
      Signed-off-by: NBalakrishna Godavarthi <bgodavar@codeaurora.org>
      Reviewed-by: NRocky Liao <rjliao@codeaurora.org>
      Tested-by: NRocky Liao <rjliao@codeaurora.org>
      Tested-by: NClaire Chang <tientzu@chromium.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1eafabe1
    • P
      mm/uaccess: Use 'unsigned long' to placate UBSAN warnings on older GCC versions · 189b396a
      Peter Zijlstra 提交于
      [ Upstream commit 29da93fea3ea39ab9b12270cc6be1b70ef201c9e ]
      
      Randy reported objtool triggered on his (GCC-7.4) build:
      
        lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x315: call to __ubsan_handle_add_overflow() with UACCESS enabled
        lib/strnlen_user.o: warning: objtool: strnlen_user()+0x337: call to __ubsan_handle_sub_overflow() with UACCESS enabled
      
      This is due to UBSAN generating signed-overflow-UB warnings where it
      should not. Prior to GCC-8 UBSAN ignored -fwrapv (which the kernel
      uses through -fno-strict-overflow).
      
      Make the functions use 'unsigned long' throughout.
      Reported-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: luto@kernel.org
      Link: http://lkml.kernel.org/r/20190424072208.754094071@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      189b396a
    • J
      x86/mm: Remove in_nmi() warning from 64-bit implementation of vmalloc_fault() · f46ae1cd
      Jiri Kosina 提交于
      [ Upstream commit a65c88e16f32aa9ef2e8caa68ea5c29bd5eb0ff0 ]
      
      In-NMI warnings have been added to vmalloc_fault() via:
      
        ebc8827f ("x86: Barf when vmalloc and kmemcheck faults happen in NMI")
      
      back in the time when our NMI entry code could not cope with nested NMIs.
      
      These days, it's perfectly fine to take a fault in NMI context and we
      don't have to care about the fact that IRET from the fault handler might
      cause NMI nesting.
      
      This warning has already been removed from 32-bit implementation of
      vmalloc_fault() in:
      
        6863ea0c ("x86/mm: Remove in_nmi() warning from vmalloc_fault()")
      
      but the 64-bit version was omitted.
      
      Remove the bogus warning also from 64-bit implementation of vmalloc_fault().
      Reported-by: NNicolai Stange <nstange@suse.de>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 6863ea0c ("x86/mm: Remove in_nmi() warning from vmalloc_fault()")
      Link: http://lkml.kernel.org/r/nycvar.YFH.7.76.1904240902280.9803@cbobk.fhfr.pmSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f46ae1cd
    • S
      smpboot: Place the __percpu annotation correctly · 3dc1e338
      Sebastian Andrzej Siewior 提交于
      [ Upstream commit d4645d30b50d1691c26ff0f8fa4e718b08f8d3bb ]
      
      The test robot reported a wrong assignment of a per-CPU variable which
      it detected by using sparse and sent a report. The assignment itself is
      correct. The annotation for sparse was wrong and hence the report.
      The first pointer is a "normal" pointer and points to the per-CPU memory
      area. That means that the __percpu annotation has to be moved.
      
      Move the __percpu annotation to pointer which points to the per-CPU
      area. This change affects only the sparse tool (and is ignored by the
      compiler).
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: f97f8f06 ("smpboot: Provide infrastructure for percpu hotplug threads")
      Link: http://lkml.kernel.org/r/20190424085253.12178-1-bigeasy@linutronix.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3dc1e338
    • K
      x86/build: Move _etext to actual end of .text · 0fcb3cd5
      Kees Cook 提交于
      [ Upstream commit 392bef709659abea614abfe53cf228e7a59876a4 ]
      
      When building x86 with Clang LTO and CFI, CFI jump regions are
      automatically added to the end of the .text section late in linking. As a
      result, the _etext position was being labelled before the appended jump
      regions, causing confusion about where the boundaries of the executable
      region actually are in the running kernel, and broke at least the fault
      injection code. This moves the _etext mark to outside (and immediately
      after) the .text area, as it already the case on other architectures
      (e.g. arm64, arm).
      Reported-and-tested-by: NSami Tolvanen <samitolvanen@google.com>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20190423183827.GA4012@beastSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0fcb3cd5
    • F
      vfio-ccw: Release any channel program when releasing/removing vfio-ccw mdev · 58a0c219
      Farhan Ali 提交于
      [ Upstream commit b49bdc8602b7c9c7a977758bee4125683f73e59f ]
      
      When releasing the vfio-ccw mdev, we currently do not release
      any existing channel program and its pinned pages. This can
      lead to the following warning:
      
      [1038876.561565] WARNING: CPU: 2 PID: 144727 at drivers/vfio/vfio_iommu_type1.c:1494 vfio_sanity_check_pfn_list+0x40/0x70 [vfio_iommu_type1]
      
      ....
      
      1038876.561921] Call Trace:
      [1038876.561935] ([<00000009897fb870>] 0x9897fb870)
      [1038876.561949]  [<000003ff8013bf62>] vfio_iommu_type1_detach_group+0xda/0x2f0 [vfio_iommu_type1]
      [1038876.561965]  [<000003ff8007b634>] __vfio_group_unset_container+0x64/0x190 [vfio]
      [1038876.561978]  [<000003ff8007b87e>] vfio_group_put_external_user+0x26/0x38 [vfio]
      [1038876.562024]  [<000003ff806fc608>] kvm_vfio_group_put_external_user+0x40/0x60 [kvm]
      [1038876.562045]  [<000003ff806fcb9e>] kvm_vfio_destroy+0x5e/0xd0 [kvm]
      [1038876.562065]  [<000003ff806f63fc>] kvm_put_kvm+0x2a4/0x3d0 [kvm]
      [1038876.562083]  [<000003ff806f655e>] kvm_vm_release+0x36/0x48 [kvm]
      [1038876.562098]  [<00000000003c2dc4>] __fput+0x144/0x228
      [1038876.562113]  [<000000000016ee82>] task_work_run+0x8a/0xd8
      [1038876.562125]  [<000000000014c7a8>] do_exit+0x5d8/0xd90
      [1038876.562140]  [<000000000014d084>] do_group_exit+0xc4/0xc8
      [1038876.562155]  [<000000000015c046>] get_signal+0x9ae/0xa68
      [1038876.562169]  [<0000000000108d66>] do_signal+0x66/0x768
      [1038876.562185]  [<0000000000b9e37e>] system_call+0x1ea/0x2d8
      [1038876.562195] 2 locks held by qemu-system-s39/144727:
      [1038876.562205]  #0: 00000000537abaf9 (&container->group_lock){++++}, at: __vfio_group_unset_container+0x3c/0x190 [vfio]
      [1038876.562230]  #1: 00000000670008b5 (&iommu->lock){+.+.}, at: vfio_iommu_type1_detach_group+0x36/0x2f0 [vfio_iommu_type1]
      [1038876.562250] Last Breaking-Event-Address:
      [1038876.562262]  [<000003ff8013aa24>] vfio_sanity_check_pfn_list+0x3c/0x70 [vfio_iommu_type1]
      [1038876.562272] irq event stamp: 4236481
      [1038876.562287] hardirqs last  enabled at (4236489): [<00000000001cee7a>] console_unlock+0x6d2/0x740
      [1038876.562299] hardirqs last disabled at (4236496): [<00000000001ce87e>] console_unlock+0xd6/0x740
      [1038876.562311] softirqs last  enabled at (4234162): [<0000000000b9fa1e>] __do_softirq+0x556/0x598
      [1038876.562325] softirqs last disabled at (4234153): [<000000000014e4cc>] irq_exit+0xac/0x108
      [1038876.562337] ---[ end trace 6c96d467b1c3ca06 ]---
      
      Similarly we do not free the channel program when we are removing
      the vfio-ccw device. Let's fix this by resetting the device and freeing
      the channel program and pinned pages in the release path. For the remove
      path we can just quiesce the device, since in the remove path the mediated
      device is going away for good and so we don't need to do a full reset.
      Signed-off-by: NFarhan Ali <alifm@linux.ibm.com>
      Message-Id: <ae9f20dc8873f2027f7b3c5d2aaa0bdfe06850b8.1554756534.git.alifm@linux.ibm.com>
      Acked-by: NEric Farman <farman@linux.ibm.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      58a0c219
    • F
      vfio-ccw: Do not call flush_workqueue while holding the spinlock · 8c1c7810
      Farhan Ali 提交于
      [ Upstream commit cea5dde42a83b5f0a039da672f8686455936b8d8 ]
      
      Currently we call flush_workqueue while holding the subchannel
      spinlock. But flush_workqueue function can go to sleep, so
      do not call the function while holding the spinlock.
      
      Fixes the following bug:
      
      [  285.203430] BUG: scheduling while atomic: bash/14193/0x00000002
      [  285.203434] INFO: lockdep is turned off.
      ....
      [  285.203485] Preemption disabled at:
      [  285.203488] [<000003ff80243e5c>] vfio_ccw_sch_quiesce+0xbc/0x120 [vfio_ccw]
      [  285.203496] CPU: 7 PID: 14193 Comm: bash Tainted: G        W
      ....
      [  285.203504] Call Trace:
      [  285.203510] ([<0000000000113772>] show_stack+0x82/0xd0)
      [  285.203514]  [<0000000000b7a102>] dump_stack+0x92/0xd0
      [  285.203518]  [<000000000017b8be>] __schedule_bug+0xde/0xf8
      [  285.203524]  [<0000000000b95b5a>] __schedule+0x7a/0xc38
      [  285.203528]  [<0000000000b9678a>] schedule+0x72/0xb0
      [  285.203533]  [<0000000000b9bfbc>] schedule_timeout+0x34/0x528
      [  285.203538]  [<0000000000b97608>] wait_for_common+0x118/0x1b0
      [  285.203544]  [<0000000000166d6a>] flush_workqueue+0x182/0x548
      [  285.203550]  [<000003ff80243e6e>] vfio_ccw_sch_quiesce+0xce/0x120 [vfio_ccw]
      [  285.203556]  [<000003ff80245278>] vfio_ccw_mdev_reset+0x38/0x70 [vfio_ccw]
      [  285.203562]  [<000003ff802458b0>] vfio_ccw_mdev_remove+0x40/0x78 [vfio_ccw]
      [  285.203567]  [<000003ff801a499c>] mdev_device_remove_ops+0x3c/0x80 [mdev]
      [  285.203573]  [<000003ff801a4d5c>] mdev_device_remove+0xc4/0x130 [mdev]
      [  285.203578]  [<000003ff801a5074>] remove_store+0x6c/0xa8 [mdev]
      [  285.203582]  [<000000000046f494>] kernfs_fop_write+0x14c/0x1f8
      [  285.203588]  [<00000000003c1530>] __vfs_write+0x38/0x1a8
      [  285.203593]  [<00000000003c187c>] vfs_write+0xb4/0x198
      [  285.203597]  [<00000000003c1af2>] ksys_write+0x5a/0xb0
      [  285.203601]  [<0000000000b9e270>] system_call+0xdc/0x2d8
      Signed-off-by: NFarhan Ali <alifm@linux.ibm.com>
      Reviewed-by: NEric Farman <farman@linux.ibm.com>
      Reviewed-by: NPierre Morel <pmorel@linux.ibm.com>
      Message-Id: <626bab8bb2958ae132452e1ddaf1b20882ad5a9d.1554756534.git.alifm@linux.ibm.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8c1c7810
    • P
      RDMA/cma: Consider scope_id while binding to ipv6 ll address · e0d25d17
      Parav Pandit 提交于
      [ Upstream commit 5d7ed2f27bbd482fd29e6b2e204b1a1ee8a0b268 ]
      
      When two netdev have same link local addresses (such as vlan and non
      vlan), two rdma cm listen id should be able to bind to following different
      addresses.
      
      listener-1: addr=lla, scope_id=A, port=X
      listener-2: addr=lla, scope_id=B, port=X
      
      However while comparing the addresses only addr and port are considered,
      due to which 2nd listener fails to listen.
      
      In below example of two listeners, 2nd listener is failing with address in
      use error.
      
      $ rping -sv -a fe80::268a:7ff:feb3:d113%ens2f1 -p 4545&
      
      $ rping -sv -a fe80::268a:7ff:feb3:d113%ens2f1.200 -p 4545
      rdma_bind_addr: Address already in use
      
      To overcome this, consider the scope_ids as well which forms the accurate
      IPv6 link local address.
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Reviewed-by: NDaniel Jurgens <danielj@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e0d25d17
    • A
      bcache: avoid clang -Wunintialized warning · 06740892
      Arnd Bergmann 提交于
      [ Upstream commit 78d4eb8ad9e1d413449d1b7a060f50b6efa81ebd ]
      
      clang has identified a code path in which it thinks a
      variable may be unused:
      
      drivers/md/bcache/alloc.c:333:4: error: variable 'bucket' is used uninitialized whenever 'if' condition is false
            [-Werror,-Wsometimes-uninitialized]
                              fifo_pop(&ca->free_inc, bucket);
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/md/bcache/util.h:219:27: note: expanded from macro 'fifo_pop'
       #define fifo_pop(fifo, i)       fifo_pop_front(fifo, (i))
                                      ^~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/md/bcache/util.h:189:6: note: expanded from macro 'fifo_pop_front'
              if (_r) {                                                       \
                  ^~
      drivers/md/bcache/alloc.c:343:46: note: uninitialized use occurs here
                              allocator_wait(ca, bch_allocator_push(ca, bucket));
                                                                        ^~~~~~
      drivers/md/bcache/alloc.c:287:7: note: expanded from macro 'allocator_wait'
                      if (cond)                                               \
                          ^~~~
      drivers/md/bcache/alloc.c:333:4: note: remove the 'if' if its condition is always true
                              fifo_pop(&ca->free_inc, bucket);
                              ^
      drivers/md/bcache/util.h:219:27: note: expanded from macro 'fifo_pop'
       #define fifo_pop(fifo, i)       fifo_pop_front(fifo, (i))
                                      ^
      drivers/md/bcache/util.h:189:2: note: expanded from macro 'fifo_pop_front'
              if (_r) {                                                       \
              ^
      drivers/md/bcache/alloc.c:331:15: note: initialize the variable 'bucket' to silence this warning
                              long bucket;
                                         ^
      
      This cannot happen in practice because we only enter the loop
      if there is at least one element in the list.
      
      Slightly rearranging the code makes this clearer to both the
      reader and the compiler, which avoids the warning.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NColy Li <colyli@suse.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      06740892
    • C
      bcache: add failure check to run_cache_set() for journal replay · 330b6798
      Coly Li 提交于
      [ Upstream commit ce3e4cfb59cb382f8e5ce359238aa580d4ae7778 ]
      
      Currently run_cache_set() has no return value, if there is failure in
      bch_journal_replay(), the caller of run_cache_set() has no idea about
      such failure and just continue to execute following code after
      run_cache_set().  The internal failure is triggered inside
      bch_journal_replay() and being handled in async way. This behavior is
      inefficient, while failure handling inside bch_journal_replay(), cache
      register code is still running to start the cache set. Registering and
      unregistering code running as same time may introduce some rare race
      condition, and make the code to be more hard to be understood.
      
      This patch adds return value to run_cache_set(), and returns -EIO if
      bch_journal_rreplay() fails. Then caller of run_cache_set() may detect
      such failure and stop registering code flow immedidately inside
      register_cache_set().
      
      If journal replay fails, run_cache_set() can report error immediately
      to register_cache_set(). This patch makes the failure handling for
      bch_journal_replay() be in synchronized way, easier to understand and
      debug, and avoid poetential race condition for register-and-unregister
      in same time.
      Signed-off-by: NColy Li <colyli@suse.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      330b6798
    • T
      bcache: fix failure in journal relplay · cd83c788
      Tang Junhui 提交于
      [ Upstream commit 631207314d88e9091be02fbdd1fdadb1ae2ed79a ]
      
      journal replay failed with messages:
      Sep 10 19:10:43 ceph kernel: bcache: error on
      bb379a64-e44e-4812-b91d-a5599871a3b1: bcache: journal entries
      2057493-2057567 missing! (replaying 2057493-20766016), disabling
      caching
      
      The reason is in journal_reclaim(), when discard is enabled, we send
      discard command and reclaim those journal buckets whose seq is old
      than the last_seq_now, but before we write a journal with last_seq_now,
      the machine is restarted, so the journal with the last_seq_now is not
      written to the journal bucket, and the last_seq_wrote in the newest
      journal is old than last_seq_now which we expect to be, so when we doing
      replay, journals from last_seq_wrote to last_seq_now are missing.
      
      It's hard to write a journal immediately after journal_reclaim(),
      and it harmless if those missed journal are caused by discarding
      since those journals are already wrote to btree node. So, if miss
      seqs are started from the beginning journal, we treat it as normal,
      and only print a message to show the miss journal, and point out
      it maybe caused by discarding.
      
      Patch v2 add a judgement condition to ignore the missed journal
      only when discard enabled as Coly suggested.
      
      (Coly Li: rebase the patch with other changes in bch_journal_replay())
      Signed-off-by: NTang Junhui <tang.junhui.linux@gmail.com>
      Tested-by: NDennis Schridde <devurandom@gmx.net>
      Signed-off-by: NColy Li <colyli@suse.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cd83c788
    • C
      bcache: return error immediately in bch_journal_replay() · 29b166da
      Coly Li 提交于
      [ Upstream commit 68d10e6979a3b59e3cd2e90bfcafed79c4cf180a ]
      
      When failure happens inside bch_journal_replay(), calling
      cache_set_err_on() and handling the failure in async way is not a good
      idea. Because after bch_journal_replay() returns, registering code will
      continue to execute following steps, and unregistering code triggered
      by cache_set_err_on() is running in same time. First it is unnecessary
      to handle failure and unregister cache set in an async way, second there
      might be potential race condition to run register and unregister code
      for same cache set.
      
      So in this patch, if failure happens in bch_journal_replay(), we don't
      call cache_set_err_on(), and just print out the same error message to
      kernel message buffer, then return -EIO immediately caller. Then caller
      can detect such failure and handle it in synchrnozied way.
      Signed-off-by: NColy Li <colyli@suse.de>
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      29b166da
    • S
      bcache: avoid potential memleak of list of journal_replay(s) in the CACHE_SYNC... · 8034a6b8
      Shenghui Wang 提交于
      bcache: avoid potential memleak of list of journal_replay(s) in the CACHE_SYNC branch of run_cache_set
      
      [ Upstream commit 95f18c9d1310730d075499a75aaf13bcd60405a7 ]
      
      In the CACHE_SYNC branch of run_cache_set(), LIST_HEAD(journal) is used
      to collect journal_replay(s) and filled by bch_journal_read().
      
      If all goes well, bch_journal_replay() will release the list of
      jounal_replay(s) at the end of the branch.
      
      If something goes wrong, code flow will jump to the label "err:" and leave
      the list unreleased.
      
      This patch will release the list of journal_replay(s) in the case of
      error detected.
      
      v1 -> v2:
      * Move the release code to the location after label 'err:' to
        simply the change.
      Signed-off-by: NShenghui Wang <shhuiw@foxmail.com>
      Signed-off-by: NColy Li <colyli@suse.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8034a6b8
    • C
      crypto: sun4i-ss - Fix invalid calculation of hash end · e82df5f1
      Corentin Labbe 提交于
      [ Upstream commit f87391558acf816b48f325a493d81d45dec40da0 ]
      
      When nbytes < 4, end is wronlgy set to a negative value which, due to
      uint, is then interpreted to a large value leading to a deadlock in the
      following code.
      
      This patch fix this problem.
      
      Fixes: 6298e948 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
      Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e82df5f1
    • S
      nvme-rdma: fix a NULL deref when an admin connect times out · 213e1523
      Sagi Grimberg 提交于
      [ Upstream commit 1007709d7d06fab09bf2d007657575958676282b ]
      
      If we timeout the admin startup sequence we might not yet have
      an I/O tagset allocated which causes the teardown sequence to crash.
      Make nvme_tcp_teardown_io_queues safe by not iterating inflight tags
      if the tagset wasn't allocated.
      
      Fixes: 4c174e636674 ("nvme-rdma: fix timeout handler")
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      213e1523
    • S
      nvme: set 0 capacity if namespace block size exceeds PAGE_SIZE · c24860f4
      Sagi Grimberg 提交于
      [ Upstream commit 01fa017484ad98fccdeaab32db0077c574b6bd6f ]
      
      If our target exposed a namespace with a block size that is greater
      than PAGE_SIZE, set 0 capacity on the namespace as we do not support it.
      
      This issue encountered when the nvmet namespace was backed by a tempfile.
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      Reviewed-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c24860f4
    • K
      net: cw1200: fix a NULL pointer dereference · 31de7f1d
      Kangjie Lu 提交于
      [ Upstream commit 0ed2a005347400500a39ea7c7318f1fea57fb3ca ]
      
      In case create_singlethread_workqueue fails, the fix free the
      hardware and returns NULL to avoid NULL pointer dereference.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      31de7f1d
    • A
      rsi: Fix NULL pointer dereference in kmalloc · eacec436
      Aditya Pakki 提交于
      [ Upstream commit d5414c2355b20ea8201156d2e874265f1cb0d775 ]
      
      kmalloc can fail in rsi_register_rates_channels but memcpy still attempts
      to write to channels. The patch replaces these calls with kmemdup and
      passes the error upstream.
      Signed-off-by: NAditya Pakki <pakki001@umn.edu>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      eacec436
    • D
      mwifiex: prevent an array overflow · 9d54cca8
      Dan Carpenter 提交于
      [ Upstream commit b4c35c17227fe437ded17ce683a6927845f8c4a4 ]
      
      The "rate_index" is only used as an index into the phist_data->rx_rate[]
      array in the mwifiex_hist_data_set() function.  That array has
      MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some
      debugfs information.  The "rate_index" variable comes from the network
      skb->data[] and it is a u8 so it's in the 0-255 range.  We need to cap
      it to prevent an array overflow.
      
      Fixes: cbf6e055 ("mwifiex: add rx histogram statistics support")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9d54cca8
    • D
      ASoC: fsl_sai: Update is_slave_mode with correct value · c2582f21
      Daniel Baluta 提交于
      [ Upstream commit ddb351145a967ee791a0fb0156852ec2fcb746ba ]
      
      is_slave_mode defaults to false because sai structure
      that contains it is kzalloc'ed.
      
      Anyhow, if we decide to set the following configuration
      SAI slave -> SAI master, is_slave_mode will remain set on true
      although SAI being master it should be set to false.
      
      Fix this by updating is_slave_mode for each call of
      fsl_sai_set_dai_fmt.
      Signed-off-by: NDaniel Baluta <daniel.baluta@nxp.com>
      Acked-by: NNicolin Chen <nicoleotsuka@gmail.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c2582f21
    • K
      slimbus: fix a potential NULL pointer dereference in of_qcom_slim_ngd_register · 67d812fb
      Kangjie Lu 提交于
      [ Upstream commit 06d5d6b7f9948a89543e1160ef852d57892c750d ]
      
      In case platform_device_alloc fails, the fix returns an error
      code to avoid the NULL pointer dereference.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      67d812fb
    • D
      libbpf: fix samples/bpf build failure due to undefined UINT32_MAX · 0cbef22f
      Daniel T. Lee 提交于
      [ Upstream commit 32e621e55496a0009f44fe4914cd4a23cade4984 ]
      
      Currently, building bpf samples will cause the following error.
      
          ./tools/lib/bpf/bpf.h:132:27: error: 'UINT32_MAX' undeclared here (not in a function) ..
           #define BPF_LOG_BUF_SIZE (UINT32_MAX >> 8) /* verifier maximum in kernels <= 5.1 */
                                     ^
          ./samples/bpf/bpf_load.h:31:25: note: in expansion of macro 'BPF_LOG_BUF_SIZE'
           extern char bpf_log_buf[BPF_LOG_BUF_SIZE];
                                   ^~~~~~~~~~~~~~~~
      
      Due to commit 4519efa6f8ea ("libbpf: fix BPF_LOG_BUF_SIZE off-by-one error")
      hard-coded size of BPF_LOG_BUF_SIZE has been replaced with UINT32_MAX which is
      defined in <stdint.h> header.
      
      Even with this change, bpf selftests are running fine since these are built
      with clang and it includes header(-idirafter) from clang/6.0.0/include.
      (it has <stdint.h>)
      
          clang -I. -I./include/uapi -I../../../include/uapi -idirafter /usr/local/include -idirafter /usr/include \
          -idirafter /usr/lib/llvm-6.0/lib/clang/6.0.0/include -idirafter /usr/include/x86_64-linux-gnu \
          -Wno-compare-distinct-pointer-types -O2 -target bpf -emit-llvm -c progs/test_sysctl_prog.c -o - | \
          llc -march=bpf -mcpu=generic  -filetype=obj -o /linux/tools/testing/selftests/bpf/test_sysctl_prog.o
      
      But bpf samples are compiled with GCC, and it only searches and includes
      headers declared at the target file. As '#include <stdint.h>' hasn't been
      declared in tools/lib/bpf/bpf.h, it causes build failure of bpf samples.
      
          gcc -Wp,-MD,./samples/bpf/.sockex3_user.o.d -Wall -Wmissing-prototypes -Wstrict-prototypes \
          -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -I./tools/lib/ -I./tools/testing/selftests/bpf/ \
          -I./tools/  lib/ -I./tools/include -I./tools/perf -c -o ./samples/bpf/sockex3_user.o ./samples/bpf/sockex3_user.c;
      
      This commit add declaration of '#include <stdint.h>' to tools/lib/bpf/bpf.h
      to fix this problem.
      Signed-off-by: NDaniel T. Lee <danieltimlee@gmail.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0cbef22f
    • S
      mac80211/cfg80211: update bss channel on channel switch · ca5b9d63
      Sergey Matyukevich 提交于
      [ Upstream commit 5dc8cdce1d722c733f8c7af14c5fb595cfedbfa8 ]
      
      FullMAC STAs have no way to update bss channel after CSA channel switch
      completion. As a result, user-space tools may provide inconsistent
      channel info. For instance, consider the following two commands:
      $ sudo iw dev wlan0 link
      $ sudo iw dev wlan0 info
      The latter command gets channel info from the hardware, so most probably
      its output will be correct. However the former command gets channel info
      from scan cache, so its output will contain outdated channel info.
      In fact, current bss channel info will not be updated until the
      next [re-]connect.
      
      Note that mac80211 STAs have a workaround for this, but it requires
      access to internal cfg80211 data, see ieee80211_chswitch_work:
      
      	/* XXX: shouldn't really modify cfg80211-owned data! */
      	ifmgd->associated->channel = sdata->csa_chandef.chan;
      
      This patch suggests to convert mac80211 workaround into cfg80211 behavior
      and to update current bss channel in cfg80211_ch_switch_notify.
      Signed-off-by: NSergey Matyukevich <sergey.matyukevich.os@quantenna.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ca5b9d63
    • S
      dmaengine: pl330: _stop: clear interrupt status · 1d057fef
      Sugar Zhang 提交于
      [ Upstream commit 2da254cc7908105a60a6bb219d18e8dced03dcb9 ]
      
      This patch kill instructs the DMAC to immediately terminate
      execution of a thread. and then clear the interrupt status,
      at last, stop generating interrupts for DMA_SEV. to guarantee
      the next dma start is clean. otherwise, one interrupt maybe leave
      to next start and make some mistake.
      
      we can reporduce the problem as follows:
      
      DMASEV: modify the event-interrupt resource, and if the INTEN sets
      function as interrupt, the DMAC will set irq<event_num> HIGH to
      generate interrupt. write INTCLR to clear interrupt.
      
      	DMA EXECUTING INSTRUCTS		DMA TERMINATE
      		|				|
      		|				|
      	       ...			      _stop
      		|				|
      		|			spin_lock_irqsave
      	     DMASEV				|
      		|				|
      		|			    mask INTEN
      		|				|
      		|			     DMAKILL
      		|				|
      		|			spin_unlock_irqrestore
      
      in above case, a interrupt was left, and if we unmask INTEN, the DMAC
      will set irq<event_num> HIGH to generate interrupt.
      
      to fix this, do as follows:
      
      	DMA EXECUTING INSTRUCTS		DMA TERMINATE
      		|				|
      		|				|
      	       ...			      _stop
      		|				|
      		|			spin_lock_irqsave
      	     DMASEV				|
      		|				|
      		|			     DMAKILL
      		|				|
      		|			   clear INTCLR
      		|			    mask INTEN
      		|				|
      		|			spin_unlock_irqrestore
      Signed-off-by: NSugar Zhang <sugar.zhang@rock-chips.com>
      Signed-off-by: NVinod Koul <vkoul@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1d057fef
    • A
      s390: qeth: address type mismatch warning · cadb16d9
      Arnd Bergmann 提交于
      [ Upstream commit 46b83629dede262315aa82179d105581f11763b6 ]
      
      clang produces a harmless warning for each use for the qeth_adp_supported
      macro:
      
      drivers/s390/net/qeth_l2_main.c:559:31: warning: implicit conversion from enumeration type 'enum qeth_ipa_setadp_cmd' to
            different enumeration type 'enum qeth_ipa_funcs' [-Wenum-conversion]
              if (qeth_adp_supported(card, IPA_SETADP_SET_PROMISC_MODE))
                  ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/s390/net/qeth_core.h:179:41: note: expanded from macro 'qeth_adp_supported'
              qeth_is_ipa_supported(&c->options.adp, f)
              ~~~~~~~~~~~~~~~~~~~~~                  ^
      
      Add a version of this macro that uses the correct types, and
      remove the unused qeth_adp_enabled() macro that has the same
      problem.
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cadb16d9