1. 31 5月, 2019 40 次提交
    • T
      timekeeping: Force upper bound for setting CLOCK_REALTIME · dc0f37b7
      Thomas Gleixner 提交于
      [ Upstream commit 7a8e61f8478639072d402a26789055a4a4de8f77 ]
      
      Several people reported testing failures after setting CLOCK_REALTIME close
      to the limits of the kernel internal representation in nanoseconds,
      i.e. year 2262.
      
      The failures are exposed in subsequent operations, i.e. when arming timers
      or when the advancing CLOCK_MONOTONIC makes the calculation of
      CLOCK_REALTIME overflow into negative space.
      
      Now people start to paper over the underlying problem by clamping
      calculations to the valid range, but that's just wrong because such
      workarounds will prevent detection of real issues as well.
      
      It is reasonable to force an upper bound for the various methods of setting
      CLOCK_REALTIME. Year 2262 is the absolute upper bound. Assume a maximum
      uptime of 30 years which is plenty enough even for esoteric embedded
      systems. That results in an upper bound of year 2232 for setting the time.
      
      Once that limit is reached in reality this limit is only a small part of
      the problem space. But until then this stops people from trying to paper
      over the problem at the wrong places.
      Reported-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
      Reported-by: NHongbo Yao <yaohongbo@huawei.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Stephen Boyd <sboyd@kernel.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1903231125480.2157@nanos.tec.linutronix.deSigned-off-by: NSasha Levin <sashal@kernel.org>
      dc0f37b7
    • A
      thunderbolt: Fix to check the return value of kmemdup · ee40c8a3
      Aditya Pakki 提交于
      [ Upstream commit fd21b79e541e4666c938a344f3ad2df74b4f5120 ]
      
      uuid in add_switch is allocted via kmemdup which can fail. The patch
      logs the error and cleans up the allocated memory for switch.
      Signed-off-by: NAditya Pakki <pakki001@umn.edu>
      Reviewed-by: NMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ee40c8a3
    • K
      thunderbolt: property: Fix a missing check of kzalloc · c8eecd65
      Kangjie Lu 提交于
      [ Upstream commit 6183d5a51866f3acdeeb66b75e87d44025b01a55 ]
      
      No check is enforced for the return value of kzalloc,
      which may lead to NULL-pointer dereference.
      
      The patch fixes this issue.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Reviewed-by: NMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c8eecd65
    • A
      efifb: Omit memory map check on legacy boot · 1de8f965
      Ard Biesheuvel 提交于
      [ Upstream commit c2999c281ea2d2ebbdfce96cecc7b52e2ae7c406 ]
      
      Since the following commit:
      
        38ac0287 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB")
      
      efifb_probe() checks its memory range via efi_mem_desc_lookup(),
      and this leads to a spurious error message:
      
         EFI_MEMMAP is not enabled
      
      at every boot on KVM.  This is quite annoying since the error message
      appears even if you set "quiet" boot option.
      
      Since this happens on legacy boot, which strangely enough exposes
      a EFI framebuffer via screen_info, let's double check that we are
      doing an EFI boot before attempting to access the EFI memory map.
      Reported-by: NTakashi Iwai <tiwai@suse.de>
      Tested-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20190328193429.21373-3-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1de8f965
    • E
      media: gspca: Kill URBs on USB device disconnect · 356f05fd
      Ezequiel Garcia 提交于
      [ Upstream commit 9b9ea7c2b57a0c9c3341fc6db039d1f7971a432e ]
      
      In order to prevent ISOC URBs from being infinitely resubmitted,
      the driver's USB disconnect handler must kill all the in-flight URBs.
      
      While here, change the URB packet status message to a debug level,
      to avoid spamming the console too much.
      
      This commit fixes a lockup caused by an interrupt storm coming
      from the URB completion handler.
      Signed-off-by: NEzequiel Garcia <ezequiel@collabora.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>
      356f05fd
    • D
      media: wl128x: prevent two potential buffer overflows · 2a9331ce
      Dan Carpenter 提交于
      [ Upstream commit 9c2ccc324b3a6cbc865ab8b3e1a09e93d3c8ade9 ]
      
      Smatch marks skb->data as untrusted so it warns that "evt_hdr->dlen"
      can copy up to 255 bytes and we only have room for two bytes.  Even
      if this comes from the firmware and we trust it, the new policy
      generally is just to fix it as kernel hardenning.
      
      I can't test this code so I tried to be very conservative.  I considered
      not allowing "evt_hdr->dlen == 1" because it doesn't initialize the
      whole variable but in the end I decided to allow it and manually
      initialized "asic_id" and "asic_ver" to zero.
      
      Fixes: e8454ff7 ("[media] drivers:media:radio: wl128x: FM Driver Common sources")
      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>
      2a9331ce
    • K
      media: video-mux: fix null pointer dereferences · 6b5693f2
      Kangjie Lu 提交于
      [ Upstream commit aeb0d0f581e2079868e64a2e5ee346d340376eae ]
      
      devm_kcalloc may fail and return a null pointer. The fix returns
      -ENOMEM upon failures to avoid null pointer dereferences.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Reviewed-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>
      6b5693f2
    • T
      kobject: Don't trigger kobject_uevent(KOBJ_REMOVE) twice. · bc75207a
      Tetsuo Handa 提交于
      [ Upstream commit c03a0fd0b609e2f5c669c2b7f27c8e1928e9196e ]
      
      syzbot is hitting use-after-free bug in uinput module [1]. This is because
      kobject_uevent(KOBJ_REMOVE) is called again due to commit 0f4dafc0
      ("Kobject: auto-cleanup on final unref") after memory allocation fault
      injection made kobject_uevent(KOBJ_REMOVE) from device_del() from
      input_unregister_device() fail, while uinput_destroy_device() is expecting
      that kobject_uevent(KOBJ_REMOVE) is not called after device_del() from
      input_unregister_device() completed.
      
      That commit intended to catch cases where nobody even attempted to send
      "remove" uevents. But there is no guarantee that an event will ultimately
      be sent. We are at the point of no return as far as the rest of the kernel
      is concerned; there are no repeats or do-overs.
      
      Also, it is not clear whether some subsystem depends on that commit.
      If no subsystem depends on that commit, it will be better to remove
      the state_{add,remove}_uevent_sent logic. But we don't want to risk
      a regression (in a patch which will be backported) by trying to remove
      that logic. Therefore, as a first step, let's avoid the use-after-free bug
      by making sure that kobject_uevent(KOBJ_REMOVE) won't be triggered twice.
      
      [1] https://syzkaller.appspot.com/bug?id=8b17c134fe938bbddd75a45afaa9e68af43a362dReported-by: Nsyzbot <syzbot+f648cfb7e0b52bf7ae32@syzkaller.appspotmail.com>
      Analyzed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Fixes: 0f4dafc0 ("Kobject: auto-cleanup on final unref")
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bc75207a
    • S
      spi: tegra114: reset controller on probe · ba906246
      Sowjanya Komatineni 提交于
      [ Upstream commit 019194933339b3e9b486639c8cb3692020844d65 ]
      
      Fixes: SPI driver can be built as module so perform SPI controller reset
      on probe to make sure it is in valid state before initiating transfer.
      Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ba906246
    • H
      HID: logitech-hidpp: change low battery level threshold from 31 to 30 percent · 2cd236c2
      Hans de Goede 提交于
      [ Upstream commit 1f87b0cd32b3456d7efdfb017fcf74d0bfe3ec29 ]
      
      According to hidpp20_batterylevel_get_battery_info my Logitech K270
      keyboard reports only 2 battery levels. This matches with what I've seen
      after testing with batteries at varying level of fullness, it always
      reports either 5% or 30%.
      
      Windows reports "battery good" for the 30% level. I've captured an USB
      trace of Windows reading the battery and it is getting the same info
      as the Linux hidpp code gets.
      
      Now that Linux handles these devices as hidpp devices, it reports the
      battery as being low as it treats anything under 31% as low, this leads
      to the user constantly getting a "Keyboard battery is low" warning from
      GNOME3, which is very annoying.
      
      This commit fixes this by changing the low threshold to anything under
      30%, which I assume is what Windows does.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2cd236c2
    • G
      cxgb3/l2t: Fix undefined behaviour · fb2c65b4
      Gustavo A. R. Silva 提交于
      [ Upstream commit 76497732932f15e7323dc805e8ea8dc11bb587cf ]
      
      The use of zero-sized array causes undefined behaviour when it is not
      the last member in a structure. As it happens to be in this case.
      
      Also, the current code makes use of a language extension to the C90
      standard, but the preferred mechanism to declare variable-length
      types such as this one is a flexible array member, introduced in
      C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last. Which is beneficial
      to cultivate a high-quality code.
      
      Fixes: e48f129c ("[SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference")
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fb2c65b4
    • W
      ASoC: fsl_utils: fix a leaked reference by adding missing of_node_put · 71efe4c7
      Wen Yang 提交于
      [ Upstream commit c705247136a523488eac806bd357c3e5d79a7acd ]
      
      The call to of_parse_phandle returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./sound/soc/fsl/fsl_utils.c:74:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 38, but without a corresponding     object release within this function.
      Signed-off-by: NWen Yang <wen.yang99@zte.com.cn>
      Cc: Timur Tabi <timur@kernel.org>
      Cc: Nicolin Chen <nicoleotsuka@gmail.com>
      Cc: Xiubo Li <Xiubo.Lee@gmail.com>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: alsa-devel@alsa-project.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      71efe4c7
    • W
      ASoC: eukrea-tlv320: fix a leaked reference by adding missing of_node_put · b6b7a78c
      Wen Yang 提交于
      [ Upstream commit b820d52e7eed7b30b2dfef5f4213a2bc3cbea6f3 ]
      
      The call to of_parse_phandle returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./sound/soc/fsl/eukrea-tlv320.c:121:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 102, but without a correspo    nding object release within this function.
      ./sound/soc/fsl/eukrea-tlv320.c:127:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 102, but without a correspo    nding object release within this function.
      Signed-off-by: NWen Yang <wen.yang99@zte.com.cn>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: alsa-devel@alsa-project.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b6b7a78c
    • N
      HID: core: move Usage Page concatenation to Main item · 69f67200
      Nicolas Saenz Julienne 提交于
      [ Upstream commit 58e75155009cc800005629955d3482f36a1e0eec ]
      
      As seen on some USB wireless keyboards manufactured by Primax, the HID
      parser was using some assumptions that are not always true. In this case
      it's s the fact that, inside the scope of a main item, an Usage Page
      will always precede an Usage.
      
      The spec is not pretty clear as 6.2.2.7 states "Any usage that follows
      is interpreted as a Usage ID and concatenated with the Usage Page".
      While 6.2.2.8 states "When the parser encounters a main item it
      concatenates the last declared Usage Page with a Usage to form a
      complete usage value." Being somewhat contradictory it was decided to
      match Window's implementation, which follows 6.2.2.8.
      
      In summary, the patch moves the Usage Page concatenation from the local
      item parsing function to the main item parsing function.
      Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
      Reviewed-by: NTerry Junge <terry.junge@poly.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      69f67200
    • G
      sh: sh7786: Add explicit I/O cast to sh7786_mm_sel() · 256f63c6
      Geert Uytterhoeven 提交于
      [ Upstream commit 8440bb9b944c02222c7a840d406141ed42e945cd ]
      
      When compile-testing on arm:
      
          arch/sh/include/cpu-sh4/cpu/sh7786.h: In function ‘sh7786_mm_sel’:
          arch/sh/include/cpu-sh4/cpu/sh7786.h:135:21: warning: passing argument 1 of ‘__raw_readl’ makes pointer from integer without a cast [-Wint-conversion]
            return __raw_readl(0xFC400020) & 0x7;
      			 ^~~~~~~~~~
          In file included from include/linux/io.h:25:0,
      		     from arch/sh/include/cpu-sh4/cpu/sh7786.h:14,
      		     from drivers/pinctrl/sh-pfc/pfc-sh7786.c:15:
          arch/arm/include/asm/io.h:113:21: note: expected ‘const volatile void *’ but argument is of type ‘unsigned int’
           #define __raw_readl __raw_readl
      			 ^
          arch/arm/include/asm/io.h:114:19: note: in expansion of macro ‘__raw_readl’
           static inline u32 __raw_readl(const volatile void __iomem *addr)
      		       ^~~~~~~~~~~
      
      __raw_readl() on SuperH is a macro that casts the passed I/O address to
      the correct type, while the implementations on most other architectures
      expect to be passed the correct pointer type.
      
      Add an explicit cast to fix this.
      
      Note that this also gets rid of a sparse warning on SuperH:
      
          arch/sh/include/cpu-sh4/cpu/sh7786.h:135:16: warning: incorrect type in argument 1 (different base types)
          arch/sh/include/cpu-sh4/cpu/sh7786.h:135:16:    expected void const volatile [noderef] <asn:2>*<noident>
          arch/sh/include/cpu-sh4/cpu/sh7786.h:135:16:    got unsigned int
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      256f63c6
    • L
      RDMA/hns: Fix bad endianess of port_pd variable · 8ea27918
      Leon Romanovsky 提交于
      [ Upstream commit 6734b2973565e36659e97e12ab0d0faf1d9f3fbe ]
      
      port_pd is treated as le32 in declaration and read, fix assignment to be
      in le32 too. This change fixes the following compilation warnings.
      
      drivers/infiniband/hw/hns/hns_roce_ah.c:67:24: warning: incorrect type
      in assignment (different base types)
      drivers/infiniband/hw/hns/hns_roce_ah.c:67:24: expected restricted __le32 [usertype] port_pd
      drivers/infiniband/hw/hns/hns_roce_ah.c:67:24: got restricted __be32 [usertype]
      
      Fixes: 9a443537 ("IB/hns: Add driver files for hns RoCE driver")
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: NGal Pressman <galpress@amazon.com>
      Reviewed-by: NLijun Ou <ouliun@huawei.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8ea27918
    • C
      chardev: add additional check for minor range overlap · 65ec64f2
      Chengguang Xu 提交于
      [ Upstream commit de36e16d1557a0b6eb328bc3516359a12ba5c25c ]
      
      Current overlap checking cannot correctly handle
      a case which is baseminor < existing baseminor &&
      baseminor + minorct > existing baseminor + minorct.
      Signed-off-by: NChengguang Xu <cgxu519@gmx.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      65ec64f2
    • P
      x86/uaccess: Fix up the fixup · fc242af8
      Peter Zijlstra 提交于
      [ Upstream commit b69656fa7ea2f75e47d7bd5b9430359fa46488af ]
      
      New tooling got confused about this:
      
        arch/x86/lib/memcpy_64.o: warning: objtool: .fixup+0x7: return with UACCESS enabled
      
      While the code isn't wrong, it is tedious (if at all possible) to
      figure out what function a particular chunk of .fixup belongs to.
      
      This then confuses the objtool uaccess validation. Instead of
      returning directly from the .fixup, jump back into the right function.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fc242af8
    • P
      x86/ia32: Fix ia32_restore_sigcontext() AC leak · 5007453c
      Peter Zijlstra 提交于
      [ Upstream commit 67a0514afdbb8b2fc70b771b8c77661a9cb9d3a9 ]
      
      Objtool spotted that we call native_load_gs_index() with AC set.
      Re-arrange the code to avoid that.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5007453c
    • P
      x86/uaccess, signal: Fix AC=1 bloat · 4614b0bb
      Peter Zijlstra 提交于
      [ Upstream commit 88e4718275c1bddca6f61f300688b4553dc8584b ]
      
      Occasionally GCC is less agressive with inlining and the following is
      observed:
      
        arch/x86/kernel/signal.o: warning: objtool: restore_sigcontext()+0x3cc: call to force_valid_ss.isra.5() with UACCESS enabled
        arch/x86/kernel/signal.o: warning: objtool: do_signal()+0x384: call to frame_uc_flags.isra.0() with UACCESS enabled
      
      Cure this by moving this code out of the AC=1 region, since it really
      isn't needed for the user access.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4614b0bb
    • P
      x86/uaccess, ftrace: Fix ftrace_likely_update() vs. SMAP · 1a3188d7
      Peter Zijlstra 提交于
      [ Upstream commit 4a6c91fbdef846ec7250b82f2eeeb87ac5f18cf9 ]
      
      For CONFIG_TRACE_BRANCH_PROFILING=y the likely/unlikely things get
      overloaded and generate callouts to this code, and thus also when
      AC=1.
      
      Make it safe.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1a3188d7
    • L
      wil6210: fix return code of wmi_mgmt_tx and wmi_mgmt_tx_ext · da30c277
      Lior David 提交于
      [ Upstream commit 49122ec42634f73babb1dc96f170023e5228d080 ]
      
      The functions that send management TX frame have 3 possible
      results: success and other side acknowledged receive (ACK=1),
      success and other side did not acknowledge receive(ACK=0) and
      failure to send the frame. The current implementation
      incorrectly reports the ACK=0 case as failure.
      Signed-off-by: NLior David <liord@codeaurora.org>
      Signed-off-by: NMaya Erez <merez@codeaurora.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      da30c277
    • W
      arm64: cpu_ops: fix a leaked reference by adding missing of_node_put · e667aef5
      Wen Yang 提交于
      [ Upstream commit 92606ec9285fb84cd9b5943df23f07d741384bfc ]
      
      The call to of_get_next_child returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
        ./arch/arm64/kernel/cpu_ops.c:102:1-7: ERROR: missing of_node_put;
        acquired a node pointer with refcount incremented on line 69, but
        without a corresponding object release within this function.
      Signed-off-by: NWen Yang <wen.yang99@zte.com.cn>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e667aef5
    • Y
      drm/panel: otm8009a: Add delay at the end of initialization · e3980dbe
      Yannick Fertré 提交于
      [ Upstream commit 0084c3c71126fc878c6dab8a6ab8ecc484c2be02 ]
      
      At the end of initialization, a delay is required by the panel. Without
      this delay, the panel could received a frame early & generate a crash of
      panel (black screen).
      Signed-off-by: NYannick Fertré <yannick.fertre@st.com>
      Reviewed-by: NPhilippe Cornu <philippe.cornu@st.com>
      Tested-by: NPhilippe Cornu <philippe.cornu@st.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1553155445-13407-1-git-send-email-yannick.fertre@st.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      e3980dbe
    • S
      scsi: ufs: Avoid configuring regulator with undefined voltage range · cb5946e5
      Stanley Chu 提交于
      [ Upstream commit 3b141e8cfd54ba3e5c610717295b2a02aab26a05 ]
      
      For regulators used by UFS, vcc, vccq and vccq2 will have voltage range
      initialized by ufshcd_populate_vreg(), however other regulators may have
      undefined voltage range if dt-bindings have no such definition.
      
      In above undefined case, both "min_uV" and "max_uV" fields in ufs_vreg
      struct will be zero values and these values will be configured on
      regulators in different power modes.
      
      Currently this may have no harm if both "min_uV" and "max_uV" always keep
      "zero values" because regulator_set_voltage() will always bypass such
      invalid values and return "good" results.
      
      However improper values shall be fixed to avoid potential bugs.  Simply
      bypass voltage configuration if voltage range is not defined.
      Signed-off-by: NStanley Chu <stanley.chu@mediatek.com>
      Reviewed-by: NAvri Altman <avri.altman@wdc.com>
      Acked-by: NAlim Akhtar <alim.akhtar@samsung.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cb5946e5
    • S
      scsi: ufs: Fix regulator load and icc-level configuration · 31318d4a
      Stanley Chu 提交于
      [ Upstream commit 0487fff76632ec023d394a05b82e87a971db8c03 ]
      
      Currently if a regulator has "<name>-fixed-regulator" property in device
      tree, it will skip current limit initialization.  This lead to a zero
      "max_uA" value in struct ufs_vreg.
      
      However, "regulator_set_load" operation shall be required on regulators
      which have valid current limits, otherwise a zero "max_uA" set by
      "regulator_set_load" may cause unexpected behavior when this regulator is
      enabled or set as high power mode.
      
      Similarly, in device's icc_level configuration flow, the target icc_level
      shall be updated if regulator also has valid current limit, otherwise a
      wrong icc_level will be calculated by zero "max_uA" and thus causes
      unexpected results after it is written to device.
      Signed-off-by: NStanley Chu <stanley.chu@mediatek.com>
      Reviewed-by: NAvri Altman <avri.altman@wdc.com>
      Acked-by: NAlim Akhtar <alim.akhtar@samsung.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      31318d4a
    • P
      rtlwifi: fix potential NULL pointer dereference · c9e44a1a
      Ping-Ke Shih 提交于
      [ Upstream commit 60209d482b97743915883d293c8b85226d230c19 ]
      
      In case dev_alloc_skb fails, the fix safely returns to avoid
      potential NULL pointer dereference.
      Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c9e44a1a
    • A
      rtc: xgene: fix possible race condition · bd2ab045
      Alexandre Belloni 提交于
      [ Upstream commit a652e00ee1233e251a337c28e18a1da59224e5ce ]
      
      The IRQ is requested before the struct rtc is allocated and registered, but
      this struct is used in the IRQ handler. This may lead to a NULL pointer
      dereference.
      
      Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
      struct before requesting the IRQ.
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bd2ab045
    • P
      brcmfmac: fix Oops when bringing up interface during USB disconnect · e29aba14
      Piotr Figiel 提交于
      [ Upstream commit 24d413a31afaee9bbbf79226052c386b01780ce2 ]
      
      Fix a race which leads to an Oops with NULL pointer dereference.  The
      dereference is in brcmf_config_dongle() when cfg_to_ndev() attempts to get
      net_device structure of interface with index 0 via if2bss mapping. This
      shouldn't fail because of check for bus being ready in brcmf_netdev_open(),
      but it's not synchronised with USB disconnect and there is a race: after
      the check the bus can be marked down and the mapping for interface 0 may be
      gone.
      
      Solve this by modifying disconnect handling so that the removal of mapping
      of ifidx to brcmf_if structure happens after netdev removal (which is
      synchronous with brcmf_netdev_open() thanks to rtln being locked in
      devinet_ioctl()). This assures brcmf_netdev_open() returns before the
      mapping is removed during disconnect.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000008
      pgd = bcae2612
      [00000008] *pgd=8be73831
      Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      Modules linked in: brcmfmac brcmutil nf_log_ipv4 nf_log_common xt_LOG xt_limit
      iptable_mangle xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6
      nf_defrag_ipv4 iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis
      u_ether usb_serial_simple usbserial cdc_acm smsc95xx usbnet ci_hdrc_imx ci_hdrc
      usbmisc_imx ulpi 8250_exar 8250_pci 8250 8250_base libcomposite configfs
      udc_core [last unloaded: brcmutil]
      CPU: 2 PID: 24478 Comm: ifconfig Not tainted 4.19.23-00078-ga62866d-dirty #115
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      PC is at brcmf_cfg80211_up+0x94/0x29c [brcmfmac]
      LR is at brcmf_cfg80211_up+0x8c/0x29c [brcmfmac]
      pc : [<7f26a91c>]    lr : [<7f26a914>]    psr: a0070013
      sp : eca99d28  ip : 00000000  fp : ee9c6c00
      r10: 00000036  r9 : 00000000  r8 : ece4002c
      r7 : edb5b800  r6 : 00000000  r5 : 80f08448  r4 : edb5b968
      r3 : ffffffff  r2 : 00000000  r1 : 00000002  r0 : 00000000
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 7ca0c04a  DAC: 00000051
      Process ifconfig (pid: 24478, stack limit = 0xd9e85a0e)
      Stack: (0xeca99d28 to 0xeca9a000)
      9d20:                   00000000 80f873b0 0000000d 80f08448 eca99d68 50d45f32
      9d40: 7f27de94 ece40000 80f08448 80f08448 7f27de94 ece4002c 00000000 00000036
      9d60: ee9c6c00 7f27262c 00001002 50d45f32 ece40000 00000000 80f08448 80772008
      9d80: 00000001 00001043 00001002 ece40000 00000000 50d45f32 ece40000 00000001
      9da0: 80f08448 00001043 00001002 807723d0 00000000 50d45f32 80f08448 eca99e58
      9dc0: 80f87113 50d45f32 80f08448 ece40000 ece40138 00001002 80f08448 00000000
      9de0: 00000000 80772434 edbd5380 eca99e58 edbd5380 80f08448 ee9c6c0c 80805f70
      9e00: 00000000 ede08e00 00008914 ece40000 00000014 ee9c6c0c 600c0013 00001043
      9e20: 0208a8c0 ffffffff 00000000 50d45f32 eca98000 80f08448 7ee9fc38 00008914
      9e40: 80f68e40 00000051 eca98000 00000036 00000003 80808b9c 6e616c77 00000030
      9e60: 00000000 00000000 00001043 0208a8c0 ffffffff 00000000 80f08448 00000000
      9e80: 00000000 816d8b20 600c0013 00000001 ede09320 801763d4 00000000 50d45f32
      9ea0: eca98000 80f08448 7ee9fc38 50d45f32 00008914 80f08448 7ee9fc38 80f68e40
      9ec0: ed531540 8074721c 00000800 00000001 00000000 6e616c77 00000030 00000000
      9ee0: 00000000 00001002 0208a8c0 ffffffff 00000000 50d45f32 80f08448 7ee9fc38
      9f00: ed531560 ec8fc900 80285a6c 80285138 edb910c0 00000000 ecd91008 ede08e00
      9f20: 80f08448 00000000 00000000 816d8b20 600c0013 00000001 ede09320 801763d4
      9f40: 00000000 50d45f32 00021000 edb91118 edb910c0 80f08448 01b29000 edb91118
      9f60: eca99f7c 50d45f32 00021000 ec8fc900 00000003 ec8fc900 00008914 7ee9fc38
      9f80: eca98000 00000036 00000003 80285a6c 00086364 7ee9fe1c 000000c3 00000036
      9fa0: 801011c4 80101000 00086364 7ee9fe1c 00000003 00008914 7ee9fc38 00086364
      9fc0: 00086364 7ee9fe1c 000000c3 00000036 0008630c 7ee9fe1c 7ee9fc38 00000003
      9fe0: 000a42b8 7ee9fbd4 00019914 76e09acc 600c0010 00000003 00000000 00000000
      [<7f26a91c>] (brcmf_cfg80211_up [brcmfmac]) from [<7f27262c>] (brcmf_netdev_open+0x74/0xe8 [brcmfmac])
      [<7f27262c>] (brcmf_netdev_open [brcmfmac]) from [<80772008>] (__dev_open+0xcc/0x150)
      [<80772008>] (__dev_open) from [<807723d0>] (__dev_change_flags+0x168/0x1b4)
      [<807723d0>] (__dev_change_flags) from [<80772434>] (dev_change_flags+0x18/0x48)
      [<80772434>] (dev_change_flags) from [<80805f70>] (devinet_ioctl+0x67c/0x79c)
      [<80805f70>] (devinet_ioctl) from [<80808b9c>] (inet_ioctl+0x210/0x3d4)
      [<80808b9c>] (inet_ioctl) from [<8074721c>] (sock_ioctl+0x350/0x524)
      [<8074721c>] (sock_ioctl) from [<80285138>] (do_vfs_ioctl+0xb0/0x9b0)
      [<80285138>] (do_vfs_ioctl) from [<80285a6c>] (ksys_ioctl+0x34/0x5c)
      [<80285a6c>] (ksys_ioctl) from [<80101000>] (ret_fast_syscall+0x0/0x28)
      Exception stack(0xeca99fa8 to 0xeca99ff0)
      9fa0:                   00086364 7ee9fe1c 00000003 00008914 7ee9fc38 00086364
      9fc0: 00086364 7ee9fe1c 000000c3 00000036 0008630c 7ee9fe1c 7ee9fc38 00000003
      9fe0: 000a42b8 7ee9fbd4 00019914 76e09acc
      Code: e5970328 eb002021 e1a02006 e3a01002 (e5909008)
      ---[ end trace 5cbac2333f3ac5df ]---
      Signed-off-by: NPiotr Figiel <p.figiel@camlintechnologies.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e29aba14
    • P
      brcmfmac: fix race during disconnect when USB completion is in progress · 8a412ed9
      Piotr Figiel 提交于
      [ Upstream commit db3b9e2e1d58080d0754bdf9293dabf8c6491b67 ]
      
      It was observed that rarely during USB disconnect happening shortly after
      connect (before full initialization completes) usb_hub_wq would wait
      forever for the dev_init_lock to be unlocked. dev_init_lock would remain
      locked though because of infinite wait during usb_kill_urb:
      
      [ 2730.656472] kworker/0:2     D    0   260      2 0x00000000
      [ 2730.660700] Workqueue: events request_firmware_work_func
      [ 2730.664807] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac)
      [ 2730.670587] [<809dd164>] (schedule) from [<8069af44>] (usb_kill_urb+0xdc/0x114)
      [ 2730.676815] [<8069af44>] (usb_kill_urb) from [<7f258b50>] (brcmf_usb_free_q+0x34/0xa8 [brcmfmac])
      [ 2730.684833] [<7f258b50>] (brcmf_usb_free_q [brcmfmac]) from [<7f2517d4>] (brcmf_detach+0xa0/0xb8 [brcmfmac])
      [ 2730.693557] [<7f2517d4>] (brcmf_detach [brcmfmac]) from [<7f251a34>] (brcmf_attach+0xac/0x3d8 [brcmfmac])
      [ 2730.702094] [<7f251a34>] (brcmf_attach [brcmfmac]) from [<7f2587ac>] (brcmf_usb_probe_phase2+0x468/0x4a0 [brcmfmac])
      [ 2730.711601] [<7f2587ac>] (brcmf_usb_probe_phase2 [brcmfmac]) from [<7f252888>] (brcmf_fw_request_done+0x194/0x220 [brcmfmac])
      [ 2730.721795] [<7f252888>] (brcmf_fw_request_done [brcmfmac]) from [<805748e4>] (request_firmware_work_func+0x4c/0x88)
      [ 2730.731125] [<805748e4>] (request_firmware_work_func) from [<80141474>] (process_one_work+0x228/0x808)
      [ 2730.739223] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [ 2730.746105] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [ 2730.752227] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      
      [ 2733.099695] kworker/0:3     D    0  1065      2 0x00000000
      [ 2733.103926] Workqueue: usb_hub_wq hub_event
      [ 2733.106914] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac)
      [ 2733.112693] [<809dd164>] (schedule) from [<809e2a8c>] (schedule_timeout+0x214/0x3e4)
      [ 2733.119621] [<809e2a8c>] (schedule_timeout) from [<809dde2c>] (wait_for_common+0xc4/0x1c0)
      [ 2733.126810] [<809dde2c>] (wait_for_common) from [<7f258d00>] (brcmf_usb_disconnect+0x1c/0x4c [brcmfmac])
      [ 2733.135206] [<7f258d00>] (brcmf_usb_disconnect [brcmfmac]) from [<8069e0c8>] (usb_unbind_interface+0x5c/0x1e4)
      [ 2733.143943] [<8069e0c8>] (usb_unbind_interface) from [<8056d3e8>] (device_release_driver_internal+0x164/0x1fc)
      [ 2733.152769] [<8056d3e8>] (device_release_driver_internal) from [<8056c078>] (bus_remove_device+0xd0/0xfc)
      [ 2733.161138] [<8056c078>] (bus_remove_device) from [<8056977c>] (device_del+0x11c/0x310)
      [ 2733.167939] [<8056977c>] (device_del) from [<8069cba8>] (usb_disable_device+0xa0/0x1cc)
      [ 2733.174743] [<8069cba8>] (usb_disable_device) from [<8069507c>] (usb_disconnect+0x74/0x1dc)
      [ 2733.181823] [<8069507c>] (usb_disconnect) from [<80695e88>] (hub_event+0x478/0xf88)
      [ 2733.188278] [<80695e88>] (hub_event) from [<80141474>] (process_one_work+0x228/0x808)
      [ 2733.194905] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [ 2733.201724] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [ 2733.207913] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      
      It was traced down to a case where usb_kill_urb would be called on an URB
      structure containing more or less random data, including large number in
      its use_count. During the debugging it appeared that in brcmf_usb_free_q()
      the traversal over URBs' lists is not synchronized with operations on those
      lists in brcmf_usb_rx_complete() leading to handling
      brcmf_usbdev_info structure (holding lists' head) as lists' element and in
      result causing above problem.
      
      Fix it by walking through all URBs during brcmf_cancel_all_urbs using the
      arrays of requests instead of linked lists.
      Signed-off-by: NPiotr Figiel <p.figiel@camlintechnologies.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8a412ed9
    • P
      brcmfmac: fix WARNING during USB disconnect in case of unempty psq · ce55a594
      Piotr Figiel 提交于
      [ Upstream commit c80d26e81ef1802f30364b4ad1955c1443a592b9 ]
      
      brcmu_pkt_buf_free_skb emits WARNING when attempting to free a sk_buff
      which is part of any queue. After USB disconnect this may have happened
      when brcmf_fws_hanger_cleanup() is called as per-interface psq was never
      cleaned when removing the interface.
      Change brcmf_fws_macdesc_cleanup() in a way that it removes the
      corresponding packets from hanger table (to avoid double-free when
      brcmf_fws_hanger_cleanup() is called) and add a call to clean-up the
      interface specific packet queue.
      
      Below is a WARNING during USB disconnect with Raspberry Pi WiFi dongle
      running in AP mode. This was reproducible when the interface was
      transmitting during the disconnect and is fixed with this commit.
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1171 at drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c:49 brcmu_pkt_buf_free_skb+0x3c/0x40
      Modules linked in: nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_mangle xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis u_ether cdc_acm smsc95xx usbnet ci_hdrc_imx ci_hdrc ulpi usbmisc_imx 8250_exar 8250_pci 8250 8250_base libcomposite configfs udc_core
      CPU: 0 PID: 1171 Comm: kworker/0:0 Not tainted 4.19.23-00075-gde33ed8 #99
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Workqueue: usb_hub_wq hub_event
      [<8010ff84>] (unwind_backtrace) from [<8010bb64>] (show_stack+0x10/0x14)
      [<8010bb64>] (show_stack) from [<80840278>] (dump_stack+0x88/0x9c)
      [<80840278>] (dump_stack) from [<8011f5ec>] (__warn+0xfc/0x114)
      [<8011f5ec>] (__warn) from [<8011f71c>] (warn_slowpath_null+0x40/0x48)
      [<8011f71c>] (warn_slowpath_null) from [<805a476c>] (brcmu_pkt_buf_free_skb+0x3c/0x40)
      [<805a476c>] (brcmu_pkt_buf_free_skb) from [<805bb6c4>] (brcmf_fws_cleanup+0x1e4/0x22c)
      [<805bb6c4>] (brcmf_fws_cleanup) from [<805bc854>] (brcmf_fws_del_interface+0x58/0x68)
      [<805bc854>] (brcmf_fws_del_interface) from [<805b66ac>] (brcmf_remove_interface+0x40/0x150)
      [<805b66ac>] (brcmf_remove_interface) from [<805b6870>] (brcmf_detach+0x6c/0xb0)
      [<805b6870>] (brcmf_detach) from [<805bdbb8>] (brcmf_usb_disconnect+0x30/0x4c)
      [<805bdbb8>] (brcmf_usb_disconnect) from [<805e5d64>] (usb_unbind_interface+0x5c/0x1e0)
      [<805e5d64>] (usb_unbind_interface) from [<804aab10>] (device_release_driver_internal+0x154/0x1ec)
      [<804aab10>] (device_release_driver_internal) from [<804a97f4>] (bus_remove_device+0xcc/0xf8)
      [<804a97f4>] (bus_remove_device) from [<804a6fc0>] (device_del+0x118/0x308)
      [<804a6fc0>] (device_del) from [<805e488c>] (usb_disable_device+0xa0/0x1c8)
      [<805e488c>] (usb_disable_device) from [<805dcf98>] (usb_disconnect+0x70/0x1d8)
      [<805dcf98>] (usb_disconnect) from [<805ddd84>] (hub_event+0x464/0xf50)
      [<805ddd84>] (hub_event) from [<80135a70>] (process_one_work+0x138/0x3f8)
      [<80135a70>] (process_one_work) from [<80135d5c>] (worker_thread+0x2c/0x554)
      [<80135d5c>] (worker_thread) from [<8013b1a0>] (kthread+0x124/0x154)
      [<8013b1a0>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
      Exception stack(0xecf8dfb0 to 0xecf8dff8)
      dfa0:                                     00000000 00000000 00000000 00000000
      dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
      ---[ end trace 38d234018e9e2a90 ]---
      ------------[ cut here ]------------
      Signed-off-by: NPiotr Figiel <p.figiel@camlintechnologies.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ce55a594
    • P
      brcmfmac: convert dev_init_lock mutex to completion · 4b2f0ebc
      Piotr Figiel 提交于
      [ Upstream commit a9fd0953fa4a62887306be28641b4b0809f3b2fd ]
      
      Leaving dev_init_lock mutex locked in probe causes BUG and a WARNING when
      kernel is compiled with CONFIG_PROVE_LOCKING. Convert mutex to completion
      which silences those warnings and improves code readability.
      
      Fix below errors when connecting the USB WiFi dongle:
      
      brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43143 for chip BCM43143/2
      BUG: workqueue leaked lock or atomic: kworker/0:2/0x00000000/434
           last function: hub_event
      1 lock held by kworker/0:2/434:
       #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
      CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Workqueue: usb_hub_wq hub_event
      [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14)
      [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4)
      [<809c4324>] (dump_stack) from [<8014195c>] (process_one_work+0x710/0x808)
      [<8014195c>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xed1d9fb0 to 0xed1d9ff8)
      9fa0:                                     00000000 00000000 00000000 00000000
      9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.19.23-00084-g454a789-dirty #123 Not tainted
      ------------------------------------------------------
      kworker/0:2/434 is trying to acquire lock:
      e29cf799 ((wq_completion)"events"){+.+.}, at: process_one_work+0x174/0x808
      
      but task is already holding lock:
      18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (&devinfo->dev_init_lock){+.+.}:
             mutex_lock_nested+0x1c/0x24
             brcmf_usb_probe+0x78/0x550 [brcmfmac]
             usb_probe_interface+0xc0/0x1bc
             really_probe+0x228/0x2c0
             __driver_attach+0xe4/0xe8
             bus_for_each_dev+0x68/0xb4
             bus_add_driver+0x19c/0x214
             driver_register+0x78/0x110
             usb_register_driver+0x84/0x148
             process_one_work+0x228/0x808
             worker_thread+0x2c/0x564
             kthread+0x13c/0x16c
             ret_from_fork+0x14/0x20
               (null)
      
      -> #1 (brcmf_driver_work){+.+.}:
             worker_thread+0x2c/0x564
             kthread+0x13c/0x16c
             ret_from_fork+0x14/0x20
               (null)
      
      -> #0 ((wq_completion)"events"){+.+.}:
             process_one_work+0x1b8/0x808
             worker_thread+0x2c/0x564
             kthread+0x13c/0x16c
             ret_from_fork+0x14/0x20
               (null)
      
      other info that might help us debug this:
      
      Chain exists of:
        (wq_completion)"events" --> brcmf_driver_work --> &devinfo->dev_init_lock
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&devinfo->dev_init_lock);
                                     lock(brcmf_driver_work);
                                     lock(&devinfo->dev_init_lock);
        lock((wq_completion)"events");
      
       *** DEADLOCK ***
      
      1 lock held by kworker/0:2/434:
       #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
      
      stack backtrace:
      CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Workqueue: events request_firmware_work_func
      [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14)
      [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4)
      [<809c4324>] (dump_stack) from [<80172838>] (print_circular_bug+0x210/0x330)
      [<80172838>] (print_circular_bug) from [<80175940>] (__lock_acquire+0x160c/0x1a30)
      [<80175940>] (__lock_acquire) from [<8017671c>] (lock_acquire+0xe0/0x268)
      [<8017671c>] (lock_acquire) from [<80141404>] (process_one_work+0x1b8/0x808)
      [<80141404>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xed1d9fb0 to 0xed1d9ff8)
      9fa0:                                     00000000 00000000 00000000 00000000
      9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      Signed-off-by: NPiotr Figiel <p.figiel@camlintechnologies.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4b2f0ebc
    • A
      b43: shut up clang -Wuninitialized variable warning · 59ec3ad3
      Arnd Bergmann 提交于
      [ Upstream commit d825db346270dbceef83b7b750dbc29f1d7dcc0e ]
      
      Clang warns about what is clearly a case of passing an uninitalized
      variable into a static function:
      
      drivers/net/wireless/broadcom/b43/phy_lp.c:1852:23: error: variable 'gains' is uninitialized when used here
            [-Werror,-Wuninitialized]
                      lpphy_papd_cal(dev, gains, 0, 1, 30);
                                          ^~~~~
      drivers/net/wireless/broadcom/b43/phy_lp.c:1838:2: note: variable 'gains' is declared here
              struct lpphy_tx_gains gains, oldgains;
              ^
      1 error generated.
      
      However, this function is empty, and its arguments are never evaluated,
      so gcc in contrast does not warn here. Both compilers behave in a
      reasonable way as far as I can tell, so we should change the code
      to avoid the warning everywhere.
      
      We could just eliminate the lpphy_papd_cal() function entirely,
      given that it has had the TODO comment in it for 10 years now
      and is rather unlikely to ever get done. I'm doing a simpler
      change here, and just pass the 'oldgains' variable in that has
      been initialized, based on the guess that this is what was
      originally meant.
      
      Fixes: 2c0d6100 ("b43: LP-PHY: Begin implementing calibration & software RFKILL support")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      59ec3ad3
    • K
      brcmfmac: fix missing checks for kmemdup · 7c9d97f3
      Kangjie Lu 提交于
      [ Upstream commit 46953f97224d56a12ccbe9c6acaa84ca0dab2780 ]
      
      In case kmemdup fails, the fix sets conn_info->req_ie_len and
      conn_info->resp_ie_len to zero to avoid buffer overflows.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7c9d97f3
    • Y
      mwifiex: Fix mem leak in mwifiex_tm_cmd · a27ce484
      YueHaibing 提交于
      [ Upstream commit 003b686ace820ce2d635a83f10f2d7f9c147dabc ]
      
      'hostcmd' is alloced by kzalloc, should be freed before
      leaving from the error handling cases, otherwise it will
      cause mem leak.
      
      Fixes: 3935ccc1 ("mwifiex: add cfg80211 testmode support")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a27ce484
    • K
      rtlwifi: fix a potential NULL pointer dereference · 7be8d425
      Kangjie Lu 提交于
      [ Upstream commit 765976285a8c8db3f0eb7f033829a899d0c2786e ]
      
      In case alloc_workqueue fails, the fix reports the error and
      returns 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>
      7be8d425
    • D
      selftests/bpf: ksym_search won't check symbols exists · f8f54929
      Daniel T. Lee 提交于
      [ Upstream commit 0979ff7992fb6f4eb837995b12f4071dcafebd2d ]
      
      Currently, ksym_search located at trace_helpers won't check symbols are
      existing or not.
      
      In ksym_search, when symbol is not found, it will return &syms[0](_stext).
      But when the kernel symbols are not loaded, it will return NULL, which is
      not a desired action.
      
      This commit will add verification logic whether symbols are loaded prior
      to the symbol search.
      Signed-off-by: NDaniel T. Lee <danieltimlee@gmail.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f8f54929
    • J
      iio: adc: ti-ads7950: Fix improper use of mlock · ef8e5a78
      Justin Chen 提交于
      [ Upstream commit abbde2792999c9ad3514dd25d7f8d9a96034fe16 ]
      
      Indio->mlock is used for protecting the different iio device modes.
      It is currently not being used in this way. Replace the lock with
      an internal lock specifically used for protecting the SPI transfer
      buffer.
      Signed-off-by: NJustin Chen <justinpopo6@gmail.com>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ef8e5a78
    • N
      iio: common: ssp_sensors: Initialize calculated_time in ssp_common_process_data · 36a59a03
      Nathan Chancellor 提交于
      [ Upstream commit 6f9ca1d3eb74b81f811a87002de2d51640d135b1 ]
      
      When building with -Wsometimes-uninitialized, Clang warns:
      
      drivers/iio/common/ssp_sensors/ssp_iio.c:95:6: warning: variable
      'calculated_time' is used uninitialized whenever 'if' condition is false
      [-Wsometimes-uninitialized]
      
      While it isn't wrong, this will never be a problem because
      iio_push_to_buffers_with_timestamp only uses calculated_time
      on the same condition that it is assigned (when scan_timestamp
      is not zero). While iio_push_to_buffers_with_timestamp is marked
      as inline, Clang does inlining in the optimization stage, which
      happens after the semantic analysis phase (plus inline is merely
      a hint to the compiler).
      
      Fix this by just zero initializing calculated_time.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/394Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      36a59a03
    • K
      iio: hmc5843: fix potential NULL pointer dereferences · dd106d19
      Kangjie Lu 提交于
      [ Upstream commit 536cc27deade8f1ec3c1beefa60d5fbe0f6fcb28 ]
      
      devm_regmap_init_i2c may fail and return NULL. The fix returns
      the error when it fails.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dd106d19