1. 31 5月, 2019 40 次提交
    • 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
    • M
      w1: fix the resume command API · 99079cee
      Mariusz Bialonczyk 提交于
      [ Upstream commit 62909da8aca048ecf9fbd7e484e5100608f40a63 ]
      
      >From the DS2408 datasheet [1]:
      "Resume Command function checks the status of the RC flag and, if it is set,
       directly transfers control to the control functions, similar to a Skip ROM
       command. The only way to set the RC flag is through successfully executing
       the Match ROM, Search ROM, Conditional Search ROM, or Overdrive-Match ROM
       command"
      
      The function currently works perfectly fine in a multidrop bus, but when we
      have only a single slave connected, then only a Skip ROM is used and Match
      ROM is not called at all. This is leading to problems e.g. with single one
      DS2408 connected, as the Resume Command is not working properly and the
      device is responding with failing results after the Resume Command.
      
      This commit is fixing this by using a Skip ROM instead in those cases.
      The bandwidth / performance advantage is exactly the same.
      
      Refs:
      [1] https://datasheets.maximintegrated.com/en/ds/DS2408.pdfSigned-off-by: NMariusz Bialonczyk <manio@skyboo.net>
      Reviewed-by: NJean-Francois Dagenais <jeff.dagenais@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      99079cee
    • N
      sched/nohz: Run NOHZ idle load balancer on HK_FLAG_MISC CPUs · 07da741d
      Nicholas Piggin 提交于
      [ Upstream commit 9b019acb72e4b5741d88e8936d6f200ed44b66b2 ]
      
      The NOHZ idle balancer runs on the lowest idle CPU. This can
      interfere with isolated CPUs, so confine it to HK_FLAG_MISC
      housekeeping CPUs.
      
      HK_FLAG_SCHED is not used for this because it is not set anywhere
      at the moment. This could be folded into HK_FLAG_SCHED once that
      option is fixed.
      
      The problem was observed with increased jitter on an application
      running on CPU0, caused by NOHZ idle load balancing being run on
      CPU1 (an SMT sibling).
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20190412042613.28930-1-npiggin@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      07da741d
    • P
      s390/kexec_file: Fix detection of text segment in ELF loader · 216155aa
      Philipp Rudo 提交于
      [ Upstream commit 729829d775c9a5217abc784b2f16087d79c4eec8 ]
      
      To register data for the next kernel (command line, oldmem_base, etc.) the
      current kernel needs to find the ELF segment that contains head.S. This is
      currently done by checking ifor 'phdr->p_paddr == 0'. This works fine for
      the current kernel build but in theory the first few pages could be
      skipped. Make the detection more robust by checking if the entry point lies
      within the segment.
      Signed-off-by: NPhilipp Rudo <prudo@linux.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      216155aa
    • M
      scsi: qedi: Abort ep termination if offload not scheduled · 6697d0b3
      Manish Rangankar 提交于
      [ Upstream commit f848bfd8e167210a29374e8a678892bed591684f ]
      
      Sometimes during connection recovery when there is a failure to resolve
      ARP, and offload connection was not issued, driver tries to flush pending
      offload connection work which was not queued up.
      
      kernel: WARNING: CPU: 19 PID: 10110 at kernel/workqueue.c:3030 __flush_work.isra.34+0x19c/0x1b0
      kernel: CPU: 19 PID: 10110 Comm: iscsid Tainted: G W 5.1.0-rc4 #11
      kernel: Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 2.9.1 12/04/2018
      kernel: RIP: 0010:__flush_work.isra.34+0x19c/0x1b0
      kernel: Code: 8b fb 66 0f 1f 44 00 00 31 c0 eb ab 48 89 ef c6 07 00 0f 1f 40 00 fb 66 0f 1f 44 00 00 31 c0 eb 96 e8 08 16 fe ff 0f 0b eb 8d <0f> 0b 31 c0 eb 87 0f 1f 40 00 66 2e 0f 1
      f 84 00 00 00 00 00 0f 1f
      kernel: RSP: 0018:ffffa6b4054dba68 EFLAGS: 00010246
      kernel: RAX: 0000000000000000 RBX: ffff91df21c36fc0 RCX: 0000000000000000
      kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff91df21c36fc0
      kernel: RBP: ffff91df21c36ef0 R08: 0000000000000000 R09: 0000000000000000
      kernel: R10: 0000000000000038 R11: ffffa6b4054dbd60 R12: ffffffffc05e72c0
      kernel: R13: ffff91db10280820 R14: 0000000000000048 R15: 0000000000000000
      kernel: FS:  00007f5d83cc1740(0000) GS:ffff91df2f840000(0000) knlGS:0000000000000000
      kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      kernel: CR2: 0000000001cc5000 CR3: 0000000465450002 CR4: 00000000001606e0
      kernel: Call Trace:
      kernel: ? try_to_del_timer_sync+0x4d/0x80
      kernel: qedi_ep_disconnect+0x3b/0x410 [qedi]
      kernel: ? 0xffffffffc083c000
      kernel: ? klist_iter_exit+0x14/0x20
      kernel: ? class_find_device+0x93/0xf0
      kernel: iscsi_if_ep_disconnect.isra.18+0x58/0x70 [scsi_transport_iscsi]
      kernel: iscsi_if_recv_msg+0x10e2/0x1510 [scsi_transport_iscsi]
      kernel: ? copyout+0x22/0x30
      kernel: ? _copy_to_iter+0xa0/0x430
      kernel: ? _cond_resched+0x15/0x30
      kernel: ? __kmalloc_node_track_caller+0x1f9/0x270
      kernel: iscsi_if_rx+0xa5/0x1e0 [scsi_transport_iscsi]
      kernel: netlink_unicast+0x17f/0x230
      kernel: netlink_sendmsg+0x2d2/0x3d0
      kernel: sock_sendmsg+0x36/0x50
      kernel: ___sys_sendmsg+0x280/0x2a0
      kernel: ? timerqueue_add+0x54/0x80
      kernel: ? enqueue_hrtimer+0x38/0x90
      kernel: ? hrtimer_start_range_ns+0x19f/0x2c0
      kernel: __sys_sendmsg+0x58/0xa0
      kernel: do_syscall_64+0x5b/0x180
      kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
      Signed-off-by: NManish Rangankar <mrangankar@marvell.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6697d0b3
    • F
      rtc: stm32: manage the get_irq probe defer case · bc90af68
      Fabien Dessenne 提交于
      [ Upstream commit cf612c5949aca2bd81a1e28688957c8149ea2693 ]
      
      Manage the -EPROBE_DEFER error case for the wake IRQ.
      Signed-off-by: NFabien Dessenne <fabien.dessenne@st.com>
      Acked-by: NAmelie Delaunay <amelie.delaunay@st.com>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bc90af68
    • S
      rtc: 88pm860x: prevent use-after-free on device remove · 7fd0d9d1
      Sven Van Asbroeck 提交于
      [ Upstream commit f22b1ba15ee5785aa028384ebf77dd39e8e47b70 ]
      
      The device's remove() attempts to shut down the delayed_work scheduled
      on the kernel-global workqueue by calling flush_scheduled_work().
      
      Unfortunately, flush_scheduled_work() does not prevent the delayed_work
      from re-scheduling itself. The delayed_work might run after the device
      has been removed, and touch the already de-allocated info structure.
      This is a potential use-after-free.
      
      Fix by calling cancel_delayed_work_sync() during remove(): this ensures
      that the delayed work is properly cancelled, is no longer running, and
      is not able to re-schedule itself.
      
      This issue was detected with the help of Coccinelle.
      Signed-off-by: NSven Van Asbroeck <TheSven73@gmail.com>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7fd0d9d1
    • J
      iwlwifi: pcie: don't crash on invalid RX interrupt · 0ea8b7cf
      Johannes Berg 提交于
      [ Upstream commit 30f24eabab8cd801064c5c37589d803cb4341929 ]
      
      If for some reason the device gives us an RX interrupt before we're
      ready for it, perhaps during device power-on with misconfigured IRQ
      causes mapping or so, we can crash trying to access the queues.
      
      Prevent that by checking that we actually have RXQs and that they
      were properly allocated.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0ea8b7cf
    • Q
      btrfs: Don't panic when we can't find a root key · bd3d8f4c
      Qu Wenruo 提交于
      [ Upstream commit 7ac1e464c4d473b517bb784f30d40da1f842482e ]
      
      When we failed to find a root key in btrfs_update_root(), we just panic.
      
      That's definitely not cool, fix it by outputting an unique error
      message, aborting current transaction and return -EUCLEAN. This should
      not normally happen as the root has been used by the callers in some
      way.
      Reviewed-by: NFilipe Manana <fdmanana@suse.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: NQu Wenruo <wqu@suse.com>
      Reviewed-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bd3d8f4c
    • J
      btrfs: fix panic during relocation after ENOSPC before writeback happens · 431cbaec
      Josef Bacik 提交于
      [ Upstream commit ff612ba7849964b1898fd3ccd1f56941129c6aab ]
      
      We've been seeing the following sporadically throughout our fleet
      
      panic: kernel BUG at fs/btrfs/relocation.c:4584!
      netversion: 5.0-0
      Backtrace:
       #0 [ffffc90003adb880] machine_kexec at ffffffff81041da8
       #1 [ffffc90003adb8c8] __crash_kexec at ffffffff8110396c
       #2 [ffffc90003adb988] crash_kexec at ffffffff811048ad
       #3 [ffffc90003adb9a0] oops_end at ffffffff8101c19a
       #4 [ffffc90003adb9c0] do_trap at ffffffff81019114
       #5 [ffffc90003adba00] do_error_trap at ffffffff810195d0
       #6 [ffffc90003adbab0] invalid_op at ffffffff81a00a9b
          [exception RIP: btrfs_reloc_cow_block+692]
          RIP: ffffffff8143b614  RSP: ffffc90003adbb68  RFLAGS: 00010246
          RAX: fffffffffffffff7  RBX: ffff8806b9c32000  RCX: ffff8806aad00690
          RDX: ffff880850b295e0  RSI: ffff8806b9c32000  RDI: ffff88084f205bd0
          RBP: ffff880849415000   R8: ffffc90003adbbe0   R9: ffff88085ac90000
          R10: ffff8805f7369140  R11: 0000000000000000  R12: ffff880850b295e0
          R13: ffff88084f205bd0  R14: 0000000000000000  R15: 0000000000000000
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
       #7 [ffffc90003adbbb0] __btrfs_cow_block at ffffffff813bf1cd
       #8 [ffffc90003adbc28] btrfs_cow_block at ffffffff813bf4b3
       #9 [ffffc90003adbc78] btrfs_search_slot at ffffffff813c2e6c
      
      The way relocation moves data extents is by creating a reloc inode and
      preallocating extents in this inode and then copying the data into these
      preallocated extents.  Once we've done this for all of our extents,
      we'll write out these dirty pages, which marks the extent written, and
      goes into btrfs_reloc_cow_block().  From here we get our current
      reloc_control, which _should_ match the reloc_control for the current
      block group we're relocating.
      
      However if we get an ENOSPC in this path at some point we'll bail out,
      never initiating writeback on this inode.  Not a huge deal, unless we
      happen to be doing relocation on a different block group, and this block
      group is now rc->stage == UPDATE_DATA_PTRS.  This trips the BUG_ON() in
      btrfs_reloc_cow_block(), because we expect to be done modifying the data
      inode.  We are in fact done modifying the metadata for the data inode
      we're currently using, but not the one from the failed block group, and
      thus we BUG_ON().
      
      (This happens when writeback finishes for extents from the previous
      group, when we are at btrfs_finish_ordered_io() which updates the data
      reloc tree (inode item, drops/adds extent items, etc).)
      
      Fix this by writing out the reloc data inode always, and then breaking
      out of the loop after that point to keep from tripping this BUG_ON()
      later.
      Signed-off-by: NJosef Bacik <josef@toxicpanda.com>
      Reviewed-by: NFilipe Manana <fdmanana@suse.com>
      [ add note from Filipe ]
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      431cbaec
    • R
      Btrfs: fix data bytes_may_use underflow with fallocate due to failed quota reserve · 1084fc9a
      Robbie Ko 提交于
      [ Upstream commit 39ad317315887c2cb9a4347a93a8859326ddf136 ]
      
      When doing fallocate, we first add the range to the reserve_list and
      then reserve the quota.  If quota reservation fails, we'll release all
      reserved parts of reserve_list.
      
      However, cur_offset is not updated to indicate that this range is
      already been inserted into the list.  Therefore, the same range is freed
      twice.  Once at list_for_each_entry loop, and once at the end of the
      function.  This will result in WARN_ON on bytes_may_use when we free the
      remaining space.
      
      At the end, under the 'out' label we have a call to:
      
         btrfs_free_reserved_data_space(inode, data_reserved, alloc_start, alloc_end - cur_offset);
      
      The start offset, third argument, should be cur_offset.
      
      Everything from alloc_start to cur_offset was freed by the
      list_for_each_entry_safe_loop.
      
      Fixes: 18513091 ("btrfs: update btrfs_space_info's bytes_may_use timely")
      Reviewed-by: NFilipe Manana <fdmanana@suse.com>
      Signed-off-by: NRobbie Ko <robbieko@synology.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1084fc9a
    • N
      x86/modules: Avoid breaking W^X while loading modules · 8715ce03
      Nadav Amit 提交于
      [ Upstream commit f2c65fb3221adc6b73b0549fc7ba892022db9797 ]
      
      When modules and BPF filters are loaded, there is a time window in
      which some memory is both writable and executable. An attacker that has
      already found another vulnerability (e.g., a dangling pointer) might be
      able to exploit this behavior to overwrite kernel code. Prevent having
      writable executable PTEs in this stage.
      
      In addition, avoiding having W+X mappings can also slightly simplify the
      patching of modules code on initialization (e.g., by alternatives and
      static-key), as would be done in the next patch. This was actually the
      main motivation for this patch.
      
      To avoid having W+X mappings, set them initially as RW (NX) and after
      they are set as RO set them as X as well. Setting them as executable is
      done as a separate step to avoid one core in which the old PTE is cached
      (hence writable), and another which sees the updated PTE (executable),
      which would break the W^X protection.
      Suggested-by: NThomas Gleixner <tglx@linutronix.de>
      Suggested-by: NAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: NNadav Amit <namit@vmware.com>
      Signed-off-by: NRick Edgecombe <rick.p.edgecombe@intel.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: <akpm@linux-foundation.org>
      Cc: <ard.biesheuvel@linaro.org>
      Cc: <deneen.t.dock@intel.com>
      Cc: <kernel-hardening@lists.openwall.com>
      Cc: <kristen@linux.intel.com>
      Cc: <linux_dti@icloud.com>
      Cc: <will.deacon@arm.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Rik van Riel <riel@surriel.com>
      Link: https://lkml.kernel.org/r/20190426001143.4983-12-namit@vmware.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8715ce03
    • B
      scsi: qla2xxx: Fix hardirq-unsafe locking · 34f3a58f
      Bart Van Assche 提交于
      [ Upstream commit 300ec7415c1fed5c73660f50c8e14a67e236dc0a ]
      
      Since fc_remote_port_delete() must be called with interrupts enabled, do
      not disable interrupts when calling that function. Remove the lockin calls
      from around the put_sess() call. This is safe because the function that is
      called when the final reference is dropped, qlt_unreg_sess(), grabs the
      proper locks. This patch avoids that lockdep reports the following:
      
      WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
      kworker/2:1/62 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
      0000000009e679b3 (&(&k->k_lock)->rlock){+.+.}, at: klist_next+0x43/0x1d0
      
      and this task is already holding:
      00000000a033b71c (&(&ha->tgt.sess_lock)->rlock){-...}, at: qla24xx_delete_sess_fn+0x55/0xf0 [qla2xxx_scst]
      which would create a new lock dependency:
       (&(&ha->tgt.sess_lock)->rlock){-...} -> (&(&k->k_lock)->rlock){+.+.}
      
      but this new dependency connects a HARDIRQ-irq-safe lock:
       (&(&ha->tgt.sess_lock)->rlock){-...}
      
      ... which became HARDIRQ-irq-safe at:
        lock_acquire+0xe3/0x200
        _raw_spin_lock_irqsave+0x3d/0x60
        qla24xx_report_id_acquisition+0xa69/0xe30 [qla2xxx_scst]
        qla24xx_process_response_queue+0x69e/0x1270 [qla2xxx_scst]
        qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx_scst]
        __handle_irq_event_percpu+0x79/0x3c0
        handle_irq_event_percpu+0x70/0xf0
        handle_irq_event+0x5a/0x8b
        handle_edge_irq+0x12c/0x310
        handle_irq+0x192/0x20a
        do_IRQ+0x73/0x160
        ret_from_intr+0x0/0x1d
        default_idle+0x23/0x1f0
        arch_cpu_idle+0x15/0x20
        default_idle_call+0x35/0x40
        do_idle+0x2bb/0x2e0
        cpu_startup_entry+0x1d/0x20
        start_secondary+0x2a8/0x320
        secondary_startup_64+0xa4/0xb0
      
      to a HARDIRQ-irq-unsafe lock:
       (&(&k->k_lock)->rlock){+.+.}
      
      ... which became HARDIRQ-irq-unsafe at:
      ...
        lock_acquire+0xe3/0x200
        _raw_spin_lock+0x32/0x50
        klist_add_tail+0x33/0xb0
        device_add+0x7e1/0xb50
        device_create_groups_vargs+0x11c/0x150
        device_create_with_groups+0x89/0xb0
        vtconsole_class_init+0xb2/0x124
        do_one_initcall+0xc5/0x3ce
        kernel_init_freeable+0x295/0x32e
        kernel_init+0x11/0x11b
        ret_from_fork+0x3a/0x50
      
      other info that might help us debug this:
      
       Possible interrupt unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&(&k->k_lock)->rlock);
                                     local_irq_disable();
                                     lock(&(&ha->tgt.sess_lock)->rlock);
                                     lock(&(&k->k_lock)->rlock);
        <Interrupt>
          lock(&(&ha->tgt.sess_lock)->rlock);
      
       *** DEADLOCK ***
      
      3 locks held by kworker/2:1/62:
       #0: 00000000a4319c16 ((wq_completion)"qla2xxx_wq"){+.+.}, at: process_one_work+0x437/0xa80
       #1: 00000000ffa34c42 ((work_completion)(&sess->del_work)){+.+.}, at: process_one_work+0x437/0xa80
       #2: 00000000a033b71c (&(&ha->tgt.sess_lock)->rlock){-...}, at: qla24xx_delete_sess_fn+0x55/0xf0 [qla2xxx_scst]
      
      the dependencies between HARDIRQ-irq-safe lock and the holding lock:
      -> (&(&ha->tgt.sess_lock)->rlock){-...} ops: 8 {
         IN-HARDIRQ-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock_irqsave+0x3d/0x60
                          qla24xx_report_id_acquisition+0xa69/0xe30 [qla2xxx_scst]
                          qla24xx_process_response_queue+0x69e/0x1270 [qla2xxx_scst]
                          qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx_scst]
                          __handle_irq_event_percpu+0x79/0x3c0
                          handle_irq_event_percpu+0x70/0xf0
                          handle_irq_event+0x5a/0x8b
                          handle_edge_irq+0x12c/0x310
                          handle_irq+0x192/0x20a
                          do_IRQ+0x73/0x160
                          ret_from_intr+0x0/0x1d
                          default_idle+0x23/0x1f0
                          arch_cpu_idle+0x15/0x20
                          default_idle_call+0x35/0x40
                          do_idle+0x2bb/0x2e0
                          cpu_startup_entry+0x1d/0x20
                          start_secondary+0x2a8/0x320
                          secondary_startup_64+0xa4/0xb0
         INITIAL USE at:
                         lock_acquire+0xe3/0x200
                         _raw_spin_lock_irqsave+0x3d/0x60
                         qla24xx_report_id_acquisition+0xa69/0xe30 [qla2xxx_scst]
                         qla24xx_process_response_queue+0x69e/0x1270 [qla2xxx_scst]
                         qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx_scst]
                         __handle_irq_event_percpu+0x79/0x3c0
                         handle_irq_event_percpu+0x70/0xf0
                         handle_irq_event+0x5a/0x8b
                         handle_edge_irq+0x12c/0x310
                         handle_irq+0x192/0x20a
                         do_IRQ+0x73/0x160
                         ret_from_intr+0x0/0x1d
                         default_idle+0x23/0x1f0
                         arch_cpu_idle+0x15/0x20
                         default_idle_call+0x35/0x40
                         do_idle+0x2bb/0x2e0
                         cpu_startup_entry+0x1d/0x20
                         start_secondary+0x2a8/0x320
                         secondary_startup_64+0xa4/0xb0
       }
       ... key      at: [<ffffffffa0c0d080>] __key.85462+0x0/0xfffffffffff7df80 [qla2xxx_scst]
       ... acquired at:
         lock_acquire+0xe3/0x200
         _raw_spin_lock_irqsave+0x3d/0x60
         klist_next+0x43/0x1d0
         device_for_each_child+0x96/0x110
         scsi_target_block+0x3c/0x40 [scsi_mod]
         fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
         qla2x00_mark_device_lost+0xa0b/0xa30 [qla2xxx_scst]
         qlt_unreg_sess+0x1c6/0x380 [qla2xxx_scst]
         qla24xx_delete_sess_fn+0xe6/0xf0 [qla2xxx_scst]
         process_one_work+0x511/0xa80
         worker_thread+0x67/0x5b0
         kthread+0x1d2/0x1f0
         ret_from_fork+0x3a/0x50
      
      the dependencies between the lock to be acquired
       and HARDIRQ-irq-unsafe lock:
      -> (&(&k->k_lock)->rlock){+.+.} ops: 13831 {
         HARDIRQ-ON-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock+0x32/0x50
                          klist_add_tail+0x33/0xb0
                          device_add+0x7e1/0xb50
                          device_create_groups_vargs+0x11c/0x150
                          device_create_with_groups+0x89/0xb0
                          vtconsole_class_init+0xb2/0x124
                          do_one_initcall+0xc5/0x3ce
                          kernel_init_freeable+0x295/0x32e
                          kernel_init+0x11/0x11b
                          ret_from_fork+0x3a/0x50
         SOFTIRQ-ON-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock+0x32/0x50
                          klist_add_tail+0x33/0xb0
                          device_add+0x7e1/0xb50
                          device_create_groups_vargs+0x11c/0x150
                          device_create_with_groups+0x89/0xb0
                          vtconsole_class_init+0xb2/0x124
                          do_one_initcall+0xc5/0x3ce
                          kernel_init_freeable+0x295/0x32e
                          kernel_init+0x11/0x11b
                          ret_from_fork+0x3a/0x50
         INITIAL USE at:
                         lock_acquire+0xe3/0x200
                         _raw_spin_lock+0x32/0x50
                         klist_add_tail+0x33/0xb0
                         device_add+0x7e1/0xb50
                         device_create_groups_vargs+0x11c/0x150
                         device_create_with_groups+0x89/0xb0
                         vtconsole_class_init+0xb2/0x124
                         do_one_initcall+0xc5/0x3ce
                         kernel_init_freeable+0x295/0x32e
                         kernel_init+0x11/0x11b
                         ret_from_fork+0x3a/0x50
       }
       ... key      at: [<ffffffff83ed8780>] __key.15491+0x0/0x40
       ... acquired at:
         lock_acquire+0xe3/0x200
         _raw_spin_lock_irqsave+0x3d/0x60
         klist_next+0x43/0x1d0
         device_for_each_child+0x96/0x110
         scsi_target_block+0x3c/0x40 [scsi_mod]
         fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
         qla2x00_mark_device_lost+0xa0b/0xa30 [qla2xxx_scst]
         qlt_unreg_sess+0x1c6/0x380 [qla2xxx_scst]
         qla24xx_delete_sess_fn+0xe6/0xf0 [qla2xxx_scst]
         process_one_work+0x511/0xa80
         worker_thread+0x67/0x5b0
         kthread+0x1d2/0x1f0
         ret_from_fork+0x3a/0x50
      
      stack backtrace:
      CPU: 2 PID: 62 Comm: kworker/2:1 Tainted: G           O      5.0.7-dbg+ #8
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      Workqueue: qla2xxx_wq qla24xx_delete_sess_fn [qla2xxx_scst]
      Call Trace:
       dump_stack+0x86/0xca
       check_usage.cold.52+0x473/0x563
       __lock_acquire+0x11c0/0x23e0
       lock_acquire+0xe3/0x200
       _raw_spin_lock_irqsave+0x3d/0x60
       klist_next+0x43/0x1d0
       device_for_each_child+0x96/0x110
       scsi_target_block+0x3c/0x40 [scsi_mod]
       fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
       qla2x00_mark_device_lost+0xa0b/0xa30 [qla2xxx_scst]
       qlt_unreg_sess+0x1c6/0x380 [qla2xxx_scst]
       qla24xx_delete_sess_fn+0xe6/0xf0 [qla2xxx_scst]
       process_one_work+0x511/0xa80
       worker_thread+0x67/0x5b0
       kthread+0x1d2/0x1f0
       ret_from_fork+0x3a/0x50
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Acked-by: NHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      34f3a58f
    • B
      scsi: qla2xxx: Avoid that lockdep complains about unsafe locking in tcm_qla2xxx_close_session() · 6ce11687
      Bart Van Assche 提交于
      [ Upstream commit d4023db71108375e4194e92730ba0d32d7f07813 ]
      
      This patch avoids that lockdep reports the following warning:
      
      =====================================================
      WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
      5.1.0-rc1-dbg+ #11 Tainted: G        W
      -----------------------------------------------------
      rmdir/1478 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
      00000000e7ac4607 (&(&k->k_lock)->rlock){+.+.}, at: klist_next+0x43/0x1d0
      
      and this task is already holding:
      00000000cf0baf5e (&(&ha->tgt.sess_lock)->rlock){-...}, at: tcm_qla2xxx_close_session+0x57/0xb0 [tcm_qla2xxx]
      which would create a new lock dependency:
       (&(&ha->tgt.sess_lock)->rlock){-...} -> (&(&k->k_lock)->rlock){+.+.}
      
      but this new dependency connects a HARDIRQ-irq-safe lock:
       (&(&ha->tgt.sess_lock)->rlock){-...}
      
      ... which became HARDIRQ-irq-safe at:
        lock_acquire+0xe3/0x200
        _raw_spin_lock_irqsave+0x3d/0x60
        qla2x00_fcport_event_handler+0x1f3d/0x22b0 [qla2xxx]
        qla2x00_async_login_sp_done+0x1dc/0x1f0 [qla2xxx]
        qla24xx_process_response_queue+0xa37/0x10e0 [qla2xxx]
        qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx]
        __handle_irq_event_percpu+0x79/0x3c0
        handle_irq_event_percpu+0x70/0xf0
        handle_irq_event+0x5a/0x8b
        handle_edge_irq+0x12c/0x310
        handle_irq+0x192/0x20a
        do_IRQ+0x73/0x160
        ret_from_intr+0x0/0x1d
        default_idle+0x23/0x1f0
        arch_cpu_idle+0x15/0x20
        default_idle_call+0x35/0x40
        do_idle+0x2bb/0x2e0
        cpu_startup_entry+0x1d/0x20
        start_secondary+0x24d/0x2d0
        secondary_startup_64+0xa4/0xb0
      
      to a HARDIRQ-irq-unsafe lock:
       (&(&k->k_lock)->rlock){+.+.}
      
      ... which became HARDIRQ-irq-unsafe at:
      ...
        lock_acquire+0xe3/0x200
        _raw_spin_lock+0x32/0x50
        klist_add_tail+0x33/0xb0
        device_add+0x7f4/0xb60
        device_create_groups_vargs+0x11c/0x150
        device_create_with_groups+0x89/0xb0
        vtconsole_class_init+0xb2/0x124
        do_one_initcall+0xc5/0x3ce
        kernel_init_freeable+0x295/0x32e
        kernel_init+0x11/0x11b
        ret_from_fork+0x3a/0x50
      
      other info that might help us debug this:
      
       Possible interrupt unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&(&k->k_lock)->rlock);
                                     local_irq_disable();
                                     lock(&(&ha->tgt.sess_lock)->rlock);
                                     lock(&(&k->k_lock)->rlock);
        <Interrupt>
          lock(&(&ha->tgt.sess_lock)->rlock);
      
       *** DEADLOCK ***
      
      4 locks held by rmdir/1478:
       #0: 000000002c7f1ba4 (sb_writers#10){.+.+}, at: mnt_want_write+0x32/0x70
       #1: 00000000c85eb147 (&default_group_class[depth - 1]#2/1){+.+.}, at: do_rmdir+0x217/0x2d0
       #2: 000000002b164d6f (&sb->s_type->i_mutex_key#13){++++}, at: vfs_rmdir+0x7e/0x1d0
       #3: 00000000cf0baf5e (&(&ha->tgt.sess_lock)->rlock){-...}, at: tcm_qla2xxx_close_session+0x57/0xb0 [tcm_qla2xxx]
      
      the dependencies between HARDIRQ-irq-safe lock and the holding lock:
      -> (&(&ha->tgt.sess_lock)->rlock){-...} ops: 127 {
         IN-HARDIRQ-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock_irqsave+0x3d/0x60
                          qla2x00_fcport_event_handler+0x1f3d/0x22b0 [qla2xxx]
                          qla2x00_async_login_sp_done+0x1dc/0x1f0 [qla2xxx]
                          qla24xx_process_response_queue+0xa37/0x10e0 [qla2xxx]
                          qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx]
                          __handle_irq_event_percpu+0x79/0x3c0
                          handle_irq_event_percpu+0x70/0xf0
                          handle_irq_event+0x5a/0x8b
                          handle_edge_irq+0x12c/0x310
                          handle_irq+0x192/0x20a
                          do_IRQ+0x73/0x160
                          ret_from_intr+0x0/0x1d
                          default_idle+0x23/0x1f0
                          arch_cpu_idle+0x15/0x20
                          default_idle_call+0x35/0x40
                          do_idle+0x2bb/0x2e0
                          cpu_startup_entry+0x1d/0x20
                          start_secondary+0x24d/0x2d0
                          secondary_startup_64+0xa4/0xb0
         INITIAL USE at:
                         lock_acquire+0xe3/0x200
                         _raw_spin_lock_irqsave+0x3d/0x60
                         qla2x00_loop_resync+0xb3d/0x2690 [qla2xxx]
                         qla2x00_do_dpc+0xcee/0xf30 [qla2xxx]
                         kthread+0x1d2/0x1f0
                         ret_from_fork+0x3a/0x50
       }
       ... key      at: [<ffffffffa125f700>] __key.62804+0x0/0xfffffffffff7e900 [qla2xxx]
       ... acquired at:
         __lock_acquire+0x11ed/0x1b60
         lock_acquire+0xe3/0x200
         _raw_spin_lock_irqsave+0x3d/0x60
         klist_next+0x43/0x1d0
         device_for_each_child+0x96/0x110
         scsi_target_block+0x3c/0x40 [scsi_mod]
         fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
         qla2x00_mark_device_lost+0x4d3/0x500 [qla2xxx]
         qlt_unreg_sess+0x104/0x2c0 [qla2xxx]
         tcm_qla2xxx_close_session+0xa2/0xb0 [tcm_qla2xxx]
         target_shutdown_sessions+0x17b/0x190 [target_core_mod]
         core_tpg_del_initiator_node_acl+0xf3/0x1f0 [target_core_mod]
         target_fabric_nacl_base_release+0x25/0x30 [target_core_mod]
         config_item_release+0x9f/0x120 [configfs]
         config_item_put+0x29/0x2b [configfs]
         configfs_rmdir+0x3d2/0x520 [configfs]
         vfs_rmdir+0xb3/0x1d0
         do_rmdir+0x25c/0x2d0
         __x64_sys_rmdir+0x24/0x30
         do_syscall_64+0x77/0x220
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      the dependencies between the lock to be acquired
       and HARDIRQ-irq-unsafe lock:
      -> (&(&k->k_lock)->rlock){+.+.} ops: 14568 {
         HARDIRQ-ON-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock+0x32/0x50
                          klist_add_tail+0x33/0xb0
                          device_add+0x7f4/0xb60
                          device_create_groups_vargs+0x11c/0x150
                          device_create_with_groups+0x89/0xb0
                          vtconsole_class_init+0xb2/0x124
                          do_one_initcall+0xc5/0x3ce
                          kernel_init_freeable+0x295/0x32e
                          kernel_init+0x11/0x11b
                          ret_from_fork+0x3a/0x50
         SOFTIRQ-ON-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock+0x32/0x50
                          klist_add_tail+0x33/0xb0
                          device_add+0x7f4/0xb60
                          device_create_groups_vargs+0x11c/0x150
                          device_create_with_groups+0x89/0xb0
                          vtconsole_class_init+0xb2/0x124
                          do_one_initcall+0xc5/0x3ce
                          kernel_init_freeable+0x295/0x32e
                          kernel_init+0x11/0x11b
                          ret_from_fork+0x3a/0x50
         INITIAL USE at:
                         lock_acquire+0xe3/0x200
                         _raw_spin_lock+0x32/0x50
                         klist_add_tail+0x33/0xb0
                         device_add+0x7f4/0xb60
                         device_create_groups_vargs+0x11c/0x150
                         device_create_with_groups+0x89/0xb0
                         vtconsole_class_init+0xb2/0x124
                         do_one_initcall+0xc5/0x3ce
                         kernel_init_freeable+0x295/0x32e
                         kernel_init+0x11/0x11b
                         ret_from_fork+0x3a/0x50
       }
       ... key      at: [<ffffffff83f3d900>] __key.15805+0x0/0x40
       ... acquired at:
         __lock_acquire+0x11ed/0x1b60
         lock_acquire+0xe3/0x200
         _raw_spin_lock_irqsave+0x3d/0x60
         klist_next+0x43/0x1d0
         device_for_each_child+0x96/0x110
         scsi_target_block+0x3c/0x40 [scsi_mod]
         fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
         qla2x00_mark_device_lost+0x4d3/0x500 [qla2xxx]
         qlt_unreg_sess+0x104/0x2c0 [qla2xxx]
         tcm_qla2xxx_close_session+0xa2/0xb0 [tcm_qla2xxx]
         target_shutdown_sessions+0x17b/0x190 [target_core_mod]
         core_tpg_del_initiator_node_acl+0xf3/0x1f0 [target_core_mod]
         target_fabric_nacl_base_release+0x25/0x30 [target_core_mod]
         config_item_release+0x9f/0x120 [configfs]
         config_item_put+0x29/0x2b [configfs]
         configfs_rmdir+0x3d2/0x520 [configfs]
         vfs_rmdir+0xb3/0x1d0
         do_rmdir+0x25c/0x2d0
         __x64_sys_rmdir+0x24/0x30
         do_syscall_64+0x77/0x220
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      stack backtrace:
      CPU: 7 PID: 1478 Comm: rmdir Tainted: G        W         5.1.0-rc1-dbg+ #11
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      Call Trace:
       dump_stack+0x86/0xca
       check_usage.cold.59+0x473/0x563
       check_prev_add.constprop.43+0x1f1/0x1170
       __lock_acquire+0x11ed/0x1b60
       lock_acquire+0xe3/0x200
       _raw_spin_lock_irqsave+0x3d/0x60
       klist_next+0x43/0x1d0
       device_for_each_child+0x96/0x110
       scsi_target_block+0x3c/0x40 [scsi_mod]
       fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
       qla2x00_mark_device_lost+0x4d3/0x500 [qla2xxx]
       qlt_unreg_sess+0x104/0x2c0 [qla2xxx]
       tcm_qla2xxx_close_session+0xa2/0xb0 [tcm_qla2xxx]
       target_shutdown_sessions+0x17b/0x190 [target_core_mod]
       core_tpg_del_initiator_node_acl+0xf3/0x1f0 [target_core_mod]
       target_fabric_nacl_base_release+0x25/0x30 [target_core_mod]
       config_item_release+0x9f/0x120 [configfs]
       config_item_put+0x29/0x2b [configfs]
       configfs_rmdir+0x3d2/0x520 [configfs]
       vfs_rmdir+0xb3/0x1d0
       do_rmdir+0x25c/0x2d0
       __x64_sys_rmdir+0x24/0x30
       do_syscall_64+0x77/0x220
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Acked-by: NHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6ce11687
    • B
      scsi: qla2xxx: Fix abort handling in tcm_qla2xxx_write_pending() · 55b95ce8
      Bart Van Assche 提交于
      [ Upstream commit e209783d66bca04b5fce4429e59338517ffc1a0b ]
      
      Implementations of the .write_pending() callback functions must guarantee
      that an appropriate LIO core callback function will be called immediately or
      at a later time.  Make sure that this guarantee is met for aborted SCSI
      commands.
      
      [mkp: typo]
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Fixes: 694833ee ("scsi: tcm_qla2xxx: Do not allow aborted cmd to advance.") # v4.13.
      Fixes: a07100e0 ("qla2xxx: Fix TMR ABORT interaction issue between qla2xxx and TCM") # v4.5.
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Acked-by: NHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      55b95ce8
    • B
      scsi: qla2xxx: Fix a qla24xx_enable_msix() error path · de3cd35f
      Bart Van Assche 提交于
      [ Upstream commit 24afabdbd0b3553963a2bbf465895492b14d1107 ]
      
      Make sure that the allocated interrupts are freed if allocating memory for
      the msix_entries array fails.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Acked-by: NHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      de3cd35f
    • V
      sched/cpufreq: Fix kobject memleak · 73026db8
      Viresh Kumar 提交于
      [ Upstream commit 9a4f26cc98d81b67ecc23b890c28e2df324e29f3 ]
      
      Currently the error return path from kobject_init_and_add() is not
      followed by a call to kobject_put() - which means we are leaking
      the kobject.
      
      Fix it by adding a call to kobject_put() in the error path of
      kobject_init_and_add().
      Signed-off-by: NTobin C. Harding <tobin@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tobin C. Harding <tobin@kernel.org>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Link: http://lkml.kernel.org/r/20190430001144.24890-1-tobin@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      73026db8
    • N
      powerpc/watchdog: Use hrtimers for per-CPU heartbeat · 0fe8ed03
      Nicholas Piggin 提交于
      [ Upstream commit 7ae3f6e130e8dc6188b59e3b4ebc2f16e9c8d053 ]
      
      Using a jiffies timer creates a dependency on the tick_do_timer_cpu
      incrementing jiffies. If that CPU has locked up and jiffies is not
      incrementing, the watchdog heartbeat timer for all CPUs stops and
      creates false positives and confusing warnings on local CPUs, and
      also causes the SMP detector to stop, so the root cause is never
      detected.
      
      Fix this by using hrtimer based timers for the watchdog heartbeat,
      like the generic kernel hardlockup detector.
      
      Cc: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
      Reported-by: NRavikumar Bangoria <ravi.bangoria@in.ibm.com>
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Tested-by: NRavi Bangoria <ravi.bangoria@linux.ibm.com>
      Reported-by: NRavi Bangoria <ravi.bangoria@linux.ibm.com>
      Reviewed-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0fe8ed03
    • Q
      arm64: Fix compiler warning from pte_unmap() with -Wunused-but-set-variable · efa336f7
      Qian Cai 提交于
      [ Upstream commit 74dd022f9e6260c3b5b8d15901d27ebcc5f21eda ]
      
      When building with -Wunused-but-set-variable, the compiler shouts about
      a number of pte_unmap() users, since this expands to an empty macro on
      arm64:
      
        | mm/gup.c: In function 'gup_pte_range':
        | mm/gup.c:1727:16: warning: variable 'ptem' set but not used
        | [-Wunused-but-set-variable]
        | mm/gup.c: At top level:
        | mm/memory.c: In function 'copy_pte_range':
        | mm/memory.c:821:24: warning: variable 'orig_dst_pte' set but not used
        | [-Wunused-but-set-variable]
        | mm/memory.c:821:9: warning: variable 'orig_src_pte' set but not used
        | [-Wunused-but-set-variable]
        | mm/swap_state.c: In function 'swap_ra_info':
        | mm/swap_state.c:641:15: warning: variable 'orig_pte' set but not used
        | [-Wunused-but-set-variable]
        | mm/madvise.c: In function 'madvise_free_pte_range':
        | mm/madvise.c:318:9: warning: variable 'orig_pte' set but not used
        | [-Wunused-but-set-variable]
      
      Rewrite pte_unmap() as a static inline function, which silences the
      warnings.
      Signed-off-by: NQian Cai <cai@lca.pw>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      efa336f7
    • M
      ARM: vdso: Remove dependency with the arch_timer driver internals · 9152b081
      Marc Zyngier 提交于
      [ Upstream commit 1f5b62f09f6b314c8d70b9de5182dae4de1f94da ]
      
      The VDSO code uses the kernel helper that was originally designed
      to abstract the access between 32 and 64bit systems. It worked so
      far because this function is declared as 'inline'.
      
      As we're about to revamp that part of the code, the VDSO would
      break. Let's fix it by doing what should have been done from
      the start, a proper system register access.
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9152b081
    • F
      media: stm32-dcmi: return appropriate error codes during probe · 2d201767
      Fabien Dessenne 提交于
      [ Upstream commit b5b5a27bee5884860798ffd0f08e611a3942064b ]
      
      During probe, return the provided errors value instead of -ENODEV.
      This allows the driver to be deferred probed if needed.
      Signed-off-by: NFabien Dessenne <fabien.dessenne@st.com>
      Acked-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>
      2d201767
    • J
      drm/nouveau/bar/nv50: ensure BAR is mapped · 5744fd7f
      Jon Derrick 提交于
      [ Upstream commit f10b83de1fd49216a4c657816f48001437e4bdd5 ]
      
      If the BAR is zero size, it indicates it was never successfully mapped.
      Ensure that the BAR is valid during initialization before attempting to
      use it.
      Signed-off-by: NJon Derrick <jonathan.derrick@intel.com>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5744fd7f
    • P
      ACPI / property: fix handling of data_nodes in acpi_get_next_subnode() · 07bb9a71
      Pierre-Louis Bossart 提交于
      [ Upstream commit 23583f7795025e3c783b680d906509366b0906ad ]
      
      When the DSDT tables expose devices with subdevices and a set of
      hierarchical _DSD properties, the data returned by
      acpi_get_next_subnode() is incorrect, with the results suggesting a bad
      pointer assignment. The parser works fine with device_nodes or
      data_nodes, but not with a combination of the two.
      
      The problem is traced to an invalid pointer used when jumping from
      handling device_nodes to data nodes. The existing code looks for data
      nodes below the last subdevice found instead of the common root. Fix
      by forcing the acpi_device pointer to be derived from the same fwnode
      for the two types of subnodes.
      
      This same problem of handling device and data nodes was already fixed
      in a similar way by 'commit bf4703fd ("ACPI / property: fix data
      node parsing in acpi_get_next_subnode()")' but broken later by 'commit
      34055190 ("ACPI / property: Add fwnode_get_next_child_node()")', so
      this should probably go to linux-stable all the way to 4.12
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      07bb9a71
    • D
      brcm80211: potential NULL dereference in brcmf_cfg80211_vndr_cmds_dcmd_handler() · c00f0fbd
      Dan Carpenter 提交于
      [ Upstream commit e025da3d7aa4770bb1d1b3b0aa7cc4da1744852d ]
      
      If "ret_len" is negative then it could lead to a NULL dereference.
      
      The "ret_len" value comes from nl80211_vendor_cmd(), if it's negative
      then we don't allocate the "dcmd_buf" buffer.  Then we pass "ret_len" to
      brcmf_fil_cmd_data_set() where it is cast to a very high u32 value.
      Most of the functions in that call tree check whether the buffer we pass
      is NULL but there are at least a couple places which don't such as
      brcmf_dbg_hex_dump() and brcmf_msgbuf_query_dcmd().  We memcpy() to and
      from the buffer so it would result in a NULL dereference.
      
      The fix is to change the types so that "ret_len" can't be negative.  (If
      we memcpy() zero bytes to NULL, that's a no-op and doesn't cause an
      issue).
      
      Fixes: 1bacb048 ("brcmfmac: replace cfg80211 testmode with vendor command")
      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>
      c00f0fbd
    • F
      spi: pxa2xx: fix SCR (divisor) calculation · 57667dc8
      Flavio Suligoi 提交于
      [ Upstream commit 29f2133717c527f492933b0622a4aafe0b3cbe9e ]
      
      Calculate the divisor for the SCR (Serial Clock Rate), avoiding
      that the SSP transmission rate can be greater than the device rate.
      
      When the division between the SSP clock and the device rate generates
      a reminder, we have to increment by one the divisor.
      In this way the resulting SSP clock will never be greater than the
      device SPI max frequency.
      
      For example, with:
      
       - ssp_clk  = 50 MHz
       - dev freq = 15 MHz
      
      without this patch the SSP clock will be greater than 15 MHz:
      
       - 25 MHz for PXA25x_SSP and CE4100_SSP
       - 16,56 MHz for the others
      
      Instead, with this patch, we have in both case an SSP clock of 12.5MHz,
      so the max rate of the SPI device clock is respected.
      Signed-off-by: NFlavio Suligoi <f.suligoi@asem.it>
      Reviewed-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Reviewed-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      57667dc8
    • A
      ASoC: imx: fix fiq dependencies · 5cf668cf
      Arnd Bergmann 提交于
      [ Upstream commit ea751227c813ab833609afecfeedaf0aa26f327e ]
      
      During randconfig builds, I occasionally run into an invalid configuration
      of the freescale FIQ sound support:
      
      WARNING: unmet direct dependencies detected for SND_SOC_IMX_PCM_FIQ
        Depends on [m]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_IMX_SOC [=m]
        Selected by [y]:
        - SND_SOC_FSL_SPDIF [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_IMX_SOC [=m]!=n && (MXC_TZIC [=n] || MXC_AVIC [=y])
      
      sound/soc/fsl/imx-ssi.o: In function `imx_ssi_remove':
      imx-ssi.c:(.text+0x28): undefined reference to `imx_pcm_fiq_exit'
      sound/soc/fsl/imx-ssi.o: In function `imx_ssi_probe':
      imx-ssi.c:(.text+0xa64): undefined reference to `imx_pcm_fiq_init'
      
      The Kconfig warning is a result of the symbol being defined inside of
      the "if SND_IMX_SOC" block, and is otherwise harmless. The link error
      is more tricky and happens with SND_SOC_IMX_SSI=y, which may or may not
      imply FIQ support. However, if SND_SOC_FSL_SSI is set to =m at the same
      time, that selects SND_SOC_IMX_PCM_FIQ as a loadable module dependency,
      which then causes a link failure from imx-ssi.
      
      The solution here is to make SND_SOC_IMX_PCM_FIQ built-in whenever
      one of its potential users is built-in.
      
      Fixes: ff40260f ("ASoC: fsl: refine DMA/FIQ dependencies")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5cf668cf
    • A
      powerpc/perf: Fix loop exit condition in nest_imc_event_init · b8bd069f
      Anju T Sudhakar 提交于
      [ Upstream commit 860b7d2286236170a36f94946d03ca9888d32571 ]
      
      The data structure (i.e struct imc_mem_info) to hold the memory address
      information for nest imc units is allocated based on the number of nodes
      in the system.
      
      nest_imc_event_init() traverse this struct array to calculate the memory
      base address for the event-cpu. If we fail to find a match for the event
      cpu's chip-id in imc_mem_info struct array, then the do-while loop will
      iterate until we crash.
      
      Fix this by changing the loop exit condition based on the number of
      non zero vbase elements in the array, since the allocation is done for
      nr_chips + 1.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Fixes: 885dcd70 ("powerpc/perf: Add nest IMC PMU support")
      Signed-off-by: NAnju T Sudhakar <anju@linux.vnet.ibm.com>
      Reviewed-by: NMadhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b8bd069f
    • B
      powerpc/boot: Fix missing check of lseek() return value · 1a6767f5
      Bo YU 提交于
      [ Upstream commit 5d085ec04a000fefb5182d3b03ee46ca96d8389b ]
      
      This is detected by Coverity scan: CID: 1440481
      Signed-off-by: NBo YU <tsu.yubo@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1a6767f5
    • A
      powerpc/perf: Return accordingly on invalid chip-id in · 74185394
      Anju T Sudhakar 提交于
      [ Upstream commit a913e5e8b43be1d3897a141ce61c1ec071cad89c ]
      
      Nest hardware counter memory resides in a per-chip reserve-memory.
      During nest_imc_event_init(), chip-id of the event-cpu is considered to
      calculate the base memory addresss for that cpu. Return, proper error
      condition if the chip_id calculated is invalid.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Fixes: 885dcd70 ("powerpc/perf: Add nest IMC PMU support")
      Reviewed-by: NMadhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Signed-off-by: NAnju T Sudhakar <anju@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      74185394
    • J
      ASoC: hdmi-codec: unlock the device on startup errors · 49c0fa1f
      Jerome Brunet 提交于
      [ Upstream commit 30180e8436046344b12813dc954b2e01dfdcd22d ]
      
      If the hdmi codec startup fails, it should clear the current_substream
      pointer to free the device. This is properly done for the audio_startup()
      callback but for snd_pcm_hw_constraint_eld().
      
      Make sure the pointer cleared if an error is reported.
      Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      49c0fa1f
    • M
      usb: dwc3: move synchronize_irq() out of the spinlock protected block · 66341171
      Marek Szyprowski 提交于
      [ Upstream commit 41a91c606e7d2b74358a944525267cc451c271e8 ]
      
      dwc3_gadget_suspend() is called under dwc->lock spinlock. In such context
      calling synchronize_irq() is not allowed. Move the problematic call out
      of the protected block to fix the following kernel BUG during system
      suspend:
      
      BUG: sleeping function called from invalid context at kernel/irq/manage.c:112
      in_atomic(): 1, irqs_disabled(): 128, pid: 1601, name: rtcwake
      6 locks held by rtcwake/1601:
       #0: f70ac2a2 (sb_writers#7){.+.+}, at: vfs_write+0x130/0x16c
       #1: b5fe1270 (&of->mutex){+.+.}, at: kernfs_fop_write+0xc0/0x1e4
       #2: 7e597705 (kn->count#60){.+.+}, at: kernfs_fop_write+0xc8/0x1e4
       #3: 8b3527d0 (system_transition_mutex){+.+.}, at: pm_suspend+0xc4/0xc04
       #4: fc7f1c42 (&dev->mutex){....}, at: __device_suspend+0xd8/0x74c
       #5: 4b36507e (&(&dwc->lock)->rlock){....}, at: dwc3_gadget_suspend+0x24/0x3c
      irq event stamp: 11252
      hardirqs last  enabled at (11251): [<c09c54a4>] _raw_spin_unlock_irqrestore+0x6c/0x74
      hardirqs last disabled at (11252): [<c09c4d44>] _raw_spin_lock_irqsave+0x1c/0x5c
      softirqs last  enabled at (9744): [<c0102564>] __do_softirq+0x3a4/0x66c
      softirqs last disabled at (9737): [<c0128528>] irq_exit+0x140/0x168
      Preemption disabled at:
      [<00000000>]   (null)
      CPU: 7 PID: 1601 Comm: rtcwake Not tainted
      5.0.0-rc3-next-20190122-00039-ga3f4ee4f8a52 #5252
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [<c01110f0>] (unwind_backtrace) from [<c010d120>] (show_stack+0x10/0x14)
      [<c010d120>] (show_stack) from [<c09a4d04>] (dump_stack+0x90/0xc8)
      [<c09a4d04>] (dump_stack) from [<c014c700>] (___might_sleep+0x22c/0x2c8)
      [<c014c700>] (___might_sleep) from [<c0189d68>] (synchronize_irq+0x28/0x84)
      [<c0189d68>] (synchronize_irq) from [<c05cbbf8>] (dwc3_gadget_suspend+0x34/0x3c)
      [<c05cbbf8>] (dwc3_gadget_suspend) from [<c05bd020>] (dwc3_suspend_common+0x154/0x410)
      [<c05bd020>] (dwc3_suspend_common) from [<c05bd34c>] (dwc3_suspend+0x14/0x2c)
      [<c05bd34c>] (dwc3_suspend) from [<c051c730>] (platform_pm_suspend+0x2c/0x54)
      [<c051c730>] (platform_pm_suspend) from [<c05285d4>] (dpm_run_callback+0xa4/0x3dc)
      [<c05285d4>] (dpm_run_callback) from [<c0528a40>] (__device_suspend+0x134/0x74c)
      [<c0528a40>] (__device_suspend) from [<c052c508>] (dpm_suspend+0x174/0x588)
      [<c052c508>] (dpm_suspend) from [<c0182134>] (suspend_devices_and_enter+0xc0/0xe74)
      [<c0182134>] (suspend_devices_and_enter) from [<c0183658>] (pm_suspend+0x770/0xc04)
      [<c0183658>] (pm_suspend) from [<c0180ddc>] (state_store+0x6c/0xcc)
      [<c0180ddc>] (state_store) from [<c09a9a70>] (kobj_attr_store+0x14/0x20)
      [<c09a9a70>] (kobj_attr_store) from [<c02d6800>] (sysfs_kf_write+0x4c/0x50)
      [<c02d6800>] (sysfs_kf_write) from [<c02d594c>] (kernfs_fop_write+0xfc/0x1e4)
      [<c02d594c>] (kernfs_fop_write) from [<c02593d8>] (__vfs_write+0x2c/0x160)
      [<c02593d8>] (__vfs_write) from [<c0259694>] (vfs_write+0xa4/0x16c)
      [<c0259694>] (vfs_write) from [<c0259870>] (ksys_write+0x40/0x8c)
      [<c0259870>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
      Exception stack(0xed55ffa8 to 0xed55fff0)
      ...
      
      Fixes: 01c10880d242 ("usb: dwc3: gadget: synchronize_irq dwc irq in suspend")
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      66341171
    • M
      usb: dwc2: gadget: Increase descriptors count for ISOC's · 1a7be0fe
      Minas Harutyunyan 提交于
      [ Upstream commit 54f37f56631747075f1f9a2f0edf6ba405e3e66c ]
      
      Some function drivers queueing more than 128 ISOC requests at a time.
      To avoid "descriptor chain full" cases, increasing descriptors count
      from MAX_DMA_DESC_NUM_GENERIC to MAX_DMA_DESC_NUM_HS_ISOC for ISOC's
      only.
      Signed-off-by: NMinas Harutyunyan <hminas@synopsys.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1a7be0fe
    • M
      ASoC: Intel: kbl_da7219_max98357a: Map BTN_0 to KEY_PLAYPAUSE · fc8c5907
      Mac Chiang 提交于
      [ Upstream commit 16ec5dfe0327ddcf279957bffe4c8fe527088c63 ]
      
      On kbl_rt5663_max98927, commit 38a5882e
          ("ASoC: Intel: kbl_rt5663_max98927: Map BTN_0 to KEY_PLAYPAUSE")
          This key pair mapping to play/pause when playing Youtube
      
      The Android 3.5mm Headset jack specification mentions that BTN_0 should
      be mapped to KEY_MEDIA, but this is less logical than KEY_PLAYPAUSE,
      which has much broader userspace support.
      
      For example, the Chrome OS userspace now supports KEY_PLAYPAUSE to toggle
      play/pause of videos and audio, but does not handle KEY_MEDIA.
      
      Furthermore, Android itself now supports KEY_PLAYPAUSE equivalently, as the
      new USB headset spec requires KEY_PLAYPAUSE for BTN_0.
      https://source.android.com/devices/accessories/headset/usb-headset-spec
      
      The same fix is required on Chrome kbl_da7219_max98357a.
      Signed-off-by: NMac Chiang <mac.chiang@intel.com>
      Reviewed-by: NBenson Leung <bleung@chromium.org>
      Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fc8c5907
    • W
      pinctrl: zte: fix leaked of_node references · b676f6c0
      Wen Yang 提交于
      [ Upstream commit 02d15f0d80720545f1f4922a1550ea4aaad4e152 ]
      
      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:
      ./drivers/pinctrl/zte/pinctrl-zx.c:415:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 407, but without a corresponding object release within this function.
      ./drivers/pinctrl/zte/pinctrl-zx.c:422:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 407, but without a corresponding object release within this function.
      ./drivers/pinctrl/zte/pinctrl-zx.c:436:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 407, but without a corresponding object release within this function.
      ./drivers/pinctrl/zte/pinctrl-zx.c:444:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 407, but without a corresponding object release within this function.
      ./drivers/pinctrl/zte/pinctrl-zx.c:448:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 407, 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: Jun Nie <jun.nie@linaro.org>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: linux-gpio@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Acked-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b676f6c0