1. 25 Nov, 2021 10 commits
  2. 23 Nov, 2021 1 commit
  3. 19 Nov, 2021 4 commits
  4. 18 Nov, 2021 1 commit
  5. 17 Nov, 2021 7 commits
  6. 16 Nov, 2021 8 commits
    • Andrii Nakryiko's avatar
      selftests/bpf: Add uprobe triggering overhead benchmarks · d41bc48b
      Andrii Nakryiko authored
      Add benchmark to measure overhead of uprobes and uretprobes. Also have
      a baseline (no uprobe attached) benchmark.
      
      On my dev machine, baseline benchmark can trigger 130M user_target()
      invocations. When uprobe is attached, this falls to just 700K. With
      uretprobe, we get down to 520K:
      
        $ sudo ./bench trig-uprobe-base -a
        Summary: hits  131.289 ± 2.872M/s
      
        # UPROBE
        $ sudo ./bench -a trig-uprobe-without-nop
        Summary: hits    0.729 ± 0.007M/s
      
        $ sudo ./bench -a trig-uprobe-with-nop
        Summary: hits    1.798 ± 0.017M/s
      
        # URETPROBE
        $ sudo ./bench -a trig-uretprobe-without-nop
        Summary: hits    0.508 ± 0.012M/s
      
        $ sudo ./bench -a trig-uretprobe-with-nop
        Summary: hits    0.883 ± 0.008M/s
      
      So there is almost 2.5x performance difference between probing nop vs
      non-nop instruction for entry uprobe. And 1.7x difference for uretprobe.
      
      This means that non-nop uprobe overhead is around 1.4 microseconds for uprobe
      and 2 microseconds for non-nop uretprobe.
      
      For nop variants, uprobe and uretprobe overhead is down to 0.556 and
      1.13 microseconds, respectively.
      
      For comparison, just doing a very low-overhead syscall (with no BPF
      programs attached anywhere) gives:
      
        $ sudo ./bench trig-base -a
        Summary: hits    4.830 ± 0.036M/s
      
      So uprobes are about 2.67x slower than pure context switch.
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20211116013041.4072571-1-andrii@kernel.org
      d41bc48b
    • Tiezhu Yang's avatar
      bpf: Change value of MAX_TAIL_CALL_CNT from 32 to 33 · ebf7f6f0
      Tiezhu Yang authored
      In the current code, the actual max tail call count is 33 which is greater
      than MAX_TAIL_CALL_CNT (defined as 32). The actual limit is not consistent
      with the meaning of MAX_TAIL_CALL_CNT and thus confusing at first glance.
      We can see the historical evolution from commit 04fd61ab ("bpf: allow
      bpf programs to tail-call other bpf programs") and commit f9dabe01
      ("bpf: Undo off-by-one in interpreter tail call count limit"). In order
      to avoid changing existing behavior, the actual limit is 33 now, this is
      reasonable.
      
      After commit 874be05f ("bpf, tests: Add tail call test suite"), we can
      see there exists failed testcase.
      
      On all archs when CONFIG_BPF_JIT_ALWAYS_ON is not set:
       # echo 0 > /proc/sys/net/core/bpf_jit_enable
       # modprobe test_bpf
       # dmesg | grep -w FAIL
       Tail call error path, max count reached jited:0 ret 34 != 33 FAIL
      
      On some archs:
       # echo 1 > /proc/sys/net/core/bpf_jit_enable
       # modprobe test_bpf
       # dmesg | grep -w FAIL
       Tail call error path, max count reached jited:1 ret 34 != 33 FAIL
      
      Although the above failed testcase has been fixed in commit 18935a72
      ("bpf/tests: Fix error in tail call limit tests"), it would still be good
      to change the value of MAX_TAIL_CALL_CNT from 32 to 33 to make the code
      more readable.
      
      The 32-bit x86 JIT was using a limit of 32, just fix the wrong comments and
      limit to 33 tail calls as the constant MAX_TAIL_CALL_CNT updated. For the
      mips64 JIT, use "ori" instead of "addiu" as suggested by Johan Almbladh.
      For the riscv JIT, use RV_REG_TCC directly to save one register move as
      suggested by Björn Töpel. For the other implementations, no function changes,
      it does not change the current limit 33, the new value of MAX_TAIL_CALL_CNT
      can reflect the actual max tail call count, the related tail call testcases
      in test_bpf module and selftests can work well for the interpreter and the
      JIT.
      
      Here are the test results on x86_64:
      
       # uname -m
       x86_64
       # echo 0 > /proc/sys/net/core/bpf_jit_enable
       # modprobe test_bpf test_suite=test_tail_calls
       # dmesg | tail -1
       test_bpf: test_tail_calls: Summary: 8 PASSED, 0 FAILED, [0/8 JIT'ed]
       # rmmod test_bpf
       # echo 1 > /proc/sys/net/core/bpf_jit_enable
       # modprobe test_bpf test_suite=test_tail_calls
       # dmesg | tail -1
       test_bpf: test_tail_calls: Summary: 8 PASSED, 0 FAILED, [8/8 JIT'ed]
       # rmmod test_bpf
       # ./test_progs -t tailcalls
       #142 tailcalls:OK
       Summary: 1/11 PASSED, 0 SKIPPED, 0 FAILED
      Signed-off-by: default avatarTiezhu Yang <yangtiezhu@loongson.cn>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Tested-by: default avatarJohan Almbladh <johan.almbladh@anyfinetworks.com>
      Tested-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Acked-by: default avatarBjörn Töpel <bjorn@kernel.org>
      Acked-by: default avatarJohan Almbladh <johan.almbladh@anyfinetworks.com>
      Acked-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Link: https://lore.kernel.org/bpf/1636075800-3264-1-git-send-email-yangtiezhu@loongson.cn
      ebf7f6f0
    • Quentin Monnet's avatar
      selftests/bpf: Configure dir paths via env in test_bpftool_synctypes.py · e12cd158
      Quentin Monnet authored
      Script test_bpftool_synctypes.py parses a number of files in the bpftool
      directory (or even elsewhere in the repo) to make sure that the list of
      types or options in those different files are consistent. Instead of
      having fixed paths, let's make the directories configurable through
      environment variable. This should make easier in the future to run the
      script in a different setup, for example on an out-of-tree bpftool
      mirror with a different layout.
      Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20211115225844.33943-4-quentin@isovalent.com
      e12cd158
    • Quentin Monnet's avatar
      bpftool: Update doc (use susbtitutions) and test_bpftool_synctypes.py · b6231815
      Quentin Monnet authored
      test_bpftool_synctypes.py helps detecting inconsistencies in bpftool
      between the different list of types and options scattered in the
      sources, the documentation, and the bash completion. For options that
      apply to all bpftool commands, the script had a hardcoded list of
      values, and would use them to check whether the man pages are
      up-to-date. When writing the script, it felt acceptable to have this
      list in order to avoid to open and parse bpftool's main.h every time,
      and because the list of global options in bpftool doesn't change so
      often.
      
      However, this is prone to omissions, and we recently added a new
      -l|--legacy option which was described in common_options.rst, but not
      listed in the options summary of each manual page. The script did not
      complain, because it keeps comparing the hardcoded list to the (now)
      outdated list in the header file.
      
      To address the issue, this commit brings the following changes:
      
      - Options that are common to all bpftool commands (--json, --pretty, and
        --debug) are moved to a dedicated file, and used in the definition of
        a RST substitution. This substitution is used in the sources of all
        the man pages.
      
      - This list of common options is updated, with the addition of the new
        -l|--legacy option.
      
      - The script test_bpftool_synctypes.py is updated to compare:
          - Options specific to a command, found in C files, for the
            interactive help messages, with the same specific options from the
            relevant man page for that command.
          - Common options, checked just once: the list in main.h is
            compared with the new list in substitutions.rst.
      Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20211115225844.33943-3-quentin@isovalent.com
      b6231815
    • Quentin Monnet's avatar
      bpftool: Add SPDX tags to RST documentation files · 43448428
      Quentin Monnet authored
      Most files in the kernel repository have a SPDX tags. The files that
      don't have such a tag (or another license boilerplate) tend to fall
      under the GPL-2.0 license. In the past, bpftool's Makefile (for example)
      has been marked as GPL-2.0 for that reason, when in fact all bpftool is
      dual-licensed.
      
      To prevent a similar confusion from happening with the RST documentation
      files for bpftool, let's explicitly mark all files as dual-licensed.
      Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20211115225844.33943-2-quentin@isovalent.com
      43448428
    • Yonghong Song's avatar
      selftests/bpf: Add a dedup selftest with equivalent structure types · 47461583
      Yonghong Song authored
      Without previous libbpf patch, the following error will occur:
      
        $ ./test_progs -t btf
        ...
        do_test_dedup:FAIL:check btf_dedup failed errno:-22#13/205 btf/dedup: btf_type_tag #5, struct:FAIL
      
      And the previous libbpf patch fixed the issue.
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20211115163943.3922547-1-yhs@fb.com
      47461583
    • Yonghong Song's avatar
      libbpf: Fix a couple of missed btf_type_tag handling in btf.c · 69a055d5
      Yonghong Song authored
      Commit 2dc1e488 ("libbpf: Support BTF_KIND_TYPE_TAG") added the
      BTF_KIND_TYPE_TAG support. But to test vmlinux build with ...
      
        #define __user __attribute__((btf_type_tag("user")))
      
      ... I needed to sync libbpf repo and manually copy libbpf sources to
      pahole. To simplify process, I used BTF_KIND_RESTRICT to simulate the
      BTF_KIND_TYPE_TAG with vmlinux build as "restrict" modifier is barely
      used in kernel.
      
      But this approach missed one case in dedup with structures where
      BTF_KIND_RESTRICT is handled and BTF_KIND_TYPE_TAG is not handled in
      btf_dedup_is_equiv(), and this will result in a pahole dedup failure.
      This patch fixed this issue and a selftest is added in the subsequent
      patch to test this scenario.
      
      The other missed handling is in btf__resolve_size(). Currently the compiler
      always emit like PTR->TYPE_TAG->... so in practice we don't hit the missing
      BTF_KIND_TYPE_TAG handling issue with compiler generated code. But lets
      add case BTF_KIND_TYPE_TAG in the switch statement to be future proof.
      
      Fixes: 2dc1e488 ("libbpf: Support BTF_KIND_TYPE_TAG")
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20211115163937.3922235-1-yhs@fb.com
      69a055d5
    • Stanislav Fomichev's avatar
      bpftool: Add current libbpf_strict mode to version output · e47d0bf8
      Stanislav Fomichev authored
      + bpftool --legacy --version
      bpftool v5.15.0
      features: libbfd, skeletons
      + bpftool --version
      bpftool v5.15.0
      features: libbfd, libbpf_strict, skeletons
      
      + bpftool --legacy --help
      Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
             bpftool batch file FILE
             bpftool version
      
             OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
             OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
                          {-V|--version} }
      + bpftool --help
      Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
             bpftool batch file FILE
             bpftool version
      
             OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
             OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
                          {-V|--version} }
      
      + bpftool --legacy
      Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
             bpftool batch file FILE
             bpftool version
      
             OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
             OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
                          {-V|--version} }
      + bpftool
      Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
             bpftool batch file FILE
             bpftool version
      
             OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
             OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
                          {-V|--version} }
      
      + bpftool --legacy version
      bpftool v5.15.0
      features: libbfd, skeletons
      + bpftool version
      bpftool v5.15.0
      features: libbfd, libbpf_strict, skeletons
      
      + bpftool --json --legacy version
      {"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":false,"skeletons":true}}
      + bpftool --json version
      {"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":true,"skeletons":true}}
      Suggested-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Link: https://lore.kernel.org/bpf/20211116000448.2918854-1-sdf@google.com
      e47d0bf8
  7. 15 Nov, 2021 9 commits
    • Jakub Kicinski's avatar
      Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · a5bdc363
      Jakub Kicinski authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf-next 2021-11-15
      
      We've added 72 non-merge commits during the last 13 day(s) which contain
      a total of 171 files changed, 2728 insertions(+), 1143 deletions(-).
      
      The main changes are:
      
      1) Add btf_type_tag attributes to bring kernel annotations like __user/__rcu to
         BTF such that BPF verifier will be able to detect misuse, from Yonghong Song.
      
      2) Big batch of libbpf improvements including various fixes, future proofing APIs,
         and adding a unified, OPTS-based bpf_prog_load() low-level API, from Andrii Nakryiko.
      
      3) Add ingress_ifindex to BPF_SK_LOOKUP program type for selectively applying the
         programmable socket lookup logic to packets from a given netdev, from Mark Pashmfouroush.
      
      4) Remove the 128M upper JIT limit for BPF programs on arm64 and add selftest to
         ensure exception handling still works, from Russell King and Alan Maguire.
      
      5) Add a new bpf_find_vma() helper for tracing to map an address to the backing
         file such as shared library, from Song Liu.
      
      6) Batch of various misc fixes to bpftool, fixing a memory leak in BPF program dump,
         updating documentation and bash-completion among others, from Quentin Monnet.
      
      7) Deprecate libbpf bpf_program__get_prog_info_linear() API and migrate its users as
         the API is heavily tailored around perf and is non-generic, from Dave Marchevsky.
      
      8) Enable libbpf's strict mode by default in bpftool and add a --legacy option as an
         opt-out for more relaxed BPF program requirements, from Stanislav Fomichev.
      
      9) Fix bpftool to use libbpf_get_error() to check for errors, from Hengqi Chen.
      
      * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (72 commits)
        bpftool: Use libbpf_get_error() to check error
        bpftool: Fix mixed indentation in documentation
        bpftool: Update the lists of names for maps and prog-attach types
        bpftool: Fix indent in option lists in the documentation
        bpftool: Remove inclusion of utilities.mak from Makefiles
        bpftool: Fix memory leak in prog_dump()
        selftests/bpf: Fix a tautological-constant-out-of-range-compare compiler warning
        selftests/bpf: Fix an unused-but-set-variable compiler warning
        bpf: Introduce btf_tracing_ids
        bpf: Extend BTF_ID_LIST_GLOBAL with parameter for number of IDs
        bpftool: Enable libbpf's strict mode by default
        docs/bpf: Update documentation for BTF_KIND_TYPE_TAG support
        selftests/bpf: Clarify llvm dependency with btf_tag selftest
        selftests/bpf: Add a C test for btf_type_tag
        selftests/bpf: Rename progs/tag.c to progs/btf_decl_tag.c
        selftests/bpf: Test BTF_KIND_DECL_TAG for deduplication
        selftests/bpf: Add BTF_KIND_TYPE_TAG unit tests
        selftests/bpf: Test libbpf API function btf__add_type_tag()
        bpftool: Support BTF_KIND_TYPE_TAG
        libbpf: Support BTF_KIND_TYPE_TAG
        ...
      ====================
      
      Link: https://lore.kernel.org/r/20211115162008.25916-1-daniel@iogearbox.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a5bdc363
    • Jakub Kicinski's avatar
      Revert "Merge branch 'mctp-i2c-driver'" · 2f6a470d
      Jakub Kicinski authored
      This reverts commit 71812af7, reversing
      changes made to cc0be1ad.
      
      Wolfram Sang says:
      
      Please revert. Besides the driver in net, it modifies the I2C core
      code. This has not been acked by the I2C maintainer (in this case me).
      So, please don't pull this in via the net tree. The question raised here
      (extending SMBus calls to 255 byte) is complicated because we need ABI
      backwards compatibility.
      
      Link: https://lore.kernel.org/all/YZJ9H4eM%2FM7OXVN0@shikoro/Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2f6a470d
    • David S. Miller's avatar
      Merge branch 'generic-phylink-validation' · 6d3b1b06
      David S. Miller authored
      Russell King says:
      
      ====================
      introduce generic phylink validation
      
      The various validate method implementations we have in phylink users
      have been quite repetitive but also prone to bugs. These patches
      introduce a generic implementation which relies solely on the
      supported_interfaces bitmap introduced during last cycle, and in the
      first patch, a bit array of MAC capabilities.
      
      MAC drivers are free to continue to do their own thing if they have
      special requirements - such as mvneta and mvpp2 which do not support
      1000base-X without AN enabled. Most implementations currently in the
      kernel can be converted to call phylink_generic_validate() directly
      from the phylink MAC operations structure once they fill in the
      supported_interfaces and mac_capabilities members of phylink_config.
      
      This series introduces the generic implementation, and converts mvneta
      and mvpp2 to use it.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6d3b1b06
    • Russell King (Oracle)'s avatar
      net: mvpp2: use phylink_generic_validate() · 5038ffea
      Russell King (Oracle) authored
      Convert mvpp2 to use phylink_generic_validate() for the bulk of its
      validate() implementation. This network adapter has a restriction
      that for 802.3z links, autonegotiation must be enabled.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5038ffea
    • Russell King (Oracle)'s avatar
      net: mvneta: use phylink_generic_validate() · 02a0988b
      Russell King (Oracle) authored
      Convert mvneta to use phylink_generic_validate() for the bulk of its
      validate() implementation. This network adapter has a restriction
      that for 802.3z links, autonegotiation must be enabled.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      02a0988b
    • Russell King (Oracle)'s avatar
      net: phylink: add generic validate implementation · 34ae2c09
      Russell King (Oracle) authored
      Add a generic validate() implementation using the supported_interfaces
      and a bitmask of MAC pause/speed/duplex capabilities. This allows us
      to entirely eliminate many driver private validate() implementations.
      
      We expose the underlying phylink_get_linkmodes() function so that
      drivers which have special needs can still benefit from conversion.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34ae2c09
    • Christophe Leroy's avatar
      net/wan/fsl_ucc_hdlc: fix sparse warnings · 5cf46d8e
      Christophe Leroy authored
      CHECK   drivers/net/wan/fsl_ucc_hdlc.c
      drivers/net/wan/fsl_ucc_hdlc.c:309:57: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:309:57:    expected void [noderef] __iomem *
      drivers/net/wan/fsl_ucc_hdlc.c:309:57:    got restricted __be16 *
      drivers/net/wan/fsl_ucc_hdlc.c:311:46: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:311:46:    expected void [noderef] __iomem *
      drivers/net/wan/fsl_ucc_hdlc.c:311:46:    got restricted __be32 *
      drivers/net/wan/fsl_ucc_hdlc.c:320:57: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:320:57:    expected void [noderef] __iomem *
      drivers/net/wan/fsl_ucc_hdlc.c:320:57:    got restricted __be16 *
      drivers/net/wan/fsl_ucc_hdlc.c:322:46: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:322:46:    expected void [noderef] __iomem *
      drivers/net/wan/fsl_ucc_hdlc.c:322:46:    got restricted __be32 *
      drivers/net/wan/fsl_ucc_hdlc.c:372:29: warning: incorrect type in assignment (different base types)
      drivers/net/wan/fsl_ucc_hdlc.c:372:29:    expected unsigned short [usertype]
      drivers/net/wan/fsl_ucc_hdlc.c:372:29:    got restricted __be16 [usertype]
      drivers/net/wan/fsl_ucc_hdlc.c:379:36: warning: restricted __be16 degrades to integer
      drivers/net/wan/fsl_ucc_hdlc.c:402:12: warning: incorrect type in assignment (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:402:12:    expected struct qe_bd [noderef] __iomem *bd
      drivers/net/wan/fsl_ucc_hdlc.c:402:12:    got struct qe_bd *curtx_bd
      drivers/net/wan/fsl_ucc_hdlc.c:425:20: warning: incorrect type in assignment (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:425:20:    expected struct qe_bd [noderef] __iomem *[assigned] bd
      drivers/net/wan/fsl_ucc_hdlc.c:425:20:    got struct qe_bd *tx_bd_base
      drivers/net/wan/fsl_ucc_hdlc.c:427:16: error: incompatible types in comparison expression (different address spaces):
      drivers/net/wan/fsl_ucc_hdlc.c:427:16:    struct qe_bd [noderef] __iomem *
      drivers/net/wan/fsl_ucc_hdlc.c:427:16:    struct qe_bd *
      drivers/net/wan/fsl_ucc_hdlc.c:462:33: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:506:41: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:528:33: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:552:38: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:596:67: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:611:41: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:851:38: warning: incorrect type in initializer (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:854:40: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:855:40: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:858:39: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:861:37: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:866:38: warning: incorrect type in initializer (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:868:21: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:870:40: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:871:40: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:873:39: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:993:57: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:995:46: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:1004:57: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:1006:46: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef expression
      drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef expression
      drivers/net/wan/fsl_ucc_hdlc.c:724:29: warning: dereference of noderef expression
      drivers/net/wan/fsl_ucc_hdlc.c:815:21: warning: dereference of noderef expression
      drivers/net/wan/fsl_ucc_hdlc.c:1021:29: warning: dereference of noderef expression
      
      Most of the warnings are due to DMA memory being incorrectly handled as IO memory.
      Fix it by doing direct read/write and doing proper dma_rmb() / dma_wmb().
      
      Other problems are type mismatches or lack of use of IO accessors.
      
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Link: https://lkml.org/lkml/2021/11/12/647Signed-off-by: default avatarChristophe Leroy <christophe.leroy@csgroup.eu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5cf46d8e
    • Yihao Han's avatar
      net: fddi: use swap() to make code cleaner · 311107bd
      Yihao Han authored
      Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid
      opencoding it.
      Signed-off-by: default avatarYihao Han <hanyihao@vivo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      311107bd
    • Guo Zhengkui's avatar
      hinic: use ARRAY_SIZE instead of ARRAY_LEN · 9ed94117
      Guo Zhengkui authored
      ARRAY_SIZE defined in <linux/kernel.h> is safer than self-defined
      macros to get size of an array such as ARRAY_LEN used here. Because
      ARRAY_SIZE uses __must_be_array(arr) to ensure arr is really an array.
      Reported-by: default avatarAlejandro Colomar <colomar.6.4.3@gmail.com>
      Signed-off-by: default avatarGuo Zhengkui <guozhengkui@vivo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ed94117