1. 26 Jan, 2019 40 commits
    • Jonas Danielsson's avatar
      mmc: atmel-mci: do not assume idle after atmci_request_end · aa0703b7
      Jonas Danielsson authored
      [ Upstream commit ae460c11 ]
      On our AT91SAM9260 board we use the same sdio bus for wifi and for the
      sd card slot. This caused the atmel-mci to give the following splat on
      the serial console:
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 538 at drivers/mmc/host/atmel-mci.c:859 atmci_send_command+0x24/0x44
        Modules linked in:
        CPU: 0 PID: 538 Comm: mmcqd/0 Not tainted 4.14.76 #14
        Hardware name: Atmel AT91SAM9
        [<c000fccc>] (unwind_backtrace) from [<c000d3dc>] (show_stack+0x10/0x14)
        [<c000d3dc>] (show_stack) from [<c0017644>] (__warn+0xd8/0xf4)
        [<c0017644>] (__warn) from [<c0017704>] (warn_slowpath_null+0x1c/0x24)
        [<c0017704>] (warn_slowpath_null) from [<c033bb9c>] (atmci_send_command+0x24/0x44)
        [<c033bb9c>] (atmci_send_command) from [<c033e984>] (atmci_start_request+0x1f4/0x2dc)
        [<c033e984>] (atmci_start_request) from [<c033f3b4>] (atmci_request+0xf0/0x164)
        [<c033f3b4>] (atmci_request) from [<c0327108>] (mmc_start_request+0x280/0x2d0)
        [<c0327108>] (mmc_start_request) from [<c032800c>] (mmc_start_areq+0x230/0x330)
        [<c032800c>] (mmc_start_areq) from [<c03366f8>] (mmc_blk_issue_rw_rq+0xc4/0x310)
        [<c03366f8>] (mmc_blk_issue_rw_rq) from [<c03372c4>] (mmc_blk_issue_rq+0x118/0x5ac)
        [<c03372c4>] (mmc_blk_issue_rq) from [<c033781c>] (mmc_queue_thread+0xc4/0x118)
        [<c033781c>] (mmc_queue_thread) from [<c002daf8>] (kthread+0x100/0x118)
        [<c002daf8>] (kthread) from [<c000a580>] (ret_from_fork+0x14/0x34)
        ---[ end trace 594371ddfa284bd6 ]---
      This is:
      This was fixed on our board by letting atmci_request_end determine what
      state we are in. Instead of unconditionally setting it to STATE_IDLE on
      Signed-off-by: default avatarJonas Danielsson <[email protected]>
      Signed-off-by: default avatarUlf Hansson <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Masahiro Yamada's avatar
      kconfig: fix memory leak when EOF is encountered in quotation · 507a004e
      Masahiro Yamada authored
      [ Upstream commit fbac5977 ]
      An unterminated string literal followed by new line is passed to the
      parser (with "multi-line strings not supported" warning shown), then
      handled properly there.
      On the other hand, an unterminated string literal at end of file is
      never passed to the parser, then results in memory leak.
      [Test Code]
        ----------(Kconfig begin)----------
        source "Kconfig.inc"
        config A
                bool "a"
        -----------(Kconfig end)-----------
        --------(Kconfig.inc begin)--------
        config B
                bool "b\No new line at end of file
        ---------(Kconfig.inc end)---------
      [Summary from Valgrind]
        Before the fix:
          LEAK SUMMARY:
             definitely lost: 16 bytes in 1 blocks
        After the fix:
          LEAK SUMMARY:
             definitely lost: 0 bytes in 0 blocks
      Eliminate the memory leak path by handling this case. Of course, such
      a Kconfig file is wrong already, so I will add an error message later.
      Signed-off-by: default avatarMasahiro Yamada <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Masahiro Yamada's avatar
      kconfig: fix file name and line number of warn_ignored_character() · c0a4b0c7
      Masahiro Yamada authored
      [ Upstream commit 77c1c0fa ]
      Currently, warn_ignore_character() displays invalid file name and
      line number.
      The lexer should use current_file->name and yylineno, while the parser
      should use zconf_curname() and zconf_lineno().
      This difference comes from that the lexer is always going ahead
      of the parser. The parser needs to look ahead one token to make a
      shift/reduce decision, so the lexer is requested to scan more text
      from the input file.
      This commit fixes the warning message from warn_ignored_character().
      [Test Code]
        ----(Kconfig begin)----
        -----(Kconfig end)-----
        Before the fix:
        <none>:0:warning: ignoring unsupported character '/'
        After the fix:
        Kconfig:1:warning: ignoring unsupported character '/'
      Signed-off-by: default avatarMasahiro Yamada <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Reinette Chatre's avatar
      x86/resctrl: Fix rdt_find_domain() return value and checks · 8edd32a1
      Reinette Chatre authored
      [ Upstream commit 52eb7433 ]
      rdt_find_domain() returns an ERR_PTR() that is generated from a provided
      domain id when the value is negative.
      Care needs to be taken when creating an ERR_PTR() from this value
      because a subsequent check using IS_ERR() expects the error to
      be within the MAX_ERRNO range. Using an invalid domain id as an
      ERR_PTR() does work at this time since this is currently always -1.
      Using this undocumented assumption is fragile since future users of
      rdt_find_domain() may not be aware of thus assumption.
      Two related issues are addressed:
      - Ensure that rdt_find_domain() always returns a valid error value by
      forcing the error to be -ENODEV when a negative domain id is provided.
      - In a few instances the return value of rdt_find_domain() is just
      checked for NULL - fix these to include a check of ERR_PTR.
      Fixes: d89b7379 ("x86/intel_rdt/cqm: Add mon_data")
      Fixes: 521348b0 ("x86/intel_rdt: Introduce utility to obtain CDP peer")
      Signed-off-by: default avatarReinette Chatre <[email protected]>
      Signed-off-by: default avatarBorislav Petkov <[email protected]>
      Cc: "H. Peter Anvin" <[email protected]>
      Cc: Ingo Molnar <[email protected]>
      Cc: Thomas Gleixner <[email protected]>
      Cc: Tony Luck <[email protected]>
      Cc: [email protected]
      Cc: [email protected]
      Cc: [email protected]
      Cc: x86-ml <[email protected]>
      Link: https://lkml.kernel.org/r/b88cd4ff[email protected]intel.comSigned-off-by: default avatarSasha Levin <[email protected]>
    • Minas Harutyunyan's avatar
      usb: dwc2: Fix disable all EP's on disconnect · c92de95a
      Minas Harutyunyan authored
      [ Upstream commit 4fe4f9fe ]
      Disabling all EP's allow to reset EP's to initial state.
      Introduced new function dwc2_hsotg_ep_disable_lock() which
      before calling dwc2_hsotg_ep_disable() function acquire
      hsotg->lock and release on exiting.
      From dwc2_hsotg_ep_disable() function removed acquiring
      In dwc2_hsotg_core_init_disconnected() function when USB
      reset interrupt asserted disabling all ep’s by
      dwc2_hsotg_ep_disable() function.
      This updates eliminating sparse imbalance warnings.
      Reverted changes in dwc2_hostg_disconnect() function.
      Introduced new function dwc2_hsotg_ep_disable_lock().
      Changed dwc2_hsotg_ep_ops. Now disable point to
      dwc2_hsotg_ep_disable_lock() function.
      In functions dwc2_hsotg_udc_stop() and dwc2_hsotg_suspend()
      dwc2_hsotg_ep_disable() function replaced by
      dwc2_hsotg_ep_disable_lock() function.
      In dwc2_hsotg_ep_disable() function removed acquiring
      of hsotg->lock.
      Fixes: dccf1bad ("usb: dwc2: Disable all EP's on disconnect")
      Signed-off-by: default avatarMinas Harutyunyan <[email protected]>
      Signed-off-by: default avatarFelipe Balbi <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Jiong Wang's avatar
      bpf: relax verifier restriction on BPF_MOV | BPF_ALU · 525cd39f
      Jiong Wang authored
      [ Upstream commit e434b8cd ]
      Currently, the destination register is marked as unknown for 32-bit
      sub-register move (BPF_MOV | BPF_ALU) whenever the source register type is
      This is too conservative that some valid cases will be rejected.
      Especially, this may turn a constant scalar value into unknown value that
      could break some assumptions of verifier.
      For example, test_l4lb_noinline.c has the following C code:
          struct real_definition *dst
      1:  if (!get_packet_dst(&dst, &pckt, vip_info, is_ipv6))
      2:    return TC_ACT_SHOT;
      4:  if (dst->flags & F_IPV6) {
      get_packet_dst is responsible for initializing "dst" into valid pointer and
      return true (1), otherwise return false (0). The compiled instruction
      sequence using alu32 will be:
        412: (54) (u32) r7 &= (u32) 1
        413: (bc) (u32) r0 = (u32) r7
        414: (95) exit
      insn 413, a BPF_MOV | BPF_ALU, however will turn r0 into unknown value even
      r7 contains SCALAR_VALUE 1.
      This causes trouble when verifier is walking the code path that hasn't
      initialized "dst" inside get_packet_dst, for which case 0 is returned and
      we would then expect verifier concluding line 1 in the above C code pass
      the "if" check, therefore would skip fall through path starting at line 4.
      Now, because r0 returned from callee has became unknown value, so verifier
      won't skip analyzing path starting at line 4 and "dst->flags" requires
      dereferencing the pointer "dst" which actually hasn't be initialized for
      this path.
      This patch relaxed the code marking sub-register move destination. For a
      SCALAR_VALUE, it is safe to just copy the value from source then truncate
      it into 32-bit.
      A unit test also included to demonstrate this issue. This test will fail
      before this patch.
      This relaxation could let verifier skipping more paths for conditional
      comparison against immediate. It also let verifier recording a more
      accurate/strict value for one register at one state, if this state end up
      with going through exit without rejection and it is used for state
      comparison later, then it is possible an inaccurate/permissive value is
      better. So the real impact on verifier processed insn number is complex.
      But in all, without this fix, valid program could be rejected.
      >From real benchmarking on kernel selftests and Cilium bpf tests, there is
      no impact on processed instruction number when tests ares compiled with
      default compilation options. There is slightly improvements when they are
      compiled with -mattr=+alu32 after this patch.
      Also, test_xdp_noinline/-mattr=+alu32 now passed verification. It is
      rejected before this fix.
      Insn processed before/after this patch:
                              default     -mattr=+alu32
      Kernel selftest
      test_xdp.o              371/371      369/369
      test_l4lb.o             6345/6345    5623/5623
      test_xdp_noinline.o     2971/2971    rejected/2727
      test_tcp_estates.o      429/429      430/430
      Cilium bpf
      bpf_lb-DLB_L3.o:        2085/2085     1685/1687
      bpf_lb-DLB_L4.o:        2287/2287     1986/1982
      bpf_lb-DUNKNOWN.o:      690/690       622/622
      bpf_lxc.o:              95033/95033   N/A
      bpf_netdev.o:           7245/7245     N/A
      bpf_overlay.o:          2898/2898     3085/2947
        - bpf_lxc.o and bpf_netdev.o compiled by -mattr=+alu32 are rejected by
          verifier due to another issue inside verifier on supporting alu32
        - Each cilium bpf program could generate several processed insn number,
          above number is sum of them.
       - Restrict the change on SCALAR_VALUE.
       - Update benchmark numbers on Cilium bpf tests.
      Signed-off-by: default avatarJiong Wang <[email protected]>
      Signed-off-by: default avatarAlexei Starovoitov <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Will Deacon's avatar
      arm64: Fix minor issues with the dcache_by_line_op macro · 26463188
      Will Deacon authored
      [ Upstream commit 33309ecd ]
      The dcache_by_line_op macro suffers from a couple of small problems:
      First, the GAS directives that are currently being used rely on
      assembler behavior that is not documented, and probably not guaranteed
      to produce the correct behavior going forward. As a result, we end up
      with some undefined symbols in cache.o:
      $ nm arch/arm64/mm/cache.o
               U civac
               U cvac
               U cvap
               U cvau
      This is due to the fact that the comparisons used to select the
      operation type in the dcache_by_line_op macro are comparing symbols
      not strings, and even though it seems that GAS is doing the right
      thing here (undefined symbols by the same name are equal to each
      other), it seems unwise to rely on this.
      Second, when patching in a DC CVAP instruction on CPUs that support it,
      the fallback path consists of a DC CVAU instruction which may be
      affected by CPU errata that require ARM64_WORKAROUND_CLEAN_CACHE.
      Solve these issues by unrolling the various maintenance routines and
      using the conditional directives that are documented as operating on
      strings. To avoid the complexity of nested alternatives, we move the
      DC CVAP patching to __clean_dcache_area_pop, falling back to a branch
      to __clean_dcache_area_poc if DCPOP is not supported by the CPU.
      Reported-by: default avatarArd Biesheuvel <[email protected]>
      Suggested-by: default avatarRobin Murphy <[email protected]>
      Signed-off-by: default avatarWill Deacon <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Lucas Stach's avatar
      clk: imx6q: reset exclusive gates on init · cc3620b8
      Lucas Stach authored
      [ Upstream commit f7542d81 ]
      The exclusive gates may be set up in the wrong way by software running
      before the clock driver comes up. In that case the exclusive setup is
      locked in its initial state, as the complementary function can't be
      activated without disabling the initial setup first.
      To avoid this lock situation, reset the exclusive gates to the off
      state and allow the kernel to provide the proper setup.
      Signed-off-by: default avatarLucas Stach <[email protected]>
      Reviewed-by: default avatarDong Aisheng <[email protected]>
      Signed-off-by: default avatarStephen Boyd <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Qian Cai's avatar
      arm64: kasan: Increase stack size for KASAN_EXTRA · 4694db1b
      Qian Cai authored
      [ Upstream commit 6e883067 ]
      If the kernel is configured with KASAN_EXTRA, the stack size is
      increased significantly due to setting the GCC -fstack-reuse option to
      "none" [1]. As a result, it can trigger a stack overrun quite often with
      32k stack size compiled using GCC 8. For example, this reproducer
      can trigger a "corrupted stack end detected inside scheduler" very
      reliably with CONFIG_SCHED_STACK_END_CHECK enabled. There are other
      reports at:
        https://lore.kernel.org/lkml/[email protected]/
        https://lore.kernel.org/lkml/[email protected]/
      There are just too many functions that could have a large stack with
      KASAN_EXTRA due to large local variables that have been called over and
      over again without being able to reuse the stacks. Some noticiable ones
      7536 shrink_inactive_list
      7440 shrink_page_list
      6560 fscache_stats_show
      3920 jbd2_journal_commit_transaction
      3216 try_to_unmap_one
      3072 migrate_page_move_mapping
      3584 migrate_misplaced_transhuge_page
      3920 ip_vs_lblcr_schedule
      4304 lpfc_nvme_info_show
      3888 lpfc_debugfs_nvmestat_data.constprop
      There are other 49 functions over 2k in size while compiling kernel with
      "-Wframe-larger-than=" on this machine. Hence, it is too much work to
      change Makefiles for each object to compile without
      -fsanitize-address-use-after-scope individually.
      [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c23Signed-off-by: default avatarQian Cai <[email protected]>
      Signed-off-by: default avatarWill Deacon <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Dmitry V. Levin's avatar
      selftests: do not macro-expand failed assertion expressions · 3fef5905
      Dmitry V. Levin authored
      [ Upstream commit b708a3cc ]
      I've stumbled over the current macro-expand behaviour of the test
      $ gcc -Wall -xc - <<'__EOF__'
      TEST(macro) {
      	int status = 0;
      $ ./a.out
      [==========] Running 1 tests from 1 test cases.
      [ RUN      ] global.macro
      <stdin>:4:global.macro:Expected 0 (0) != (((signed char) (((status) & 0x7f) + 1) >> 1) > 0) (0)
      global.macro: Test terminated by assertion
      [     FAIL ] global.macro
      [==========] 0 / 1 tests passed.
      [  FAILED  ]
      With this change the output of the same test looks much more
      [==========] Running 1 tests from 1 test cases.
      [ RUN      ] global.macro
      <stdin>:4:global.macro:Expected 0 (0) != WIFSIGNALED(status) (0)
      global.macro: Test terminated by assertion
      [     FAIL ] global.macro
      [==========] 0 / 1 tests passed.
      [  FAILED  ]
      The issue is very similar to the bug fixed in glibc assert(3)
      three years ago:
      Cc: Shuah Khan <[email protected]>
      Cc: Kees Cook <[email protected]>
      Cc: Andy Lutomirski <[email protected]>
      Cc: Will Drewry <[email protected]>
      Cc: [email protected]
      Signed-off-by: default avatarDmitry V. Levin <[email protected]>
      Acked-by: default avatarKees Cook <[email protected]>
      Signed-off-by: default avatarShuah Khan <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Bart Van Assche's avatar
      scsi: target/core: Make sure that target_wait_for_sess_cmds() waits long enough · 6c05aea6
      Bart Van Assche authored
      [ Upstream commit ad669505 ]
      A session must only be released after all code that accesses the session
      structure has finished. Make sure that this is the case by introducing a
      new command counter per session that is only decremented after the
      .release_cmd() callback has finished. This patch fixes the following crash:
      BUG: KASAN: use-after-free in do_raw_spin_lock+0x1c/0x130
      Read of size 4 at addr ffff8801534b16e4 by task rmdir/14805
      CPU: 16 PID: 14805 Comm: rmdir Not tainted 4.18.0-rc2-dbg+ #5
      Call Trace:
      srpt_set_ch_state+0x27/0x70 [ib_srpt]
      srpt_disconnect_ch+0x1b/0xc0 [ib_srpt]
      srpt_close_session+0xa8/0x260 [ib_srpt]
      target_shutdown_sessions+0x170/0x180 [target_core_mod]
      core_tpg_del_initiator_node_acl+0xf3/0x200 [target_core_mod]
      target_fabric_nacl_base_release+0x25/0x30 [target_core_mod]
      config_item_release+0x9c/0x110 [configfs]
      config_item_put+0x26/0x30 [configfs]
      configfs_rmdir+0x3b8/0x510 [configfs]
      Cc: Nicholas Bellinger <[email protected]>
      Cc: Mike Christie <[email protected]>
      Cc: Christoph Hellwig <[email protected]>
      Cc: David Disseldorp <[email protected]>
      Cc: Hannes Reinecke <[email protected]>
      Signed-off-by: default avatarBart Van Assche <[email protected]>
      Signed-off-by: Martin K. Petersen's avatarMartin K. Petersen <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • David Disseldorp's avatar
      scsi: target: use consistent left-aligned ASCII INQUIRY data · 074a5fa4
      David Disseldorp authored
      [ Upstream commit 0de26357 ]
      spc5r17.pdf specifies:
        4.3.1 ASCII data field requirements
        ASCII data fields shall contain only ASCII printable characters (i.e.,
        code values 20h to 7Eh) and may be terminated with one or more ASCII null
        (00h) characters.  ASCII data fields described as being left-aligned
        shall have any unused bytes at the end of the field (i.e., highest
        offset) and the unused bytes shall be filled with ASCII space characters
      LIO currently space-pads the T10 VENDOR IDENTIFICATION and PRODUCT
      IDENTIFICATION fields in the standard INQUIRY data. However, the PRODUCT
      REVISION LEVEL field in the standard INQUIRY data as well as the T10 VENDOR
      IDENTIFICATION field in the INQUIRY Device Identification VPD Page are
      Fix this inconsistency by using space-padding for all of the above fields.
      Signed-off-by: default avatarDavid Disseldorp <[email protected]>
      Reviewed-by: default avatarChristoph Hellwig <[email protected]>
      Reviewed-by: default avatarBryant G. Ly <[email protected]>
      Reviewed-by: default avatarLee Duncan <[email protected]>
      Reviewed-by: default avatarHannes Reinecke <[email protected]>
      Reviewed-by: Roman Bolshakov's avatarRoman Bolshakov <[email protected]>
      Signed-off-by: Martin K. Petersen's avatarMartin K. Petersen <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • yupeng820921's avatar
      net: call sk_dst_reset when set SO_DONTROUTE · 221fed3a
      yupeng820921 authored
      [ Upstream commit 0fbe82e6 ]
      after set SO_DONTROUTE to 1, the IP layer should not route packets if
      the dest IP address is not in link scope. But if the socket has cached
      the dst_entry, such packets would be routed until the sk_dst_cache
      expires. So we should clean the sk_dst_cache when a user set
      SO_DONTROUTE option. Below are server/client python scripts which
      could reprodue this issue:
      server side code:
      import socket
      import struct
      import time
      s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
      s.bind(('', 9000))
      sock, addr = s.accept()
      sock.setsockopt(socket.SOL_SOCKET, socket.SO_DONTROUTE, struct.pack('i', 1))
      while True:
      client side code:
      import socket
      import time
      s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
      s.connect(('server_address', 9000))
      while True:
          data = s.recv(1024)
      Signed-off-by: yupeng820921's avataryupeng <[email protected]>
      Signed-off-by: default avatarDavid S. Miller <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Gao Xiang's avatar
      staging: erofs: fix use-after-free of on-stack `z_erofs_vle_unzip_io' · 54d0b69a
      Gao Xiang authored
      [ Upstream commit 848bd9ac ]
      The root cause is the race as follows:
       Thread #0                         Thread #1
       z_erofs_vle_unzip_kickoff         z_erofs_submit_and_unzip
                                          struct z_erofs_vle_unzip_io io[]
                                          [end of function]
      Fix it by taking the waitqueue lock between atomic_add_return and
      wake_up to close such the race.
      kernel message:
      Unable to handle kernel paging request at virtual address 97f7052caa1303dc
      Workqueue: kverityd verity_work
      task: ffffffe32bcb8000 task.stack: ffffffe3298a0000
      PC is at __wake_up_common+0x48/0xa8
      LR is at __wake_up+0x3c/0x58
      Call trace:
      [<ffffff94a08ff648>] __wake_up_common+0x48/0xa8
      [<ffffff94a08ff8b8>] __wake_up+0x3c/0x58
      [<ffffff94a0c11b60>] z_erofs_vle_unzip_kickoff+0x40/0x64
      [<ffffff94a0c118e4>] z_erofs_vle_read_endio+0x94/0x134
      [<ffffff94a0c83c9c>] bio_endio+0xe4/0xf8
      [<ffffff94a1076540>] dec_pending+0x134/0x32c
      [<ffffff94a1076f28>] clone_endio+0x90/0xf4
      [<ffffff94a0c83c9c>] bio_endio+0xe4/0xf8
      [<ffffff94a1095024>] verity_work+0x210/0x368
      [<ffffff94a08c4150>] process_one_work+0x188/0x4b4
      [<ffffff94a08c45bc>] worker_thread+0x140/0x458
      [<ffffff94a08cad48>] kthread+0xec/0x108
      [<ffffff94a0883ab4>] ret_from_fork+0x10/0x1c
      Code: d1006273 54000260 f9400804 b9400019 (b85fc081)
      ---[ end trace be9dde154f677cd1 ]---
      Reviewed-by: default avatarChao Yu <[email protected]>
      Signed-off-by: default avatarGao Xiang <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Vivek Gautam's avatar
      media: venus: core: Set dma maximum segment size · 181aa135
      Vivek Gautam authored
      [ Upstream commit de2563bc ]
      Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
      [  460.308650] ------------[ cut here ]------------
      [  460.313490] qcom-venus aa00000.video-codec: DMA-API: mapping sg segment longer than device claims to support [len=4194304] [max=65536]
      [  460.326017] WARNING: CPU: 3 PID: 3555 at src/kernel/dma/debug.c:1301 debug_dma_map_sg+0x174/0x254
      [  460.338888] Modules linked in: venus_dec venus_enc videobuf2_dma_sg videobuf2_memops hci_uart btqca bluetooth venus_core v4l2_mem2mem videobuf2_v4l2 videobuf2_common ath10k_snoc ath10k_core ath lzo lzo_compress zramjoydev
      [  460.375811] CPU: 3 PID: 3555 Comm: V4L2DecoderThre Tainted: G        W         4.19.1 #82
      [  460.384223] Hardware name: Google Cheza (rev1) (DT)
      [  460.389251] pstate: 60400009 (nZCv daif +PAN -UAO)
      [  460.394191] pc : debug_dma_map_sg+0x174/0x254
      [  460.398680] lr : debug_dma_map_sg+0x174/0x254
      [  460.403162] sp : ffffff80200c37d0
      [  460.406583] x29: ffffff80200c3830 x28: 0000000000010000
      [  460.412056] x27: 00000000ffffffff x26: ffffffc0f785ea80
      [  460.417532] x25: 0000000000000000 x24: ffffffc0f4ea1290
      [  460.423001] x23: ffffffc09e700300 x22: ffffffc0f4ea1290
      [  460.428470] x21: ffffff8009037000 x20: 0000000000000001
      [  460.433936] x19: ffffff80091b0000 x18: 0000000000000000
      [  460.439411] x17: 0000000000000000 x16: 000000000000f251
      [  460.444885] x15: 0000000000000006 x14: 0720072007200720
      [  460.450354] x13: ffffff800af536e0 x12: 0000000000000000
      [  460.455822] x11: 0000000000000000 x10: 0000000000000000
      [  460.461288] x9 : 537944d9c6c48d00 x8 : 537944d9c6c48d00
      [  460.466758] x7 : 0000000000000000 x6 : ffffffc0f8d98f80
      [  460.472230] x5 : 0000000000000000 x4 : 0000000000000000
      [  460.477703] x3 : 000000000000008a x2 : ffffffc0fdb13948
      [  460.483170] x1 : ffffffc0fdb0b0b0 x0 : 000000000000007a
      [  460.488640] Call trace:
      [  460.491165]  debug_dma_map_sg+0x174/0x254
      [  460.495307]  vb2_dma_sg_alloc+0x260/0x2dc [videobuf2_dma_sg]
      [  460.501150]  __vb2_queue_alloc+0x164/0x374 [videobuf2_common]
      [  460.507076]  vb2_core_reqbufs+0xfc/0x23c [videobuf2_common]
      [  460.512815]  vb2_reqbufs+0x44/0x5c [videobuf2_v4l2]
      [  460.517853]  v4l2_m2m_reqbufs+0x44/0x78 [v4l2_mem2mem]
      [  460.523144]  v4l2_m2m_ioctl_reqbufs+0x1c/0x28 [v4l2_mem2mem]
      [  460.528976]  v4l_reqbufs+0x30/0x40
      [  460.532480]  __video_do_ioctl+0x36c/0x454
      [  460.536610]  video_usercopy+0x25c/0x51c
      [  460.540572]  video_ioctl2+0x38/0x48
      [  460.544176]  v4l2_ioctl+0x60/0x74
      [  460.547602]  do_video_ioctl+0x948/0x3520
      [  460.551648]  v4l2_compat_ioctl32+0x60/0x98
      [  460.555872]  __arm64_compat_sys_ioctl+0x134/0x20c
      [  460.560718]  el0_svc_common+0x9c/0xe4
      [  460.564498]  el0_svc_compat_handler+0x2c/0x38
      [  460.568982]  el0_svc_compat+0x8/0x18
      [  460.572672] ---[ end trace ce209b87b2f3af88 ]---
      >From above warning one would deduce that the sg segment will overflow
      the device's capacity. In reality, the hardware can accommodate larger
      sg segments.
      So, initialize the max segment size properly to weed out this warning.
      Based on a similar patch sent by Sean Paul for mdss:
      https://patchwork.kernel.org/patch/10671457/Signed-off-by: default avatarVivek Gautam <[email protected]>
      Acked-by: default avatarStanimir Varbanov <[email protected]>
      Signed-off-by: default avatarHans Verkuil <[email protected]>
      Signed-off-by: default avatarMauro Carvalho Chehab <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Leo Yan's avatar
      coresight: tmc: Fix bad register address for CLAIM · b436f384
      Leo Yan authored
      [ Upstream commit 323ed1e0 ]
      Commit 4d3ebd36 ("coreisght: tmc: Claim device before use") uses
      CLAIM tag to validate if the device is available, it needs to pass
      the device base address to access related registers.
      In the function tmc_etb_disable_hw() it wrongly passes the driver data
      pointer as register base address, thus it's easily to produce the kernel
      warning info like below:
      [   83.579898] WARNING: CPU: 4 PID: 2970 at drivers/hwtracing/coresight/coresight.c:207 coresight_disclaim_device_unlocked+0x44/0x80
      [   83.591448] Modules linked in:
      [   83.594485] CPU: 4 PID: 2970 Comm: uname Not tainted 4.19.0-rc6-00417-g721b509 #110
      [   83.602067] Hardware name: ARM Juno development board (r2) (DT)
      [   83.607932] pstate: 80000085 (Nzcv daIf -PAN -UAO)
      [   83.612681] pc : coresight_disclaim_device_unlocked+0x44/0x80
      [   83.618375] lr : coresight_disclaim_device_unlocked+0x44/0x80
      [   83.624064] sp : ffff00000fe3ba20
      [   83.627347] x29: ffff00000fe3ba20 x28: ffff80002d430dc0
      [   83.632618] x27: ffff800033177c00 x26: ffff80002eb44480
      [   83.637889] x25: 0000000000000001 x24: ffff800033c72600
      [   83.643160] x23: ffff0000099b11f8 x22: ffff0000099b11c8
      [   83.648430] x21: 0000000000000002 x20: ffff800033a90418
      [   83.653701] x19: ffff0000099b11c8 x18: 0000000000000000
      [   83.658971] x17: 0000000000000000 x16: 0000000000000000
      [   83.664241] x15: 0000000000000000 x14: 0000000000000000
      [   83.669511] x13: 0000000000000000 x12: 0000000000000000
      [   83.674782] x11: 0000000000000000 x10: 0000000000000000
      [   83.680052] x9 : 0000000000000000 x8 : 0000000000000001
      [   83.685322] x7 : 0000000000010000 x6 : ffff800033ebab18
      [   83.690593] x5 : ffff800033ebab18 x4 : ffff800033e6c698
      [   83.695862] x3 : 0000000000000001 x2 : 0000000000000000
      [   83.701133] x1 : 0000000000000000 x0 : 0000000000000001
      [   83.706404] Call trace:
      [   83.708830]  coresight_disclaim_device_unlocked+0x44/0x80
      [   83.714180]  coresight_disclaim_device+0x34/0x48
      [   83.718756]  tmc_disable_etf_sink+0xc4/0xf0
      [   83.722902]  coresight_disable_path_from+0xc8/0x240
      [   83.727735]  coresight_disable_path+0x24/0x30
      [   83.732053]  etm_event_stop+0x130/0x170
      [   83.735854]  etm_event_del+0x24/0x30
      [   83.739399]  event_sched_out.isra.51+0xcc/0x1e8
      [   83.743887]  group_sched_out.part.53+0x44/0xb0
      [   83.748291]  ctx_sched_out+0x298/0x2b8
      [   83.752005]  task_ctx_sched_out+0x74/0xa8
      [   83.755980]  perf_event_exit_task+0x140/0x418
      [   83.760298]  do_exit+0x3f4/0xcf0
      [   83.763497]  do_group_exit+0x5c/0xc0
      [   83.767041]  __arm64_sys_exit_group+0x24/0x28
      [   83.771359]  el0_svc_common+0x110/0x178
      [   83.775160]  el0_svc_handler+0x94/0xe8
      [   83.778875]  el0_svc+0x8/0xc
      [   83.781728] ---[ end trace 02d8d8eac46db9e5 ]---
      This patch is to fix this bug by using 'drvdata->base' as the
      register base address for CLAIM related operation.
      Fixes: 4d3ebd36 ("coreisght: tmc: Claim device before use")
      Cc: Suzuki Poulose <[email protected]>
      Cc: Mathieu Poirier <[email protected]>
      Cc: Mike Leach <[email protected]>
      Cc: Robert Walker <[email protected]>
      Signed-off-by: default avatarLeo Yan <[email protected]>
      Reviewed-by: default avatarSuzuki K Poulose <[email protected]>
      Signed-off-by: default avatarMathieu Poirier <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Yu Zhao's avatar
      ASoC: use dma_ops of parent device for acp_audio_dma · b4ba1c27
      Yu Zhao authored
      [ Upstream commit 23aa128b ]
      AMD platform device acp_audio_dma can only be created by parent PCI
      device driver (drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c). Pass struct
      device of the parent to snd_pcm_lib_preallocate_pages() so
      dma_alloc_coherent() can use correct dma_ops. Otherwise, it will
      use default dma_ops which is nommu_dma_ops on x86_64 even when
      IOMMU is enabled and set to non passthrough mode.
      Though platform device inherits some dma related fields during its
      creation in mfd_add_device(), we can't simply pass its struct device
      to snd_pcm_lib_preallocate_pages() because dma_ops is not among the
      inherited fields. Even it were, drivers/iommu/amd_iommu.c would
      ignore it because get_device_id() doesn't handle platform device.
      This change shouldn't give us any trouble even struct device of the
      parent becomes null or represents some non PCI device in the future,
      because get_dma_ops() correctly handles null struct device or uses
      the default dma_ops if struct device doesn't have it set.
      Signed-off-by: default avatarYu Zhao <[email protected]>
      Signed-off-by: default avatarMark Brown <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Nathan Chancellor's avatar
      media: firewire: Fix app_info parameter type in avc_ca{,_app}_info · e6256cb1
      Nathan Chancellor authored
      [ Upstream commit b2e9a4ed ]
      Clang warns:
      drivers/media/firewire/firedtv-avc.c:999:45: warning: implicit
      conversion from 'int' to 'char' changes value from 159 to -97
              app_info[0] = (EN50221_TAG_APP_INFO >> 16) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      drivers/media/firewire/firedtv-avc.c:1000:45: warning: implicit
      conversion from 'int' to 'char' changes value from 128 to -128
              app_info[1] = (EN50221_TAG_APP_INFO >>  8) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      drivers/media/firewire/firedtv-avc.c:1040:44: warning: implicit
      conversion from 'int' to 'char' changes value from 159 to -97
              app_info[0] = (EN50221_TAG_CA_INFO >> 16) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      drivers/media/firewire/firedtv-avc.c:1041:44: warning: implicit
      conversion from 'int' to 'char' changes value from 128 to -128
              app_info[1] = (EN50221_TAG_CA_INFO >>  8) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      4 warnings generated.
      Change app_info's type to unsigned char to match the type of the
      member msg in struct ca_msg, which is the only thing passed into the
      app_info parameter in this function.
      Link: https://github.com/ClangBuiltLinux/linux/issues/105Signed-off-by: Nathan Chancellor's avatarNathan Chancellor <[email protected]>
      Signed-off-by: default avatarMauro Carvalho Chehab <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]kernel.org>
    • Ard Biesheuvel's avatar
      arm64: relocatable: fix inconsistencies in linker script and options · 8799dd0b
      Ard Biesheuvel authored
      [ Upstream commit 3bbd3db8 ]
      readelf complains about the section layout of vmlinux when building
      with CONFIG_RELOCATABLE=y (for KASLR):
        readelf: Warning: [21]: Link field (0) should index a symtab section.
        readelf: Warning: [21]: Info field (0) should index a relocatable section.
      Also, it seems that our use of '-pie -shared' is contradictory, and
      thus ambiguous. In general, the way KASLR is wired up at the moment
      is highly tailored to how ld.bfd happens to implement (and conflate)
      PIE executables and shared libraries, so given the current effort to
      support other toolchains, let's fix some of these issues as well.
      - Drop the -pie linker argument and just leave -shared. In ld.bfd,
        the differences between them are unclear (except for the ELF type
        of the produced image [0]) but lld chokes on seeing both at the
        same time.
      - Rename the .rela output section to .rela.dyn, as is customary for
        shared libraries and PIE executables, so that it is not misidentified
        by readelf as a static relocation section (producing the warnings
      - Pass the -z notext and -z norelro options to explicitly instruct the
        linker to permit text relocations, and to omit the RELRO program
        header (which requires a certain section layout that we don't adhere
        to in the kernel). These are the defaults for current versions of
      - Discard .eh_frame and .gnu.hash sections to avoid them from being
        emitted between .head.text and .text, screwing up the section layout.
      These changes only affect the ELF image, and produce the same binary
      [0] b9dce7f1 ("arm64: kernel: force ET_DYN ELF type for ...")
      Cc: Nick Desaulniers <[email protected]>
      Cc: Peter Smith <[email protected]>
      Tested-by: default avatarNick Desaulniers <[email protected]>
      Signed-off-by: default avatarArd Biesheuvel <[email protected]>
      Signed-off-by: default avatarWill Deacon <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Breno Leitao's avatar
      powerpc/pseries/cpuidle: Fix preempt warning · a95bc96d
      Breno Leitao authored
      [ Upstream commit 2b038cbc ]
      When booting a pseries kernel with PREEMPT enabled, it dumps the
      following warning:
         BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
         caller is pseries_processor_idle_init+0x5c/0x22c
         CPU: 13 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc3-00090-g12201a0128bc-dirty #828
         Call Trace:
         [c000000429437ab0] [c0000000009c8878] dump_stack+0xec/0x164 (unreliable)
         [c000000429437b00] [c0000000005f2f24] check_preemption_disabled+0x154/0x160
         [c000000429437b90] [c000000000cab8e8] pseries_processor_idle_init+0x5c/0x22c
         [c000000429437c10] [c000000000010ed4] do_one_initcall+0x64/0x300
         [c000000429437ce0] [c000000000c54500] kernel_init_freeable+0x3f0/0x500
         [c000000429437db0] [c0000000000112dc] kernel_init+0x2c/0x160
         [c000000429437e20] [c00000000000c1d0] ret_from_kernel_thread+0x5c/0x6c
      This happens because the code calls get_lppaca() which calls
      get_paca() and it checks if preemption is disabled through
      Preemption should be disabled because the per CPU variable may make no
      sense if there is a preemption (and a CPU switch) after it reads the
      per CPU data and when it is used.
      In this device driver specifically, it is not a problem, because this
      code just needs to have access to one lppaca struct, and it does not
      matter if it is the current per CPU lppaca struct or not (i.e. when
      there is a preemption and a CPU migration).
      That said, the most appropriate fix seems to be related to avoiding
      the debug_smp_processor_id() call at get_paca(), instead of calling
      preempt_disable() before get_paca().
      Signed-off-by: default avatarBreno Leitao <[email protected]>
      Signed-off-by: Michael Ellerman's avatarMichael Ellerman <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Breno Leitao's avatar
      powerpc/xmon: Fix invocation inside lock region · 8196c073
      Breno Leitao authored
      [ Upstream commit 8d4a8622 ]
      Currently xmon needs to get devtree_lock (through rtas_token()) during its
      invocation (at crash time). If there is a crash while devtree_lock is being
      held, then xmon tries to get the lock but spins forever and never get into
      the interactive debugger, as in the following case:
      	int *ptr = NULL;
      	raw_spin_lock_irqsave(&devtree_lock, flags);
      	*ptr = 0xdeadbeef;
      This patch avoids calling rtas_token(), thus trying to get the same lock,
      at crash time. This new mechanism proposes getting the token at
      initialization time (xmon_init()) and just consuming it at crash time.
      This would allow xmon to be possible invoked independent of devtree_lock
      being held or not.
      Signed-off-by: default avatarBreno Leitao <[email protected]>
      Reviewed-by: default avatarThiago Jung Bauermann <[email protected]>
      Signed-off-by: Michael Ellerman's avatarMichael Ellerman <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Daniel Axtens's avatar
      media: uvcvideo: Refactor teardown of uvc on USB disconnect · 13e97606
      Daniel Axtens authored
      [ Upstream commit 10e1fdb9 ]
      Currently, disconnecting a USB webcam while it is in use prints out a
      number of warnings, such as:
      WARNING: CPU: 2 PID: 3118 at /build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237 sysfs_remove_group+0x8b/0x90
      sysfs group ffffffffa7cd0780 not found for kobject 'event13'
      This has been noticed before. [0]
      This is because of the order in which things are torn down.
      If there are no streams active during a USB disconnect:
       - uvc_disconnect() is invoked via device_del() through the bus
         notifier mechanism.
       - this calls uvc_unregister_video().
       - uvc_unregister_video() unregisters the video device for each
       - because there are no streams open, it calls uvc_delete()
       - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
         input device.
       - uvc_delete() calls media_device_unregister(), which cleans up the
         media device
       - uvc_delete(), uvc_unregister_video() and uvc_disconnect() all
         return, and we end up back in device_del().
       - device_del() then cleans up the sysfs folder for the camera with
         dpm_sysfs_remove(). Because uvc_status_cleanup() and
         media_device_unregister() have already been called, this all works
      If, on the other hand, there *are* streams active during a USB disconnect:
       - uvc_disconnect() is invoked
       - this calls uvc_unregister_video()
       - uvc_unregister_video() unregisters the video device for each
       - uvc_unregister_video() and uvc_disconnect() return, and we end up
         back in device_del().
       - device_del() then cleans up the sysfs folder for the camera with
         dpm_sysfs_remove(). Because the status input device and the media
         device are children of the USB device, this also deletes their
         sysfs folders.
       - Sometime later, the final stream is closed, invoking uvc_release().
       - uvc_release() calls uvc_delete()
       - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
         input device. Because the sysfs directory has already been removed,
         this causes a WARNing.
       - uvc_delete() calls media_device_unregister(), which cleans up the
         media device. Because the sysfs directory has already been removed,
         this causes another WARNing.
      To fix this, we need to make sure the devices are always unregistered
      before the end of uvc_disconnect(). To this, move the unregistration
      into the disconnect path:
       - split uvc_status_cleanup() into two parts, one on disconnect that
         unregisters and one on delete that frees.
       - move v4l2_device_unregister() and media_device_unregister() into
         the disconnect path.
      [0]: https://lkml.org/lkml/2016/12/8/657
      [Renamed uvc_input_cleanup() to uvc_input_unregister()]
      Signed-off-by: default avatarDaniel Axtens <[email protected]>
      Acked-by: default avatarGreg Kroah-Hartman <[email protected]>
      Signed-off-by: Laurent Pinchart's avatarLaurent Pinchart <[email protected]>
      Signed-off-by: default avatarMauro Carvalho Chehab <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Joel Fernandes (Google)'s avatar
      pstore/ram: Do not treat empty buffers as valid · 9e969ba4
      Joel Fernandes (Google) authored
      [ Upstream commit 30696378 ]
      The ramoops backend currently calls persistent_ram_save_old() even
      if a buffer is empty. While this appears to work, it is does not seem
      like the right thing to do and could lead to future bugs so lets avoid
      that. It also prevents misleading prints in the logs which claim the
      buffer is valid.
      I got something like:
      	found existing buffer, size 0, start 0
      When I was expecting:
      	no valid data in buffer (sig = ...)
      This bails out early (and reports with pr_debug()), since it's an
      acceptable state.
      Signed-off-by: default avatarJoel Fernandes (Google) <[email protected]>
      Co-developed-by: default avatarKees Cook <[email protected]>
      Signed-off-by: default avatarKees Cook <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • A.s. Dong's avatar
      clk: imx: make mux parent strings const · 6029666f
      A.s. Dong authored
      [ Upstream commit 9e5ef7a5 ]
      As the commit 2893c379 ("clk: make strings in parent name arrays
      const"), let's make the parent strings const, otherwise we may meet
      the following warning when compiling:
      drivers/clk/imx/clk-imx7ulp.c: In function 'imx7ulp_clocks_init':
      drivers/clk/imx/clk-imx7ulp.c:73:35: warning: passing argument 5 of
      	'imx_clk_mux_flags' discards 'const' qualifier from pointer target type
        clks[IMX7ULP_CLK_APLL_PRE_SEL] = imx_clk_mux_flags("apll_pre_sel", base + 0x508, 0,
      	1, pll_pre_sels, ARRAY_SIZE(pll_pre_sels), CLK_SET_PARENT_GATE);
      In file included from drivers/clk/imx/clk-imx7ulp.c:23:0:
      drivers/clk/imx/clk.h:200:27: note: expected 'const char **' but argument is
       of type 'const char * const*'
      Cc: Stephen Boyd <[email protected]>
      Cc: Michael Turquette <[email protected]>
      Cc: Shawn Guo <[email protected]>
      Signed-off-by: default avatarDong Aisheng <[email protected]>
      Signed-off-by: default avatarStephen Boyd <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Masahiro Yamada's avatar
      kbuild: let fixdep directly write to .*.cmd files · a41c9b57
      Masahiro Yamada authored
      [ Upstream commit 392885ee ]
      Currently, fixdep writes dependencies to .*.tmp, which is renamed to
      .*.cmd after everything succeeds. This is a very safe way to avoid
      corrupted .*.cmd files. The if_changed_dep has carried this safety
      mechanism since it was added in 2002.
      If fixdep fails for some reasons or a user terminates the build while
      fixdep is running, the incomplete output from the fixdep could be
      This is my insight about some bad scenarios:
      [1] If the compiler succeeds to generate *.o file, but fixdep fails
          to write necessary dependencies to .*.cmd file, Make will miss
          to rebuild the object when headers or CONFIG options are changed.
          In this case, fixdep should not generate .*.cmd file at all so
          that 'arg-check' will surely trigger the rebuild of the object.
      [2] A partially constructed .*.cmd file may not be a syntactically
          correct makefile. The next time Make runs, it would include it,
          then fail to parse it. Once this happens, 'make clean' is be the
          only way to fix it.
      In fact, [1] is no longer a problem since commit 9c2af1c7 ("kbuild:
      add .DELETE_ON_ERROR special target"). Make deletes a target file on
      any failure in its recipe. Because fixdep is a part of the recipe of
      *.o target, if it fails, the *.o is deleted anyway. However, I am a
      bit worried about the slight possibility of [2].
      So, here is a solution. Let fixdep directly write to a .*.cmd file,
      but allow makefiles to include it only when its corresponding target
      This effectively reverts commit 2982c953 ("kbuild: remove redundant
      $(wildcard ...) for cmd_files calculation"), and commit 00d78ab2
      ("kbuild: remove dead code in cmd_files calculation in top Makefile")
      because now we must check the presence of targets.
      Signed-off-by: default avatarMasahiro Yamada <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Daniel Santos's avatar
      jffs2: Fix use of uninitialized delayed_work, lockdep breakage · 39e10358
      Daniel Santos authored
      [ Upstream commit a788c527 ]
      jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
      is defined then a write buffer is available and has been initialized.
      However, this does is not the case when the mtd device has no
      out-of-band buffer:
      int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
              if (!c->mtd->oobsize)
                      return 0;
      The resulting call to cancel_delayed_work_sync passing a uninitialized
      (but zeroed) delayed_work struct forces lockdep to become disabled.
      [   90.050639] overlayfs: upper fs does not support tmpfile.
      [   90.652264] INFO: trying to register non-static key.
      [   90.662171] the code is fine but needs lockdep annotation.
      [   90.673090] turning off the locking correctness validator.
      [   90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
      [   90.696672] Stack : 00000000 00000000 80d8f6a2 00000038 805f0000 80444600 8fe364f4 805dfbe7
      [   90.713349]         80563a30 000006e2 8068370c 00000001 00000000 00000001 8e2fdc48 ffffffff
      [   90.730020]         00000000 00000000 80d90000 00000000 00000106 00000000 6465746e 312e3420
      [   90.746690]         6b636f6c 03bf0000 f8000000 20676e69 00000000 80000000 00000000 8e2c2a90
      [   90.763362]         80d90000 00000001 00000000 8e2c2a90 00000003 80260dc0 08052098 80680000
      [   90.780033]         ...
      [   90.784902] Call Trace:
      [   90.789793] [<8000f0d8>] show_stack+0xb8/0x148
      [   90.798659] [<8005a000>] register_lock_class+0x270/0x55c
      [   90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
      [   90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
      [   90.828345] [<8003f27c>] flush_work+0x200/0x24c
      [   90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
      [   90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
      [   90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
      [   90.866729] [<80158fc4>] sys_sync+0x44/0x9c
      [   90.875067] [<80014424>] syscall_common+0x34/0x58
      Signed-off-by: Daniel Santos's avatarDaniel Santos <[email protected]>
      Reviewed-by: default avatarHou Tao <[email protected]>
      Signed-off-by: default avatarBoris Brezillon <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Nathan Chancellor's avatar
      efi/libstub: Disable some warnings for x86{,_64} · 27556568
      Nathan Chancellor authored
      [ Upstream commit 3db5e0ba ]
      When building the kernel with Clang, some disabled warnings appear
      because this Makefile overrides KBUILD_CFLAGS for x86{,_64}. Add them to
      this list so that the build is clean again.
      -Wpointer-sign was disabled for the whole kernel before the beginning of Git history.
      -Waddress-of-packed-member was disabled for the whole kernel and for
      the early boot code in these commits:
        bfb38988 ("kbuild: clang: Disable 'address-of-packed-member' warning")
        20c6c189 ("x86/boot: Disable the address-of-packed-member compiler warning").
      -Wgnu was disabled for the whole kernel and for the early boot code in
      these commits:
        61163efa ("kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang")
        6c3b56b1 ("x86/boot: Disable Clang warnings about GNU extensions").
       [ mingo: Made the changelog more readable. ]
      Tested-by: Sedat Dilek's avatarSedat Dilek <[email protected]>
      Signed-off-by: Nathan Chancellor's avatarNathan Chancellor <[email protected]>
      Signed-off-by: default avatarArd Biesheuvel <[email protected]>
      Reviewed-by: Sedat Dilek's avatarSedat Dilek <[email protected]>
      Cc: Andy Lutomirski <[email protected]>
      Cc: Arend van Spriel <[email protected]>
      Cc: Bhupesh Sharma <[email protected]>
      Cc: Borislav Petkov <[email protected]>
      Cc: Dave Hansen <[email protected]>
      Cc: Eric Snowberg <[email protected]>
      Cc: Hans de Goede <[email protected]>
      Cc: Joe Perches <[email protected]>
      Cc: Jon Hunter <[email protected]>
      Cc: Julien Thierry <[email protected]>
      Cc: Linus Torvalds <[email protected]>
      Cc: Marc Zyngier <[email protected]>
      Cc: Matt Fleming <[email protected]>
      Cc: Peter Zijlstra <[email protected]>
      Cc: Sai Praneeth Prakhya <[email protected]>
      Cc: Thomas Gleixner <[email protected]>
      Cc: YiFei Zhu <[email protected]>
      Cc: [email protected]
      Link: http://lkml.kernel.org/r/[email protected]
      Link: https://github.com/ClangBuiltLinux/linux/issues/112Signed-off-by: default avatarIngo Molnar <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Chuck Lever's avatar
      rxe: IB_WR_REG_MR does not capture MR's iova field · 1da48f58
      Chuck Lever authored
      [ Upstream commit b024dd0e ]
      FRWR memory registration is done with a series of calls and WRs.
      1. ULP invokes ib_dma_map_sg()
      2. ULP invokes ib_map_mr_sg()
      3. ULP posts an IB_WR_REG_MR on the Send queue
      Step 2 generates an iova. It is permissible for ULPs to change this
      iova (with certain restrictions) between steps 2 and 3.
      rxe_map_mr_sg captures the MR's iova but later when rxe processes the
      REG_MR WR, it ignores the MR's iova field. If a ULP alters the MR's iova
      after step 2 but before step 3, rxe never captures that change.
      When the remote sends an RDMA Read targeting that MR, rxe looks up the
      R_key, but the altered iova does not match the iova stored in the MR,
      causing the RDMA Read request to fail.
      Reported-by: default avatarAnna Schumaker <[email protected]>
      Signed-off-by: default avatarChuck Lever <[email protected]>
      Reviewed-by: Sagi Grimberg's avatarSagi Grimberg <[email protected]>
      Signed-off-by: default avatarJason Gunthorpe <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Chris Wilson's avatar
      drm/amdgpu: Reorder uvd ring init before uvd resume · c5656fd9
      Chris Wilson authored
      [ Upstream commit 3b34c14f ]
      As amd_uvd_resume() accesses the uvd ring, it must be initialised first
      or else we trigger errors like:
      [    5.595963] [drm] Found UVD firmware Version: 1.87 Family ID: 17
      [    5.595969] [drm] PSP loading UVD firmware
      [    5.596266] ------------[ cut here ]------------
      [    5.596268] ODEBUG: assert_init not available (active state 0) object type: timer_list hint:           (null)
      [    5.596285] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80
      [    5.596286] Modules linked in: amdgpu(+) hid_logitech_hidpp(+) chash gpu_sched amd_iommu_v2 ttm drm_kms_helper crc32c_intel drm hid_sony ff_memless igb hid_logitech_dj nvme dca i2c_algo_bit nvme_core wmi pinctrl_amd uas usb_storage
      [    5.596299] CPU: 0 PID: 507 Comm: systemd-udevd Tainted: G        W         4.20.0-0.rc1.git4.1.fc30.x86_64 #1
      [    5.596301] Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0901 07/23/2018
      [    5.596303] RIP: 0010:debug_print_object+0x6a/0x80
      [    5.596305] Code: 8b 43 10 83 c2 01 8b 4b 14 4c 89 e6 89 15 e6 82 b0 02 4c 8b 45 00 48 c7 c7 60 fd 34 a6 48 8b 14 c5 a0 da 08 a6 e8 6a 6a b8 ff <0f> 0b 5b 83 05 d0 45 3e 01 01 5d 41 5c c3 83 05 c5 45 3e 01 01 c3
      [    5.596306] RSP: 0018:ffffa02ac863f8c0 EFLAGS: 00010282
      [    5.596307] RAX: 0000000000000000 RBX: ffffa02ac863f8e0 RCX: 0000000000000006
      [    5.596308] RDX: 0000000000000007 RSI: ffff9160e9a7bfe8 RDI: ffff9160f91d6c60
      [    5.596310] RBP: ffffffffa6742740 R08: 0000000000000002 R09: 0000000000000000
      [    5.596311] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa634ff69
      [    5.596312] R13: 00000000000b79d0 R14: ffffffffa80f76d8 R15: 0000000000266000
      [    5.596313] FS:  00007f762abf7940(0000) GS:ffff9160f9000000(0000) knlGS:0000000000000000
      [    5.596314] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    5.596315] CR2: 000055fdc593f000 CR3: 00000007e999c000 CR4: 00000000003406f0
      [    5.596317] Call Trace:
      [    5.596321]  debug_object_assert_init+0x14a/0x180
      [    5.596327]  del_timer+0x2e/0x90
      [    5.596383]  amdgpu_fence_process+0x47/0x100 [amdgpu]
      [    5.596430]  amdgpu_uvd_resume+0xf6/0x120 [amdgpu]
      [    5.596475]  uvd_v7_0_sw_init+0xe0/0x280 [amdgpu]
      [    5.596523]  amdgpu_device_init.cold.30+0xf97/0x14b6 [amdgpu]
      [    5.596563]  ? amdgpu_driver_load_kms+0x53/0x330 [amdgpu]
      [    5.596604]  amdgpu_driver_load_kms+0x86/0x330 [amdgpu]
      [    5.596614]  drm_dev_register+0x115/0x150 [drm]
      [    5.596654]  amdgpu_pci_probe+0xbd/0x120 [amdgpu]
      [    5.596658]  local_pci_probe+0x41/0x90
      [    5.596661]  pci_device_probe+0x188/0x1a0
      [    5.596666]  really_probe+0xf8/0x3b0
      [    5.596669]  driver_probe_device+0xb3/0xf0
      [    5.596672]  __driver_attach+0xe1/0x110
      [    5.596674]  ? driver_probe_device+0xf0/0xf0
      [    5.596676]  bus_for_each_dev+0x79/0xc0
      [    5.596679]  bus_add_driver+0x155/0x230
      [    5.596681]  ? 0xffffffffc07d9000
      [    5.596683]  driver_register+0x6b/0xb0
      [    5.596685]  ? 0xffffffffc07d9000
      [    5.596688]  do_one_initcall+0x5d/0x2be
      [    5.596691]  ? rcu_read_lock_sched_held+0x79/0x80
      [    5.596693]  ? kmem_cache_alloc_trace+0x264/0x290
      [    5.596695]  ? do_init_module+0x22/0x210
      [    5.596698]  do_init_module+0x5a/0x210
      [    5.596701]  load_module+0x2137/0x2430
      [    5.596703]  ? lockdep_hardirqs_on+0xed/0x180
      [    5.596714]  ? __do_sys_init_module+0x150/0x1a0
      [    5.596715]  __do_sys_init_module+0x150/0x1a0
      [    5.596722]  do_syscall_64+0x60/0x1f0
      [    5.596725]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [    5.596726] RIP: 0033:0x7f762b877dee
      [    5.596728] Code: 48 8b 0d 9d 20 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6a 20 0c 00 f7 d8 64 89 01 48
      [    5.596729] RSP: 002b:00007ffc777b8558 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
      [    5.596730] RAX: ffffffffffffffda RBX: 000055fdc48da320 RCX: 00007f762b877dee
      [    5.596731] RDX: 00007f762b9f284d RSI: 00000000006c5fc6 RDI: 000055fdc527a060
      [    5.596732] RBP: 00007f762b9f284d R08: 0000000000000003 R09: 0000000000000002
      [    5.596733] R10: 000055fdc48ad010 R11: 0000000000000246 R12: 000055fdc527a060
      [    5.596734] R13: 000055fdc48dca20 R14: 0000000000020000 R15: 0000000000000000
      [    5.596740] irq event stamp: 134618
      [    5.596743] hardirqs last  enabled at (134617): [<ffffffffa513d52e>] console_unlock+0x45e/0x610
      [    5.596744] hardirqs last disabled at (134618): [<ffffffffa50037e8>] trace_hardirqs_off_thunk+0x1a/0x1c
      [    5.596746] softirqs last  enabled at (133146): [<ffffffffa5e00365>] __do_softirq+0x365/0x47c
      [    5.596748] softirqs last disabled at (133139): [<ffffffffa50c64f9>] irq_exit+0x119/0x120
      [    5.596749] ---[ end trace eaee508abfebccdc ]---
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108709Reviewed-by: default avatarChristian König <[email protected]>
      Signed-off-by: default avatarChris Wilson <[email protected]>
      Cc: Alex Deucher <[email protected]>
      Signed-off-by: default avatarAlex Deucher <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Kunihiko Hayashi's avatar
      net: ethernet: ave: Set initial wol state to disabled · 2ca0f9b6
      Kunihiko Hayashi authored
      [ Upstream commit 7200f2e3 ]
      If wol state of phy hardware is enabled after reset, phy_ethtool_get_wol()
      returns that wol.wolopts is true.
      However, since net_device.wol_enabled is zero and this doesn't apply wol
      state until calling ethtool_set_wol(), so mdio_bus_phy_may_suspend()
      returns true, that is, it's in a state where phy can suspend even though
      wol state is enabled.
      In this inconsistency, phy_suspend() returns -EBUSY, and at last,
      suspend sequence fails with the following message:
          dpm_run_callback(): mdio_bus_phy_suspend+0x0/0x58 returns -16
          PM: Device 65000000.ethernet-ffffffff:01 failed to suspend: error -16
          PM: Some devices failed to suspend, or early wake event detected
      In order to fix the above issue, this patch forces to set initial wol state
      to disabled as default.
      Signed-off-by: default avatarKunihiko Hayashi <[email protected]>
      Signed-off-by: default avatarDavid S. Miller <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Manish Rangankar's avatar
      scsi: qedi: Check for session online before getting iSCSI TLV data. · d09c144e
      Manish Rangankar authored
      [ Upstream commit d5632b11 ]
      The kernel panic was observed after switch side perturbation,
      BUG: unable to handle kernel NULL pointer dereference at (null)
           IP: [<ffffffff8132b5a0>] strcmp+0x20/0x40
           PGD 0 Oops: 0000 [#1] SMP
      CPU: 8 PID: 647 Comm: kworker/8:1 Tainted: G        W  OE  ------------   3.10.0-693.el7.x86_64 #1
      Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/20/2018
      Workqueue: slowpath-13:00. qed_slowpath_task [qed]
      task: ffff880429eb8fd0 ti: ffff880429190000 task.ti: ffff880429190000
      RIP: 0010:[<ffffffff8132b5a0>]  [<ffffffff8132b5a0>] strcmp+0x20/0x40
      RSP: 0018:ffff880429193c68  EFLAGS: 00010202
      RAX: 000000000000000a RBX: 0000000000000002 RCX: 0000000000000000
      RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff88042bda7a41
      RBP: ffff880429193c68 R08: 000000000000ffff R09: 000000000000ffff
      R10: 0000000000000007 R11: ffff88042b3af338 R12: ffff880420b007a0
      R13: ffff88081aa56af8 R14: 0000000000000001 R15: ffff88081aa50410
      FS:  0000000000000000(0000) GS:ffff88042fe00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 00000000019f2000 CR4: 00000000003407e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      ffff880429193d20 ffffffffc02a0c90 ffffc90004b32000 ffff8803fd3ec600
      ffff88042bda7800 ffff88042bda7a00 ffff88042bda7840 ffff88042bda7a40
      0000000129193d10 2e3836312e323931 ff000a342e363232 ffffffffc01ad99d
      Call Trace:
      [<ffffffffc02a0c90>] qedi_get_protocol_tlv_data+0x270/0x470 [qedi]
      [<ffffffffc01ad99d>] ? qed_mfw_process_tlv_req+0x24d/0xbf0 [qed]
      [<ffffffffc01653ae>] qed_mfw_fill_tlv_data+0x5e/0xd0 [qed]
      [<ffffffffc01ad9b9>] qed_mfw_process_tlv_req+0x269/0xbf0 [qed]
      Fix kernel NULL pointer deref by checking for session is online before
      getting iSCSI TLV data.
      Signed-off-by: default avatarManish Rangankar <[email protected]>
      Reviewed-by: default avatarLee Duncan <[email protected]>
      Signed-off-by: Martin K. Petersen's avatarMartin K. Petersen <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Jiada Wang's avatar
      ASoC: pcm3168a: Don't disable pcm3168a when CONFIG_PM defined · 05bb55dd
      Jiada Wang authored
      [ Upstream commit 489db5d9 ]
      pcm3168 codec support runtime_[resume|suspend], whenever it
      is not active, it enters suspend mode, and it's clock and regulators
      will be disabled. so there is no need to disable them again in
      remove callback.  Otherwise we got following kernel warnings,
      when unload pcm3168a driver
      [  222.257514] unbalanced disables for amp-en-regulator
      [  222.262526] ------------[ cut here ]------------
      [  222.267158] WARNING: CPU: 0 PID: 2423 at drivers/regulator/core.c:2264 _regulator_disable+0x28/0x108
      [  222.276291] Modules linked in:
      [  222.279343]  snd_soc_pcm3168a_i2c(-)
      [  222.282916]  snd_aloop
      [  222.285272]  arc4
      [  222.287194]  wl18xx
      [  222.289289]  wlcore
      [  222.291385]  mac80211
      [  222.293654]  cfg80211
      [  222.295923]  aes_ce_blk
      [  222.298366]  crypto_simd
      [  222.300896]  cryptd
      [  222.302992]  aes_ce_cipher
      [  222.305696]  crc32_ce
      [  222.307965]  ghash_ce
      [  222.310234]  aes_arm64
      [  222.312590]  gf128mul
      [  222.314860]  snd_soc_rcar
      [  222.317476]  sha2_ce
      [  222.319658]  xhci_plat_hcd
      [  222.322362]  sha256_arm64
      [  222.324978]  xhci_hcd
      [  222.327247]  sha1_ce
      [  222.329430]  renesas_usbhs
      [  222.332133]  evdev
      [  222.334142]  sha1_generic
      [  222.336758]  rcar_gen3_thermal
      [  222.339810]  cpufreq_dt
      [  222.342253]  ravb_streaming(C)
      [  222.345304]  wlcore_sdio
      [  222.347834]  thermal_sys
      [  222.350363]  udc_core
      [  222.352632]  mch_core(C)
      [  222.355161]  usb_dmac
      [  222.357430]  snd_soc_pcm3168a
      [  222.360394]  snd_soc_ak4613
      [  222.363184]  gpio_keys
      [  222.365540]  virt_dma
      [  222.367809]  nfsd
      [  222.369730]  ipv6
      [  222.371652]  autofs4
      [  222.373834]  [last unloaded: snd_soc_pcm3168a_i2c]
      [  222.378629] CPU: 0 PID: 2423 Comm: rmmod Tainted: G        WC      4.14.63-04798-gd456126e4a42-dirty #457
      [  222.388196] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT)
      [  222.396199] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000
      [  222.402117] PC is at _regulator_disable+0x28/0x108
      [  222.406906] LR is at _regulator_disable+0x28/0x108
      [  222.411695] pc : [<ffff0000083bd89c>] lr : [<ffff0000083bd89c>] pstate: 00000145
      [  222.419089] sp : ffff00000a0a3c80
      [  222.422401] x29: ffff00000a0a3c80
      [  222.425799] x28: ffff8006fa8c6200
      [  222.429199] x27: ffff0000086f1000
      [  222.432597] x26: 000000000000006a
      [  222.435997] x25: 0000000000000124
      [  222.439395] x24: 0000000000000018
      [  222.442795] x23: 0000000000000006
      [  222.446193] x22: ffff8006f925d490
      [  222.449592] x21: ffff8006f9ac2068
      [  222.452991] x20: ffff8006f9ac2000
      [  222.456390] x19: 0000000000000005
      [  222.459787] x18: 000000000000000a
      [  222.463186] x17: 0000000000000000
      [  222.466584] x16: 0000000000000000
      [  222.469984] x15: 000000000d3f616a
      [  222.473382] x14: 0720072007200720
      [  222.476781] x13: 0720072007200720
      [  222.480179] x12: 0720072007200720
      [  222.483578] x11: 0720072007200720
      [  222.486975] x10: 0720072007200720
      [  222.490375] x9 : 0720072007200720
      [  222.493773] x8 : 07200772076f0774
      [  222.497172] x7 : 0000000000000000
      [  222.500570] x6 : 0000000000000007
      [  222.503969] x5 : 0000000000000000
      [  222.507367] x4 : 0000000000000000
      [  222.510766] x3 : 0000000000000000
      [  222.514164] x2 : c790b852091e2600
      [  222.517563] x1 : 0000000000000000
      [  222.520961] x0 : 0000000000000028
      [  222.524361] Call trace:
      [  222.526805] Exception stack(0xffff00000a0a3b40 to 0xffff00000a0a3c80)
      [  222.533245] 3b40: 0000000000000028 0000000000000000 c790b852091e2600 0000000000000000
      [  222.541075] 3b60: 0000000000000000 0000000000000000 0000000000000007 0000000000000000
      [  222.548905] 3b80: 07200772076f0774 0720072007200720 0720072007200720 0720072007200720
      [  222.556735] 3ba0: 0720072007200720 0720072007200720 0720072007200720 000000000d3f616a
      [  222.564564] 3bc0: 0000000000000000 0000000000000000 000000000000000a 0000000000000005
      [  222.572394] 3be0: ffff8006f9ac2000 ffff8006f9ac2068 ffff8006f925d490 0000000000000006
      [  222.580224] 3c00: 0000000000000018 0000000000000124 000000000000006a ffff0000086f1000
      [  222.588053] 3c20: ffff8006fa8c6200 ffff00000a0a3c80 ffff0000083bd89c ffff00000a0a3c80
      [  222.595883] 3c40: ffff0000083bd89c 0000000000000145 0000000000000000 0000000000000000
      [  222.603713] 3c60: 0000ffffffffffff ffff00000a0a3c30 ffff00000a0a3c80 ffff0000083bd89c
      [  222.611543] [<ffff0000083bd89c>] _regulator_disable+0x28/0x108
      [  222.617375] [<ffff0000083bd9c4>] regulator_disable+0x48/0x68
      [  222.623033] [<ffff0000083be8e4>] regulator_bulk_disable+0x58/0xc0
      [  222.629134] [<ffff0000007d831c>] pcm3168a_remove+0x30/0x50 [snd_soc_pcm3168a]
      [  222.636270] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c]
      [  222.644106] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70
      [  222.649766] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0
      [  222.656640] [<ffff00000843ced8>] driver_detach+0x70/0x7c
      [  222.661951] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0
      [  222.667609] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c
      [  222.673268] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30
      [  222.678666] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c]
      [  222.687019] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4
      [  222.692850] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000)
      [  222.699289] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8
      [  222.707119] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000
      [  222.714948] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005
      [  222.722778] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000
      [  222.730607] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000
      [  222.738436] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001
      [  222.746266] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010
      [  222.754096] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130
      [  222.761926] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a
      [  222.769755] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [  222.777589] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38
      [  222.782899] ---[ end trace eaf8939a3698b1a8 ]---
      [  222.787609] Failed to disable VCCDA2: -5
      [  222.791649] ------------[ cut here ]------------
      [  222.796283] WARNING: CPU: 0 PID: 2423 at drivers/clk/clk.c:595 clk_core_disable+0xc/0x1d8
      [  222.804460] Modules linked in:
      [  222.807511]  snd_soc_pcm3168a_i2c(-)
      [  222.811083]  snd_aloop
      [  222.813439]  arc4
      [  222.815360]  wl18xx
      [  222.817456]  wlcore
      [  222.819551]  mac80211
      [  222.821820]  cfg80211
      [  222.824088]  aes_ce_blk
      [  222.826531]  crypto_simd
      [  222.829060]  cryptd
      [  222.831155]  aes_ce_cipher
      [  222.833859]  crc32_ce
      [  222.836127]  ghash_ce
      [  222.838396]  aes_arm64
      [  222.840752]  gf128mul
      [  222.843020]  snd_soc_rcar
      [  222.845637]  sha2_ce
      [  222.847818]  xhci_plat_hcd
      [  222.850522]  sha256_arm64
      [  222.853138]  xhci_hcd
      [  222.855407]  sha1_ce
      [  222.857589]  renesas_usbhs
      [  222.860292]  evdev
      [  222.862300]  sha1_generic
      [  222.864917]  rcar_gen3_thermal
      [  222.867968]  cpufreq_dt
      [  222.870410]  ravb_streaming(C)
      [  222.873461]  wlcore_sdio
      [  222.875991]  thermal_sys
      [  222.878520]  udc_core
      [  222.880789]  mch_core(C)
      [  222.883318]  usb_dmac
      [  222.885587]  snd_soc_pcm3168a
      [  222.888551]  snd_soc_ak4613
      [  222.891341]  gpio_keys
      [  222.893696]  virt_dma
      [  222.895965]  nfsd
      [  222.897886]  ipv6
      [  222.899808]  autofs4
      [  222.901990]  [last unloaded: snd_soc_pcm3168a_i2c]
      [  222.906783] CPU: 0 PID: 2423 Comm: rmmod Tainted: G        WC      4.14.63-04798-gd456126e4a42-dirty #457
      [  222.916349] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT)
      [  222.924351] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000
      [  222.930270] PC is at clk_core_disable+0xc/0x1d8
      [  222.934799] LR is at clk_core_disable_lock+0x20/0x34
      [  222.939761] pc : [<ffff0000083ab9b8>] lr : [<ffff0000083acd28>] pstate: 800001c5
      [  222.947154] sp : ffff00000a0a3cf0
      [  222.950466] x29: ffff00000a0a3cf0
      [  222.953864] x28: ffff8006fa8c6200
      [  222.957263] x27: ffff0000086f1000
      [  222.960661] x26: 000000000000006a
      [  222.964061] x25: 0000000000000124
      [  222.967458] x24: 0000000000000015
      [  222.970858] x23: ffff8006f9ffa8d0
      [  222.974256] x22: ffff8006faf16480
      [  222.977655] x21: ffff0000007e7040
      [  222.981053] x20: ffff8006faadd100
      [  222.984452] x19: 0000000000000140
      [  222.987850] x18: 000000000000000a
      [  222.991249] x17: 0000000000000000
      [  222.994647] x16: 0000000000000000
      [  222.998046] x15: 000000000d477819
      [  223.001444] x14: 0720072007200720
      [  223.004843] x13: 0720072007200720
      [  223.008242] x12: 0720072007200720
      [  223.011641] x11: 0720072007200720
      [  223.015039] x10: 0720072007200720
      [  223.018438] x9 : 0720072007200720
      [  223.021837] x8 : 0720072007200720
      [  223.025236] x7 : 0000000000000000
      [  223.028634] x6 : 0000000000000007
      [  223.032034] x5 : 0000000000000000
      [  223.035432] x4 : 0000000000000000
      [  223.038831] x3 : 0000000000000000
      [  223.042229] x2 : 0000000004720471
      [  223.045628] x1 : 0000000000000000
      [  223.049026] x0 : ffff8006faadd100
      [  223.052426] Call trace:
      [  223.054870] Exception stack(0xffff00000a0a3bb0 to 0xffff00000a0a3cf0)
      [  223.061309] 3ba0:                                   ffff8006faadd100 0000000000000000
      [  223.069139] 3bc0: 0000000004720471 0000000000000000 0000000000000000 0000000000000000
      [  223.076969] 3be0: 0000000000000007 0000000000000000 0720072007200720 0720072007200720
      [  223.084798] 3c00: 0720072007200720 0720072007200720 0720072007200720 0720072007200720
      [  223.092628] 3c20: 0720072007200720 000000000d477819 0000000000000000 0000000000000000
      [  223.100458] 3c40: 000000000000000a 0000000000000140 ffff8006faadd100 ffff0000007e7040
      [  223.108287] 3c60: ffff8006faf16480 ffff8006f9ffa8d0 0000000000000015 0000000000000124
      [  223.116117] 3c80: 000000000000006a ffff0000086f1000 ffff8006fa8c6200 ffff00000a0a3cf0
      [  223.123947] 3ca0: ffff0000083acd28 ffff00000a0a3cf0 ffff0000083ab9b8 00000000800001c5
      [  223.131777] 3cc0: ffff00000a0a3cf0 ffff0000083acd1c 0000ffffffffffff ffff8006faadd100
      [  223.139606] 3ce0: ffff00000a0a3cf0 ffff0000083ab9b8
      [  223.144483] [<ffff0000083ab9b8>] clk_core_disable+0xc/0x1d8
      [  223.150054] [<ffff0000083acd58>] clk_disable+0x1c/0x28
      [  223.155198] [<ffff0000007d8328>] pcm3168a_remove+0x3c/0x50 [snd_soc_pcm3168a]
      [  223.162334] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c]
      [  223.170167] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70
      [  223.175826] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0
      [  223.182700] [<ffff00000843ced8>] driver_detach+0x70/0x7c
      [  223.188012] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0
      [  223.193669] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c
      [  223.199329] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30
      [  223.204726] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c]
      [  223.213079] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4
      [  223.218909] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000)
      [  223.225349] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8
      [  223.233179] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000
      [  223.241008] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005
      [  223.248838] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000
      [  223.256668] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000
      [  223.264497] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001
      [  223.272327] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010
      [  223.280157] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130
      [  223.287986] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a
      [  223.295816] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [  223.303648] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38
      [  223.308958] ---[ end trace eaf8939a3698b1a9 ]---
      [  223.313752] ------------[ cut here ]------------
      [  223.318383] WARNING: CPU: 0 PID: 2423 at drivers/clk/clk.c:477 clk_core_unprepare+0xc/0x1ac
      [  223.326733] Modules linked in:
      [  223.329784]  snd_soc_pcm3168a_i2c(-)
      [  223.333356]  snd_aloop
      [  223.335712]  arc4
      [  223.337633]  wl18xx
      [  223.339728]  wlcore
      [  223.341823]  mac80211
      [  223.344092]  cfg80211
      [  223.346360]  aes_ce_blk
      [  223.348803]  crypto_simd
      [  223.351332]  cryptd
      [  223.353428]  aes_ce_cipher
      [  223.356131]  crc32_ce
      [  223.358400]  ghash_ce
      [  223.360668]  aes_arm64
      [  223.363024]  gf128mul
      [  223.365293]  snd_soc_rcar
      [  223.367909]  sha2_ce
      [  223.370091]  xhci_plat_hcd
      [  223.372794]  sha256_arm64
      [  223.375410]  xhci_hcd
      [  223.377679]  sha1_ce
      [  223.379861]  renesas_usbhs
      [  223.382564]  evdev
      [  223.384572]  sha1_generic
      [  223.387188]  rcar_gen3_thermal
      [  223.390239]  cpufreq_dt
      [  223.392682]  ravb_streaming(C)
      [  223.395732]  wlcore_sdio
      [  223.398261]  thermal_sys
      [  223.400790]  udc_core
      [  223.403059]  mch_core(C)
      [  223.405588]  usb_dmac
      [  223.407856]  snd_soc_pcm3168a
      [  223.410820]  snd_soc_ak4613
      [  223.413609]  gpio_keys
      [  223.415965]  virt_dma
      [  223.418234]  nfsd
      [  223.420155]  ipv6
      [  223.422076]  autofs4
      [  223.424258]  [last unloaded: snd_soc_pcm3168a_i2c]
      [  223.429050] CPU: 0 PID: 2423 Comm: rmmod Tainted: G        WC      4.14.63-04798-gd456126e4a42-dirty #457
      [  223.438616] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT)
      [  223.446618] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000
      [  223.452536] PC is at clk_core_unprepare+0xc/0x1ac
      [  223.457239] LR is at clk_unprepare+0x28/0x3c
      [  223.461506] pc : [<ffff0000083ab5a4>] lr : [<ffff0000083ace4c>] pstate: 60000145
      [  223.468900] sp : ffff00000a0a3d00
      [  223.472211] x29: ffff00000a0a3d00
      [  223.475609] x28: ffff8006fa8c6200
      [  223.479009] x27: ffff0000086f1000
      [  223.482407] x26: 000000000000006a
      [  223.485807] x25: 0000000000000124
      [  223.489205] x24: 0000000000000015
      [  223.492604] x23: ffff8006f9ffa8d0
      [  223.496003] x22: ffff8006faf16480
      [  223.499402] x21: ffff0000007e7040
      [  223.502800] x20: ffff8006faf16420
      [  223.506199] x19: ffff8006faadd100
      [  223.509597] x18: 000000000000000a
      [  223.512997] x17: 0000000000000000
      [  223.516395] x16: 0000000000000000
      [  223.519794] x15: 0000000000000000
      [  223.523192] x14: 00000033fe89076c
      [  223.526591] x13: 0000000000000400
      [  223.529989] x12: 0000000000000400
      [  223.533388] x11: 0000000000000000
      [  223.536786] x10: 00000000000009e0
      [  223.540185] x9 : ffff00000a0a3be0
      [  223.543583] x8 : ffff8006fa8c6c40
      [  223.546982] x7 : ffff8006fa8c6400
      [  223.550380] x6 : 0000000000000001
      [  223.553780] x5 : 0000000000000000
      [  223.557178] x4 : ffff8006fa8c6200
      [  223.560577] x3 : 0000000000000000
      [  223.563975] x2 : ffff8006fa8c6200
      [  223.567374] x1 : 0000000000000000
      [  223.570772] x0 : ffff8006faadd100
      [  223.574170] Call trace:
      [  223.576615] Exception stack(0xffff00000a0a3bc0 to 0xffff00000a0a3d00)
      [  223.583054] 3bc0: ffff8006faadd100 0000000000000000 ffff8006fa8c6200 0000000000000000
      [  223.590884] 3be0: ffff8006fa8c6200 0000000000000000 0000000000000001 ffff8006fa8c6400
      [  223.598714] 3c00: ffff8006fa8c6c40 ffff00000a0a3be0 00000000000009e0 0000000000000000
      [  223.606544] 3c20: 0000000000000400 0000000000000400 00000033fe89076c 0000000000000000
      [  223.614374] 3c40: 0000000000000000 0000000000000000 000000000000000a ffff8006faadd100
      [  223.622204] 3c60: ffff8006faf16420 ffff0000007e7040 ffff8006faf16480 ffff8006f9ffa8d0
      [  223.630033] 3c80: 0000000000000015 0000000000000124 000000000000006a ffff0000086f1000
      [  223.637863] 3ca0: ffff8006fa8c6200 ffff00000a0a3d00 ffff0000083ace4c ffff00000a0a3d00
      [  223.645693] 3cc0: ffff0000083ab5a4 0000000060000145 0000000000000140 ffff8006faadd100
      [  223.653523] 3ce0: 0000ffffffffffff ffff0000083ace44 ffff00000a0a3d00 ffff0000083ab5a4
      [  223.661353] [<ffff0000083ab5a4>] clk_core_unprepare+0xc/0x1ac
      [  223.667103] [<ffff0000007d8330>] pcm3168a_remove+0x44/0x50 [snd_soc_pcm3168a]
      [  223.674239] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c]
      [  223.682070] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70
      [  223.687731] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0
      [  223.694604] [<ffff00000843ced8>] driver_detach+0x70/0x7c
      [  223.699915] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0
      [  223.705572] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c
      [  223.711230] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30
      [  223.716628] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c]
      [  223.724980] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4
      [  223.730811] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000)
      [  223.737250] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8
      [  223.745079] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000
      [  223.752909] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005
      [  223.760739] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000
      [  223.768568] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000
      [  223.776398] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001
      [  223.784227] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010
      [  223.792057] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130
      [  223.799886] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a
      [  223.807715] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [  223.815546] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38
      [  223.820855] ---[ end trace eaf8939a3698b1aa ]---
      Fix this issue by only disable clock and regulators in remove callback
      when CONFIG_PM isn't defined
      Signed-off-by: default avatarJiada Wang <[email protected]>
      Signed-off-by: default avatarMark Brown <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • James Morse's avatar
      arm64: Use a raw spinlock in __install_bp_hardening_cb() · a80ff3a3
      James Morse authored
      [ Upstream commit d8797b12 ]
      __install_bp_hardening_cb() is called via stop_machine() as part
      of the cpu_enable callback. To force each CPU to take its turn
      when allocating slots, they take a spinlock.
      With the RT patches applied, the spinlock becomes a mutex,
      and we get warnings about sleeping while in stop_machine():
      | [    0.319176] CPU features: detected: RAS Extension Support
      | [    0.319950] BUG: scheduling while atomic: migration/3/36/0x00000002
      | [    0.319955] Modules linked in:
      | [    0.319958] Preemption disabled at:
      | [    0.319969] [<ffff000008181ae4>] cpu_stopper_thread+0x7c/0x108
      | [    0.319973] CPU: 3 PID: 36 Comm: migration/3 Not tainted 4.19.1-rt3-00250-g330fc2c2a880 #2
      | [    0.319975] Hardware name: linux,dummy-virt (DT)
      | [    0.319976] Call trace:
      | [    0.319981]  dump_backtrace+0x0/0x148
      | [    0.319983]  show_stack+0x14/0x20
      | [    0.319987]  dump_stack+0x80/0xa4
      | [    0.319989]  __schedule_bug+0x94/0xb0
      | [    0.319991]  __schedule+0x510/0x560
      | [    0.319992]  schedule+0x38/0xe8
      | [    0.319994]  rt_spin_lock_slowlock_locked+0xf0/0x278
      | [    0.319996]  rt_spin_lock_slowlock+0x5c/0x90
      | [    0.319998]  rt_spin_lock+0x54/0x58
      | [    0.320000]  enable_smccc_arch_workaround_1+0xdc/0x260
      | [    0.320001]  __enable_cpu_capability+0x10/0x20
      | [    0.320003]  multi_cpu_stop+0x84/0x108
      | [    0.320004]  cpu_stopper_thread+0x84/0x108
      | [    0.320008]  smpboot_thread_fn+0x1e8/0x2b0
      | [    0.320009]  kthread+0x124/0x128
      | [    0.320010]  ret_from_fork+0x10/0x18
      Switch this to a raw spinlock, as we know this is only called with
      IRQs masked.
      Signed-off-by: default avatarJames Morse <[email protected]>
      Signed-off-by: default avatarWill Deacon <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Ondrej Mosnáček's avatar
      selinux: always allow mounting submounts · cf635148
      Ondrej Mosnáček authored
      [ Upstream commit 2cbdcb88 ]
      If a superblock has the MS_SUBMOUNT flag set, we should always allow
      mounting it. These mounts are done automatically by the kernel either as
      part of mounting some parent mount (e.g. debugfs always mounts tracefs
      under "tracing" for compatibility) or they are mounted automatically as
      needed on subdirectory accesses (e.g. NFS crossmnt mounts). Since such
      automounts are either an implicit consequence of the parent mount (which
      is already checked) or they can happen during regular accesses (where it
      doesn't make sense to check against the current task's context), the
      mount permission check should be skipped for them.
      Without this patch, attempts to access contents of an automounted
      directory can cause unexpected SELinux denials.
      In the current kernel tree, the MS_SUBMOUNT flag is set only via
      vfs_submount(), which is called only from the following places:
       - AFS, when automounting special "symlinks" referencing other cells
       - CIFS, when automounting "referrals"
       - NFS, when automounting subtrees
       - debugfs, when automounting tracefs
      In all cases the submounts are meant to be transparent to the user and
      it makes sense that if mounting the master is allowed, then so should be
      the automounts. Note that CAP_SYS_ADMIN capability checking is already
      skipped for (SB_KERNMOUNT|SB_SUBMOUNT) in:
       - sget_userns() in fs/super.c:
      	if (!(flags & (SB_KERNMOUNT|SB_SUBMOUNT)) &&
      	    !(type->fs_flags & FS_USERNS_MOUNT) &&
      		return ERR_PTR(-EPERM);
       - sget() in fs/super.c:
              /* Ensure the requestor has permissions over the target filesystem */
              if (!(flags & (SB_KERNMOUNT|SB_SUBMOUNT)) && !ns_capable(user_ns, CAP_SYS_ADMIN))
                      return ERR_PTR(-EPERM);
      Verified internally on patched RHEL 7.6 with a reproducer using
      NFS+httpd and selinux-tesuite.
      Fixes: 93faccbb ("fs: Better permission checking for submounts")
      Signed-off-by: Ondrej Mosnáček's avatarOndrej Mosnacek <omosnace[email protected]>
      Signed-off-by: default avatarPaul Moore <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Anatolij Gustschin's avatar
      fpga: altera-cvp: fix probing for multiple FPGAs on the bus · fa893cba
      Anatolij Gustschin authored
      [ Upstream commit 30522a95 ]
      Currently registering CvP managers works only for first probed CvP
      device, for all other devices it is refused due to duplicated chkcfg
      sysfs entry:
      fpga_manager fpga3: Altera CvP FPGA Manager @0000:0c:00.0 registered
      sysfs: cannot create duplicate filename '/bus/pci/drivers/altera-cvp/chkcfg'
      CPU: 0 PID: 3808 Comm: bash Tainted: G           O      4.19.0-custom+ #5
      Call Trace:
        altera_cvp_probe+0x16f/0x2a0 [altera_cvp]
        ? pci_match_device+0xb1/0xf0
        ? selinux_file_permission+0xdc/0x130
        ? find_vma+0xd/0x60
       altera-cvp 0000:0c:00.0: Can't create sysfs chkcfg file
       fpga_manager fpga3: fpga_mgr_unregister Altera CvP FPGA Manager @0000:0c:00.0
      Move chkcfg creation to module init as suggested by Alan.
      Signed-off-by: default avatarAnatolij Gustschin <[email protected]>
      Acked-by: default avatarAlan Tull <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Yoshihiro Shimoda's avatar
      usb: gadget: udc: renesas_usb3: add a safety connection way for forced_b_device · deabd513
      Yoshihiro Shimoda authored
      [ Upstream commit ceb94bc5 ]
      This patch adds a safety connection way for "forced_b_device" with
      "workaround_for_vbus" like below:
      < Example for R-Car E3 Ebisu >
       # modprobe <any usb gadget driver>
       # echo 1 > /sys/kernel/debug/ee020000.usb/b_device
       (connect a usb cable to host side.)
       # echo 2 > /sys/kernel/debug/ee020000.usb/b_device
      Previous code should have connected a usb cable before the "b_device"
      is set to 1 on the Ebisu board. However, if xHCI driver on the board
      is probed, it causes some troubles:
       - Conflicts USB VBUS/signals between the board and another host.
       - "Cannot enable. Maybe the USB cable is bad?" might happen on
         both the board and another host with a usb hub.
       - Cannot enumerate a usb gadget correctly because an interruption
         of VBUS change happens unexpectedly.
      Reported-by: default avatarKazuya Mizuguchi <[email protected]>
      Signed-off-by: Yoshihiro Shimoda's avatarYoshihiro Shimoda <[email protected]>
      Signed-off-by: default avatarFelipe Balbi <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Daniel T. Lee's avatar
      samples: bpf: fix: error handling regarding kprobe_events · d8e74c74
      Daniel T. Lee authored
      [ Upstream commit 5a863813 ]
      Currently, kprobe_events failure won't be handled properly.
      Due to calling system() indirectly to write to kprobe_events,
      it can't be identified whether an error is derived from kprobe or system.
          // buf = "echo '%c:%s %s' >> /s/k/d/t/kprobe_events"
          err = system(buf);
          if (err < 0) {
              printf("failed to create kprobe ..");
              return -1;
      For example, running ./tracex7 sample in ext4 partition,
      "echo p:open_ctree open_ctree >> /s/k/d/t/kprobe_events"
      gets 256 error code system() failure.
      => The error comes from kprobe, but it's not handled correctly.
      According to man of system(3), it's return value
      just passes the termination status of the child shell
      rather than treating the error as -1. (don't care success)
      Which means, currently it's not working as desired.
      (According to the upper code snippet)
          ex) running ./tracex7 with ext4 env.
          # Current Output
          sh: echo: I/O error
          failed to open event open_ctree
          # Desired Output
          failed to create kprobe 'open_ctree' error 'No such file or directory'
      The problem is, error can't be verified whether from child ps
      or system. But using write() directly can verify the command
      failure, and it will treat all error as -1. So I suggest using
      write() directly to 'kprobe_events' rather than calling system().
      Signed-off-by: Daniel T. Lee's avatarDaniel T. Lee <[email protected]>
      Signed-off-by: default avatarDaniel Borkmann <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>
    • Martin Blumenstingl's avatar
      clk: meson: meson8b: fix incorrect divider mapping in cpu_scale_table · 857420d3
      Martin Blumenstingl authored
      [ Upstream commit ad9b2b8e ]
      The public S805 datasheet only mentions that
      HHI_SYS_CPU_CLK_CNTL1[20:29] contains a divider called "cpu_scale_div".
      Unfortunately it does not mention how to use the register contents.
      The Amlogic 3.10 GPL kernel sources are using the following code to
      calculate the CPU clock based on that register (taken from
      arch/arm/mach-meson8/clock.c in the 3.10 Amlogic kernel, shortened to
      make it easier to read):
      N = (aml_read_reg32(P_HHI_SYS_CPU_CLK_CNTL1) >> 20) & 0x3FF;
      if (sel == 3) /* use cpu_scale_div */
        div = 2 * N;
        div = ... /* not relevant for this example */
      cpu_clk = parent_clk / div;
      This suggests that the formula is: parent_rate / 2 * register_value
      However, running perf (which can measure the CPU clock rate thanks to
      the ARM PMU) shows that this formula is not correct.
      This can be reproduced with the following steps:
      1. boot into u-boot
      2. let the CPU clock run off the XTAL clock:
         mw.l 0xC110419C 0x30 1
      3. set the cpu_scale_div register:
         to value 0x1: mw.l 0xC110415C 0x801016A2 1
         to value 0x2: mw.l 0xC110415C 0x802016A2 1
         to value 0x5: mw.l 0xC110415C 0x805016A2 1
      4. let the CPU clock run off cpu_scale_div:
         mw.l 0xC110419C 0xbd 1
      5. boot Linux
      6. run: perf stat -aB stress --cpu 4 --timeout 10
      7. check the "cycles" value
      I get the following results depending on the cpu_scale_div value:
      - (cpu_in_sel - this is the input clock for cpu_scale_div - runs at
      - 0x1 = 300MHz
      - 0x2 = 200MHz
      - 0x5 = 100MHz
      This means that the actual formula to calculate the output of the
      cpu_scale_div clock is: parent_rate / 2 * (register value + 1).
      The register value 0x0 is reserved. When letting the CPU clock run off
      the cpu_scale_div while the value is 0x0 the whole board hangs (even in
      I also verified this with the TWD timer: when adding this to the .dts
      without specifying it's clock it will auto-detect the PERIPH (which is
      the input clock of the TWD) clock rate (and the result is shown in the
      kernel log). On Meson8, Meson8b and Meson8m2 the PERIPH clock is CPUCLK
      divided by 4. This also matched for all three test-cases from above (in
      all cases the TWD timer clock rate was approx. one fourth of the CPU
      clock rate).
      A small note regarding the "fixes" tag: the original issue seems to
      exist virtually since forever. Even commit 28b9fcd0 ("clk:
      meson8b: Add support for Meson8b clocks") seems to handle this wrong. I
      still decided to use commit 251b6fd3 ("clk: meson: rework meson8b
      cpu clock") because this is the first commit which gets the CPU hiearchy
      correct and thus it's the first commit where the cpu_scale_div register
      is used correctly (apart from the bug in the cpu_scale_table).
      Fixes: 251b6fd3 ("clk: meson: rework meson8b cpu clock")
      Signed-off-by: default avatarMartin Blumenstingl <[email protected]>
      Signed-off-by: Neil Armstrong's avatarNeil Armstrong <[email protected]>
      Link: https://lkml.kernel.org/r/[email protected]Signed-off-by: default avatarSasha Levin <[email protected]>
    • Martin Blumenstingl's avatar
      clk: meson: meson8b: add support for more M/N values in sys_pll · 92941af1
      Martin Blumenstingl authored
      [ Upstream commit e36c7e98 ]
      The sys_pll on the EC-100 board is configured to 1584MHz at boot
      (either by u-boot, firmware or chip defaults). This is achieved by using
      M = 66, N = 1 (24MHz * 66 / 1).
      At boot the CPU clock is running off sys_pll divided by 2 which results
      in 792MHz. Thus M = 66 is considered to be a "safe" value for Meson8b.
      To achieve 1608MHz (one of the CPU OPPs on Meson8 and Meson8m2) we need
      M = 67, N = 1. I ran "stress --cpu 4" while infinitely cycling through
      all available frequencies on my Meson8m2 board and could not spot any
      issues with this setting (after ~12 hours of running this).
      On Meson8, Meson8b and Meson8m2 we also want to be able to use 408MHz
      and 816MHz CPU frequencies. These can be achieved by dividing sys_pll by
      4 (for 408MHz) or 2 (for 816MHz). That means that sys_pll has to run at
      1632MHz which can be generated using M = 68, N = 1.
      Similarily we also want to be able to use 1008MHz as CPU frequency. This
      means that sys_pll has to run either at 1008MHz or 2016MHz. The former
      would result in an M value of 42, which is lower than the smallest value
      used by the 3.10 GPL kernel sources from Amlogic (50 is the lower limit
      there). Thus we need to run sys_pll at 2016MHz which can ge generated
      using M = 84, N = 1.
      I tested M = 68 and M = 84 on my Meson8b Odroid-C1 and my Meson8m2 board
      by running "stress --cpu 4" while infinitely cycling thorugh all
      available frequencies. I could not spot any issues after ~12 hours of
      running this.
      Amlogic's 3.10 GPL kernel sources have more M/N combinations. I did not
      add them yet because M = 74 (to achieve close to 1800MHz on Meson8) and
      M = 82 (to achieve close to 1992MHz on Meson8 as well) caused my
      Meson8m2 board to hang randomly. It's not clear why this is (for example
      because the board's voltage regulator design is bad, some missing bits
      for these values in our clk-pll driver, etc.). Thus the following M
      values from the Amlogic 3.10 GPL kernel sources are skipped as of now:
      69, 70, 71, 72, 73, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98
      Signed-off-by: default avatarMartin Blumenstingl <[email protected]>
      Acked-by: Jerome Brunet's avatarJerome Brunet <[email protected]>
      Signed-off-by: Neil Armstrong's avatarNeil Armstrong <[email protected]>
      Link: https://lkml.kernel.org/r/[email protected]Signed-off-by: default avatarSasha Levin <[email protected]>
    • Ville Syrjälä's avatar
      drm/atomic-helper: Complete fake_commit->flip_done potentially earlier · 6927bff4
      Ville Syrjälä authored
      [ Upstream commit 2de42f79 ]
      Consider the following scenario:
      1. nonblocking enable crtc
      2. wait for the event
      3. nonblocking disable crtc
      On i915 this can lead to a spurious -EBUSY from step 3 on
      account of non-enabled planes getting the fake_commit in step 1
      and we don't complete the fake_commit-> flip_done until
      drm_atomic_helper_commit_hw_done() which can happen a long
      time after the flip event was sent out.
      This will become somewhat easy to hit on SKL+ once we start
      to add all the planes for the crtc to every modeset commit
      for the purposes of forcing a watermark register programming
      To make the race a little less pronounced let's complete
      fake_commit->flip_done after drm_atomic_helper_wait_for_flip_done().
      For the single crtc case this should make the race quite
      theoretical, assuming drm_atomic_helper_wait_for_flip_done()
      actually has to wait for the real commit flip_done. In case
      the real commit flip_done gets completed singificantly before
      drm_atomic_helper_wait_for_flip_done(), or we are dealing with
      multiple crtcs whose vblanks don't line up nicely the race still
      [1] https://patchwork.freedesktop.org/patch/262670/
      Cc: Maarten Lankhorst <[email protected]>
      Fixes: 080de2e5 ("drm/atomic: Check for busy planes/connectors before setting the commit")
      Testcase: igt/kms_cursor_legacy/*nonblocking-modeset-vs-cursor-atomic
      Signed-off-by: default avatarVille Syrjälä <[email protected]>
      Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]Reviewed-by: default avatarMaarten Lankhorst <[email protected]>
      Signed-off-by: default avatarSasha Levin <[email protected]>